Cách phù hợp với thử nghiệm trong các lần chạy nước rút của Scrum và cách viết các câu chuyện của người dùng trong Scrum

Tôi là trưởng nhóm phát triển của một dự án mới tại công ty của tôi. Đây là dự án đầu tiên mà công ty sẽ sử dụng Scrum. Chúng tôi có một thác nước / SDLC lặp. Các BA viết tài liệu yêu cầu, bàn giao cho dev và kiểm tra, dev bắt đầu phát triển và sẽ phát hành để thử nghiệm trong các lần lặp. Người kiểm thử mất nhiều thời gian để kiểm tra bản phát hành mà theo đó các nhà phát triển tiếp tục phát triển nhưng cũng sửa lỗi cho bản phát hành hiện tại. Tôi có một vài câu hỏi

1. Trong một lần chạy nước rút với 5 câu chuyện khi nào bạn phát hành để thử nghiệm? Có phải ngay khi một câu chuyện được hoàn thành bởi dev hoặc sau khi tất cả các câu chuyện được hoàn thành nhưng trước khi kết thúc nước rút, hãy kiểm tra thời gian cần thiết để kiểm tra.
2. Nếu BA viết câu chuyện người dùng thì nên là chi tiết. Theo truyền thống, phải mất nhiều thời gian để viết một thông số kỹ thuật với tất cả bố cục UI, hành vi, văn bản, vv để được hoàn thiện. Tôi đoán câu hỏi của tôi là làm thế nào để viết những câu chuyện có thể thực hiện và kiểm tra được.
3. Nhóm thử nghiệm của chúng tôi là phi kỹ thuật. Việc kiểm tra giao diện người dùng tự động đối với Scrum quan trọng như thế nào. Giao diện người dùng dựa trên WPF.

Tôi có kinh nghiệm phát triển vững chắc bằng cách sử dụng các phương thức nhanh (TDD, đánh giá mã, tái cấu trúc, v.v.) nhưng mới đối với scrum.

chỉnh sửa: Bằng cách lặp lại, ý tôi là nếu có 100 yêu cầu, chúng tôi có thể đưa ra để thử nghiệm khi chúng tôi đã hoàn thành 30, 35, 35 yêu cầu thay vì đợi đến khi tất cả 100 yêu cầu đã được hoàn thành.

Nếu thử nghiệm tách biệt với phát triển, bạn có hai nhóm scrum riêng biệt. Đó là một ý tưởng tồi để có một tay làm việc khác.

Các nhà phát triển của bạn phải viết các bài kiểm tra của riêng họ, tách biệt với nhóm khác này. Bạn phải coi nhóm "kiểm tra" này là khách hàng của mình.

Trong một lần chạy nước rút ... khi nào bạn phát hành để thử nghiệm?

Khi nước rút được thực hiện. Hoàn thành Điều đó có nghĩa là bạn đã thực hiện kiểm tra đơn vị của riêng mình và chắc chắn rằng nó hoạt động. Sau khi nhóm phát triển của bạn hoàn tất, bạn phát hành nó cho các nhóm khác để "thử nghiệm" hoặc "triển khai" hoặc bất kỳ điều gì khác xảy ra trong tổ chức.

Tôi đoán câu hỏi của tôi là làm thế nào để viết những câu chuyện có thể thực hiện và kiểm tra được.

Điều đó thay đổi từ đội này sang đội khác. BA là một phần của nhóm phát triển. Bạn phải làm việc với tư cách là một nhóm (BA cộng với các nhà phát triển) để có được số lượng chi tiết phù hợp. Đó là nỗ lực của nhóm để có được thông tin chính xác từ BA đến các thành viên còn lại trong nhóm.

Việc kiểm tra giao diện người dùng tự động đối với Scrum quan trọng như thế nào.

Thiết yếu. Hoàn toàn cần thiết cho bất kỳ sự phát triển UI. Các nhà phát triển phải tự thực hiện tất cả các thử nghiệm trước khi nó được trao cho "nhóm thử nghiệm". Nếu có UI, họ phải kiểm tra nó. Nếu không có UI, thì không cần kiểm tra UI tự động. Kiểm tra là cần thiết, và một giao diện người dùng phải được kiểm tra. Kiểm tra tự động là thực hành tốt nhất hiện nay.

