Chiều trước buổi nghiệm thu, product gửi một đường dẫn cùng tài khoản dùng chung cho quản lý vận hành. Danh sách trống vì chưa có dữ liệu mẫu. Người kiểm tra tự tạo hồ sơ, nhập thiếu trường bắt buộc rồi kết luận chức năng chưa chạy. Dev lại cho rằng thao tác đó nằm ngoài phạm vi đã thống nhất.
Buổi nghiệm thu chưa có dữ liệu, kịch bản và kết quả mong đợi để mọi người kiểm tra cùng một phiên bản yêu cầu.
Nghiệm thu cần xác nhận điều gì?
Nghiệm thu không phải buổi dùng thử tự do và không thay thế kiểm thử. Mục tiêu là xác nhận sản phẩm đáp ứng luồng nghiệp vụ trong điều kiện gần với cách làm việc thực tế.
Product nối yêu cầu với kịch bản. Engineering chuẩn bị phiên bản và tài khoản. Người dùng nghiệp vụ xác nhận quy tắc. QA hỗ trợ tái hiện lỗi.
Nếu yêu cầu chưa thể kiểm tra, đội nên làm rõ theo quy trình viết spec và test case. Yêu cầu mơ hồ đưa vào UAT chỉ làm cuộc tranh luận xuất hiện muộn hơn.
Chuẩn bị dữ liệu theo từng kịch bản
Bộ dữ liệu không cần lớn nhưng phải đại diện đúng các nhánh cần nghiệm thu. Với tính năng duyệt báo giá, đội có thể cần hồ sơ đủ điều kiện, thiếu thông tin hoặc vượt quyền. Mỗi hồ sơ cần mã nhận biết để người kiểm tra và dev nói về cùng một trường hợp.
Không sao chép nguyên dữ liệu khách hàng thật sang môi trường thử nghiệm. Hãy thay thông tin liên hệ, nội dung hợp đồng và trường nhạy cảm. Nếu có tích hợp, ghi rõ phần dùng dịch vụ thử, phần mô phỏng và phản hồi chưa thể kiểm tra.
Quy trình chuẩn bị trước buổi nghiệm thu
1. Khóa phiên bản và phạm vi
Product ghi phiên bản, yêu cầu đã duyệt và phần chưa nằm trong lần bàn giao. Engineering xác nhận bản triển khai.
2. Chuyển yêu cầu thành kịch bản
Mỗi kịch bản có trạng thái đầu, vai trò, bước chính, kết quả mong đợi và dấu hiệu hoàn thành. Ngoại lệ quan trọng được viết riêng.
3. Tạo tài khoản và dữ liệu
Đội chuẩn bị tài khoản theo vai trò, dữ liệu có mã nhận biết và cách đặt lại để kiểm tra lần nữa.
4. Chạy kiểm tra nội bộ
Product hoặc QA chạy toàn bộ kịch bản. Link hỏng, thiếu quyền và dữ liệu sai phải được xử lý trước buổi nghiệm thu.
5. Chốt cách ghi nhận
Dùng một nơi để ghi kịch bản đạt, lỗi, câu hỏi nghiệp vụ và yêu cầu ngoài phạm vi. Mỗi mục có người xử lý cùng bước tiếp theo.
Viết tiêu chí để hai phía kiểm tra giống nhau
Tiêu chí tốt mô tả điều kiện và hành vi quan sát được. Thay vì viết “hệ thống xử lý đúng đơn hàng”, hãy ghi: khi nhân viên gửi đơn có đủ trường bắt buộc, trạng thái chuyển sang chờ duyệt, quản lý được mở chi tiết, còn nhân viên khác không có quyền phê duyệt.
Cần kiểm tra trường hợp thành công và bị từ chối. Nếu dữ liệu thiếu, lỗi xuất hiện ở đâu? Nếu hai người cùng xử lý, bản ghi cuối theo quy tắc nào? Nếu dịch vụ phụ thuộc không phản hồi, người dùng có thể thử lại ra sao?
Một ý tưởng hợp lý xuất hiện trong buổi nghiệm thu vẫn là yêu cầu mới nếu trước đó chưa được duyệt.
Phân biệt lỗi, thiếu yêu cầu và đề xuất cải tiến
Lỗi là khi sản phẩm không chạy theo yêu cầu đã duyệt. Thiếu yêu cầu xảy ra khi đội phát hiện một quy tắc nghiệp vụ cần thiết nhưng tài liệu chưa xác định. Đề xuất cải tiến giúp thao tác thuận tiện hơn nhưng không ngăn luồng hiện tại hoàn thành.
Lỗi thuộc phạm vi cần có mức ảnh hưởng, cách tái hiện và phiên bản sửa. Thiếu yêu cầu cần người có quyền chốt quy tắc trước khi dev thay đổi. Đề xuất cải tiến đi vào backlog, không mặc nhiên trở thành điều kiện chặn bàn giao.
Nếu phạm vi đổi trong lúc phát triển, đội có thể dùng quy trình quản lý thay đổi phạm vi MVP để cập nhật spec, test case và mốc bàn giao cùng nhau.
Checklist sẵn sàng cho buổi nghiệm thu
Phạm vi và môi trường
- Phiên bản kiểm tra đã được ghi rõ.
- Link, tài khoản và quyền truy cập đã được thử.
- Tích hợp thử và phần mô phỏng đã được phân biệt.
- Dữ liệu có thể đặt lại để chạy lại kịch bản.
Kịch bản và kết quả
- Mỗi kịch bản có trạng thái đầu vào và kết quả quan sát được.
- Dữ liệu bao phủ luồng chính cùng ngoại lệ quan trọng.
- Người kiểm tra biết nơi ghi lỗi và thông tin cần cung cấp.
- Người chốt lỗi chặn bàn giao và yêu cầu mới đã được xác định.
Kết thúc nghiệm thu bằng quyết định rõ ràng
Cuối buổi, đội cần biết kịch bản đã đạt, lỗi chặn bàn giao, mục có thể sửa sau và phần cần quyết định thêm. Không dùng câu “cơ bản ổn” làm kết quả. Biên bản nên có mã kịch bản, trạng thái, người phụ trách và lần kiểm tra lại.
Đội phải thống nhất người xác nhận cuối. Nếu sản phẩm mới chỉ là prototype, đừng dùng quy trình bàn giao của hệ thống chạy thật. Bài khi nào nên làm prototype, khi nào nên xây sản phẩm chạy thật giúp phân biệt mức chuẩn bị.
Dịch vụ Product Development của Auranium có thể hỗ trợ đội làm rõ yêu cầu, chuẩn bị tiêu chí nghiệm thu và tổ chức bàn giao theo phạm vi đã duyệt. Người dùng nghiệp vụ kiểm tra đúng việc, còn engineering nhận phản hồi đủ thông tin để xử lý.