Tiêu chí chấp nhận cho các trường hợp cạnh

Tôi là chủ sở hữu sản phẩm trong một nhóm nhanh nhẹn. Tôi khi thực hiện kiểm tra chấp nhận PO tôi thường ghi chú để thử một số trường hợp cạnh. Nó không phải là hiếm khi tôi khám phá một cái gì đó và sau đó tôi chuyển nó trở lại cho các nhà phát triển. Tôi đang bị đẩy lùi từ một trong những nhà phát triển khi tôi từ chối câu chuyện của anh ấy. Anh ấy nói không công bằng vì tôi không chỉ định các trường hợp cạnh và cách chương trình sẽ đáp ứng trong các tiêu chí chấp nhận, vì anh ấy có xu hướng chỉ viết mã cho những gì tôi mô tả trong câu chuyện. Tôi đã khuyến khích anh ấy hỏi tôi khi anh ấy va vào bất kỳ trường hợp cạnh nào trong khi viết mã, nhưng anh ấy nghĩ rằng đó không phải là công việc của anh ấy để suy nghĩ thông qua các trường hợp cạnh, đó là của tôi và tôi nên tạo ra những câu chuyện mới cho lần chạy nước rút tiếp theo.

Để bảo vệ tôi không biết thiết kế của anh ấy cho câu chuyện cho đến khi anh ấy thực hiện nó, vì vậy rất khó để lặp lại tất cả các khả năng (cấu hình sẽ nằm trong tệp DB hoặc thuộc tính?). Để đơn giản, giả sử chúng ta có một câu chuyện để thêm phân chia cho một ứng dụng máy tính. Trong thế giới SCRUM lý tưởng, tôi có cần phải thêm "kịch bản xử lý chia cho 0" cho tiêu chí chấp nhận hay anh ta nên xử lý các trường hợp đó khi phát triển để ứng dụng không phát sinh vào ngày 5/0? Để rõ ràng, trong trường hợp này tôi sẽ không chấp nhận nếu ứng dụng bị lỗi mạnh vào ngày 5/0, nhưng tôi sẽ vượt qua nếu nó ghi nhật ký, in DIV0 hoặc bất kỳ cách nào khác để xử lý lỗi ... miễn là nó không xảy ra tai nạn

Tôi nghĩ rằng câu trả lời là cả hai bạn nên suy nghĩ về trường hợp cạnh của riêng bạn. Với tư cách là nhà phát triển nên xử lý các trường hợp cạnh là dữ liệu cụ thể như ứng dụng bị sập từ bất kỳ đầu vào nào của người dùng, 5/0 chắc chắn rơi vào phần này của phổ. Nhà phát triển nên hỏi về bạn những gì bạn nghĩ sẽ là một thông báo lỗi thích hợp khi đầu vào được đưa ra như một phần của sự tương tác của người dùng dẫn đến một cái gì đó không hợp lệ.

Phần phổ của bạn là khía cạnh kinh doanh của mọi thứ. Máy tính nên hoạt động như thế nào nếu tài khoản người dùng không được phép sử dụng nút chia? Nó nên hoạt động như thế nào khi tài khoản được phép sử dụng thao tác Mod nhưng không có quyền truy cập vào tính năng phân chia?

Thông điệp quan trọng tôi nghĩ rằng bạn cần truyền tải và được sự chấp nhận của tất cả các thành viên trong nhóm, đó là tất cả các bạn trong cùng một đội. Nếu sản phẩm không hoàn thành, sản phẩm không hoàn thành và nhóm phải đổ lỗi, không phải bất kỳ thành viên nào.

Nhóm cần phải làm việc cùng nhau thay vì có thái độ / câu thần chú "Không phải công việc của tôi, không phải trách nhiệm của tôi".

Tiêu chí chấp nhận có ở dạng:

• Chấp nhận kinh doanh
• Đảm bảo chất lượng

Thông thường, sự chấp nhận của doanh nghiệp thường là trả lời câu hỏi:

• Liệu các tính năng đã được thực hiện làm những gì tôi muốn nó làm?

Tính năng này sẽ có một số yêu cầu được định hướng kinh doanh, như nếu tôi nhấn nút này, tôi hy vọng hành động này sẽ xảy ra. Nó sẽ liệt kê (các) kịch bản kinh doanh dự kiến ​​và hành vi dự kiến ​​nhưng nó sẽ không bao gồm tất cả các trường hợp có thể xảy ra.

Dự kiến ​​yêu cầu kinh doanh phải được xác định trước khi lặp để đảm bảo chất lượng có thể phát triển bất kỳ kỹ thuật nào đối với các yêu cầu phi kinh doanh. Đảm bảo chất lượng nên phát triển các trường hợp phá hủy cũng như các trường hợp cạnh khi cần thiết.

Cả hai bộ yêu cầu nên được xem xét trước khi bắt đầu bất kỳ công việc câu chuyện nào để có thể ước tính và cam kết chính thức cho đơn vị công việc. Một khi điều này được thực hiện, tính năng / câu chuyện có thể được làm việc trên. Tại thời điểm này, mọi người đều rõ ràng về những gì sẽ được chuyển giao từ quan điểm kinh doanh và kỹ thuật.

