Критерії прийняття випадкових випадків

Я власник продукту в спритній команді. Я, роблячи тестування прийому на пошту, зазвичай зазначаю, щоб спробувати деякі крайові випадки. Мені нечасто щось виявити, і тоді я передаю його чортам. Коли я відкидаю його розповіді, я отримую відштовхування від одного з розробників. Він каже, що це несправедливо, оскільки я не визначаю кращі випадки та як програма повинна відповідати за критеріями прийняття, оскільки він, як правило, кодує лише те, що я описую в історії. Я закликав його запитувати мене, коли він натрапляє на будь-які крайові випадки під час кодування, але він вважає, що це не його робота, щоб продумати крайові випадки, його міну, і я повинен створити нові історії для наступного спринту.

На мою захист я не знаю його дизайну для історії, поки він не реалізує її, тому важко повторити всі можливості (чи буде конфігурація у файлі БД чи властивостей?). Для простоти скажемо, у нас є історія, щоб додати поділ до програми для калькулятора. Чи в ідеальному світі СКРУМ буде доручено мені додати критерії прийняття "сценарій поділу на нуль" до критеріїв прийняття чи він повинен працювати над тими випадками, коли він розвивається, щоб додаток не набував 5/07? Зрозуміло, що в цьому випадку я б не прийняв, якщо програма сильно вийшла з ладу 5/0, але я проходив би, якщо він реєструє, друкує DIV0 або будь-який інший спосіб вирішення помилки ... до тих пір, поки це не буде Збій.

Я думаю, що відповідь - вам обом слід думати про свій власний набір крайових справ. Він як розробник повинен обробляти крайові випадки, які є специфічними для даних, як-от аварія програми з будь-якого даного вводу користувача, 5/0, безумовно, потрапляє в цю частину спектру. Розробник повинен запитати про вас, що, на вашу думку, було б відповідним повідомленням про помилку, коли введення, подане як частина взаємодії користувача, призводить до чогось недійсного.

Ваша частина спектру - це ділова сторона речей. Як повинен поводитися калькулятор, якщо в обліковому записі користувача не може використовувати кнопку розділення? Як слід поводитись, коли обліковому запису дозволено використовувати операцію Mod, але не має доступу до функції поділу?

Важливе повідомлення, на який я думаю, що вам потрібно передати та прийняти всіх членів команди, - це те, що ви всі в одній команді. Якщо продукт не є повним, то продукт не є повним, і винна команда, а не будь-який член.

Команді потрібно працювати разом, а не мати тип відношення / мантри "Не моя робота, не моя відповідальність".

Критерії прийняття формуються у вигляді:

• Прийняття бізнесу
• Прийняття гарантії якості

Зазвичай прийняття бізнесу зазвичай відповідає на питання:

• Чи реалізована функція виконує те, що я хочу зробити?

Ця функція матиме ряд вимог, орієнтованих на бізнес, наприклад, якщо я натискаю цю кнопку, я очікую, що ця дія відбудеться. У ньому будуть перераховані очікувані бізнес-сценарії та очікувана поведінка, але він не охопить усіх можливих випадків.

Очікується, що вимога бізнесу повинна бути визначена до ітерації, щоб забезпечення якості могло розробити будь-які технічні вимоги щодо комерційних потреб. Забезпечення якості повинно розробляти як руйнівні, так і кращі випадки, якщо це необхідно.

Обидва набори вимог повинні бути переглянуті перед початком будь-якого сюжетного твору, щоб офіційна оцінка та зобов’язання могли відбутися для одиниці роботи. Як тільки це буде зроблено, над функцією / розповідями можна працювати. На сьогоднішній день всім зрозуміло, що потрібно досягти як з бізнес-так, так і з технічної точки зору.

Історія досягає остаточного визнання, як тільки члени команди з питань бізнесу та забезпечення якості вийдуть з неї Це має відбуватися під час ітерації як для прийняття бізнесу, так і для забезпечення якості. Це визначення зробленого (DoD), яке сигналізує про додаткову роботу над історією.

Будь-які нові висновки можуть фіксуватися як дефекти або додаткові відбитки історії. У досконалому світі цього ніколи не відбудеться, але насправді зазвичай існує деяка кількість «відкриттів», що відбувається під час роботи над особливістю / історією. Це природно.

Команда повинна працювати разом (бізнес, QA, розробник) , щоб хеш з будь-якого туманного типу виявлення вимог. Якщо це спритно, всі вони повинні сидіти за одним столом, щоб сприяти спілкуванню та швидкому вирішенню будь-яких питань, які можуть виникнути. Це має вийти приблизно так:

QA:

"Гей, розробнику, ми повинні вирішити цей конкретний сценарій. Я виявив, що якщо я ввожу ці дані, я отримаю помилку."

DEV:

"Це не стосувалося жодних вимог, але ми можемо додати деякі додаткові функціональні можливості, щоб вирішити цю проблему. Добре, Ей, бізнесмено, як би ви хотіли, щоб програма вела себе у цій справі?"

БІЗНЕС:

"Давайте покажемо наше стандартне повідомлення про помилку і дозвольмо користувачеві спробувати ще раз для цього сценарію. Скільки додаткових зусиль буде тоді?"

DEV:

