Tìm hiểu về User Story và Acceptance Criteria qua Examples

Trong ngành phát triển phần mềm, từ 'Requirement' xác định mục tiêu của chúng ta là gì, những gì khách hàng cần và điều gì sẽ làm cho công ty của chúng ta tăng trưởng .

Là một công ty sản xuất phần mềm hoặc một công ty cung cấp các dịch vụ trong các lĩnh vực phần mềm khác nhau, cơ sở chính cho tất cả chúng là 'Requirement' và sự thành công được xác định bởi các yêu cầu được đáp ứng như thế nào.

Thuật ngữ 'Requirement' có các tên khác nhau trong các phương pháp làm dự án khác nhau.

Trong Waterfall , nó được gọi là ' Requirement / Specification Document ', trong Agile hoặc SCRUM nó được gọi là 'Epic', 'User Story'.

Theo mô hình Waterfall, các tài liệu yêu cầu là tài liệu khổng lồ của 200 trang trở lên vì toàn bộ sản phẩm được thực hiện trong một giai đoạn. Nhưng đây không phải là trường hợp của Agile / SCRUM vì trong các phương pháp này các yêu cầu được cung cấp cho các chức năng hoặc tính năng nhỏ khi sản phẩm được chuẩn bị theo từng bước.

What is a User Story?

User Story là yêu cầu đối với bất kỳ chức năng hoặc tính năng nào được ghi trong một hoặc hai dòng và tối đa 5 dòng. Một User Story thường là yêu cầu đơn giản nhất có thể và là về một và chỉ một chức năng (hoặc một tính năng).

Định dạng tiêu chuẩn được sử dụng phổ biến nhất cho việc tạo User Story :

As a <user role/customer, I want to < goal to be accomplished> so that I can <reason of the goal>.

Examples:

Là người dùng WhatsApp, tôi muốn có một biểu tượng máy ảnh trong hộp thoại viết để chụp và gửi ảnh để tôi có thể nhấp và chia sẻ ảnh của tôi cùng với tất cả bạn bè của tôi.

What is an Acceptance Criteria?

Acceptance Criteria là một tập hợp các điều kiện được chấp nhận hoặc các quy tắc kinh doanh mà chức năng hoặc tính năng phải thỏa mãn và đáp ứng, để được chấp nhận bởi Product Owner/Stakeholders.

Đây là một phần rất quan trọng trong việc hoàn thành câu chuyện của người dùng và cần được nghiên cứu bởi Product Owner and Business Analyst rất tỉ mỉ bởi vì thiếu một tiêu chí duy nhất có thể tốn rất nhiều chi phí. Đây là một danh sách được list ra và đánh số.

Định dạng của nó như sau:

“Given some precondition when I do some action then I expect the result”.

Example (w.r.t to above user story):

Hãy xem xét rằng tôi đang trò chuyện với một người bạn và tôi sẽ có thể chụp một bức ảnh. Khi tôi nhấp vào một bức ảnh, tôi sẽ có thể thêm một chú thích cho hình ảnh trước khi gửi nó. Nếu có một số vấn đề với việc khởi động camera điện thoại của tôi, một thông báo lỗi như 'Không thể bắt đầu camera'. vv, nên được hiển thị cho phù hợp. Do đó, User Story định nghĩa yêu cầu đối với bất kỳ chức năng hoặc tính năng nào trong khi Acceptance Criteria xác định 'Định nghĩa đã hoàn thành' cho User Story or Requirement.

Là một QA, rất quan trọng để hiểu được User Story và Acceptance Criteria của nó một cách sâu sắc thậm chí không còn nghi ngờ gì nữa khi bắt đầu test. Để hiểu tại sao điều cực kỳ quan trọng là đào sâu vào User Story và Acceptance Criteria, chúng ta sẽ đi tiếp đến vài ví dụ cụ thể.

Digging deep into User stories

Để bắt đầu, trước tiên chúng ta hãy đào sâu nghiên cứu về User Stories để hiểu tầm quan trọng của nó.

Trường hợp 1:

Dự án ứng dụng dành cho thiết bị di động và sản phẩm là một ứng dụng được thiết kế cho những người giao hàng.

Bạn sẽ thấy người giao hàng đến nơi giao hàng của bạn. Và họ có điện thoại di động mà họ yêu cầu bạn cung cấp chữ ký của bạn sau khi giao hàng. Chữ ký này phản ánh trên cổng thông tin của các nhà cung cấp dịch vụ chuyển phát nhanh như DTDC, FedEx vv

Hãy tưởng tượng rằng ứng dụng dành cho thiết bị di động mới được khởi chạy và cổng của họ đã có sẵn và đang hoạt động.

Problem : Ở một Sprint Product Owner của bạn đưa ra một User Story dành cho ứng dụng trên điện thoại di động này “As a Portal Admin, I should be able to view the signature taken by the delivery person at the time of delivery” . Ở đây cổng thông tin (ứng dụng web) được thay đổi và cập nhật cho phù hợp để phản ánh chữ ký.

