Viết tiêu chí nghiệm thu bằng tình huống cụ thể

Yêu cầu như người dùng được cập nhật đơn hàng có vẻ rõ cho đến khi hai người bất đồng về đơn nào, đổi gì và sau đó xảy ra điều gì. Tiêu chí nghiệm thu chuyển ý định rộng thành hành vi quan sát được. Ví dụ cụ thể giúp bên mua và nhóm triển khai phát hiện bất đồng khi thay đổi còn tương đối dễ trao đổi.

Bắt đầu bằng quy tắc và ranh giới

Nêu quy tắc nghiệp vụ trước khi mô tả màn hình. Xác định người thực hiện, trạng thái liên quan và điều kiện cho phép hành động. Phân biệt đề nghị của khách hàng với thay đổi được cho phép. Quyết định quy tắc có áp dụng cho bản ghi nhập từ ngoài và thao tác nhân viên hay không.

Dùng cấu trúc đơn giản: với điều kiện đã biết, khi người được nêu thực hiện hành động, thì xuất hiện kết quả quan sát được. Đây là khuyến nghị cách viết, không bắt buộc dùng một công cụ kiểm thử cụ thể. Không đưa chi tiết triển khai nội bộ vào trừ khi đó thật sự là nghĩa vụ nghiệm thu.

Thêm ví dụ buộc phải quyết định

Với mỗi quy tắc quan trọng, viết trường hợp thường, trường hợp tại ranh giới và trường hợp bị cấm. Thay từ như nhanh chóng hay hợp lệ bằng điều kiện người rà soát đánh giá được. Nếu chưa rõ ngưỡng, nêu người quyết định thay vì tự đặt số.

Khi quy tắc kiểm soát truy cập, thêm hành động bị từ chối bên cạnh hành động thành công. OWASP khuyến nghị kiểm thử để xác nhận quyền đã xác định trong thiết kế được thực thi.[6] Hỏi trạng thái nào còn lại sau từ chối, không chỉ hỏi thông báo gì xuất hiện. Thông báo lỗi chưa chứng minh dữ liệu không đổi.

Ví dụ giả định: đổi địa chỉ giao hàng

Một nhà cung cấp văn phòng phẩm giả định cho khách đổi địa chỉ trước khi kho cho xuất hàng. Ví dụ đầu bắt đầu bằng đơn chưa được xuất và khách có quyền. Sau thay đổi hợp lệ, đơn hiển thị địa chỉ mới, còn giá trị cũ vẫn có sẵn cho nhân viên được phép xem.

Ví dụ đối chiếu bắt đầu sau khi kho cho xuất. Việc sửa trực tiếp bị từ chối, địa chỉ giao không đổi và khách nhận hướng dẫn hỗ trợ đã thống nhất. Nhóm vẫn phải quyết định cho xuất hàng nghĩa là gì và hệ thống biết trạng thái đó bằng cách nào.

Rà soát ví dụ theo danh sách

Cùng người phụ trách nghiệp vụ, đại diện người dùng và nhóm triển khai đi qua từng ví dụ. Giải quyết cách hiểu khác nhau trước khi coi tiêu chí đã sẵn sàng.

• Nêu bản ghi ban đầu, người thao tác, quyền và trạng thái nghiệp vụ liên quan.
• Xác định một hành động đang được xem xét.
• Mô tả kết quả quan sát được và trạng thái bắt buộc giữ nguyên.
• Thêm trường hợp ranh giới hoặc bị cấm cho mỗi quy tắc quan trọng.
• Giao thuật ngữ chưa thống nhất cho người quyết định cụ thể.

Tách nghiệm thu khỏi chất lượng chung

Trong Scrum, Definition of Done mô tả trạng thái chất lượng bắt buộc của Increment, tức phần tăng trưởng sản phẩm.[5] Ví dụ nghiệm thu tính năng không thay thế thỏa thuận rộng hơn đó. Chúng mô tả hành vi riêng, còn kiểm tra chung có thể bao quát vấn đề xuất hiện ở nhiều tính năng.

Không thể liệt kê hết ví dụ cho quy trình phức tạp. Ưu tiên trường hợp phân biệt cách hiểu cạnh tranh và có hệ quả đáng kể. Giữ tiêu chí đủ dễ hiểu để nghiệp vụ rà soát. Kiểm thử kỹ thuật có thể kiểm tra thêm tổ hợp mà không biến trao đổi nghiệm thu thành đặc tả khó đọc.