User story là gì và tiêu chí chấp nhận

Hướng dẫn các tiêu chí chấp nhận user story với các kịch bản thực tế.

Trong ngành phát triển phần mềm, từ 'Yêu cầu' xác định mục tiêu, những gì khách hàng cần chính xác và điều gì sẽ làm cho công ty phát triển. Có thể là một công ty sản phẩm làm cho sản phẩm phần mềm hoặc một công ty dịch vụ 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à yêu cầu 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ữ "yêu cầu" có tên khác nhau trong các phương pháp luận dự án khác nhau.

Trong mô hình water fall , nó được gọi là 'Requirement / Specification Document', trong Agile hoặc SCRUM nó được gọi là 'Epic', '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 được nêu dưới đây:

Là <vai trò người dùng / khách hàng, tôi muốn <mục tiêu cần đạt được> để tôi có thể <lý do của mục tiêu>.

Thí dụ:

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.

Tiêu chí chấp nhận 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 nghiệp vụ mà chức năng hoặc tính năng phải đáp ứng và đáp ứng, để được chấp nhận bởi Chủ sở hữu sản phẩm / Các bên liên quan.

Đây là một phần rất quan trọng trong việc hoàn thành User story và cần được nghiên cứu bởi Chủ sở hữu sản phẩm và Chuyên gia phân tích 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í. .

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

"Cho một số tiền điều kiện khi tôi làm một số hành động và tôi mong đợi kết quả".

Ví dụ (từ User story ở trên):

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 tranh. Khi tôi nhấp vào một bức tranh, 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 xác định yêu cầu đối với bất kỳ chức năng hoặc tính năng nào trong khi Tiêu chí Chấp nhận xác định ' hoàn thành' cho User story hoặc yêu cầu.

Là một QA, rất quan trọng để hiểu được User story và các tiêu chí chấp nhận 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 thử nghiệm. Đào sâu vào User story Để bắt đầu, trước tiên chúng ta hãy hiểu tầm quan trọng của một nghiên cứu sâu về một điều căn bản và cơ bản, đó là User story.

Các trường hợp sau đây là kinh nghiệm thực tế của riêng tôi.

Trường hợp 1:

3 năm trước, tôi đã làm việc trên một 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 thông tin của họ đã có sẵn và đang hoạt động.

Vấn đề: chủ sở hữu Sản phẩm của bạn có User story dành cho ứng dụng trên thiết bị di động này "Với tư cách là Admin, tôi sẽ có thể xem chữ ký của người giao hàng tại thời điểm giao hàng". Ở đâ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ý.

Với tư cách là Quản lý chất lượng, 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 ?

Giải pháp: 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ừ Chủ sở hữu sản phẩm hoặc Chuyên gia phân tích 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.

Trường hợp số 2

6 năm trước, tôi đã làm việc về Ứ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 có thể sử dụng nó cho các loại tiền tệ khác nhau để lên kế hoạch đầu tư, tiết kiệm

Vấn đề: Chủ sở hữu Sản phẩm cung cấp cho bạn User story "Với tư cách là Người cố vấn, tôi muốn xem báo cáo của khách hàng của tôi dựa trên các thông tin tài chính được cung cấp".

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

• 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 và

• 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

Giải pháp: Tôi nêu ra mối quan tâm này trực tiếp với Chủ sở hữu sản phẩm của chúng tôi và làm cho anh ta 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 story khác nhau cho sprint sắp tới với sự ưu tiên.

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ọ.

Hiểu được các tiêu chí chấp nhận 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 lần chạy sprint tiếp theo nhưng nếu một tiêu chí chấp nhận bị bỏ qua, user story sẽ không thể được release.

Tôi đoán tất cả chúng ta đã có thể sử dụng ngân hàng 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 báo cáo 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 Chủ sở hữu sản phẩm cung cấp cho bạn user story này "Là khách hàng, tôi muốn tải xuống bản sao kê tài khoản của mình để tôi có thể xem tất cả các giao dịch của tôi được thực hiện trong một khoảng thời gian cụ thể".

Với các Tiêu chí Chấp nhận sau đây khi đang ở trang tải xuống lịch sử giao dịch :

• khoảng thời gian mà tôi muốn tải xuống lịch sử giao dịch.
• tài khoản mà tôi muốn tải xuống .
• không được phép tải xuống lịch sử cho ngày trong tương lai.
• không được phép chọn ngày 10 năm trước trong quá khứ.
• có thể xem tệp tin đã tải xuống.
• có thể tải xuống trong định dạng doc, excel và pdf.

Có 3 điều thiếu ở các tiêu chí trên :

• 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, 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 User story. Bạn càng nghiên cứu sâu hơn về các điều kiện và quy tắc nghiệp vụ 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 có gì chi phí so với những gì nó có thể chi phí trong giai đoạn kiểm thử.

Điều quan trọng là phải thực hiện tìm hiểu sâu sâu user story và các tiêu chí chấp nhận ngay từ giai đoạn đầu ngay cả trước khi sự phát triển hoặc kiểm thử bắt đầu.

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

• Tốn Thời gian: Nếu sự khác biệt hoặc sai sót trong các tiêu chí chấp nhận / user story được tìm thấy khi phát triển đang diễn ra hoặc kiểm thử đ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 sprint còn lại.

Điều này không xảy ra ngay cả khi Chủ sở hữu sản phẩm bỏ lỡ vài điều, họ sẽ chuyển user story đến lần sprint sắp tới. 95% là họ yêu cầu đội thực hiện việc công viêc cần thiết và release trong cùng 1 sprint.

Do đó nó trở thành một cơn ác mộng cho đội phát triển vì họ phải dành thêm thời gian, đến 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 các tiêu chí / user story ở giai đoạn sớm nhất có thể.

• Tốn công sức: Các developer và QA phải xem lại code được thực hiện và test cases 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ó sẽ trở thành áp lực.

Trong tình huống như vậy, sẽ có những sai sót trong giai đoạn phát triển hoặc kiểm thử.

Hiểu sâu về User story và tiêu chí chấp nhận 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 khi lên kế hoạch một cách tích cực, nói chuyện với BA, tự nghiên cứu . Bạn càng đặt nhiều nỗ lực, bạn càng học thì càng phát triển.

Dù là QA hay developer, tất cả mọi người phải ở cùng hướng về user story và các tiêu chí chấp nhận của họ, chỉ khi đó sự thành công của khách hàng mới có thể đạt được.

Bài viết được dịch lại từ nguồn: http://www.softwaretestinghelp.com/user-story-acceptance-criteria/#more-22289