Câu chuyện đạt đến sự chấp nhận cuối cùng một khi các thành viên nhóm đảm bảo chất lượng và kinh doanh đăng nhập vào câu chuyện. Điều này sẽ xảy ra trong quá trình lặp lại cho cả chấp nhận kinh doanh và chấp nhận đảm bảo chất lượng. Đây là định nghĩa của việc thực hiện (DoD) báo hiệu công việc câu chuyện bổ sung có thể được bắt đầu.

Bất kỳ phát hiện mới có thể được ghi lại như là khiếm khuyết hoặc gai câu chuyện bổ sung. Trong một thế giới hoàn hảo, điều này sẽ không bao giờ xảy ra, nhưng trong thực tế thường có một số lượng "khám phá" xảy ra khi làm việc trên một tính năng / câu chuyện. Điều này là tự nhiên.

Các đội phải làm việc cùng nhau (kinh doanh, bảo đảm chất lượng, phát triển) để băm ra bất kỳ loại phát hiện mơ hồ của yêu cầu. Nếu điều này là nhanh nhẹn, tất cả họ nên ngồi cùng một bàn để thúc đẩy giao tiếp và giải quyết nhanh chóng cho bất kỳ câu hỏi có thể phát sinh. Nó sẽ đi một cái gì đó như thế này:

QA:

"Này, Nhà phát triển chúng ta nên xử lý tình huống cụ thể này. Tôi đã phát hiện ra rằng nếu tôi nhập dữ liệu này, tôi sẽ gặp lỗi."

DEV:

"Điều đó không được đề cập trong bất kỳ yêu cầu nào, nhưng chúng tôi có thể thêm một số chức năng bổ sung để giải quyết vấn đề này. OK, Hey Business Person, bạn muốn ứng dụng xử lý như thế nào trong trường hợp này?"

KINH DOANH:

"Hãy hiển thị thông báo lỗi tiêu chuẩn của chúng tôi và cho phép người dùng thử lại cho kịch bản này. Sau đó, sẽ có thêm bao nhiêu nỗ lực?"

DEV:

"Sẽ thật dễ dàng, chỉ một hoặc hai giờ nữa. Tôi có thể cam kết thực hiện lần lặp này. QA vui lòng cập nhật tiêu chí chấp nhận của bạn cho kịch bản này, chúng tôi không cần thêm một câu chuyện cho việc này. Cảm ơn!"

Hoặc nếu đó là một tác phẩm nhiều, một câu chuyện mới được thêm vào hồ sơ tồn đọng. Nhóm vẫn có thể chấp nhận câu chuyện gốc vì nó đáp ứng tất cả các yêu cầu ban đầu, và sau đó chọn câu chuyện tăng đột biến trong lần lặp tiếp theo.

Viết phần mềm ứng xử một cách mạnh mẽ khi đối mặt với đầu vào không chính xác hoặc mơ hồ là một phần thiết yếu trong công việc của nhà phát triển phần mềm.

Nếu nhà phát triển của bạn không thấy nó theo cách đó, hãy bao gồm các yêu cầu phi chức năng bổ sung trong đặc tả yêu cầu nêu rõ yêu cầu này và cung cấp cho nhà phát triển của bạn một ví dụ về quy trình thử nghiệm của bạn để họ có thể tự áp dụng quy trình đó trước khi gửi bản cuối cùng mã để xem xét.

Các bài kiểm tra chấp nhận nên là một phần quan trọng của bất kỳ tài liệu yêu cầu nào. Nếu một yêu cầu không nêu rõ các tiêu chí của nó để chấp nhận, thì đó không thực sự là một yêu cầu; đó là một điều ước

Điều đã xảy ra ở đây là bạn đã phát hiện ra giá trị . Giá trị đầu vào không được nghĩ đến khi câu chuyện (và tiêu chí chấp nhận) được viết hoặc khi mã được viết. Nếu đó không phải là một phần của tiêu chí chấp nhận, bạn thực sự không có cơ sở để từ chối câu chuyện.

Những gì chúng tôi sẽ làm trong nhóm của tôi là:

1. Tạo một lỗi chi tiết hành vi dự kiến ​​và thực tế.
2. Cập nhật các tiêu chí chấp nhận để yêu cầu tìm thấy mới được ghi lại.
3. Ưu tiên Bug cùng với tất cả các Câu chuyện và Lỗi khác trong lần lặp tiếp theo.

Lợi ích ở đây là bạn buộc phải xem xét việc sửa lỗi này hay không là điều quan trọng nhất tiếp theo phải làm. Nó có thể hoặc không đủ quan trọng để sửa chữa, nhưng điều quan trọng là giá trị của nó được xem xét.

