Retrospective là cuộc họp nhìn lại cách team đã làm việc để giữ lại điều tốt và cải thiện điều chưa hiệu quả. Nó không chỉ dành cho Scrum và cũng không phải một buổi “kể tội” cá nhân.
Retrospective diễn ra khi nào?
Tùy, retrospective có thể được tổ chức vào cuối sprint, cuối dự án, tại release milestone hoặc bất cứ khi nào team cần nhìn lại process.
Người tham gia không chỉ có tester mà còn có developer, Product Owner, Business Analyst và các vai trò liên quan.
Ba câu hỏi cốt lõi
- Điều gì làm tốt?
- Điều gì làm chưa tốt?
- Làm thế nào để áp dụng cải tiến và giữ lại thành công trong tương lai?
Kết quả cần được ghi nhận, thường là một phần của test completion report. Quan trọng hơn, action items phải có người phụ trách và được theo dõi; nếu không, retrospective chỉ tạo ra một danh sách mong muốn.
Mỗi người trong team có 1 mẩu giấy để viết điều tốt và chưa tốt ra, sau đó dán lên bảng. Scrum Master đi qua 1 lượt, sau đó toàn team đưa ra các nhận xét và bài học rút ra. Cuối cùng lưu lại nội dung buổi họp vào wiki công ty.
Lợi ích điển hình cho Testing
1. Tăng effectiveness và efficiency
Team loại bỏ bước thừa, rút ngắn feedback loop và ưu tiên đúng rủi ro.
- Ví dụ: thay vì chạy toàn bộ regression thủ công mỗi Sprint, team phân lớp suite và tự động hóa các luồng ổn định.
2. Cải thiện chất lượng Testware
Cùng review test process giúp phát hiện test case trùng lặp, expected result mơ hồ, dữ liệu khó tái sử dụng hoặc bộ automation không ổn định.
- Ví dụ: Bộ auto test chạy không ổn định, PO nắm được tình hình, để lại 20% effort của team để sprint tới xử lý nó luôn
3. Team bonding và learning
Mọi người có cơ hội nêu vấn đề, chia sẻ kiến thức và hiểu khó khăn của nhau. Tester học thêm về kiến trúc; developer hiểu rõ hơn risk và coverage.
4. Cải thiện Test Basis
Các thiếu sót trong requirement, acceptance criteria và tài liệu có thể được đưa về xử lý có hệ thống thay vì để tester tự suy đoán trong từng Sprint.
- Ví dụ: Nhiều ticket viết sơ sài, thiếu Acceptance Criteria -> Nhờ buổi này mà đến sprint sau BA sẽ làm việc chuẩn chỉ hơn
5. Hợp tác tốt hơn giữa Development và Testing
Team cùng tối ưu handoff, cách report defect, thời điểm review và trách nhiệm đối với quality.
Ví dụ action item tốt
| Phát hiện | Action item cụ thể |
|---|---|
| Nhiều defect do acceptance criteria mơ hồ | Tester tham gia refinement; dùng checklist review từ Sprint sau |
| Regression kéo dài 3 ngày | Chọn 5 luồng critical để automation trong hai Sprint |
| Bug bị trả lại vì thiếu evidence | Chuẩn hóa defect template và ví dụ trước ngày X |
Kết luận
Retrospective giúp team ghi nhận bài học, biến chúng thành hành động có thể theo dõi và kiểm tra kết quả ở vòng tiếp theo. Với testing, đây là cơ chế quan trọng để cải thiện cả process, testware, test basis và collaboration.
