Agile testing là gì? Vai trò của tester trong Scrum
Trong mô hình thác nước, tester chờ đến cuối dự án mới vào việc. Trong Agile, không còn cái "cuối" đó nữa — kiểm thử diễn ra song song với phát triển, và tester tham gia từ lúc yêu cầu còn là một câu chuyện chưa rõ ràng.
Agile testing là gì?
Agile testing là cách tiếp cận kiểm thử trong đó hoạt động kiểm thử diễn ra liên tục và song song với phát triển, thay vì là một giai đoạn tách rời ở cuối. Tester là thành viên của đội phát triển, không phải một bộ phận nghiệm thu bên ngoài.
| Khía cạnh | Mô hình thác nước | Agile |
|---|---|---|
| Thời điểm test | Sau khi code xong toàn bộ | Liên tục trong từng sprint |
| Vai trò tester | Người gác cổng cuối cùng | Thành viên đội, tham gia từ đầu |
| Tài liệu | Dày, ký duyệt trước | Vừa đủ, cập nhật liên tục |
| Phản hồi lỗi | Sau nhiều tuần hoặc tháng | Trong vài giờ đến vài ngày |
| Trách nhiệm chất lượng | Thuộc về đội kiểm thử | Cả đội cùng chịu trách nhiệm |
Tester làm gì trong từng sự kiện Scrum
| Sự kiện | Tester đóng góp gì | Giá trị tạo ra |
|---|---|---|
| Backlog refinement | Đặt câu hỏi làm rõ story, chỉ ra tiêu chí chấp nhận còn thiếu hoặc mơ hồ | Cao nhất — sửa yêu cầu ở đây rẻ hơn sửa code rất nhiều |
| Sprint planning | Ước lượng công sức kiểm thử, cảnh báo story nào khó test | Sprint không bị vỡ vì quên phần test |
| Daily standup | Báo tiến độ test, nêu vật cản (thiếu môi trường, thiếu dữ liệu) | Vật cản được gỡ trong ngày thay vì cuối sprint |
| Sprint review | Trình bày kết quả kiểm thử, nêu rủi ro còn lại | Người ra quyết định có thông tin thật |
| Retrospective | Đề xuất cải tiến quy trình dựa trên lỗi lặp lại | Đội bớt lặp lại cùng một sai lầm |
Acceptance Criteria và Definition of Done
Hai khái niệm này hay bị nhầm lẫn nhưng phục vụ mục đích khác nhau.
| Acceptance Criteria | Definition of Done | |
|---|---|---|
| Phạm vi | Riêng từng story | Áp dụng cho mọi story trong đội |
| Nội dung | Điều kiện cụ thể để story được coi là đúng | Chuẩn chất lượng chung: đã review code, đã test, đã cập nhật tài liệu |
| Ai định nghĩa | Chủ sản phẩm cùng đội | Cả đội thống nhất một lần |
| Với tester | Là đầu vào để thiết kế test case | Là tiêu chí ra ở cấp story |
Viết Acceptance Criteria theo cấu trúc Given – When – Then
Story: Là khách hàng, tôi muốn áp mã khuyến mãi vào giỏ hàng
để được giảm giá trước khi thanh toán.
AC1 Given giỏ hàng có tổng tiền 500.000đ
When khách nhập mã GIAM10 còn hiệu lực
Then tổng tiền hiển thị 450.000đ và dòng "Giảm giá: -50.000đ"
AC2 Given khách đã áp một mã khuyến mãi
When khách nhập thêm mã thứ hai
Then hệ thống báo "Chỉ áp dụng một mã cho mỗi đơn hàng"
AC3 Given mã khuyến mãi đã hết hạn
When khách nhập mã đó
Then hệ thống báo "Mã đã hết hạn" và không thay đổi tổng tiềnXử lý khi không kịp test trong sprint
Tình huống kinh điển: lập trình viên bàn giao story vào chiều thứ Năm, sprint kết thúc thứ Sáu. Đây là vấn đề quy trình, không phải vấn đề của riêng tester.
Xử lý trước mắt
- Ưu tiên theo rủi ro: test luồng chính và các trường hợp thiệt hại lớn trước.
- Báo minh bạch trong standup: story nào chưa được test đủ và rủi ro là gì.
- Không đánh dấu hoàn thành cho story chưa đạt định nghĩa hoàn thành — đây là ranh giới không nên nhượng bộ.
Xử lý gốc rễ trong retrospective
- Đề xuất bàn giao theo từng phần trong sprint thay vì dồn vào cuối.
- Áp dụng giới hạn công việc đang làm để tránh mọi story cùng chạy tới đích một lúc.
- Đưa công sức kiểm thử vào ước lượng story ngay từ sprint planning.
- Đẩy nhiều kiểm tra xuống tầng unit và API để giảm tải cho kiểm thử thủ công cuối sprint.
Kim tự tháp kiểm thử trong Agile
Agile chỉ chạy được nếu phản hồi đủ nhanh. Điều đó buộc phần lớn kiểm tra phải nằm ở tầng thấp, nơi test chạy trong vài giây thay vì vài giờ.
- Tầng unit (~70%): lập trình viên viết, chạy trong mili-giây, chỉ ra chính xác hàm nào sai.
- Tầng API/integration (~20%): nơi tester đóng góp giá trị cao nhất cho tự động hoá.
- Tầng giao diện (~10%): chỉ các luồng người dùng quan trọng nhất.
- Kiểm thử khám phá thủ công: không nằm trong kim tự tháp nhưng không thể thiếu — đây là nơi tìm ra thứ không ai nghĩ tới.
Câu hỏi thường gặp
Agile testing khác kiểm thử truyền thống ở điểm nào?
Khác ở thời điểm và vai trò. Kiểm thử truyền thống diễn ra sau khi code xong toàn bộ, do một đội tách biệt thực hiện. Agile testing diễn ra liên tục trong từng sprint, tester là thành viên của đội phát triển và tham gia từ lúc làm rõ yêu cầu, còn trách nhiệm chất lượng thuộc về cả đội.
Tester tham gia buổi refinement để làm gì?
Để đặt câu hỏi làm rõ story và chỉ ra tiêu chí chấp nhận còn thiếu, mơ hồ hoặc mâu thuẫn. Đây là hoạt động tạo giá trị cao nhất của tester, vì sửa một yêu cầu sai ở giai đoạn này rẻ hơn rất nhiều so với sửa sau khi đã lập trình xong.
Definition of Done và Acceptance Criteria khác nhau ra sao?
Acceptance Criteria là điều kiện cụ thể để một story được coi là đúng, khác nhau giữa các story. Definition of Done là chuẩn chất lượng chung áp dụng cho mọi story trong đội, ví dụ đã review code, đã test, đã cập nhật tài liệu. Với tester, AC là đầu vào thiết kế test case còn DoD là tiêu chí ra.
Story chưa test xong mà hết sprint thì xử lý thế nào?
Không đánh dấu hoàn thành cho story chưa đạt định nghĩa hoàn thành, và báo minh bạch rủi ro trong standup. Về gốc rễ, hãy nêu vấn đề ở retrospective: nguyên nhân thường là dồn bàn giao vào cuối sprint, và cách chữa là bàn giao theo từng phần cùng việc đưa công sức kiểm thử vào ước lượng ngay từ sprint planning.