Tất nhiên, bạn vẫn cần tìm cách khuyến khích các nhà phát triển (và chính bạn) khám phá những trường hợp cạnh này ở phía trước. Nếu nhóm nhà phát triển của bạn không dành thời gian chia nhỏ câu chuyện, hãy khuyến khích họ có phiên lập kế hoạch chi tiết trước khi bắt đầu làm việc với họ.

Một số quan sát:

... khi tôi từ chối những câu chuyện của anh ấy

Tôi không biết văn hóa hoặc quy trình làm việc của bạn, nhưng với tôi từ chối một câu chuyện là một bước nghiêm trọng. Nếu tôi là nhà phát triển, tôi cũng sẽ tạo ra sự thúc đẩy vì đó là hành động được ghi lại phản ánh không tốt đến tôi và về đội.

Ông nói không công bằng vì tôi không chỉ định các trường hợp cạnh.

Thật không công bằng khi anh ta mong bạn biết tất cả các trường hợp cạnh. Nhưng đồng thời, thật không công bằng khi bạn mong đợi điều đó ở anh ấy. Mọi thay đổi đều có rủi ro và khi các vấn đề được phát hiện, bạn cần phải làm việc cùng nhau như một nhóm để giải quyết chúng.

Tôi không biết thiết kế của anh ấy cho câu chuyện cho đến khi anh ấy thực hiện nó

Bạn không cần phải biết thiết kế. Có thể hữu ích khi biết thiết kế để đưa ra những phỏng đoán có giáo dục ban đầu về việc câu chuyện nào dễ hơn hoặc khó hơn để quản lý tồn đọng. Nhưng tránh bẫy nhà phát triển vào thiết kế của bạn khi bạn viết truyện. Nó hút tất cả những điều thú vị từ nó khi bạn chỉ đơn giản là một bàn phím kích hoạt bằng giọng nói cho PO.

Có vẻ như các bạn nên làm việc để cải thiện quy trình và thực hiện xây dựng đội ngũ. Một số điều tôi có thể đề xuất cho quá trình:

• Đề nghị các nhà phát triển bao gồm thời gian trong câu chuyện để sửa chữa các trường hợp cạnh được phát hiện. Heck, làm cho nó một phần của mỗi câu chuyện người dùng. Điều này có thể dễ dàng phòng thủ thông qua mục tiêu 0 lỗi mới được giới thiệu. Vấn đề là nhà phát triển hiện không có kế hoạch cho nó. Và anh ấy đã hết thời khi bạn phát hiện ra vấn đề. Dù sao đi nữa cũng sẽ mất thời gian, vì vậy hãy đặt nó vào câu chuyện có thể nhìn thấy trong khi lập kế hoạch.
• Sau khi thử nghiệm (và cảm ơn bạn đã thử nghiệm bằng cách này!), Hãy gửi cho nhà phát triển danh sách các vấn đề được phát hiện. Việc sửa chữa những vấn đề đó sẽ đi ngược lại điều kiện "sửa chữa các trường hợp cạnh".
• Nếu bất cứ điều gì vẫn chưa được trộn hoặc được phát hiện quá muộn, hãy quyết định xem câu chuyện có cần được đẩy hay không dựa trên việc liệu trường hợp sử dụng có thể được thực hiện hay không. Vấn đề được biết đến và xung quanh công việc xảy ra. Tiết lộ chúng trong ghi chú phát hành và tạo ra những câu chuyện mới để sửa chúng.
• Nếu có một điểm thô đặc biệt trong quy trình tạo ra phản hồi, thì hãy thay đổi quy trình của bạn! Rốt cuộc, cải tiến quy trình là một phần của Scrum. Ví dụ: nếu nhà phát triển của bạn buồn bã khi bạn từ chối câu chuyện, thì hãy đề xuất với nhóm thay đổi quy trình để từ chối không kích hoạt sửa lỗi. Thực hiện kiểm tra và sửa lỗi trước khi Hoàn thành và Từ chối.
• Làm việc với nhóm và những gì họ đã sản xuất và sử dụng nó tốt nhất bạn có thể. Họ không làm công việc hoàn hảo và bạn cũng vậy. Vì vậy, kế hoạch cho điều đó. Các nhóm của tôi thường là người sùng đạo, vì vậy chúng tôi có câu chuyện người dùng Hỗ trợ không có kế hoạch mỗi lần chạy nước rút cho các vấn đề nổi cộm ... lập kế hoạch cho những người không có kế hoạch.

Các yêu cầu phải rõ ràng và súc tích. Nếu họ không, sau đó xảy ra chính xác những gì đã xảy ra với bạn. Đó là lỗi của bạn, và điều tồi tệ nhất bạn có thể làm khi chỉ định các yêu cầu là giả định mọi thứ.

Bạn ví dụ cụ thể, về chia cho số không. Nếu bạn không xác định rằng bạn muốn ghi lại lỗi, thì đừng phàn nàn nếu nhà phát triển in 100 kết quả.

Nhưng trong những trường hợp như vậy, tôi sẽ chỉ lấp đầy những khoảng trống còn thiếu và chuyển chúng cho nhà phát triển. Rốt cuộc, lỗi trong yêu cầu xảy ra.