Nơi để đặt chi tiết về các tiêu chí chấp nhận của một câu chuyện người dùng?

Trong bài đăng trên blog này về tiêu chí chấp nhận , tác giả giải thích rằng tiêu chí chấp nhận tốt nên:

• Nêu rõ ý định không phải là một giải pháp (ví dụ: Người dùng có thể chọn một tài khoản, chứ không phải là Người dùng có thể chọn tài khoản từ một người thả xuống)

• Không phụ thuộc vào việc triển khai (lý tưởng là các cụm từ sẽ giống nhau cho dù tính năng / câu chuyện này sẽ được triển khai trên web, ví dụ như hệ thống, điện thoại di động hoặc hệ thống kích hoạt bằng giọng nói)

• Là mức độ tương đối cao (không phải mọi chi tiết cần phải được viết)

Và thêm thông tin chi tiết như:

• Tiêu đề cột là Số dư
• Định dạng cân bằng cán là 99.999.999.999,9 D / CR
• Chúng ta nên sử dụng một danh sách thả xuống thay vì các hộp kiểm

nên được chuyển đến tài liệu nội bộ của Đội hoặc kiểm tra chấp nhận tự động

Tuy nhiên , tôi thường nghe mọi người cau mày về việc sử dụng Cucumber hoặc các khung tương tự để thực hiện các bài kiểm tra GUI. Hơn nữa, sử dụng tài liệu nội bộ có thể tạo ra nhiều vấn đề do không cập nhật tài liệu thường xuyên.

Tôi vẫn đang cố gắng tìm một cách hiệu quả để nắm bắt những chi tiết như vậy trong suốt cuộc trò chuyện với khách hàng.

Tôi có hai nơi (là chủ sở hữu sản phẩm)

Phản hồi mới từ khách hàng có thể dịch trong nhiều câu chuyện hơn, thay đổi các ưu tiên câu chuyện hoặc một số chi tiết mới về một câu chuyện. Trong nhật ký sau, tôi ghi lại những chi tiết này cho những câu chuyện trong tương lai mà tôi có thể quên bằng cách khác. Đây là những ghi chú cho bản thân tôi.

Ngay trước cuộc họp lập kế hoạch, tôi dịch những gì trong đầu + những ghi chú này thành thứ gì đó mà nhóm có thể xem xét. Tài liệu này (chúng tôi sử dụng một trang wiki cho mỗi sử thi người dùng) được tiếp tục hoàn thiện & hoàn thành trong kế hoạch chạy nước rút như là một phần của cuộc thảo luận về câu chuyện với nhóm.

Tôi thích chụp 'Ràng buộc' dưới dạng 'PS' ở cuối câu chuyện của mình.

[user] [actions] so that [goal]

Constraints:
- No Touching
- Actions must be gluten free

Những hạn chế đó là những hạn chế mà khách hàng đưa ra cho thiết kế của tôi, phải được xem xét khi cân nhắc các giải pháp khác nhau - tôi cần biết về chúng trước, vì vậy tôi ưu tiên cho chúng rất nhiều.

Tôi thích xác định các thử nghiệm chấp nhận cho từng kiểu Câu chuyện BDD như một phần của tài liệu cấp cao (Tính năng - Câu chuyện - Thử nghiệm)

WHEN [preconditions]
GIVEN [trigger action/condition/event/situation]
THEN [expected outcome]

Các chi tiết cụ thể như những chi tiết được đề cập ở trên sẽ là một phần của bản mô phỏng màn hình mà khách hàng đăng nhập; những chi tiết như vậy không phải lúc nào cũng được biết trước, nhưng trong mọi trường hợp, chúng đều nằm dưới 'ràng buộc thiết kế'. Tôi làm, khi các mockup được biết trước, bao gồm các mockup và các ràng buộc thiết kế theo thỏa thuận trong tài liệu cấp cao, bởi vì khách hàng phải đăng xuất trước khi bắt đầu công việc.

Vì vậy, trong khi về mặt khái niệm riêng biệt, tôi thấy không có hại trong việc đưa nó vào cùng một tài liệu. Ngay cả khi không yêu cầu đăng xuất máy khách, thật thuận tiện khi có tất cả các yêu cầu cho một tính năng / câu chuyện ở một nơi.

Tôi có một cách tiếp cận khá thực tế - nếu một chi tiết kỹ thuật quan trọng đối với việc chấp nhận một câu chuyện thì nó phải nằm trong tiêu chí chấp nhận, bất kể một số bài đăng trên blog nói gì. Nếu điều thực sự quan trọng là tên cột phải là "số dư", thì đó phải là một phần của tiêu chí chấp nhận.

Điều này có thể dẫn đến các tiêu chí chấp nhận quá dài. Trong trường hợp như vậy, tôi nghĩ rằng có một tiêu chí chấp nhận là "phải vượt qua bộ thử nghiệm X" và nó nằm trong "bộ thử nghiệm X" nơi bạn đặt tất cả các chi tiết khó chịu về sản phẩm.