Hướng dẫn các tiêu chí gật đầu user story với những 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 xác thực và điều gì sẽ làm cho doanh nghiệp phát triển. Có thể là một doanh nghiệp sản phẩm làm cho sản phẩm phần mềm hoặc một doanh nghiệp dịch vụ cung cấp các dịch vụ trong các nghành 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 ra làm sao.

Thuật ngữ “yêu cầu” mang 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 so 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ổ quát nhất cho việc tạo User Story được nêu về sau:

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

Tỉ 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 để mà chụp và gửi ảnh để tôi có thể nhấp và san sẻ ảnh của tôi cùng với tất cả bầy của tôi.

Tiêu chí gật đầu là một tập hợp các điều kiện kèm theo được gật đầu 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 gật đầu 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 Viên 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 ngân sách. .

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

“Cho một số tiền điều kiện kèm theo 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ó được thể chụp một bức tranh. Khi tôi nhấp vào một trong những bức tranh, tôi sẽ có được thể thêm một chú thích cho hình ảnh trước lúc gửi nó. Nếu có một số vấn đề với việc phát động camera Smartphone của tôi, một thông tin lỗi như ‘Không thể mở màn camera’. vv, nên được hiển thị cho phù hợp.

Do đó, User story xác định yêu cầu so với bất kỳ chức năng hoặc tính năng nào trong những lúc Tiêu chí Đồng ý chấp thuậ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í gật đầu của nó một cách thâm thúy thậm chí là không còn nghi ngờ gì nữa khi mở màn thử nghiệm. Đào sâu vào User story Để mở màn, trước tiên tất cả 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ơ 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 đã thao tác làm việc trên một Dự án ứng dụng dành riêng 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 dân giao hàng.

Các bạn sẽ thấy người giao hàng đến nơi giao hàng của bạn. Và họ có Smartphone di động mà người ta yêu cầu bạn cung cấp chữ ký của bạn sau khoản thời gian giao hàng. Chữ ký này phản ánh trên cổng thông tin của khá nhiều 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 riêng 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 riêng cho ứng dụng trên thiết bị di động này “Với tư cách là Admin, tôi sẽ có được thể xem chữ ký của người giao hàng tại thời khắc giao hàng”. Ở đây cổng thông tin (ứng dụng web) được thay đổi và update cho phù hợp để phản ánh chữ ký.

Với tư cách là Quản lý chất lượng sản phẩm, bạn phải xác minh xem chữ ký đã chụp trong ứng dụng dành riêng cho thiết bị di động đang phản ánh như mong đợi trong cổng thông tin không.

Nếu như 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 “So với lịch sử dân tộc 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 dân truy cập cổng xem lịch sử dân tộc giao hàng?” Tài liệu lịch sử dân tộc cần xóa ?

Giải pháp: Lúc các bảng DB tương ứng được update để thêm một cột mới cho vị trí Chữ ký, tài 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 tin cho thấy ‘Không có chữ ký tồn tại’ nên được hiển thị.

Điều này còn có thể được gọi là thiếu sót từ Chủ sở hữu sản phẩm hoặc Chuyên Viên 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 chiếc 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 đã thao tác 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 những loại tiền tệ khác nhau để lên kế hoạch góp vốn đầu tư, tiết kiệm ngân sách

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 giải trình 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 giải trình 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ử dân tộc như trong giải trình được xem lần gần đây nhất và

• Nếu đồng tiền được thay đổi sau khoản thời gian cung cấp cụ thể chi tiết tài chính của khách hàng, giải trình 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 những tiêu chí gật đầu và tất cả những điều kiện kèm theo và quy tắc khác một cách triệt để thậm chí là 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í gật đầu bị bỏ qua, user story sẽ không còn thể được release.

Tôi đoán tất cả tất cả chúng ta đã có thể sử dụng nhà băng và hồ hết tất cả chúng ta sử dụng nó mỗi ngày và tôi tải về giải trình lịch sử dân tộc của tôi rất nhiều. Nếu như 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 giải trình của bạn. Có một tùy chọn để chọn nếu như khách hàng chỉ muốn tải về các Tín dụng thanh toán / Nợ / cả hai.

Lúc 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ả những thanh toán giao dịch của tôi được thực hiện trong một khoảng tầm thời kì cụ thể”.

Với những Tiêu chí Đồng ý chấp thuận sau đây khi đang ở trang tải xuống lịch sử dân tộc thanh toán giao dịch :

• khoảng tầm thời kì mà tôi muốn tải xuống lịch sử dân tộc thanh toán 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ử dân tộc 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ẽ tiến hành tải xuống.
• tin tức gì (Tên cột) sẽ tiến hành hiển thị trong tệp.
• List tùy chọn để chọn loại thanh toán giao dịch mà khách hàng muốn, tức là chỉ ghi nợ hoặc chỉ có những khoản tín dụng thanh toán 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 kì, tuy nhiên vẫn nghiên cứu tốt về mỗi tiêu chí gật đầu và nỗ lực 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 kèm theo và quy tắc nghiệp vụ thì bạn càng có nhiều tri thức về tính chất năng này.

Lỗi tìm thấy trong thời đoạn ban sơ không có gì ngân sách so với những gì nó có thể ngân sách trong thời đ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í gật đầu ngay từ thời đoạn đầu trong cả trước lúc sự phát triển hoặc kiểm thử mở màn.

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

• Tốn Thời kì: Nếu sự khác biệt hoặc sơ sót trong các tiêu chí gật đầu / 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 sở hữu thể cần phải được thực hiện trong thời kì sprint sót lại.

Điều này sẽ không xẩy ra ngay cả những lúc 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ấp 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 kì, đến vào buổi tối cuối tuần hoặc thao tác làm việc vào thời điểm cuối đêm. Điều này còn có thể tránh khỏi bằng phương pháp nghiên cứu và thảo luận các tiêu chí / user story ở thời đoạn sớm nhất có thể.

• Tốn sức lực lao động: 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. Update, 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 sức ép.

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

Hiểu sâu về User story và tiêu chí gật đầu chỉ có thể đạt được bằng phương pháp dành thời kì nghiên cứu nó.

Không có phương tiện 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à tri thức về sản phẩm.

Tham gia vào cuộc họp trước lúc 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ì sẽ 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í gật đầu của họ, chỉ khi đó sự thành công của khách hàng mới có thể đạt được.

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