Dòng dưới cùng. Một nhóm "kiểm tra" riêng biệt và một BA viết từng chi tiết nhỏ không phải là một tổ chức tối ưu cho Scrum. Scrum có nghĩa là bạn phải suy nghĩ lại về tổ chức cũng như các quy trình của bạn.

Hầu hết các câu trả lời tôi sẽ đưa ra liên quan đến một phương pháp phát triển phần mềm Agile so với phương pháp Thác lặp. Scrum chỉ là một triển khai Agile phổ biến.

1. Trong Scrum điển hình không có giai đoạn thử nghiệm riêng biệt, bởi vì thử nghiệm chính thức nên xảy ra trong toàn bộ nước rút. Khi nhà phát triển hoàn thành Câu chuyện người dùng, tài nguyên QA đã chuẩn bị sẵn các trường hợp thử nghiệm của anh ấy / cô ấy và bắt đầu thử nghiệm tại thời điểm đó. Nếu trường hợp thử nghiệm của họ vượt qua, họ chấp nhận câu chuyện của người dùng và chuyển sang câu chuyện tiếp theo. Khi tất cả Câu chuyện của Người dùng đã được hoàn thành và Được chấp nhận thì chạy nước rút kết thúc và bạn bắt đầu câu chuyện tiếp theo. Tất cả điều này phụ thuộc vào Tích hợp liên tục, vì vậy những thay đổi phát triển ngay lập tức có sẵn cho QA. Phát triển hơn nữa nên tuân theo các hướng dẫn TDD để đảm bảo kiểm tra hồi quy nhanh và không đau nhất có thể.

2. Đó là một ý tưởng tốt cho BA để viết câu chuyện của người dùng, nhưng để kiểm soát chi tiết và cụ thể hơn, Câu chuyện người dùng có thể đi kèm với các tài liệu Yêu cầu chính thức. Câu chuyện người dùng nên được viết theo quan điểm của một người dùng theo vai trò. Nó thể hiện nhu cầu theo quan điểm của người dùng, do đó, khá tự nhiên nếu phần mềm hiện đang đáp ứng tất cả các khía cạnh của nhu cầu đó thì câu chuyện của người dùng đang được đáp ứng. Câu chuyện của người dùng có thể bao gồm các câu chuyện người dùng trẻ em và Nhiệm vụ được giao. Có thể có sự trùng lặp trong Nhiệm vụ cho nhiều câu chuyện của người dùng.

3. Kiểm tra giao diện người dùng tự động có thể là một điều tốt, nhưng cá nhân tôi cảm thấy rằng nỗ lực nhiều hơn về các phương pháp TDD và phạm vi kiểm tra đơn vị 100% của tất cả các Logic nghiệp vụ là quan trọng hơn. Hầu hết các nhóm phát triển phần mềm dường như không thể đạt được phạm vi bao phủ 100% về Logic nghiệp vụ, vì vậy theo tôi, Kiểm tra giao diện người dùng tự động sẽ lãng phí thời gian quý báu có thể được sử dụng để viết thêm các bài kiểm tra đơn vị cho BL. Đó là một sự xa xỉ không phải là một nhu cầu trong quan điểm của tôi.

1. Trong Scrum, bạn phải tạo ra sự gia tăng phần mềm có thể thay đổi được vào cuối mỗi lần chạy nước rút. Do đó, Scrum thúc đẩy khái niệm về toàn bộ nhóm hoặc nhóm chức năng chéo trong đó mọi kỹ năng cần có để dẫn dắt một câu chuyện người dùng nhất định phải thực hiện phải có trong nhóm.

   Trong dự án hiện tại của tôi, vì một câu chuyện được thử nghiệm đầy đủ là một phần định nghĩa được thực hiện của chúng tôi, chúng tôi đã nhúng các thử nghiệm trong các nhóm. Trong vài ngày đầu tiên của cuộc chạy nước rút, trong khi các nhà phát triển bắt đầu làm việc với những câu chuyện người dùng đầu tiên, những người thử nghiệm sẽ chuẩn bị các kịch bản thử nghiệm và thiết lập một số dữ liệu thử nghiệm. Ngay sau khi nhà phát triển cho một trong những câu chuyện của người dùng kết thúc, họ sẽ kiểm tra nó.

