Kiểm thử trước khi PR - Phần 3 - Áp dụng vào PR Review và quy trình sửa lỗi

Ở Phần 1 và Phần 2, mình đã nói về Unit Test/Integration Test là gì và cách xây test case. Bài cuối này là lúc biến hết mấy thứ đó thành thói quen thật, ngay trong PR hàng ngày.

Chất lượng không phải việc của một mình dev

Ba vai trò cùng góp phần vào đây:

• Lập trình viên: hiểu rõ sự khác biệt giữa đặc tả và thực tế triển khai, thực hiện Unit Test, tổng hợp các khía cạnh Integration Test, ghi rõ nội dung xác nhận vào PR
• Reviewer: kiểm tra thiếu sót trong khía cạnh kiểm thử, xác nhận phạm vi ảnh hưởng, kiểm tra phân quyền và liên kết ngoài, yêu cầu bổ sung nếu phát hiện thiếu sót
• PM/QA: đánh giá rủi ro nghiệp vụ quan trọng, xác nhận điều kiện nghiệm thu (Acceptance Criteria), thu thập thông tin cần thiết cho quyết định phát hành

Review PR thì nên nhìn vào đâu?

Review không chỉ là đọc code, mà còn là ngồi soi lại khía cạnh kiểm thử:

• Unit Test: đã xác nhận cả happy path và exception chưa? Đã xem xét giá trị biên chưa?
• Integration Test: đã xác nhận các màn hình/API/DB liên quan chưa? Đã xác nhận sự khác biệt theo quyền hạn/vai trò chưa? Đã xác nhận liên kết dịch vụ ngoài (thành công/thất bại) chưa?
• Ghi chép review: kết quả kiểm thử đã được ghi lại trong PR/ticket chưa?

Ghi test vào PR sao cho người khác đọc hiểu ngay

PR dễ review là PR mà chỉ cần đọc là biết mình đã làm gì, ảnh hưởng tới đâu. Ví dụ cách ghi (dạng checklist Markdown):

Unit Test
☑ Kiểm tra định dạng email
☑ Kiểm tra trường bắt buộc
☑ Kiểm tra giới hạn ký tự
☑ Kiểm tra trùng lặp

Integration Test
☑ Đăng ký thành công từ màn hình đăng ký
☑ Lưu đúng giá trị vào cơ sở dữ liệu
☑ Chuyển hướng đến màn hình hoàn tất
☑ Gửi email hoàn tất thành công

Phạm vi ảnh hưởng
☑ Màn hình chi tiết thành viên
☑ Màn hình chỉnh sửa / Màn hình quản trị
☑ Xuất file CSV

Hai điều nên tránh:

• Đừng viết chung chung "đã test" — ghi vậy thì người khác chẳng biết bạn test cái gì, test kiểu gì. Cứ liệt kê cụ thể ra.
• Đừng để nguyên mục chưa test trong template — chỉ giữ lại những gì mình đã thực sự kiểm tra và chắc là chạy đúng.

Sửa lỗi xong chưa phải là hết

Sửa lỗi không dừng ở "đã sửa" — còn phải chắc là nó không quay lại. 5 bước:

1. Tái hiện: làm rõ điều kiện phát sinh lỗi
2. Nguyên nhân: xác định xử lý hoặc liên kết bị lỗi
3. Sửa lỗi: khắc phục trong phạm vi tối thiểu
4. Thêm test: thêm test để phát hiện lại cùng lỗi trong tương lai
5. Ghi nhận PR: lưu lại nguyên nhân, cách sửa và nội dung xác nhận

Tóm lại sau 3 bài

Kiểm thử không phải là việc làm cuối cùng trước khi merge, mà là một phần của việc làm ra sản phẩm tốt:

• Unit Test — chắc từng xử lý riêng lẻ chạy đúng
• Integration Test — chắc mọi thứ ghép lại vẫn chạy đúng
• PR Review — không chỉ đọc code, mà còn xem cả góc độ kiểm thử đã làm

Khi mỗi người tự sắp xếp quan điểm kiểm thử trước khi tạo PR, và ghi lại rõ ràng "đã kiểm tra thật những gì", chất lượng sẽ không còn phụ thuộc vào một cá nhân nào — nó trở thành thứ cả team cùng giữ.