Là QA, bạn phải xác minh xem chữ ký đã chụp trong ứng dụng dành cho thiết bị di động đang phản ánh như mong đợi trong cổng thông tin không.

Nếu bạn nhìn vào User Story này, có vẻ đơn giản nhưng có một yêu cầu ẩn ở đây rằng "Đối với lịch sử giao hàng, không có chức năng phản chiếu chữ ký, vậy điều gì sẽ xảy ra nếu những người truy cập cổng xem lịch sử giao hàng?" Dữ liệu lịch sử cần xóa ? Chúng tôi có nên cho phép tai nạn hoặc lỗi cho dữ liệu đó không?

Tất nhiên không phải ở tất cả, điều này nên được xử lý nhã nhặn.

Solution: Khi các bảng DB tương ứng được cập nhật để thêm một cột mới cho vị trí Chữ ký, dữ liệu cũ nên có một giá trị NULL hoặc 0 cần được kiểm tra và một thông báo cho biết 'Không có chữ ký tồn tại' nên được hiển thị.

Điều này có thể được gọi là thiếu sót từ Product Owner hoặc Business Analysis nhưng điều này phải được thực hiện. Thực hiện một tính năng thành công nhưng phá vỡ một cái gì đó cùng với nó không phải là mong muốn của khách hàng. Điều này cần được thực hiện cùng với cùng một câu chuyện của người dùng và trong cùng một Sprint.

Trường hợp 2:

Ứng dụng Tài chính Kế hoạch Hưu Trí (không có BA), một ứng dụng toàn cầu mà Tài chính như CA, Tài chính Cố vấn có thể sử dụng nó cho các loại tiền tệ khác nhau để dự án kế hoạch đầu tư, tiết kiệm, vv thời gian lớn cho khách hàng.

Problem: Product Owner cung cấp cho bạn User Story "As an Advisor, I want to view the report of my customer based on the financial details provided".

Ở đây có 2 yêu cầu ẩn và tôi sẽ gọi nó là một câu chuyện không đầy đủ bởi vì:

• a] Các báo cáo nên xem xét tỷ lệ chuyển đổi tiền tệ hàng ngày và không phải là tỷ lệ chuyển đổi trong lịch sử như trong báo cáo được xem lần gần đây nhất

• b] Nếu đồng tiền được thay đổi sau khi cung cấp chi tiết tài chính của khách hàng, báo cáo sẽ hiển thị bằng đơn vị tiền tệ đã thay đổi.

Solution : Tôi nêu ra mối quan tâm này trực tiếp với Product Owner của chúng tôi và làm cho anh ấy biết rằng cả hai điều này phải được thực hiện càng sớm càng tốt. Ông đã đồng ý với tôi và tạo ra 2 User Stories khác nhau cho Sprint sắp tới với độ ưu tiên cao.

Take Away : Chúng bị tìm ra vì chúng ta đều biết rất rõ về các sản phẩm, thiết kế, cấu trúc của chúng. Kiến thức này chỉ có thể đạt được bằng cách hiểu được sản phẩm một cách hoàn chỉnh, bằng cách hiểu được khả năng tương tác của module và bằng cách nghiên cứu kỹ.

Ghi chép để làm cho mọi thứ dễ dàng hơn và thảo luận với BA và các nhà phát triển về suy nghĩ của họ.

In-Depth look at Acceptance Criteria

Hiểu được các Acceptance Criteria và tất cả các điều kiện và quy tắc khác một cách triệt để thậm chí còn quan trọng hơn việc hiểu một User Story. Bởi vì nếu yêu cầu là không đầy đủ hoặc mơ hồ, nó có thể được đưa lên trong Srpint tiếp theo nhưng nếu một tiêu chí chấp nhận bị bỏ qua, bản thân câu chuyện của người dùng không thể được giải phóng.

Tôi đoán tất cả chúng ta đã có thể sử dụng ngân hàng trực tuyến tại một số điểm và hầu hết chúng ta sử dụng nó mỗi ngày và tôi tải về báo cáo lịch sử của tôi rất nhiều. Nếu bạn quan sát nó cẩn thận, có một số tùy chọn cụ thể có sẵn để tải chúng.

Có một tùy chọn để chọn loại tệp để tải tuyên bố của bạn. Có một tùy chọn để chọn nếu bạn chỉ muốn tải về các Tín dụng / Nợ / cả hai.

Bây giờ hãy tưởng tượng rằng Product Owner cung cấp cho bạn User Story “As a customer, I want to download my account statement so that I can view all my transactions done for a specific period”.

Với các Acceptance Criteria sau đây:

• Xét rằng tôi đang ở trang Tải xuống Báo cáo Lịch sử, tôi nên chọn khoảng thời gian mà tôi muốn tải xuống bản tuyên bố.
• Xét rằng tôi đang ở trang Tải xuống Báo cáo Lịch sử, tôi nên chọn tài khoản mà tôi muốn tải xuống bản tuyên bố.
• Xét rằng tôi đang ở trang Tải xuống Báo cáo Lịch sử, tôi không được phép tải xuống bản tuyên bố cho ngày 'To' trong tương lai.
• Xét rằng tôi đang ở trang Tải xuống Báo cáo Lịch sử, tôi không được phép chọn ngày 'From' 10 năm nữa trong quá khứ.
• Xét rằng tôi tải xuống bản tuyên bố của mình, tôi sẽ có thể xem tệp tin đã tải xuống.
• Xét rằng tôi đang ở trang Tải xuống Báo cáo Lịch sử, tôi sẽ có thể tải xuống tuyên bố của tôi trong định dạng doc, excel và pdf.

If you go through this acceptance, there are 3 things missing here:

Name and format of the file name that will be downloaded. What information (Column names) is to be displayed in the file. The options list to select what kind of a transaction the customer wants i.e. only debits or only credits or both. Such cases may happen once in a while, however still study well about each acceptance criteria and try to visualize it with reference to the user story. The more you study deeply about the conditions and business rules the more will be your knowledge about the feature.

Bugs found in the initial stage cost nothing compared to what it may cost in the ‘testing’ stage.

Nếu bạn trải qua sự chấp nhận này, có 3 điều thiếu ở đây:

• Tên và định dạng của tên tệp sẽ được tải xuống.

• Thông tin gì (Tên cột) sẽ được hiển thị trong tệp.

• Danh sách tùy chọn để chọn loại giao dịch mà khách hàng muốn có nghĩa là chỉ ghi nợ hoặc chỉ có các khoản tín dụng hoặc cả hai.

• Các trường hợp như vậy có thể xảy ra một lần trong một thời gian, tuy nhiên vẫn nghiên cứu tốt về mỗi tiêu chí chấp nhận và cố gắng hình dung nó với tham chiếu đến câu chuyện của người dùng. Bạn càng nghiên cứu sâu hơn về các điều kiện và quy tắc kinh doanh thì bạn càng có nhiều kiến ​​thức về tính năng này.

Lỗi tìm thấy trong giai đoạn ban đầu không tốn nhiều chi phí nếu so với những gì nó có thể tiêu tốn trong giai đoạn testing.

Importance of finding Discrepancies in User Story/Acceptance Criteria

Bởi vì nó bao gồm:

#1) Wastage of Time: Nếu sự khác biệt hoặc sai sót trong các User Story/Acceptance Criteria của người dùng được tìm thấy khi phát triển đang diễn ra hoặc thử nghiệm đang diễn ra, thì rất nhiều việc làm lại có thể cần phải được thực hiện trong thời gian chạy Sprint còn lại.

Điều này không xảy ra ngay cả khi Product Owner bỏ lỡ vài điều, họ sẽ chuyển User Story đến Srpint sắp tới. 95% cơ hội là họ yêu cầu đội thực hiện việc thực hiện cần thiết và giải phóng nó trong cùng một Sprint.

Do đó nó trở thành một cơn ác mộng cho đội vì họ phải dành thêm thời gian, vào cuối tuần hoặc làm việc vào cuối đêm. Điều này có thể tránh được bằng cách nghiên cứu và thảo luận về cácser Story/Acceptance Criteria ở giai đoạn sớm nhất có thể.

#2) Wastage of Efforts: Devs và QA phải xem lại các đoạn code được thực hiện và các trường hợp test một lần nữa. Cập nhật, thêm và loại bỏ theo yêu cầu không phải là một nhiệm vụ dễ dàng. Nó trở nên quá đau đớn vì đã có một áp lực để deliver đúng deadline.

Trong tình huống như vậy, có những sai sót trong giai đoạn phát triển hoặc thử nghiệm. Nếu bạn gặp tình huống như vậy hãy cho "Ghép cặp DevQA'. Như bánh trên bánh, họ có thể bổ trợ cho nhau và các bạn có thể không phải tốn nhiều effort cho việc làm thêm giờ.

Conclusion

Hiểu sâu về User Story and Acceptance Criteria chỉ có thể đạt được bằng cách dành thời gian nghiên cứu nó.

Không có công cụ hoặc khóa học cụ thể sẵn có trên thị trường để làm điều này cho bạn vì đây là tất cả về tư duy logic, kinh nghiệm và kiến ​​thức về sản phẩm.

Tham gia vào cuộc họp trước kế hoạch một cách tích cực, nói chuyện với BA, nghiên cứu của bạn chỉ có thể giúp bạn đạt được điều này. Bạn càng đặt nhiều nỗ lực, bạn càng học và phát triển.

Dù là QA hay Dev, tất cả mọi người phải ở cùng một trang về cácUser Story and Acceptance Criteria của họ, chỉ khi đó sự thành công của khách hàng mới có thể đạt được.

Nguồn : http://www.softwaretestinghelp.com/user-story-acceptance-criteria/#