"Це буде просто. Додаткові години чи дві. Я можу взяти на себе цю ітерацію. QA, будь ласка, оновіть свої критерії прийняття цього сценарію, для цього нам не потрібна додаткова історія. Дякую!"

Або якщо це велика робота, до відставання додається нова історія. Команда все ще може прийняти оригінальну історію, оскільки вона відповідає всім оригінальним вимогам, а потім зібрати історію з шипом у наступній ітерації.

Написання програмного забезпечення, яке поводиться надійно внаслідок неправильного або неоднозначного введення, є важливою частиною роботи розробника програмного забезпечення.

Якщо ваші розробники не бачать цього таким чином, включіть додаткові нефункціональні вимоги в специфікацію вимог, які чітко вказують цю вимогу, і надайте своїм розробникам приклад вашого тестового процесу, щоб вони могли застосувати цей процес самостійно, перш ніж подавати остаточний код для перегляду.

Тести на прийняття повинні бути важливою частиною будь-якого документа з вимогами. Якщо вимога також не містить своїх критеріїв прийняття, це насправді не є вимогою; це бажання.

Тут сталося те, що ви виявили цінність . Вхідне значення не замислювалося, коли було написано історію (та критерії прийняття) або коли був написаний код. Якщо це не є частиною критеріїв прийняття, у вас насправді немає підстав для відхилення історії.

Що ми зробили б у моїй команді:

1. Створіть помилку з деталізацією очікуваної та реальної поведінки.
2. Оновіть критерії прийняття, щоб нова знайдена вимога була задокументована.
3. Визначте пріоритет помилку разом з усіма іншими історіями та помилками у наступній ітерації.

Перевага тут полягає в тому, що ви змушені розглянути питання про те, чи виправити цю помилку - це наступне найважливіше, що потрібно зробити. Це може бути або не бути досить важливим для виправлення, але важливо враховувати його значення.

Звичайно, вам все-таки потрібно знайти спосіб заохотити розробників (і себе) дослідити ці крайові справи наперед. Якщо ваша команда розробників не витрачає час на розбиття історій, рекомендуйте їм детально планувати сесію до початку роботи над ними.

Деякі зауваження:

... коли я відкидаю його історії

Я не знаю вашої робочої культури чи процесу, але для мене відкидання історії - важкий крок. Якби я був дияволом, я б також створив поштовх, тому що це записані дії, які погано відображаються на мені та на команді.

Він каже, що це несправедливо, оскільки я не вказую крайових випадків.

Не чесно від нього сподіватися, що ти знаєш усі крайні справи. Але в той же час не чесно, що ти очікуєш від нього. Кожна зміна має ризик, і коли проблеми виявляються, вам потрібно працювати разом, як команда для їх вирішення.

Я не знаю його дизайну для історії, поки він не реалізує її

Ви не повинні знати дизайн. Це може бути корисно знати дизайн, щоб зробити початкові освічені здогадки про те, які історії легші чи складніші для управління відставанням. Але уникайте захоплення розробника у ваш дизайн, коли ви пишете історії. Це витягує всю насолоду від цього, коли ви просто голосово активована клавіатура для PO.

Здається, ви, хлопці, повинні працювати над вдосконаленням процесів і займатися побудовою команди. Деякі речі, які я можу запропонувати для процесу:

• Запропонуйте, щоб розробник включив час у розповіді до обкладинки, що фіксує виявлені крайові корпуси. Чорт забирай, зроби це частиною кожної історії користувача. Це легко можна захистити за допомогою 0 нових помилок. Проблема в тому, що розробник наразі не планує цього. І йому не вистачає часу, коли ви виявляєте проблеми. Це займе час у будь-якому випадку, тому введіть його в історію, де це видно під час планування.
• Після тестування (і до речі дякую за тестування!) Надішліть розробнику список виявлених проблем. Виправлення цих питань буде суперечити умові задоволення "кращих справ".
• Якщо що-небудь залишається нефіксованим або виявлено занадто пізно, вирішіть, чи потрібно розповідати про історію, виходячи з того, чи можна виконати справу використання. Трапляються відомі проблеми та проблеми. Розкрийте їх у примітках до випуску та створіть нові історії для їх виправлення.
• Якщо в процесі є певна груба пляма, яка генерує віддачу, то змініть процес! Зрештою, вдосконалення процесів є частиною Scrum. Наприклад, якщо ваш розробник засмучується, коли ви відхиляєте історію, тоді запропонуйте команді змінити процес, щоб відхилення не викликало виправлень. Зробіть тестування та виправлення до завершеного та відхиленого.
• Працюйте з командою і тим, що вони виробили, і найкращим чином скористайтеся цим. Вони не виконують ідеальної роботи, як і ви. Тож плануйте це. Мої команди, як правило, були девпасами, тому у нас є історія користувача «Незапланована підтримка», кожен спринт для нагальних проблем ... планування для непланових.

Вимоги повинні бути чіткими і стислими. Якщо їх немає, то трапляється саме те, що сталося з вами. Це ваша вина, і найгірше, що ви можете зробити, визначаючи вимоги, - це припускати речі.

Ви конкретний приклад, щодо поділу на нуль. Якщо ви не вказали, що хочете зареєструвати помилку, тоді не скаржтеся, якщо розробник надрукує 100 в результаті.

Але в таких випадках я просто заповнюю пропущені прогалини і передаю їх розробнику. Зрештою, помилки в вимогах все ж трапляються.