Testing muốn thành công phải được điều chỉnh theo Software Development Lifecycle. Không thể lấy nguyên quy trình kiểm thử của một dự án Waterfall rồi áp dụng cho Scrum hoặc DevOps mà không thay đổi.

SDLC ảnh hưởng đến Testing như thế nào?

Theo ISTQB, lựa chọn SDLC tác động đến năm nhóm quyết định chính:

• Scope và timing: test level, test type nào được thực hiện và vào thời điểm nào.
• Test documentation: testware cần chi tiết đến mức nào.
• Test techniques và test approach: cách thiết kế và ưu tiên kiểm thử.
• Test automation: phạm vi và mức độ tự động hóa.
• Tester roles: trách nhiệm và cách tester cộng tác với các vai trò khác.

Testing trong từng nhóm SDLC

Sequential development (Waterfall)

Ở các giai đoạn đầu, tester thường review requirement, thực hiện test analysis và test design. Vì executable code xuất hiện ở giai đoạn sau, dynamic testing thường không thể bắt đầu sớm.

Do đó static testing và early review đặc biệt quan trọng với kiểu phát triển "cổ điển" theo tuần tự này

Iterative và incremental development (lặp lại và tăng tiến)

Mỗi iteration có thể tạo ra prototype hoặc product increment hoạt động được. Static và dynamic testing có thể diễn ra ở nhiều test level trong từng vòng.

Việc giao increment thường xuyên đòi hỏi feedback nhanh và regression testing rộng. Nên automation test thường buộc phải sử dụng

Agile development

Agile chấp nhận thay đổi xuyên suốt dự án, vì vậy thường ưu tiên lightweight documentation và automation để hỗ trợ regression testing. Nhiều manual testing sử dụng experience-based techniques vì chúng linh hoạt và không đòi hỏi test analysis, test design quá nặng từ trước.

Good Testing Practices áp dụng cho mọi SDLC

• Mỗi development activity có một test activity tương ứng: mọi work product phát triển đều được quality control, không chỉ executable code.
  • Ví dụ:
    1. BA viết requirement cho chức năng thanh toán → Tester review requirement.
    2. Dev code payment service → Dev chạy unit test/component test.
    3. Hệ thống hoàn thiện → QA chạy system test.

→ Không phải đợi “code xong hết” mới bắt đầu QC.

• Mỗi test level có test objectives riêng: kiểm thử đủ rộng nhưng tránh lặp lại cùng một mục tiêu ở nhiều level.
  • Ví dụ: Với chức năng tính tổng tiền:
    • Component test kiểm tra hàm calculateTotal() tính đúng;
    • Component Integration Test kiểm tra Cart gọi Pricing API đúng; giá tiền hiển thị trên màn hình sau khi ốp voucher là đúng
    • System Test Test luồng Add to cart → Checkout → tính giá/voucher/shipping → Place Order của toàn bộ hệ thống
    • SIT: kiểm tra luồng thanh toán tích hợp ok với cổng thanh toán Momo, trừ tiền chuẩn
    • Acceptance Test PO nghiệm thu quy trình mua hàng đáp ứng nhu cầu business.
• Test analysis và test design bắt đầu sớm: thực hiện trong development phase tương ứng để tuân thủ early testing.
  • Ví dụ: BA đang viết requirement cho Login, dev chưa code gì cả. Tester đã đọc requirement và nghĩ ra test condition: đúng password, sai password, account bị lock, password rỗng… → Tester thiết kế test sớm, không chờ dev code xong.
• Tester review work product ngay từ bản nháp: phát hiện điểm mờ, không rõ ràng, không đồng nhất trước khi chúng đi vào code.
  • Ví dụ: BA vừa có bản nháp SRS: “Password phải từ 8–20 ký tự”. Tester review và hỏi: Có bắt buộc chữ hoa không? Có cho phép space không? Unicode thì sao? → Requirement được làm rõ trước khi dev code. Đây chính là một biểu hiện của shift-left.