Quy Trình Kiểm Thử Phần Mềm (STLC) Gồm Mấy Bước?

Quy trình kiểm thử phần mềm — theo chuẩn ISTQB CTFL v4.0 (mục 1.4) — gồm 7 nhóm hoạt động: (1) lập kế hoạch test, (2) giám sát & kiểm soát test, (3) phân tích test, (4) thiết kế test, (5) hiện thực test, (6) thực thi test, và (7) hoàn tất test. Cách gọi "STLC 6 bước" phổ biến ngoài thực tế chỉ là phiên bản gom nhóm lại cho dễ nhớ.

Dù bạn làm Manual Testing là gì hay automation, mọi hoạt động kiểm thử đều chạy theo khung này. 🙂 Trong bài, tôi đi qua từng hoạt động theo đúng ISTQB, kèm bảng ánh xạ sang cách gọi "6 bước" quen thuộc, tiêu chí entry/exit và cách quy trình vận hành khác đi trong Agile.

Quy trình kiểm thử (STLC) là gì?

STLC là vòng đời kiểm thử phần mềm — tập hợp các nhóm hoạt động kiểm thử mà đội test thực hiện để đảm bảo chất lượng sản phẩm. Mỗi hoạt động có mục tiêu, đầu vào, đầu ra (testware) và tiêu chí hoàn thành rõ ràng, nhờ vậy việc kiểm thử có thể lập kế hoạch, theo dõi và báo cáo được thay vì làm theo cảm tính.

Để hiểu cho đúng chuẩn: ISTQB không dùng từ "STLC" mà gọi đây là "test process" (quy trình kiểm thử), gồm 7 nhóm hoạt động liệt kê ở phần đầu bài. Syllabus cũng dẫn chiếu tiêu chuẩn ISO/IEC/IEEE 29119-2 cho ai muốn đào sâu. "STLC 6 bước" là cách diễn đạt phổ biến của ngành — không sai, nhưng nó gom một số hoạt động lại với nhau.

Và một điểm CTFL nhấn mạnh, đừng hiểu nhầm: các hoạt động này thường được thực hiện lặp lại hoặc song song, chứ không nhất thiết chạy tuần tự như dây chuyền. Ví dụ thiết kế và hiện thực test thường đan xen; còn giám sát & kiểm soát test diễn ra liên tục xuyên suốt cả quá trình.

Điểm cốt lõi cần nhớ: kiểm thử không phải là chạy test rồi báo lỗi cho xong. Phần lớn giá trị nằm ở các hoạt động trước khi chạy test — phân tích và thiết kế. Chuẩn bị càng kỹ, lúc thực thi càng nhàn và càng bắt được nhiều lỗi quan trọng.

STLC khác SDLC thế nào?

Nhiều bạn mới hay nhầm hai khái niệm này. Cách phân biệt đơn giản: SDLC bao trùm cả việc xây dựng phần mềm, còn quy trình kiểm thử chỉ là phần test nằm song hành bên trong SDLC.

Tiêu chí | SDLC (vòng đời phát triển) | STLC (quy trình kiểm thử)
Phạm vi | Toàn bộ quá trình tạo ra phần mềm | Riêng hoạt động kiểm thử
Mục tiêu | Xây dựng và bàn giao sản phẩm | Đảm bảo chất lượng, phát hiện lỗi
Bắt đầu từ | Thu thập yêu cầu nghiệp vụ | Lập kế hoạch & phân tích dưới góc nhìn test
Người thực hiện | BA, Dev, QA, PM… | Chủ yếu đội test/QA
Quan hệ | Khung lớn, bao trùm | Một phần chạy song song trong SDLC

Nói ngắn gọn: quy trình kiểm thử là "khúc test" trong SDLC được phóng to và làm cho bài bản. Nó bắt đầu sớm hơn nhiều người tưởng — ngay từ khi có yêu cầu, chứ không đợi đến lúc code xong.

7 hoạt động kiểm thử theo chuẩn ISTQB (CTFL v4.0)

Trước khi đi vào chi tiết, đây là bảng ánh xạ giữa cách gọi "6 bước STLC" phổ biến và 7 hoạt động chuẩn ISTQB — để bạn không bị rối khi đọc tài liệu khác nhau:

"6 bước STLC" phổ biến | Hoạt động tương ứng theo ISTQB CTFL v4.0
1. Phân tích yêu cầu | Test analysis (phân tích test)
2. Lập kế hoạch test | Test planning (lập kế hoạch) + Test monitoring & control (giám sát, chạy xuyên suốt)
3. Thiết kế test case | Test design (thiết kế) + một phần Test implementation
4. Chuẩn bị môi trường test | Nằm trong Test design (xác định yêu cầu) & Test implementation (dựng môi trường)
5. Thực thi test | Test execution (thực thi)
6. Đóng chu kỳ test | Test completion (hoàn tất)

Dưới đây là 7 hoạt động theo đúng ISTQB, mỗi hoạt động gồm: mục tiêu · việc làm · đầu ra (testware).

1. Lập kế hoạch test (Test Planning)

Mục tiêu: Xác định mục tiêu test và chọn cách tiếp cận phù hợp nhất trong các ràng buộc của dự án.

Việc làm: Xác định phạm vi, chiến lược test, ước lượng công sức, lịch trình, phân tích rủi ro, định nghĩa entry/exit criteria.

Đầu ra: Test plan, test schedule, risk register, entry & exit criteria (thường nằm trong test plan).

2. Giám sát & kiểm soát test (Test Monitoring & Control)