2. Đây là một trong những khó khăn lớn nhất trong Scrum IMO. Bạn phải tìm đúng số lượng đặc điểm kỹ thuật cần thiết để có được một câu chuyện người dùng có thể kiểm tra được. Quá nhiều phân tích, tài liệu và đặc điểm kỹ thuật trả trước sẽ dẫn đến một kế hoạch cứng nhắc chắc chắn sẽ chứng minh sai trong quá trình chạy nước rút. Ngược lại, câu chuyện người dùng chưa được Chủ sở hữu sản phẩm xác định rõ ràng và thể hiện sẽ dẫn đến băng thông liên lạc bão hòa giữa các nhà phát triển và PO trong Sprint và trì hoãn phát triển trong khi PO đưa ra quyết định về câu chuyện của người dùng giữa chừng trong giai đoạn nước rút .

   Trong trường hợp của chúng tôi, chúng tôi đã xác định số lượng chi tiết phù hợp cho câu chuyện của người dùng là 1 / mô tả dưới dạng "như một ... tôi muốn ... để ..." và 2 / một loạt chấp nhận tiêu chí. Chúng tôi hiếm khi tạo ra các bản nhái của UI trước đó, nó có thể xảy ra trong quá trình chạy nước rút nhưng chúng là những bản phác thảo bị loại bỏ sau đó.

3. Theo kinh nghiệm của tôi, kiểm tra giao diện người dùng tự động cực kỳ tốn thời gian và cực kỳ dễ vỡ. Có nhiều cách để làm điều đó trong WPF nhưng tôi sẽ cẩn thận suy nghĩ về chi phí bảo trì của các thử nghiệm như vậy với các lợi ích trước khi đi theo cách đó.

Làm việc trong các vòng lặp ngắn hơn và ngắn hơn làm cho tất cả các bàn giao này ngày càng đắt hơn. Bạn có thể giảm các chi phí này bằng cách tuân theo một quy tắc đơn giản, ngu ngốc: giảm một nửa kích thước lô, thay đổi cách bạn làm việc để làm cho thoải mái, lặp lại cho đến khi hạnh phúc.

Lấy ví dụ nước rút 5 tầng của bạn. Nếu các nhóm của bạn đã quen viết mã cho tất cả 5 câu chuyện, sau đó thử nghiệm tất cả 5 câu chuyện, thì kích thước lô là 5 câu chuyện. Cắt nó làm đôi. Trong lần chạy nước rút tiếp theo, trước tiên hãy làm việc với 3 câu chuyện khẩn cấp nhất, để chúng sẵn sàng để thử nghiệm sớm nhất có thể. Khi những người thử nghiệm đang thử nghiệm 3 câu chuyện đó, phần còn lại có thể có 2 câu chuyện còn lại sẵn sàng để thử nghiệm. Điều này sẽ gây ra một số cơn đau ngày càng tăng. Thay đổi cách bạn làm việc để làm cho điều này thoải mái hơn.

Ví dụ, nhiều người sẽ làm việc trên mỗi câu chuyện cùng nhau, vì vậy hãy thử ghép nối nhiều hơn và xem điều đó có giúp bạn làm việc ổn định hơn không. Hoặc, có lẽ, những người thử nghiệm sẽ tìm thấy những vấn đề trong câu chuyện 2 khiến một số lập trình viên mất tập trung trong khi họ đang cố gắng làm việc ở câu chuyện 5, vì vậy hãy khuyến khích các lập trình viên và những người thử nghiệm chạy nước rút tiếp theo để thảo luận về cách kiểm tra một trong những câu chuyện trong "đợt đầu tiên "Để các lập trình viên ít có khả năng mắc lỗi mà người kiểm tra có thể dễ dàng bắt được bằng một bài kiểm tra.

