Trong static testing, review không chỉ là “gửi tài liệu nhờ mọi người xem giúp”. Một review hiệu quả cần đúng người, mục tiêu rõ, có thời gian chuẩn bị và feedback được xử lý đến nơi đến chốn.
Vì sao cần feedback sớm và thường xuyên?
Nếu stakeholder chỉ xem sản phẩm ở cuối dự án, team có thể làm đúng theo tài liệu nhưng lại không còn đúng với nhu cầu hiện tại. Hậu quả thường là sửa lại nhiều, trễ deadline và tranh luận xem ai hiểu sai.
Feedback sớm giúp team tránh hiểu nhầm requirement, theo kịp thay đổi, hiểu rõ mình đang xây gì và tập trung vào tính năng có giá trị hoặc rủi ro cao nhất.
Quy trình Review gồm 5 hoạt động
1. Lập kế hoạch (Planning)
Xác định mục tiêu, phạm vi, work product, tiêu chí chất lượng, phần cần tập trung, exit criteria, tài liệu hỗ trợ, effort và thời gian.
2. Khởi động Review (Review Initiation)
Đảm bảo mọi người có quyền truy cập tài liệu, hiểu vai trò và có đủ checklist, tiêu chuẩn hoặc thông tin để bắt đầu.
3. Review cá nhân (Individual Review)
Mỗi reviewer tự xem work product, áp dụng kỹ thuật phù hợp và ghi lại anomaly, đề xuất, câu hỏi. Review trước giúp buổi họp không biến thành lúc mọi người mới bắt đầu đọc tài liệu.
4. Trao đổi và phân tích (Communication and Analysis)
Team thảo luận các anomaly (điểm bất thường) vì không phải anomaly nào cũng là defect. Mỗi mục cần được xác định trạng thái, người phụ trách và hành động tiếp theo; đồng thời đánh giá chất lượng của work product.
5. Sửa và báo cáo (Fixing and Reporting)
Author sửa work product; defect cần được ghi nhận để theo dõi. Khi đạt exit criteria, work product được chấp nhận và kết quả review được báo cáo.
Các vai trò chính trong Review
| Vai trò | Trách nhiệm chính |
|---|---|
| Manager (Quản lý) | Quyết định nội dung cần review và cung cấp người, thời gian, nguồn lực |
| Author (Tác giả) | Tạo và sửa work product được review |
| Moderator / Facilitator | Điều phối cuộc họp, quản lý thời gian, hòa giải và tạo môi trường an toàn. Có thể do Scrum Master hoặc Team Lead đảm nhiệm |
| Scribe / Recorder | Tổng hợp anomaly, ghi quyết định và thông tin review. Do 1 member đảm nhiệm |
| Reviewer | Thực hiện review; có thể là thành viên dự án, chuyên gia hoặc stakeholder |
| Review Leader | Chịu trách nhiệm tổng thể, chọn người tham gia và tổ chức thời gian, địa điểm |
Phân biệt 4 loại Review
| Loại | Đặc điểm dễ nhớ | Ví dụ |
|---|---|---|
| Informal Review | Không có quy trình xác định, không bắt buộc output chính thức; mục tiêu chính là tìm anomaly | Dev nhờ đồng nghiệp xem nhanh pull request |
| Walkthrough | Do author dẫn dắt; có thể dùng để giải thích, lấy đồng thuận, tạo ý tưởng và tìm anomaly | BA trình bày user flow mới cho Dev và Tester |
| Technical Review | Reviewer có chuyên môn kỹ thuật, moderator điều phối; nhấn mạnh đồng thuận và quyết định kỹ thuật | Nhóm senior review phương án tách database |
| Inspection | Cấp cao nhất, take time nhất, formal nhất, theo đủ quy trình, thu thập metrics; mục tiêu chính là tìm tối đa anomaly | Review tài liệu của hệ thống có yêu cầu tuân thủ nghiêm ngặt |
Điều gì giúp Review thành công?
- Mục tiêu rõ và exit criteria đo được; không dùng review để đánh giá cá nhân.
- Chọn loại review phù hợp với mục tiêu, rủi ro, work product và bối cảnh.
- Chia tài liệu thành phần nhỏ để reviewer giữ được sự tập trung.
- Cho người tham gia đủ thời gian chuẩn bị.
- Feedback quay lại author và stakeholder để cải thiện sản phẩm lẫn cách làm việc.
- Có sự ủng hộ của quản lý, đào tạo vai trò và điều phối cuộc họp tốt.
- Xây dựng văn hóa review để học hỏi và cải tiến, không phải để đổ lỗi.
Kết luận
Review hiệu quả không nhất thiết lúc nào cũng formal. Một user story đơn giản có thể chỉ cần informal review; một quyết định kiến trúc quan trọng có thể cần technical review; hệ thống critical có thể cần inspection. Điều quan trọng là feedback xuất hiện sớm, đúng người, đủ cụ thể và được theo dõi đến khi xử lý xong.