Mục tiêu: Liên tục đối chiếu tiến độ thực tế với kế hoạch và có hành động điều chỉnh khi cần.

Việc làm: Thu thập metrics, theo dõi tiến độ và chất lượng, ra quyết định điều chỉnh (control). Hoạt động này chạy xuyên suốt quy trình, không phải một "bước" riêng lẻ.

Đầu ra: Test progress report, các chỉ thị điều chỉnh, thông tin rủi ro cập nhật.

3. Phân tích test (Test Analysis)

Mục tiêu: Trả lời câu hỏi "test cái gì?" dựa trên test basis (yêu cầu, user story…).

Việc làm: Phân tích test basis để tìm tính năng cần test, xác định và ưu tiên các điều kiện test (test conditions) cùng rủi ro; đánh giá tính khả thi test (testability) của tài liệu.

Đầu ra: Danh sách test condition đã ưu tiên (ví dụ acceptance criteria), defect report cho lỗi phát hiện ngay trong tài liệu.

4. Thiết kế test (Test Design)

Mục tiêu: Trả lời câu hỏi "test như thế nào?" — biến test condition thành test case và testware cụ thể.

Việc làm: Triển khai test condition thành test case, xác định coverage item, áp dụng kỹ thuật test, đồng thời xác định yêu cầu test data và thiết kế môi trường test.

Đầu ra: Test case (đã ưu tiên), test charter, coverage item, yêu cầu test data và yêu cầu môi trường test.

5. Hiện thực test (Test Implementation)

Mục tiêu: Chuẩn bị đầy đủ mọi thứ để sẵn sàng thực thi test.

Việc làm: Tạo/thu thập testware, gom test case thành test procedure và test suite, viết script manual & automation, sắp xếp lịch thực thi, dựng và kiểm tra môi trường test.

Đầu ra: Test procedure, script tự động, test suite, test data, test execution schedule, các thành phần môi trường (stub, driver, mô phỏng…).

6. Thực thi test (Test Execution)

Mục tiêu: Chạy test theo lịch và ghi nhận kết quả.

Việc làm: Thực thi test (manual hoặc tự động), so sánh kết quả thực tế với mong đợi, log kết quả, phân tích anomaly để tìm nguyên nhân và báo lỗi.

Đầu ra: Test log, defect report. Xem thêm cách viết test case để bước này trơn tru.

7. Hoàn tất test (Test Completion)

Mục tiêu: Tổng kết, lưu giữ kinh nghiệm và testware cho tương lai.

Việc làm: Diễn ra ở các mốc (release, hết iteration, hoàn tất một test level): xử lý defect/CR còn tồn, lưu trữ testware, đóng môi trường về trạng thái thống nhất, rút bài học kinh nghiệm.

Đầu ra: Test completion report, action item cải tiến, tài liệu lessons learned, change request (ví dụ dưới dạng product backlog item).

Entry & Exit criteria — bắt đầu và kết thúc test khi nào?

Theo CTFL (mục 5.1.3), entry criteria là các điều kiện cần có để bắt đầu một hoạt động hay một test level (ví dụ: đã có testware, môi trường test và test data sẵn sàng). Exit criteria là các điều kiện cần đạt để chính thức tuyên bố hoàn thành (ví dụ: đạt độ phủ yêu cầu, số lỗi tồn đọng dưới ngưỡng, mức rủi ro còn lại chấp nhận được).

Điểm cần nhớ cho đúng chuẩn: entry/exit criteria không phải là cổng cứng tách rời từng "bước", mà là một phần của test approach nằm trong test plan, do người lập kế hoạch định nghĩa từ đầu. Bảng dưới minh họa cách áp dụng theo tư duy thực tế:

Mốc | Entry (bắt đầu khi…) | Exit (kết thúc khi…)
Phân tích & thiết kế | Có test basis (yêu cầu/user story) | Test condition & test case đã review xong
Hiện thực & môi trường | Test case đã có, cấu hình sẵn sàng | Môi trường dựng xong, smoke test pass
Thực thi test | Testware + môi trường sẵn sàng | Đạt exit criteria đã định (độ phủ, lỗi tồn)
Hoàn tất | Thực thi test hoàn tất | Có Test Completion Report & lessons learned

Quy trình kiểm thử trong Agile/Scrum

Trong mô hình truyền thống (Waterfall), các hoạt động test diễn ra tập trung và tài liệu khá dày. Khi vào Agile/Scrum, bản chất 7 hoạt động không mất đi — chúng được "nén" lại và lặp theo từng sprint:

Liên tục và lặp lại: Mỗi sprint là một vòng quy trình test thu nhỏ; test chạy song song với phát triển, không chờ code xong hết.

Tester đóng góp vào planning: Theo CTFL (5.1.2), tester tham gia ngay từ release/iteration planning — viết user story testable, góp ý acceptance criteria, ước lượng công sức test, phân tích rủi ro.

Shift-left mạnh: Tester vào cuộc sớm để bắt lỗi ngay từ tài liệu, thay vì chỉ test ở cuối.

Giám sát liên tục, hoàn tất theo mốc: Test monitoring & control diễn ra hằng ngày (daily); test completion gắn với mốc hết iteration hoặc release.

Tài liệu gọn hơn: Test plan nặng được thay bằng test strategy ngắn gọn; nhiều thông tin nằm trong công cụ thay vì văn bản dài.

Tóm lại, Agile không xóa bỏ quy trình kiểm thử — nó làm quy trình nhanh, gọn và liên tục hơn. Nắm vững 7 hoạt động gốc theo ISTQB vẫn là nền tảng để bạn linh hoạt trong mọi mô hình.