Có thể mất một vài lần chạy nước rút để giải quyết các vấn đề lớn liên quan đến những người thử nghiệm kiểm tra một loạt câu chuyện nhỏ trong khi các lập trình viên làm việc với các câu chuyện tiếp theo. Một khi nó trở nên thoải mái, cắt giảm kích thước lô một nửa một lần nữa. Và một lần nữa. Trong vòng một năm hoặc lâu hơn, nhóm sẽ thoải mái thử nghiệm các câu chuyện vì các lập trình viên tin rằng họ đã hoàn thành với chúng và có thể ít mắc lỗi hơn trên đường đi. Mỗi câu chuyện sẽ được thực hiện sớm hơn.

Tất nhiên, tại thời điểm này, bây giờ bạn có thể làm điều tương tự với các lô mà nhóm nhận được từ chủ sở hữu sản phẩm hoặc nhóm gửi đến tổ chức hoạt động. Và như thế. Tại thời điểm này, bạn có thể giải quyết "các BA nên viết bao nhiêu chi tiết cho các câu chuyện?" vấn đề.

Nhân tiện: để những người thử nghiệm có thể giảm thời gian quay vòng, họ sẽ phải áp dụng một số tự động hóa, bằng cách kết hợp học cách tự động hóa và lập trình viên giúp họ tự động hóa. Khi bạn cố gắng giảm kích thước lô, bạn sẽ tìm ra khi nào bạn cần khắc phục những sự cố đó. Đừng thêm tự động hóa chỉ vì một cuốn sách nói rằng bạn cần nó.

Tôi hy vọng rằng sẽ giúp bạn.

Chỉ muốn chia sẻ một số kinh nghiệm như dưới đây, hy vọng rằng nó hữu ích cho bạn.

Trong một lần chạy nước rút với 5 câu chuyện khi nào bạn phát hành để thử nghiệm? Có phải ngay khi một câu chuyện được hoàn thành bởi dev hoặc sau khi tất cả các câu chuyện được hoàn thành nhưng trước khi kết thúc nước rút, hãy kiểm tra thời gian cần thiết để kiểm tra.

Đối với mỗi câu chuyện người dùng lớn, nó nên được chia thành nhiều nhiệm vụ phụ và khi các nhiệm vụ phụ hoàn thành bởi nhà phát triển, chúng nên được phát hành cho QC để thử nghiệm ngay lập tức. Khiếm khuyết nên được sửa chữa sau khi thử nghiệm cho các nhiệm vụ phụ kết thúc thử nghiệm.

Nếu BA viết câu chuyện người dùng thì nên là chi tiết. Theo truyền thống, phải mất nhiều thời gian để viết một thông số kỹ thuật với tất cả bố cục UI, hành vi, văn bản, vv để được hoàn thiện. Tôi đoán câu hỏi của tôi là làm thế nào để viết những câu chuyện có thể thực hiện và kiểm tra được.

Trong Scrum, các câu chuyện của người dùng phải ở bất kỳ định dạng nào miễn là các cuộc hội thoại xung quanh các câu chuyện xảy ra và không được mong đợi sẽ được hoàn thành hoặc tĩnh. Một câu chuyện nhỏ, được gọi đơn giản là một câu chuyện của người dùng, là một câu chuyện được hiểu rõ và có thể được thực hiện trong giai đoạn nước rút. Ưu tiên của câu chuyện có thể dựa trên ROI, giá trị doanh nghiệp hoặc bất cứ điều gì khác mà người dùng đồng ý là quan trọng. Đây là hoạt động của PO.

Nhóm thử nghiệm của chúng tôi là phi kỹ thuật. Việc kiểm tra giao diện người dùng tự động đối với Scrum quan trọng như thế nào. Giao diện người dùng dựa trên WPF

Áp dụng thử nghiệm tự động hóa trong Scrum là hoạt động khá khó khăn. Bởi vì tất cả các chức năng được triển khai không đầy đủ và không thực sự ổn định để cho phép QC triển khai trường hợp thử nghiệm bằng một số công cụ kiểm tra tự động. Nó nên được thực hiện cho một lần chạy nước rút gọi là: hồi quy.