Меню

Що таке історія користувача та критерії прийняття (приклади)

what is user story acceptance criteria

Спробуйте Наш Інструмент Для Усунення Проблем

Ідеальний посібник з критеріїв прийняття історії користувачів із реальними сценаріями:

У галузі розробки програмного забезпечення слово «Вимога» визначає, якою є наша мета, що саме потрібно клієнтам і що змусить нашу компанію збільшити свій бізнес.

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

Термін «вимога» має різні назви в різних методологіях проекту.

В Водоспад , це називається ' Документ з вимогами / специфікацією ’, В Agile або SCRUM його називають «Епічним», «Історією користувача».

Історія користувача та критерії прийняття

За моделлю «Водоспад» документи «Вимога» складають величезні документи на 200 або більше сторінок, оскільки весь продукт реалізований в один етап. Але це не так у випадку з Agile / SCRUM, оскільки в цих методологіях даються вимоги щодо невеликих функціональних можливостей або особливостей, оскільки продукт готується поетапно.

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

Давайте спочатку відвідаємо основи.

Що ви дізнаєтесь:

Що таке історія користувача?

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

Найбільш часто використовуваний стандартний формат для створення історії користувача зазначений нижче:

Як

Приклад:

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

Історія користувача та критерій прийняття

Що таке критерії прийнятності?

Критерій прийнятності - це набір прийнятих умов або ділових правил, яким повинна відповідати функціональність або функція, щоб їх прийняли Власник продукту / Зацікавлені сторони.

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

Його формат такий:

' Враховуючи певні передумови, коли я роблю певні дії, я очікую на результат '.

чому потрібно запускати програму, використовуючи дані тесту для введення?

Приклад (w.r.t до вищезгаданої історії користувача):

  • Давайте врахуємо, що я спілкуюся в чаті з другом, і я мав би змогу зробити знімок.
  • Коли я натискаю на зображення, я маю змогу додати до нього підпис перед надсиланням.
  • Якщо виникає проблема із запуском камери телефону, з’являється повідомлення про помилку, наприклад „Не вдається запустити камеру“. тощо, слід відображати відповідно.

Отже, історія користувача визначає вимогу щодо будь-якої функціональності чи функції, тоді як Критерії прийняття визначає „Визначення виконаного” для історії користувача або вимоги.

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

Копаючись глибоко в історіях користувачів

Для початку давайте спочатку зрозуміємо важливість «поглибленого» вивчення базової та фундаментальної речі, тобто Історії користувачів.

Наступні випадки - це мій власний реальний досвід.

Випадок №1:

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

Ви б бачили, як до вас приїжджає постачальник. І у них є мобільний телефон, на якому вони просять вас дати свій підпис після доставки. Цей підпис відображається на порталі постачальників кур'єрських послуг, таких як DTDC, FedEx тощо.

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

Проблема: Для Sprint власник вашого продукту має історію користувача для цього мобільного додатка, який «Як адміністратор порталу я повинен мати можливість переглянути підпис, прийнятий особою, що доставляє, під час доставки» . Тут портал (веб-додаток) змінюється та оновлюється відповідно до відображення підпису.

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

Якщо ви подивитесь на цю історію користувачів, вона виглядає просто, але тут є прихована вимога: 'Щодо історичних поставок функція відображення підписів не існувала, то що має статися, якщо хлопці порталу переглядають історичні доставки?' Чи слід знищити історичні дані? Чи слід допускати збої або помилки таких даних?

Звичайно, зовсім не, з цим слід поводитись люб’язно.

Рішення: Коли відповідні таблиці БД оновлюються, щоб додати новий стовпець для розташування Підпис, старі дані повинні мати значення NULL або 0, яке слід перевірити, і повинно бути показано повідомлення про те, що «Підпис не існує».

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

Справа No2

6 років тому я працював над заявкою на фінансування виходу на пенсію (без бакалавра), яка була глобальною програмою, де такі люди, як Фінанси, такі як CA, консультанти з фінансів, могли використовувати її для різних валют для проектування інвестиційних планів, заощаджень тощо тощо. великий період для своїх клієнтів.

Проблема: Власник продукту надає вам історію користувача «Як радник я хочу переглянути звіт мого замовника на основі наданих фінансових деталей».

Тут було 2 приховані вимоги, і я б назвав це неповною історією, оскільки:

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

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

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

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

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

Поглиблений погляд на критерії прийнятності

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

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

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

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

З наступними критеріями прийнятності:

  • Враховуючи те, що я перебуваю на сторінці Завантажити історичну заяву, мені слід вибрати період, протягом якого я хочу завантажити заяву.
  • Враховуючи те, що я перебуваю на сторінці Завантажити історичну заяву, мені слід вибрати обліковий запис, для якого я хочу завантажити заяву.
  • Враховуючи те, що я перебуваю на сторінці Завантажити історичну заяву, мені не дозволяється завантажувати заяву на майбутню дату „До”.
  • Враховуючи те, що я перебуваю на сторінці Завантажити історичну заяву, мені не дозволять вибирати дату «Від», яка не перевищувала 10 років тому.
  • Враховуючи те, що я завантажую свою заяву, я повинен мати можливість переглянути завантажений файл.
  • Враховуючи, що я перебуваю на сторінці Завантажити історичну заяву, я мав би змогу завантажити свою заяву у форматах doc, excel та pdf.

Якщо ви пройдете це прийняття, тут не вистачає 3 речей:

  • Назва та формат імені файлу, який буде завантажено.
  • Яку інформацію (імена стовпців) слід відображати у файлі.
  • Список опцій, щоб вибрати, яку транзакцію бажає клієнт, тобто лише дебети, або лише кредити, або обидва.

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

Помилки, виявлені на початковому етапі, не коштують нічого порівняно з тим, що може коштувати на етапі «тестування».

Критерії приймання

Важливість виявлення розбіжностей в історії користувачів / Критеріях прийняття

Завжди важливо глибоко заглибитися в історії користувачів та критерії прийняття на ранній стадії ще до початку розробки або тестування.

Оскільки це передбачає:

# 1) Втрата часу:

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

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

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

# 2) Втрата зусиль:

Розробникам та контролю якості доводиться знову переглядати впроваджений код та тестувати кейси. Оновлення, додавання та видалення відповідно до вимог не є простим завданням. Це стає занадто болісно, ​​оскільки вже існує тиск, щоб виконати своєчасно.

У такій ситуації є ймовірність помилок на стадії розробки або тестування. Якщо ви зіткнулися з такою ситуацією, скористайтеся 'DevQA Pairing'. Як черевичка, ви можете не отримати компенсацію за додаткову роботу.

Невідповідність історії користувача та критеріїв прийняття

Висновок

Глибокого розуміння історії користувача та критеріїв прийняття можна досягти, лише витративши величезний час на її вивчення.

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

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

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

Чи є у вас щось нове, щоб поділитися з нами своїм досвідом роботи з Історіями користувачів? Будь ласка, висловіть свої думки нижче !!

Рекомендована література

^