Các boundary value và edge case quan trọng đã được kiểm tra hết
Không còn test case nào fail hoặc đã có bug report tương ứng
Tất cả test đều chạy được độc lập và cho kết quả nhất quán
Chỉ test happy path
Bỏ qua edge case và invalid input khiến bug bị bỏ sót. Luôn tự hỏi "điều gì xảy ra nếu người dùng làm sai?"
Test phụ thuộc lẫn nhau
Test A phải chạy trước Test B mới đúng. Mỗi unit test phải độc lập hoàn toàn với test khác.
Viết test quá phức tạp
Test case khó hiểu hơn cả code đang test. Một test case chỉ nên kiểm tra đúng một điều.
Dùng dữ liệu thật (production data)
Rủi ro bảo mật và test không kiểm soát được. Luôn dùng dữ liệu giả định (mock data).
Integration Test
Cấp độ 2
Kiểm thử sự tương tác giữa các module, component hoặc service khi kết hợp với nhau
0 / 0 hoàn thành
Kiểm tra luồng dữ liệu đi đúng giữa các module khi chúng được kết hợp
Phát hiện lỗi về interface, API contract, và định dạng dữ liệu không khớp
Xác nhận kết nối database, external service, và third-party API hoạt động đúng
Đảm bảo các quy trình nghiệp vụ end-to-end cơ bản chạy được từ đầu đến cuối
Các module nào sẽ được tích hợp? Thứ tự tích hợp từng bước như thế nào?
API contract (định dạng request/response) đã được tài liệu hóa đầy đủ chưa?
Môi trường test integration đã có đủ các service, database cần thiết chưa?
Unit test của tất cả các module liên quan đã pass trước đó chưa?
Nếu external service chưa sẵn sàng, có stub/mock thay thế không?
Tất cả luồng nghiệp vụ quan trọng đã được kiểm tra từ đầu đến cuối
Mọi điểm tích hợp (API, DB, service) đều được test ít nhất một lần
Các kịch bản lỗi khi service phụ không khả dụng đã được kiểm tra
Không còn lỗi mức nghiêm trọng (critical/blocker) nào đang mở
Kết quả test được ghi chép và review với team lead/developer
Test tích hợp toàn bộ một lúc (Big Bang)
Khi lỗi xảy ra, không biết module nào gây ra. Hãy tích hợp và test từng cặp module một cách tuần tự.
Bỏ qua test khi unit test đã pass hết
Unit test pass không có nghĩa integration sẽ hoạt động. Lỗi interface chỉ xuất hiện khi kết hợp.
Không kiểm tra kịch bản lỗi mạng/timeout
Chỉ test khi mọi thứ hoạt động bình thường, bỏ qua trường hợp service chậm hoặc mất kết nối.
Không dọn dữ liệu sau mỗi test
Dữ liệu test cũ ảnh hưởng đến test mới, gây ra kết quả sai. Luôn setup và teardown dữ liệu rõ ràng.
System Test
Cấp độ 3
Kiểm thử toàn bộ hệ thống như một thể thống nhất, từ góc nhìn người dùng cuối
0 / 0 hoàn thành
Kiểm tra toàn bộ hệ thống hoàn chỉnh đáp ứng yêu cầu chức năng và phi chức năng
Đánh giá hiệu năng, bảo mật, khả năng sử dụng của toàn bộ hệ thống
Mô phỏng hành vi thực tế của người dùng cuối trong môi trường gần giống production
Phát hiện các lỗi chỉ xuất hiện ở cấp độ hệ thống, không thấy được ở cấp độ thấp hơn
Môi trường System Test có cấu hình gần giống production không (server, OS, cấu hình mạng)?
Tài liệu yêu cầu hệ thống (SRS) có đầy đủ để làm cơ sở kiểm tra không?
Integration Test đã pass hết chưa? Hệ thống đã ở trạng thái ổn định để test chưa?
Các tiêu chí nghiệm thu (exit criteria) cho System Test là gì? Bao nhiêu bug thì dừng?
Có test data đủ để mô phỏng khối lượng dữ liệu thực tế không?
Tất cả test case quan trọng (priority High/Critical) đã pass
Không còn bug mức Blocker hoặc Critical nào đang mở chưa fix
Các tiêu chí phi chức năng (thời gian phản hồi, bảo mật cơ bản) đã được verify
Regression test pass, không có tính năng cũ nào bị bể
Test summary report đã được viết và approve bởi Test Lead/QA Manager
Test trên môi trường không đúng
Test trên localhost nhưng production dùng server khác cấu hình. Kết quả sẽ không phản ánh thực tế.
Bỏ qua kiểm tra phi chức năng
Chỉ tập trung vào "chạy được chưa" mà quên mất hiệu năng, bảo mật, khả năng mở rộng.
Không chạy regression test khi có fix
Developer fix bug X nhưng làm hỏng tính năng Y. Luôn chạy lại bộ test cũ sau mỗi lần thay đổi.
Test với lượng dữ liệu quá ít
Hệ thống chạy tốt với 10 record test nhưng chậm khi có 1 triệu record thật. Cần test với data gần thực tế.
Acceptance Test
Cấp độ 4
Kiểm thử nghiệm thu từ góc nhìn của khách hàng/người dùng để quyết định có chấp nhận sản phẩm không
0 / 0 hoàn thành
Xác nhận phần mềm đáp ứng đúng yêu cầu và kỳ vọng của khách hàng/người dùng thực tế
Nhận được sự đồng ý chính thức của stakeholder để triển khai lên production
Kiểm tra phần mềm phù hợp với quy trình nghiệp vụ thực tế của tổ chức
Đây là cửa ải cuối cùng trước khi sản phẩm được bàn giao - cần đặc biệt cẩn thận
Tiêu chí nghiệm thu (Acceptance Criteria) cho từng user story/requirement là gì? Đã được viết rõ ràng chưa?
Ai là người tham gia Acceptance Test? Khách hàng? Business Analyst? Product Owner?
System Test đã hoàn thành và tất cả bug critical đã được fix chưa?
Test data có giống với dữ liệu thực tế của doanh nghiệp không?
Kết quả như thế nào thì được coi là "pass" và cho phép go-live? Đã thống nhất với stakeholder chưa?
100% acceptance criteria của các user story đã được verify và pass
Khách hàng / Product Owner đã ký vào biên bản nghiệm thu chính thức
Không còn bug nào ảnh hưởng đến quy trình nghiệp vụ cốt lõi
Tài liệu đào tạo người dùng và kế hoạch go-live đã được phê duyệt
Toàn bộ stakeholder liên quan đã được thông báo và đồng thuận triển khai
Acceptance Criteria không rõ ràng từ đầu
Không ai biết "pass" nghĩa là gì. Phải xác định và viết AC rõ ràng ngay từ giai đoạn lên yêu cầu.
Để tester làm Acceptance Test thay khách hàng
UAT phải có sự tham gia của người dùng thực hoặc đại diện nghiệp vụ, không phải QA đại diện cho họ.
Bỏ qua giai đoạn này do áp lực deadline
Không có sign-off dẫn đến tranh chấp sau khi go-live. Đây là bước pháp lý và không thể bỏ qua.
Phát hiện yêu cầu mới ở giai đoạn này
Acceptance Test chỉ kiểm tra những gì đã được ký kết, không phải nơi để thêm tính năng mới ngoài scope.
So sánh nhanh 4 cấp độ
Tiêu chí
Unit
Integration
System
Acceptance
Ai thực hiện
Developer / Tester
Tester
QA Team
Khách hàng / PO
Phạm vi test
Hàm / Class
Module + API
Toàn hệ thống
Nghiệp vụ thực tế
Môi trường
Local / CI
Dev / Staging
Staging (gần Production)
Staging / Pre-prod
Chi phí fix lỗi
Thấp nhất
Trung bình
Cao
Rất cao
Lưu ý cho Fresher Tester
Phát hiện lỗi càng sớm trong vòng đời phát triển phần mềm thì chi phí sửa càng thấp. Hãy luôn bắt đầu từ Unit Test và đi lên theo thứ tự. Đừng bỏ qua bất kỳ cấp độ nào vì "nghĩ là ổn rồi".