Quy trình phát triển phần mềm SDLC: Tester cần hiểu gì từ đầu
6 tháng trước · 13 phút đọc
SDLC là gì và tại sao tester cần biết?
Mình nhớ hồi mới vào nghề, mình chỉ biết nhận task test rồi... test. Không biết feature đó từ đâu ra, ai quyết định nó hoạt động thế nào, và khi bug bị reject thì phải hỏi ai. Sau 2 tuần loay hoay, senior mới ngồi giải thích: "Em cần hiểu SDLC trước."
SDLC - viết tắt của Software Development Life Cycle (vòng đời phát triển phần mềm) - là quy trình từ lúc một phần mềm được lên ý tưởng cho đến khi release và bảo trì. Nó không chỉ là chuyện của dev hay PM. Tester tham gia hầu hết các giai đoạn, dù nhiều fresher không biết điều này.
Tại sao quan trọng? Hiểu SDLC giúp bạn:
- Biết mình cần làm gì ở từng thời điểm trong dự án
- Đọc requirement không còn bị "đọc mà không hiểu đọc để làm gì"
- Trao đổi với dev và BA bằng cùng ngôn ngữ
- Phát hiện lỗi từ sớm - trước cả khi code được viết
Biết mình đứng ở đâu trong quy trình giúp tester tự tin hơn rất nhiều
Một con số đáng suy nghĩ: Chi phí sửa lỗi sau khi release tốn gấp nhiều lần so với phát hiện ngay trong giai đoạn requirements - đây là số liệu được nhiều nghiên cứu phần mềm xác nhận. Nghĩa là việc bắt đầu test từ sớm trong SDLC không phải "làm màu" - mà là tiết kiệm tiền thật sự cho dự án.
6 giai đoạn SDLC và tester xuất hiện ở đâu
Phần lớn dự án phần mềm tại Việt Nam - dù chạy Agile hay Waterfall - đều đi qua các giai đoạn cốt lõi này. Tester không chỉ ngồi đợi đến giai đoạn 5 mới làm việc.
Tester tham gia sớm hơn nhiều người nghĩ - không phải chỉ lúc có build để test
Giai đoạn 1: Lập kế hoạch (Planning)
PM, BA và khách hàng ngồi xác định: làm cái gì, làm cho ai, trong bao lâu, chi phí bao nhiêu. Tester thường chưa tham gia trực tiếp ở đây, nhưng nếu có - bạn có thể đóng góp về risk assessment: tính năng nào khó test, cần bao nhiêu thời gian test.
Giai đoạn 2: Phân tích yêu cầu (Requirements Analysis)
Đây là giai đoạn BA viết tài liệu yêu cầu (requirement document). Tester nên tham gia review tài liệu này. Tại sao? Vì bạn sẽ phát hiện những chỗ mơ hồ mà cả BA lẫn dev không để ý.
Ví dụ thực tế: Mình từng review requirement cho tính năng "giới hạn số lần nhập sai OTP" của một app ngân hàng tại VN. Requirement ghi "khóa sau 3 lần sai" nhưng không nói: khóa trong bao lâu? Khóa tài khoản hay khóa thiết bị? Reset counter sau bao lâu? Bốn câu hỏi đó tránh được 4 bug tiềm năng.
Giai đoạn 3: Thiết kế (Design)
Dev và architect thiết kế cấu trúc hệ thống, database, UI/UX. Tester bắt đầu viết test plan và phác thảo test case dựa trên design document. Không cần đợi có code mới bắt đầu.
Giai đoạn 4: Lập trình (Development/Coding)
Dev viết code. Tester song song hoàn thiện test case và chuẩn bị môi trường test. Đây là lúc bạn nên hỏi dev về edge case kỹ thuật - những trường hợp nào dễ bị lỗi về logic.
Giai đoạn 5: Kiểm thử (Testing)
Build được chuyển sang cho tester. Đây là giai đoạn tập trung nhất của bạn: chạy test case, báo bug, verify fix, regression test. Bài sau mình sẽ đi chi tiết từng loại testing ở đây.
Giai đoạn 6: Triển khai và bảo trì (Deployment & Maintenance)
Phần mềm lên production. Tester thường chạy smoke testing (kiểm tra nhanh các tính năng chính sau deploy) để xác nhận không có gì bị hỏng. Giai đoạn bảo trì - khi có bug từ user report hoặc tính năng mới - thì vòng SDLC lại bắt đầu.
Tester đọc requirement như thế nào cho đúng
Nhận được tài liệu yêu cầu lần đầu, phần lớn fresher làm một trong hai việc: đọc lướt qua rồi bắt tay viết test case ngay, hoặc đọc xong... không biết bắt đầu từ đâu. Cả hai đều dễ bỏ sót bug quan trọng.
Mình có một quy trình đọc requirement mà mình áp dụng từ năm thứ hai, và nó thực sự hiệu quả.
Đọc requirement đúng cách tiết kiệm được cả ngày fix bug sau này
Bước 1: Đọc toàn bộ một lần, không ghi chú
Đọc để nắm bức tranh tổng thể. Tính năng này làm gì? Ai dùng? Kết quả mong đợi là gì?
Bước 2: Đọc lại, đặt câu hỏi W-H
Mỗi đoạn requirement, tự hỏi:
- What: cụ thể tính năng làm cái gì?
- Who: người dùng nào trigger tính năng này?
- When: điều kiện nào kích hoạt?
- What if: nếu user làm sai thì sao?
Bước 3: Đánh dấu điểm mơ hồ
Bất kỳ chỗ nào bạn thấy từ như "nhanh", "dễ dùng", "phù hợp", "thông thường" - đánh dấu hỏi. Những từ này không đo lường được, tức là không test được.
Ví dụ: Requirement ghi "hệ thống phải phản hồi nhanh". Bạn cần hỏi: nhanh là bao nhiêu giây? Trên mạng 4G hay Wifi? Khi 100 user hay 10.000 user đồng thời?
Bước 4: Liệt kê test scenario trước khi viết test case
Từ requirement, viết ra tất cả scenario có thể xảy ra: happy path (đúng hết), negative case (sai input), edge case (biên giới). Sau đó mới viết test case chi tiết.
Bạn có thể tải checklist này để dùng ngay khi đọc requirement lần đầu: Tải checklist đọc requirement cho fresher
Ví dụ thực tế: Dự án quản lý đơn hàng tại Việt Nam
Lý thuyết SDLC đọc mãi cũng trừu tượng. Mình lấy ví dụ từ một dự án khá phổ biến ở VN: hệ thống quản lý đơn hàng cho chuỗi cửa hàng bán lẻ, kiểu như app nội bộ của shop quần áo hoặc cửa hàng điện thoại.
Tester trong dự án thực tế tham gia nhiều giai đoạn hơn mô tả trên giấy
Planning: PM và khách hàng xác định cần module: tạo đơn, cập nhật trạng thái, báo cáo doanh thu. Tester chưa vào, nhưng nếu được mời review risk - bạn có thể note: "Module báo cáo doanh thu cần test kỹ phép tính, dễ sai với số lớn".
Requirements: BA viết tài liệu. Tester review và phát hiện: requirement ghi "cập nhật trạng thái đơn hàng" nhưng không liệt kê hết trạng thái (Mới → Xác nhận → Đang giao → Hoàn thành → Hủy). Bạn hỏi thêm: trạng thái nào được phép chuyển sang trạng thái nào? Có thể hủy đơn đang giao không? Ai có quyền hủy?
Design: Designer làm UI, dev làm database schema. Tester viết test plan: sẽ test manual trước, automation sau. Phân loại test case theo module.
Development: Dev code 3 tuần. Tester hoàn thiện 80 test case, chia thành: 30 happy path, 35 negative case, 15 edge case. Trong đó edge case đặc thù VN: tên khách hàng có dấu tiếng Việt (Nguyễn Thị Ánh), địa chỉ giao hàng có ký tự đặc biệt, số điện thoại 10 số vs 11 số cũ.
Testing: Build đầu tiên nhận được, mình chạy smoke testing - kiểm tra nhanh 10 tính năng chính có chạy được không. 3 cái fail ngay, báo dev fix trước khi chạy full. Sau đó mới chạy hết 80 test case. Tìm được 12 bug, trong đó có 2 bug quan trọng: giỏ hàng tính sai tổng tiền khi có khuyến mãi, và filter báo cáo theo ngày bị lệch múi giờ UTC+7.
Deployment: App lên server staging, chạy smoke test lần nữa. Xác nhận OK, PM deploy production. Sau 2 ngày có 1 user report bug nhỏ - back to testing.
Cái bug múi giờ đó, nếu không có tester hỏi "hệ thống dùng múi giờ nào?" trong lúc review requirement thì không ai nghĩ đến.
Agile SDLC - phiên bản phổ biến nhất tại dự án VN hiện nay
Nhiều bạn fresher học SDLC theo dạng Waterfall (tuần tự, giai đoạn sau xong mới bắt đầu giai đoạn kế), nhưng thực tế phần lớn công ty phần mềm tại Việt Nam đang chạy Agile hoặc một biến thể của nó. Hiểu sự khác biệt là cần thiết.
Agile không bỏ qua các giai đoạn SDLC - chỉ lặp lại chúng nhanh hơn
Trong Agile, dự án được chia thành các sprint - thường 1-2 tuần/sprint. Mỗi sprint là một vòng SDLC thu nhỏ: lên kế hoạch → dev → test → demo → review. Tester không đợi dev code xong cả dự án mới bắt đầu. Bạn test từng tính năng nhỏ, sprint này qua sprint khác.
Điều này có nghĩa gì với tester fresher?
Deadline test ngắn hơn nhiều. Nếu sprint 2 tuần, dev code xong thường vào ngày thứ 8-9, tester có 4-5 ngày. Không có chỗ cho việc viết test case từ đầu khi nhận build. Bạn phải chuẩn bị test case từ đầu sprint, song song với lúc dev đang code.
Cũng trong Agile, daily meeting (họp ngắn mỗi sáng 15 phút) là cơ hội để bạn cập nhật: hôm qua test được gì, hôm nay test gì, có bị block gì không. Tester cần biết nói ngắn gọn, đúng trọng tâm.
Một điểm nữa: trong Agile, definition of done (định nghĩa "xong") của một tính năng thường bao gồm cả "test passed". Nghĩa là dev không được đánh dấu task là done nếu tester chưa verify. Đây là lý do tester là một mắt xích thực sự trong team, không phải người ngồi "gác cổng" cuối cùng.
Nếu muốn hiểu sâu hơn về môi trường làm việc thực tế trong một team Agile - từ cách đọc requirement, viết test case đến báo bug - khóa Kiểm thử phần mềm cover khá kỹ phần này với các bài tập thực hành theo sprint thật.
Vị trí của tester trong team - đừng hiểu nhầm vai trò
Một quan niệm sai mình thấy rất phổ biến với fresher và người trái ngành: nghĩ rằng tester chỉ là người "bấm bấm" xem app chạy được không, và nếu có bug thì báo cho dev fix.
Thực ra không phải vậy.
Tester là cầu nối giữa yêu cầu nghiệp vụ và sản phẩm cuối - không chỉ là người kiểm tra cuối
Trong một team dev điển hình tại Việt Nam, tester làm việc trực tiếp với:
- BA (Business Analyst): để hiểu requirement, hỏi về logic nghiệp vụ
- Dev: để báo bug, discuss về edge case kỹ thuật, clarify behavior
- PM (Project Manager): để báo cáo tiến độ test, estimate thời gian
- Khách hàng/PO (Product Owner): đôi khi tham gia UAT - kiểm thử chấp nhận người dùng
Tester không phải "kẻ thù của dev". Đây là quan niệm sai nhất. Mục tiêu chung là phần mềm chất lượng. Khi bạn báo bug, bạn đang giúp dev không phải chịu trách nhiệm về lỗi đó sau này. Cái gọi là "conflict" giữa tester và dev thường đến từ cách giao tiếp, không phải bản chất vai trò.
Một điều mình hay nói với các bạn mới: tester là người đại diện cho user trong team. Bạn test không phải để "tìm lỗi cho vui" mà để đảm bảo người dùng thật sự không gặp phải điều đó. Khi bạn nghĩ theo hướng này, công việc có ý nghĩa hơn hẳn.
25, 28, hay 32 tuổi chuyển ngành sang tester đều được. Lớp mình từng có bạn từ ngành kế toán, bạn từ ngành luật. Điểm chung của những bạn làm tốt không phải là biết code, mà là tư duy tỉ mỉ và chịu đặt câu hỏi. Đó là thứ tester cần nhất.
Bài tiếp mình sẽ hướng dẫn cách viết test case đầu tiên cho tính năng đăng nhập - tính năng có ở hầu hết mọi app và là bài tập thực hành lý tưởng để bắt đầu. Bookmark lại nhé!
Nếu bạn muốn có lộ trình bài bản hơn từ zero đến có việc, khóa Kiểm thử phần mềm xây dựng theo đúng trình tự này - từ SDLC, đọc requirement, viết test case đến báo bug và interview. Đáng để xem qua.