Урок · Разбиране на работатаОт изискване
до проверимо очакване
Преди да тестваш, трябва да знаеш как изглежда правилният резултат. Тук ще превърнем кратко бизнес описание във въпроси, ясни правила и конкретни критерии за приемане.
Съдържание на тази страница
Разбери каква работа трябва да стане възможна
Изискването не започва непременно с подробна спецификация. Може да получиш задача „Добавяме връщане за корекция“, скица на екран или разказ от колега. Това е начало на разговора. За UAT трябва да разбереш кой работи, какво иска да постигне, при какви условия и какво трябва да получи накрая.
Представи си, че преглеждащ открива грешен адрес в заявка. Досега той отказва заявката, а авторът създава нова. Бизнесът иска корекция, за да се запази същата заявка и историята ѝ. Тогава целта не е просто наличието на бутон „Върни“. Целта е грешните данни да бъдат поправени и работата да продължи проследимо, без ненужно повторно въвеждане.
Ако тестваш само дали бутонът се натиска, можеш да пропуснеш, че авторът не получава задачата, че причината е невидима или че преглеждащият продължава да вижда старите данни. Разбирането на бизнес нуждата подсказва какви последствия да провериш.
Запиши нуждата в едно изречение
„Като преглеждащ искам да върна заявката с причина, за да може авторът да поправи разрешените данни и да я изпрати отново със запазена история.“
Това описание още не отговаря на всички въпроси, но показва участниците, действието и причината за промяната.
Раздели краткото описание на въпроси
Ще използваме измислен процес за заявка за служебно оборудване. Авторът подава заявка, преглеждащият проверява данните и може да я върне за корекция. Примерът не описва конкретна настройка на Digi.
| Какво трябва да разбереш | Конкретен въпрос | Защо променя теста |
|---|
| Кой | Всеки преглеждащ ли може да върне, или само назначеният? | Избираш правилни и неправилни роли. |
| Кога | В кои състояния е разрешено връщане? | Проверяваш допустим и недопустим преход. |
| Какво | Кои полета може да промени авторът? | Сравняваш разрешените редакции с ограничените. |
| Причина | Задължителна ли е и има ли минимална дължина? | Подготвяш допустима, празна и гранична стойност. |
| Получател | Къде авторът намира върнатата задача? | Проверяваш реалната видимост за автора. |
| Продължаване | При повторно изпращане задачата връща ли се при същия преглеждащ? | Следиш правилното предаване и крайното състояние. |
| История | Какви събития и стойности трябва да се пазят? | Знаеш какво доказателство да сравниш. |
| Изключение | Какво става, ако авторът вече не е активен? | Може да е нужен отделен сценарий или ограничение. |
Не всички въпроси трябва да доведат до нова функция. Екипът може да реши, че определен случай е извън текущия обхват. Важното е решението да е видимо, с отговорник и причина. Неяснотата не трябва да се превръща мълчаливо в лично предположение.
03 / ДОГОВОРЕНИ ПРАВИЛАПревърни отговорите в конкретни критерии
За учебния пример приемаме следните изрично договорени правила. В реална задача те трябва да дойдат от бизнес отговорника.
- Само назначеният преглеждащ връща заявка в състояние „В преглед“.
- Причината е задължителна и съдържа 10–300 знака след премахване на външните интервали.
- След връщане заявката е „За корекция“ и се появява в задачите на автора.
- Авторът вижда причината и редактира само описание и адрес за доставка.
- След повторно изпращане заявката запазва своя ID и се връща при същия преглеждащ с актуалните данни.
- Историята показва кой и кога е върнал и изпратил отново; причината остава достъпна.
Всяко правило поражда едно или повече очаквания. Например правило 4 включва видимост на причината, възможност за редакция на два конкретни атрибута и забрана за редакция на останалите. Един общ тест „корекцията работи“ би скрил тези различия.
Формат „Дадено — Когато — Тогава“
Дадено: заявка EQ-17 е „В преглед“ и е възложена на преглеждащ А.
Когато: преглеждащ А я върне с причина „Поправете адреса за доставка“.
Тогава: същата заявка става „За корекция“, авторът я вижда в задачите си и вижда точната причина; в историята има събитие с преглеждащ А и час.
Този формат свързва началните условия, действието и наблюдаемия резултат. Не е задължителна форма за всяка организация. Ползата му е, че не позволява очакването да остане само „системата работи правилно“.
За ролята на критериите при общото разбиране: Atlassian — Acceptance criteria. Примерите тук са самостоятелно разработени.
04 / ОСНОВАНИЕОткъде идва очакваният резултат
В UAT трябва да можеш да отговориш „Защо очаквам точно това?“. Основанието може да е одобрено изискване, бизнес правило, договорен процес, актуален дизайн, образец на документ или потвърдено решение по въпрос. Запиши точната версия и място, а не само „така каза бизнесът“.
Вече работещата система също може да е източник за сравнение при замяна или промяна. Но старото поведение не е автоматично правилното: възможно е новото изискване нарочно да го изменя. Уточни кое трябва да се запази и кое трябва да се промени.
| Източник | Какво може да потвърди | Какво да изясниш |
|---|
| Дизайн на екран | Полета, текстове, подредба и показани състояния. | Бизнес ограничения, роли и поведение при грешка, които не са изобразени. |
| Правило за изчисление | Формула, единици, закръгляване и приложими условия. | Източника на входните данни и кога се извършва изчислението. |
| Примерен документ | Задължителни полета, текст и формат. | Дали е актуален и кои стойности се попълват според случая. |
| Отговор в задача | Решение по конкретно неясно правило. | Кой го е потвърдил и дали изискването е обновено. |
Ако два източника си противоречат, опиши противоречието и засегнатия сценарий. Например документът позволява редакция на адреса, а дизайнът го показва като заключен. Не обявявай произволно единия за грешен; поискай общо решение.
05 / ПРОСЛЕДИМОСТСвържи правилото с проверката и резултата
Проследимост означава да можеш да тръгнеш от едно правило и да намериш как е проверено, в коя версия, с какви данни и с какъв резултат. Това не изисква сложен инструмент. Добре поддържана таблица може да е достатъчна.
| Правило | Сценарии | Какво търсим в резултата |
|---|
| R-01: правилна роля и състояние | RET-01: назначеният връща; RET-02: чуждата роля не връща. | Разрешеното действие се изпълнява; недопустимото не променя заявката. |
| R-02: причина 10–300 знака | RET-03: граници; RET-04: празна причина. | Допустимото се приема, недопустимото не извършва връщане. |
| R-03 до R-06: цялата корекция | RET-05: авторът поправя и предава отново. | Същият ID, новите данни, правилният получател и история. |
Няколко правила могат да се проверят в един сценарий, а едно правило може да изисква няколко сценария. Връзката не означава, че е изпълнен всеки възможен случай. Ако няма сценарий за неактивен автор, не твърдим, че този случай е потвърден.
При промяна на R-02 от 300 на 500 знака връзките ти показват кои очаквания, данни и проверки да обновиш. Старите доказателства остават валидни за старата версия, но не доказват автоматично новата граница.
06 / НЕЯСНОТА И ПРОМЯНАКак да зададеш въпрос, който води до решение
Въпросът „Как трябва да работи?“ е твърде широк. Посочи ситуацията, липсващото правило, вариантите и последствията за теста.
Пример: „За RET-05: след корекция заявката трябва ли да се върне при първоначалния преглеждащ, или да се разпредели отново? При първия вариант проверявам запазено възлагане; при втория — текущото правило за разпределяне. Нужно е решение преди изпълнението.“
Запиши отговора в общия документ или задача и добави линк към сценария. Ако решението пристигне по време на сесия, прегледай дали вече изпълнени случаи са засегнати. Не променяй тихо очакването само за да съвпадне с наблюдавания резултат.
Новото предложение „Авторът да може да сменя и продукта“ може да е полезно, но не е част от горните правила. То се оценява като промяна. Ако без него реалната работа е невъзможна, обясни бизнес затруднението; липсата в списъка не е достатъчна причина проблемът да бъде пренебрегнат.
07 / ПРИЛОЖИРазработи едно кратко изискване
Задача: получаваш „Потребителят трябва да може да отменя заявка“. Напиши пет уточняващи въпроса и два критерия за приемане. Не добавяй непотвърдени правила като готови факти.
Разбор и примерен подход
Попитай: кой може да отменя; в кои състояния; нужна ли е причина; какво става с възложените задачи; има ли вече извършена външна операция и как се обработва тя. Допълнително уточни историята и уведомяването.
Критерий с ясно отбелязано допускане: „Ако е потвърдено, че авторът отменя само чернова, при отмяна на собствена чернова тя става ‘Отменена’ и не може да бъде изпратена.“ Втори: „Потребител без право на отмяна не може да промени състоянието на чуждата заявка.“ И двата се използват след потвърждение на съответните правила.
Добрата разработка показва кое знаеш, кое е въпрос и на какво се основава очакването. Не е достатъчно да има дълъг списък от предполагаеми функции.