Acceptance Criteria (AC) là một phần quan trọng trong quá trình phát triển phần mềm và giúp đảm bảo tính hoàn thiện và chấp nhận của chức năng hoặc tính năng. Trong bài viết này, chúng ta sẽ tìm hiểu về Acceptance Criteria và cách viết chúng một cách hiệu quả.
Acceptance Criteria (AC) là gì?
Acceptance Criteria là một tập hợp các điều kiện mà tính năng hoặc chức năng phải thỏa mãn để được chấp nhận bởi Product Owner hoặc Stakeholder. Đây là các tiêu chí đánh giá mà khách hàng mong đợi và giúp đảm bảo rằng thông tin về sản phẩm là minh bạch và dễ hiểu.
Hình ảnh minh họa Acceptance Criteria
Ai tạo Acceptance Criteria?
Acceptance Criteria thường được tạo ra bởi Product Owner. Nếu PO không quen viết AC, họ có thể giao phó công việc này cho một người có kỹ năng viết như Business Analyst, Scrum member thích hợp hoặc Requirement Analyst. Sau đó, Development Team sẽ xem xét và chỉnh sửa AC để đảm bảo rằng tài liệu đầy đủ và không có điểm mơ hồ.
Cách viết Acceptance Criteria hiệu quả
Có nhiều cách viết Acceptance Criteria nhưng có hai cấu trúc phổ biến là Theo kịch bản (Given/When/Then) và Theo Quy tắc (Checklist).
Theo kịch bản (Given/When/Then)
Cấu trúc theo kịch bản có thể được sử dụng để viết Acceptance Criteria:
- Scenario: Đặt tên cho hành vi sẽ mô tả.
- Given: Trạng thái bắt đầu của kịch bản (bao gồm một số điều kiện).
- When: Hành động cụ thể mà người dùng thực hiện.
- Then: Kết quả mà người dùng mong muốn khi thực hiện hành động đó.
- And: Sử dụng bất kỳ lúc nào trong 3 câu trước.
Sau khi nêu xong các bước trên, cần đảm bảo rằng tất cả hành động mà người dùng thực hiện để hoàn thành nhiệm vụ và trải nghiệm kết quả đã được bao hàm đầy đủ.
VD User story: Là người dùng, tôi muốn đăng nhập vào hệ thống.
AC1: Nếu thông tin hợp lệ, người dùng có thể đăng nhập.
- Given: Người dùng có tài khoản trong hệ thống.
- And: Người dùng đang ở trang "Đăng nhập".
- When: Người dùng nhập "duyenthai" vào trường Username.
- And: Người dùng nhập "duyen123" vào trường Password.
- And: Người dùng nhấn nút "Đăng nhập".
- Then: Người dùng nhìn thấy thông báo "Đăng nhập thành công".
- And: Chuyển sang "Trang chủ".
AC2: Nếu nhập sai mật khẩu, người dùng không đăng nhập được vào hệ thống.
- Given: Người dùng có tài khoản trong hệ thống.
- And: Người dùng đang ở trang "Đăng nhập".
- When: Người dùng nhập "duyenthai" vào trường Username.
- And: Người dùng nhập "duyen120" vào trường Password.
- And: Người dùng nhấn nút "Đăng nhập".
- Then: Người dùng không thể đăng nhập vào hệ thống.
- And: Hệ thống thông báo "Sai thông tin mật khẩu, vui lòng nhập lại!".
- And: Hệ thống giữ nguyên giao diện "Đăng nhập".
Tuy nhiên, có những trường hợp mà việc sử dụng cấu trúc Given/When/Then không phù hợp như:
- User story mô tả chức năng cấp thấp yêu cầu các phần tử chứa bảng từ điển, danh sách.
- Mục tiêu của điều kiện chấp nhận không yêu cầu hiểu rõ về các ca kiểm thử cụ thể.
- Mô tả ràng buộc về thiết kế và trải nghiệm người dùng của một tính năng.
Trong những trường hợp này, việc mô tả Acceptance Criteria theo dạng quy tắc hay checklist là lựa chọn hợp lý.
Dạng quy tắc (Checklist)
Acceptance Criteria thể hiện hành vi của hệ thống dựa trên những quy tắc đã được đề ra. Acceptance Criteria dạng quy tắc thường được sử dụng để mô tả và vẽ ra những trường hợp cụ thể. Với cấu trúc này, ta thường sử dụng các gạch đầu dòng đơn giản.
VD User story: Là người dùng, tôi muốn có thể tìm kiếm nhà với những thông tin địa chỉ.
AC giao diện tìm kiếm:
- Thanh Tìm kiếm đặt trên cùng.
- Cho phép người dùng tìm kiếm địa chỉ theo Tỉnh/Thành phố, Huyện/Quận, Xã/Phường. Mỗi trường này đều là select option cho phép người dùng tìm kiếm nhanh.
- Bắt đầu tìm kiếm khi người dùng nhấn vào ô "Tìm kiếm".
- Place holder là “Bạn muốn đi đâu?”.
- Tìm kiếm dạng gần đúng.
- Không hỗ trợ tìm kiếm những ký tự đặc biệt.
Kết luận
Việc xác định rõ ràng Acceptance Criteria trong quá trình phát triển phần mềm giúp đảm bảo tính hoàn thiện và sự chấp nhận của tính năng. Dù nhóm phát triển sử dụng mô hình nào, việc viết AC dễ hiểu và bao quát là điều cần thiết. Hãy tuân thủ những lưu ý khi viết AC như:
- Viết theo cách mà ai cũng có thể hiểu.
- Tránh sử dụng mô tả kỹ thuật trong AC.
- Có format nhất quán.
- Viết chỉ những AC quan trọng và bắt buộc có trong User story.
Mong rằng những thông tin này sẽ giúp bạn hiểu rõ hơn về Acceptance Criteria và cách viết chúng cho mỗi tính năng trong sản phẩm của mình.
Phân biệt Acceptance Criteria và Definition of Done (DoD)
Có nhiều người nhầm lẫn giữa khái niệm DoD (khái niệm về sự hoàn thành trong Scrum) và Acceptance Criteria (tiêu chí nghiệm thu của chủ đầu tư hoặc đơn vị vận hành). Dưới đây là sự khác biệt giữa hai khái niệm này:
Ví dụ của DoD:
- Tính năng chạy được.
- Code đã được review chéo.
- Hoàn thành kiểm thử chấp nhận.
- Release lên môi trường staging.
Ví dụ của AC với User story: Là người dùng tôi muốn có thể tìm kiếm nhà với những thông tin địa chỉ.
- Thanh Tìm kiếm đặt trên cùng.
- Cho phép người dùng tìm kiếm địa chỉ theo Tỉnh/Thành phố, Huyện/Quận, Xã/Phường. Mỗi trường này đều là select option cho phép người dùng tìm kiếm nhanh.
- Bắt đầu tìm kiếm khi người dùng nhấn vào ô "Tìm kiếm".
- Place holder là “Bạn muốn đi đâu?”.
- Tìm kiếm dạng gần đúng.
- Không hỗ trợ tìm kiếm những ký tự đặc biệt.
Xin lưu ý rằng đối với mỗi dự án, có thể có sự thay đổi về quy trình và tiêu chí chấp nhận. Quan trọng là tuân thủ và áp dụng những tiêu chuẩn phù hợp với dự án của bạn.
