Отваряш сценария.
Какво правиш след това?
Подробна последователност за UAT сесия: подготовка, изпълнение, наблюдение, описване на отклонение, обсъждане с екипа и повторна проверка.
Съдържание на тази страница
Потвърди условията за работа
Отвори актуалния регистър и избери сценария, който ще изпълняваш. Прочети целта, началното състояние и очакванията. Ако са нужни две роли, уговори участието на другия човек или подготви разрешените отделни сесии. Случайно отворен администраторски акаунт може да промени цялото поведение.
Провери адреса на средата и версията. Адресът може да е същият след обновяване; затова не е достатъчен сам по себе си. Прочети съобщенията за промени и известните ограничения. Ако нужната функция е временно изключена, изясни дали сценарият е изпълним.
Подготви записите и файловете. Сравни началното им състояние с описаното. Заявка, която някой вече е одобрил, не може мълчаливо да замени нужната чернова. Ако използваш нов запис вместо предварително посочения, запиши неговия ID.
Примерен начален запис
„RET-05, изпълнение RUN-08. Тестова среда; build UAT-42; процес V2; автор А и преглеждащ П; заявка EQ-17 е ‘За корекция’; адрес ‘Тестова 1’; причина ‘Поправете адреса за доставка’. Начало 10:15 Europe/Sofia.“
Идентификаторите и часът са учебни. В реална сесия се попълват наблюдаваните стойности.
Прави действие и проверявай следствието
Изпълни първата стъпка с правилната роля. Изчакай договорения видим резултат: зареден екран, приключило запазване, създадена задача. Ако интерфейсът показва, че още обработва, не натискай многократно, освен ако точно повторението е предмет на теста.
Сравни резултата веднага. При запазване провери стойностите в записания обект. При предаване влез като следващия участник и отвори същия ID. При документ отвори произведения файл и сравни съдържанието му. Съобщението за успех потвърждава само това, което действително означава в приложението.
Разделяй наблюдението от обяснението. „След повторно изпращане преглеждащият вижда стария адрес“ е факт. „Кешът е счупен“ е хипотеза, ако няма потвърждение. Хипотезата може да се добави отделно, но не трябва да замества доказателството.
Ако стъпката мине, продължи към следващата. Ако има отклонение, запиши го преди да промениш условията. Презареждане, смяна на акаунт или нов запис могат да изтрият важния контекст. Кратка снимка и точните данни често са по-полезни от много несвързани снимки след това.
Реши какво може да продължи
Намереният проблем не означава непременно край на цялата сесия. Ако погрешна стойност прави следващото решение безсмислено, засегнатият маршрут не може да бъде потвърден. Ако има правописна грешка, а задачата е изпълнима, може да продължиш и да запишеш отделен дефект. Решението зависи от последствията и уговорения подход.
Не поправяй данните по скрит начин, за да довършиш сценария, и после да го отчетеш като изцяло успешен. Ако екипът разреши временна подготовка, опиши я и отдели кои стъпки са проверени при нормални условия и кои — след намесата.
| Ситуация | Какво записваш | Следващо действие |
|---|---|---|
| Записът показва погрешна стойност. | Несъответствие, точна стъпка и засегнат резултат. | Дефект; преценка кои проверки още са смислени. |
| Не можеш да влезеш с нужната роля. | Блокиране и причина; дали е проблем с акаунт или наблюдаван дефект. | Отговорник за достъпа/проблема; друга независима задача. |
| Очакването не е договорено. | Конкретен бизнес въпрос. | Решение преди заключение по засегнатата проверка. |
| Тестовите данни са използвани от друг участник. | Разлика спрямо предварителното условие. | Подготовка на нов запис и ново изпълнение. |
Ако не знаеш дали пречката е дефект или подготовка, опиши наблюдаваното и какво ти е необходимо. Не е нужно да си сигурна в техническата причина, за да направиш проблема видим.
Установи условията, без да изгубиш първия резултат
За повторение първо върни валидните начални условия с нов запис или по договорения начин. Следвай същите действия. Запиши дали проблемът се повтаря и в колко опита. „2 от 3“ описва повече от „понякога“, но остава вярно само за направените опити.
Ако проблемът не се повтори, първото наблюдение не изчезва. Сравни разликите: версия, акаунт, състояние, данни, отворени раздели, последователност и време между действията. Възможно е резултатът да зависи от нещо, което още не е изолирано.
Не повтаряй безкрайно. След достатъчно опити за полезно описание предай фактите на екипа. При периодичен проблем могат да помогнат точен час, ID на запис и събитията непосредствено преди него. Техническият екип може да ги свърже с логове.
Провери регистъра за съществуваща задача. Ако съвпадат резултатът и условията, добави доказателството там според екипния процес. Ако има различна роля или различно бизнес последствие, опиши разликата, за да се реши дали е същият проблем.
От „не запазва“ до използваем дефект
Следният запис е измислен пример за проблем в процеса за корекция. Той не е открит дефект в Digi.
RET-BUG-01 · След корекция преглеждащият вижда стария адрес
Среда и версия: тестова среда, build UAT-42, процес V2; браузър и версия се попълват от изпълнението.
Основание: R-05 — след повторно изпращане същият преглеждащ получава актуалните данни. Сценарий RET-05, RUN-08.
Условия: EQ-17 е „За корекция“; автор А; преглеждащ П; адрес „Тестова 1“. Няма едновременно редактиране от друг участник.
- Като автор А отвори EQ-17.
- Промени адреса на „Тестова 2“ и изпрати отново.
- Като преглеждащ П отвори EQ-17 от възложените задачи.
- Сравни адреса с изпратената стойност.
Очаквано: преглеждащ П вижда „Тестова 2“ за същата заявка.
Действително: в примера преглеждащ П вижда „Тестова 1“, докато автор А вижда „Тестова 2“.
Честота: попълва се след повторните опити, например „2 от 2 при същите условия“ само ако е наблюдавано.
Въздействие: следващият участник може да вземе решение или да изготви документ с неактуален адрес. Правилното предаване на корекцията не е потвърдено.
Доказателства: снимка на изпратения адрес при автора, снимка на същия ID при преглеждащия, часове на действията и линк към изпълнението.
Допълнително наблюдение: поведението след еднократно презареждане се записва отделно. Техническата причина не е установена.
Този запис позволява да се разбере проблемът без присъствие на автора му. Избягва се и объркване с друг случай, например адрес, който изобщо не е бил изпратен успешно.
Обясни въздействието и поискай конкретно решение
При прегледа на проблемите екипът уточнява валидността, тежестта, приоритета, отговорника и следващите действия. Подготви бизнес последствията: коя работа е засегната, за кои роли, при какви условия, колко често се изпълнява и има ли надежден временен начин.
Тежестта описва последствието. Приоритетът отразява и срокове, зависимости и ред на работа. Не превръщай лично раздразнение в оценка „критично“. Обясни как може да се стигне до неправилно решение, изгубени данни или невъзможна задача. Екипът прилага своята скала.
Обходният начин се проверява, преди да се предлага като решение. Ако „презареди“ показва новия адрес само понякога, това не е надеждна мярка. Ако е нужна ръчна поправка от администратор за всяка заявка, опиши усилието, риска и зависимостта.
Пример за ясен коментар
„Проблемът се вижда в RET-05, стъпка 4, build UAT-42. Авторът вижда новия адрес, преглеждащият — стария за същия ID. Това пречи на решение по актуални данни. Нужно е потвърждение кой поема поправката и в коя версия да повторим проверката. Прилагам двете снимки и часовете.“
При спор дали поведението е дефект върни разговора към изискването и работата. Ако правилото е неясно, нужен е бизнес отговор. Ако е променено, актуализирайте очакването и запазете причината. Затваряне без обяснение оставя приемането непълно.
Провери новата версия и свързаните резултати
Преди повторната проверка потвърди, че поправката е в средата. Номерът на задачата със статус „готово“ не показва непременно, че нужната доставка е разположена. Запиши версията и дали са нужни нови данни.
- Възстанови началните условия на дефекта.
- Повтори точните стъпки с конкретните стойности.
- Сравни резултата с критерия; запази новото доказателство.
- Провери свързаните резултати, засегнати от промяната, според договорения обхват.
- Отрази резултата в дефекта и сценария, с връзка към предишното изпълнение.
За адреса повторната проверка потвърждава конкретния проблем. Свързаните проверки може да включват другото редактируемо поле, непроменените данни, историята и документ, който използва адреса. Изборът се обсъжда с екипа според поправката; не е механично повторение на целия пакет.
Ако проблемът остава, запиши новото наблюдение и върни задачата по екипния процес. Ако се появи различен проблем, опиши го отделно и свържи задачите. Първият дефект може да е поправен, а целият сценарий все още да не преминава.
Остави отчет, по който може да се продължи
Отбележи един текущ статус за всеки сценарий, но запази историята на изпълненията. Добави действителния резултат и линковете. Празен ред в таблицата не казва дали тестът е пропуснат, забравен или блокиран.
Учебен дневен отчет
„Обхват: връщане за корекция, build UAT-42. От 8 планирани сценария: 4 успешни, 1 неуспешен, 2 блокирани и 1 неизпълнен. Неуспешният е RET-05 — преглеждащият вижда стария адрес, RET-BUG-01. Двата блокирани изискват акаунт на заместник, който още не е предоставен. Следва: поправка на RET-BUG-01, осигуряване на акаунта и повторно изпълнение. Приемането на корекцията още няма достатъчно основание.“
Бройките сами не обясняват риска. Добави коя бизнес задача остава непотвърдена и от кого зависи продължаването. Ако има срок, посочи договорения срок, а не произволно обещание.
Запази доказателствата в общото място, провери връзките и остави използваните тестови записи в известно състояние. Уведоми координатора за блокерите по уговорения канал. Така следващият участник няма да повтаря подготовката на сляпо.