Как да създадеш
смислени UAT сценарии

Започни с цел, а не с бутон

„Натискам Запази“ е действие. „Авторът подготвя чернова, прекъсва работата и по-късно я продължава без загуба на данни“ е бизнес сценарий. Второто описание подсказва да затвориш и отвориш записа, да сравниш данните и да провериш дали авторът може да продължи.

Името на сценария трябва да позволява на човек, който не е присъствал при подготовката, да разбере какво се доказва. Избягвай „Тест 1“ или „Форма“. Използвай „Авторът поправя върната заявка и я изпраща на същия преглеждащ“.

За да не стане сценарият необозрим, ограничи го до една разпознаваема цел с начало и край. Ако включваш създаване, отказ, ново създаване, корекция и изтриване в един ред, при проблем ще е трудно да разбереш кое е изпълнено и кое остава непроверено.

Раздели големите процеси на самостоятелни случаи, но запази и поне един пълен бизнес маршрут. Само малки проверки на отделни екрани могат да пропуснат проблем при предаването между участниците.

Опиши изпълнение, което друг може да повтори

Продължаваме примера за корекция от урока за изискванията. Всички данни и идентификатори са учебни.

Как се записва резултатът: за всяко несъответствие посочи стъпката. При успешен случай запази доказателство за новия адрес, получателя и историята. Не попълвай „Успешен“, преди да са изпълнени всички очаквания в обхвата.

След теста: отбележи крайното състояние на EQ-17. Ако следващ тест очаква „За корекция“, този запис вече не е готов за него. Подготви друг или възстанови началното състояние по разрешения начин.

Провери нормалната работа и важните отклонения

Успешният маршрут често се нарича happy path. Той показва как завършва задачата при подходящи условия. Включи го, защото без него не знаеш дали основната работа изобщо е възможна. След това избери отклонения с реална бизнес значимост.

Недопустим вход не означава, че тестът трябва да е неуспешен. Ако очакването е системата да отхвърли празна причина и тя го направи правилно, тестът е успешен. „Неуспешен“ описва разминаването с очакването, а не наличието на съобщение за грешка.

Използвай групи и граници

Не е практично да провериш всяка възможна стойност. Групирай данните според правилото и избери представители. Ако допустимият срок е цяло число от 1 до 30 дни, групите включват валидни цели числа, стойности под минимума, над максимума, дробни числа, текст и липса на стойност.

Валидната средна стойност 7 проверява нормална работа. Стойностите около границите проверяват къде точно се сменя поведението. За този пример използвай 0, 1, 2 и 29, 30, 31. Добави 1,5, текст и празно поле като отделни случаи. Очакването за всеки записвай предварително.

При десетична стойност „една стъпка над границата“ зависи от договорената точност. Ако сумата има два знака след десетичната запетая, около 500,00 са смислени 499,99 и 500,01. Ако данните са само цели бройки, използваш 499 и 501. Не смесвай тези два модела.

Променяй едно условие, когато търсиш причината

За проверка на празна причина остави останалите данни валидни. Ако едновременно смениш роля, срок, адрес и състояние, отказът няма да покаже кое правило е сработило. След като отделните правила са разбрани, могат да се проверяват и важни комбинации.

Не пропускай формата на данните

„00123“ може да е идентификатор, а не число. Ако първите нули са значими, записът и износът трябва да ги запазят. Дата „03/04“ е двусмислена без договорен формат. При часове уточни часова зона. За суми уточни валута, единици и закръгляване. Не избирай очакването само по това как Excel е показал стойността.

Използвай малка таблица за решения

Когато действието зависи от няколко условия, таблицата прави пропуските видими. За връщането в нашия пример са важни назначението, състоянието и причината.

Това е избран набор, а не всички математически комбинации. Той изолира всяко условие. Ако има особен риск при две едновременно нарушени условия, добави отделен случай. Не наричай набора „пълно покритие“, без да уточниш какво точно покрива.

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

Провери прехода и неговите последствия

Състоянието определя каква работа е допустима в момента. При преход проверявай четири неща: новото състояние, следващия отговорник, данните и историята. Променен етикет на екрана е само част от доказателството.

Ако заявката е „За корекция“, но няма задача за автора, процесът може да е блокиран. Ако историята показва правилното действие, но преглеждащият вижда стара версия на данните, бизнес решението може да е неправилно. Затова проверявай свързаните резултати заедно.

Недопустимите преходи са също важни: повторно одобрение на приключила заявка, редакция след заключване, изпращане на отменена чернова. Кои точно са забранени се определя от процеса, а не от универсален списък.

Оцени дали работата е изпълнима

Функцията може да дава правилни данни и въпреки това да затруднява ежедневната задача. Неразбираемо съобщение, скрито задължително поле или загуба на въведеното след поправка могат да причинят прекъсване или грешки. Запиши конкретната задача и препятствието.

За договорените условия провери последователността с клавиатура, видимостта на активния елемент, яснотата на етикетите и съобщенията, четимостта при увеличение и дали важна информация се различава само по цвят. Отбележи устройство, браузър и мащаб. Такъв преглед открива конкретни затруднения, но не е пълен одит за достъпност.

Официални насоки за ограничен първоначален преглед: W3C WAI — Easy Checks.

При бавна работа запиши конкретната операция, обема данни, началния и крайния момент и условията. „Бавно е“ е наблюдение за обсъждане; „отворих списък с 200 тестови заявки, чаках 12 секунди до използваем екран в два последователни опита“ е проверима информация. Числата тук са учебни, не допустим праг.

Избери какво да провериш първо

Списъкът от възможни проверки расте бързо. Подреди го по бизнес последствие, вероятност и честота на употреба, засегнати потребители и размер на промяната. Зависимостите също имат значение: ако създаването на заявка не работи, много следващи сценарии може да не могат да започнат.

Първо потвърди готовността на основния маршрут. След това провери най-важните рискове: правилна роля, точни данни, критично решение, предотвратяване на дублиране и реален краен резултат. Включи редките, но тежки случаи, когато са в обхвата; ежедневната честота не е единственият критерий.

Когато времето не стига, запиши какво отпада и какъв риск остава. Това е решение на отговорните участници, не причина да отбележиш непроведените случаи като успешни. Прегледай набора с бизнес представител: липсва ли реална задача, която таблицата с полета не е уловила?

Подготви проверките за един бутон

Правило: само авторът на чернова може да я изпрати. Изискват се основание от 10 до 200 знака и срок от 1 до 30 цели дни. След изпращане има една заявка „В преглед“ и задача за договорения преглеждащ.

Създай един пълен успешен случай и поне шест допълнителни проверки. За всяка запиши стойността, началното състояние и очакването.