UAT
приемане от бизнеса
Проверяваме дали хората могат да завършат договорената работа с правилни данни, права и резултат. Решението за приемане се опира на изпълнени сценарии и видим остатъчен риск.
Съдържание на тази страница
За подготовката използвай уроците за изисквания и сценарии. За цял пример с два цикъла отвори разработения казус.
Какво трябва да установи UAT
Основният въпрос е: „Може ли този потребител да свърши тази бизнес задача с този продукт при договорените условия?“ Проверяваме целия резултат, включително предаването към други роли и системи.
Демонстрацията показва как се предполага, че работи решението. В UAT участниците изпълняват сценарии, записват резултати и оценяват отклоненията. Обучението помага да използват системата, но участието в обучение не означава приемане.
Подготовката започва с изискванията. Изпълнението обикновено е след основните проверки на готова, интегрирана версия, която позволява смислена бизнес работа. При поетапна доставка може да има няколко UAT цикъла и отделни решения за отделни обхвати.
Контекст за участието на бизнеса: ISTQB Acceptance Testing. Пример за корпоративно внедряване: Microsoft Learn — UAT. Конкретните правила на Dynamics 365 не се пренасят автоматично към всеки проект.
Избери бизнес задачите и участниците
Запиши кои процеси, потребителски групи, канали, продукти и интеграции се приемат. Посочи какво остава извън този цикъл и каква е причината. За всеки сценарий определи изпълнител и собственик на очаквания резултат.
- Включи хора, които познават работата, а не само проектния екип.
- Осигури акаунтите на реалните роли. Проверка само с администратор пропуска ограниченията на ежедневния потребител.
- Включи чести сценарии и важни изключения: отказ, корекция, липсващи данни, повторение и зависимост от друга роля.
- Уточни предварително кой има право да приеме резултата и кой решава спорните правила.
Подреди по бизнес риск
Започни с процесите, при които грешка би спряла работата, засегнала много потребители или довела до погрешни данни, документи и решения. Включи ежедневните задачи и важните изключения. При ограничено време отговорникът договаря приоритетите; отпадналите сценарии остават описани като непроверени.
Планирай време за подготовка, изпълнение, изясняване на проблеми и проверка на поправките. Уговори кога са налични другите роли, вместо да оставяш сценария да чака между две стъпки.
QA може да подготви данните, да води протокола и да помага при възпроизвеждане. Това не прехвърля бизнес решението към QA. Разработчикът подпомага диагностиката, но не замества представителя на потребителя.
Договори измерими критерии
„Да е удобно“ и „да работи добре“ оставят място за различни тълкувания. Опиши наблюдаемото поведение, условията и резултата. Критериите се съгласуват преди изпълнението.
| Неясно | Проверимо учебно правило |
|---|---|
| Заявката отива при правилния човек. | Изпратена заявка от служител на екип А се появява в задачите на одобряващия за екип А. |
| Има връщане. | Връщането изисква причина; авторът я вижда, редактира и изпраща отново със запазена история. |
| Не се губят данни. | След успешно запазване и повторно отваряне срокът и видът достъп съвпадат с изпратените стойности. |
| Бързо е. | Екипът задава операция, обем, среда, мрежови условия, метод на измерване и допустимо време. |
По същия начин уточни достъпност, формати, справки, известия и документи, когато са необходими за работа. Числов праг за бързина или процент успех не е универсален стандарт и не се измисля от тестера.
За формулиране на критерии: Atlassian — Acceptance criteria.
Провери дали може да започне цикълът
Следният списък е предложение за входни условия. Екипът го адаптира според риска и обхвата.
- Версията, конфигурацията и промените са известни; няма неотбелязано обновяване по време на сесията.
- Нужните предходни тестове са изпълнени и известните дефекти са предоставени за оценка.
- Ключовите сценарии могат да се изпълнят; блокерите имат решение или договорено ограничение на обхвата.
- Участниците разполагат с правилните роли, инструкции и време за работа.
- Тестовите данни са реалистични, разрешени и достатъчни за всички варианти.
- Интеграциите и настройките са достатъчно близки до целевата среда; разликите са описани.
- Критериите, сценарийните очаквания, начинът за дефекти и приемащият отговорник са ясни.
Тестова среда не означава задължително пълно копие на продукцията. Важно е да се знае как разликите влияят на доказателствата. Успех със симулация (mock) на външна услуга не потвърждава реалната интеграция.
Подготви данните предварително
За всеки случай запиши началния запис и точните стойности. Използвай отделни записи за отказ, корекция и успешно приключване, ако състоянията им не позволяват повторна употреба. Подготви както обичайни стойности, така и допустими граници и недопустими входове. Уговори кой създава, възстановява и изчиства данните след теста.
Ако условие липсва, блокирай засегнатите сценарии или съгласувай по-тесен обхват. Непроверената част остава видима в отчета.
Приемане на процес за заявка за достъп
Учебен бизнес процес. Служител заявява временен достъп, ръководител решава, а изпълнител предоставя одобрения достъп. Това не описва текуща реализация в Digi. Използваме го, за да свържем изискване, сценарий и доказателство.
Правила на примера
| ID | Критерий |
|---|---|
| AC-01 | Срокът е цяло число от 1 до 30 дни включително; невалидните данни не създават заявка. |
| AC-02 | Изпращането създава една заявка с точния вид достъп и задача за одобряващия на екипа. |
| AC-03 | Чужд автор не редактира заявката; одобряващият вижда само разрешените му задачи. |
| AC-04 | Връщането изисква причина; авторът поправя и изпраща отново; историята остава. |
| AC-05 | След одобрение изпълнителят предоставя точно одобрения вид и срок; едва тогава заявката е „Изпълнена“. |
| AC-06 | При отказ не се предоставя достъп; авторът вижда резултата и причината. |
Сценарий UAT-01 за успешно изпълнение
Цел: служител получава одобрения достъп „Редакция“ за 7 дни. Условия: тестови служител в екип А, одобряващ А и изпълнител; известна версия; договорена интеграция за предоставянето. Ако последната липсва, не можем да потвърдим края на сценария.
| Стъпка и участник | Действие | Очаквано доказателство |
|---|---|---|
| 1 · Служител | Попълва валидни данни, избира „Редакция“, 7 дни и изпраща. | Един ID на заявка; точни стойности; статус „Изпратена“. |
| 2 · Одобряващ А | Отваря възложената задача и сверява искането. | Задачата принадлежи на правилната роля; данните не са променени. |
| 3 · Одобряващ А | Одобрява. | Решение с автор и час; статус „Одобрена“; задача за изпълнителя. |
| 4 · Изпълнител | Предоставя одобрения достъп чрез договорения тестов механизъм. | Потвърждение от свързаната система за правилен вид и срок; едва след него „Изпълнена“. |
| 5 · Служител | Отваря резултата и използва разрешеното действие в тестовата система. | Може да редактира договорения ресурс; вижда правилния срок и крайния статус. |
Снимката на статус „Одобрена“ не е доказателство за изпълнена стъпка 4. Запиши източника на всяко доказателство. Ако тестът спре по средата, целият сценарий още няма успешен краен резултат.
Останалите нужни сценарии
| Сценарий | Какво доказва | Критерии |
|---|---|---|
| UAT-02 · Корекция | Причината достига автора; променените данни стигат повторно до одобряващия; историята е запазена. | AC-02, AC-04 |
| UAT-03 · Отказ | Няма предоставен достъп; авторът вижда отказа и причината. | AC-06 |
| UAT-04 · Роли | Чужд служител и несъответстващ одобряващ не действат по заявката. | AC-03 |
| UAT-05 · Грешни и гранични данни | 1 и 30 са допустими; 0, 31 и 1,5 не създават заявка. | AC-01 |
| UAT-06 · Повторно изпращане | Двоен клик или договорен повторен опит не създава дублиран бизнес резултат. | AC-02 |
Това е примерна матрица за проследяване. Към всеки ред при изпълнение се добавят версия, резултат, доказателство и дефект. Отделните случаи могат да се разделят допълнително според сложността.
Изпълни и запази резултатите
- Потвърди версията, ролите, данните и началното състояние.
- Прочети целта и очакванията, преди да изпълниш сценария.
- Следвай задачата с акаунта на съответния участник. При предаване към друга роля запази общия ID.
- Провери бизнес резултата, свързаните записи, документи, известия и история според обхвата.
- Запиши действителното, статуса и доказателството. При отклонение създай или свържи дефект.
- След поправка повтори засегнатите сценарии върху новата версия. Отбележи кои по-стари резултати се заменят.
QA може да помага при технически затруднения. Ако водещият трябва постоянно да извършва скрити действия, за да завърши процесът, това е наблюдение за зависимост или използваемост, което трябва да се оцени.
Статусът описва резултата точно
| Статус | Кога се използва |
|---|---|
| Неизпълнен / Not run | Сценарият още не е започнат. |
| В изпълнение / In progress | Работата е започнала, но още няма пълен резултат. |
| Успешен / Passed | Очакванията за целия сценарий са изпълнени и има доказателство. |
| Неуспешен / Failed | Наблюдавано е несъответствие с очаквания резултат; свързва се описанието на проблема. |
| Блокиран / Blocked | Пречка не позволява проверката: например липсва роля, интеграция или необходим запис. Посочва се причина и отговорник. |
| Не е приложим / Not applicable | Екипът потвърждава, че случаят не важи за обхвата; записва се основание. Не се брои като успешен. |
При неуспешна стъпка и блокирани следващи проверки опиши и двете. Общият статус се задава по правилата на регистъра, без да се губи фактът за дефекта.
Всекидневният кратък отчет съдържа изпълнено, останало, дефекти, блокери и нужни решения. Блокираният сценарий не се превръща в успешен заради наближаващ срок.
Раздели проблемите от новите желания
| Наблюдение | Как се обработва |
|---|---|
| Договорено правило не е изпълнено. | Дефект с възпроизводими стъпки и оценка на въздействието. |
| Правилото липсва или е противоречиво. | Въпрос към отговорника; засегнатото приемане остава нерешено. |
| Появява се нова функция извън обхвата. | Искане за промяна с бизнес оценка и решение за обхвата. |
| Работата е невъзможна поради пропусната бизнес нужда. | Съществен проблем за приемане; не се отхвърля само защото липсва в първоначалния списък. Бизнес собственикът оценява промяна на обхвата и риска. |
| Средата, данните или инструкцията пречат. | Проблем по подготовката с отговорник. Записва се как влияе на резултата. |
Обсъждането на дефекти е обща преценка на въздействие, срок, решение и проверка. Ново изискване не бива да се скрива като козметична забележка, а дефект не бива да се затваря като „желание“ без обосновано решение.
Подготви заключение по критериите и риска
Критериите за приключване се договарят предварително. Примерен набор: важните бизнес сценарии са изпълнени; резултатите са прегледани; блокерите са решени; всеки останал дефект има бизнес оценка; ограниченията и непровереното са видими.
Не използвай общо правило като „95% зелени означава приемаме“. Един неуспешен критичен сценарий може да е по-важен от много успешни малки проверки.
Възможни решения
- Прието: договорените критерии за посочения обхват са изпълнени и отговорникът е потвърдил.
- Прието с условия: само ако процесът на организацията го допуска. Записват се отклоненията, рискът, временната мярка, собственикът, срокът и начинът за последващо потвърждение. Ясно е дали условието трябва да се изпълни преди внедряване.
- Не е прието: съществени критерии не са изпълнени; посочват се нужните поправки и повторни проверки.
- Решението е отложено: няма достатъчно доказателства или остава блокирана важна част.
Приемащият трябва да има необходимите правомощия. Условно приемане не отменя задължителни организационни, договорни или нормативни изисквания.
Какво съдържа записът за приемане
Обхват, версия и конфигурация, среда, период, участници, критерии, резултати и доказателства; списък на отворените дефекти, условията и риска; решение, име и роля на упълномощения приемащ и дата. Формата може да бъде протокол или одобрен запис в използваната система.
Това потвърждение често се нарича sign-off. Отметка, натиснат бутон в учебен файл или имейл без необходимите правомощия не замества договорения процес за приемане.
Предай към внедряване и проследи условията
Бизнес приемането е вход към решението за внедряване. Отделно се проверяват необходимите технически и оперативни условия: конфигурация, наблюдение, инструкции, поддръжка, миграция и възстановяване според проекта.
След внедряването екипът изпълнява договорени безопасни проверки и наблюдава реалната работа. QA и бизнесът проследяват приетите условия и новите проблеми. Не изпълнявай учебни разрушителни сценарии върху реални данни.
Ако след UAT има съществена промяна, оценете кои сценарии и решения са засегнати. При нужда повторете проверките и обновете приемането за новата версия.