Работният
комплект за UAT
Инструментът е полезен, когато помага да намериш правилото, да изпълниш задачата или да покажеш резултата. Започни с комплекта, който използва екипът.
Съдържание на тази страница
След общия комплект премини към подробните практически стъпки с браузър, формуляри, списъци и регистър.
Кой инструмент за какво служи
| Инструмент | За какво го използваш | Какъв резултат пазиш |
|---|---|---|
| Договорен браузър, например Chrome или Edge | Работа в предоставената UAT среда с нужните роли и устройства. | Адрес на средата, версия на продукта, браузър и версия, роля. |
| Хранилище за изисквания, например Confluence, SharePoint или документ на екипа | Намиране на одобрените правила, критерии, процес и ограничения. | Линк, идентификатор и версия на изискването. |
| Excel, Google Sheets или тестов модул на екипа | Списък със сценарии, участници, състояния, резултати и зависимости. | Един общ, актуален регистър. |
| Jira, Azure DevOps или друга система за задачи | Проследяване на дефекти, въпроси, промени и поправки. | Номер на задачата, отговорник, решение и резултат от повторната проверка. |
| Снимка / запис на екрана | Показване на конкретен резултат или последователност. | Четливо доказателство, свързано със сценарий и задача. |
| Дизайн или прототип, например Figma, ако е предоставен | Проверка на договорени екрани, текстове и действия. | Линк към точната версия; отклонения спрямо договореното. |
| Teams, Slack или среща на екипа | Бързо изясняване на блокер или бизнес правило. | Окончателният отговор се отразява и в общата задача/документ. |
Това са примери за категории, а не списък за задължителна инсталация. Не е нужно да използваш всички изброени продукти. Шаблоните в този пакет могат да се копират в избрания от екипа инструмент.
Работи в правилната среда и роля
- Отвори адреса, предоставен за конкретния UAT цикъл. Запиши средата и версията. Ако версията не се вижда, поискай идентификатора от координатора.
- Провери с кой акаунт си влязла, организацията и активната роля. Не разчитай само на името в раздела на браузъра.
- За различни роли използвай отделни профили или договорени отделни сесии. Два обикновени раздела в един профил обикновено споделят входа.
- Настрой езика, мащаба и размера на прозореца според сценария. При проблем запиши тези условия.
- Изпълни задачата с нормалните действия на потребителя. Проверявай стойностите след запазване и повторно отваряне, а не само съобщението за успех.
Презареждане, излизане от акаунта и изчистване на данни могат да променят условията. Първо запиши проблема. Ако след презареждане изчезне, отчети това като наблюдение — не е доказателство за поправка.
Частният прозорец помага за отделяне на сесия, но не е универсално решение за няколко независими роли. Частните прозорци могат да споделят сесия помежду си; поведението зависи от браузъра.
Минимален контекст за всеки резултат
Среда + версия + дата и час + акаунт/роля + сценарий + тестов запис. Например: UAT среда, build 42, 02.10.2026 14:20 Europe/Sofia, редактор от тестова организация А, UAT-03, запис DEMO-17. Това е измислен пример, не адрес или версия на Digi.
Намери основанието за очакването
Преди проверката отвори договореното изискване и точните критерии. Дизайнът помага за видимото поведение, но не описва непременно всички бизнес правила. Стар имейл, чат или минала версия могат вече да не са актуални.
Ако изискването и дизайнът си противоречат, не избирай сама кое има предимство. Запиши конкретното противоречие за решение. Ако липсва важна бизнес нужда, обясни коя задача е невъзможна и поискай оценка на обхвата.
За преглед на предоставен дизайн: Figma — Guide to inspecting. Използвай достъпните за акаунта възможности; допълнителен платен режим не е условие за UAT.
Поддържай общ списък на сценариите
Един ред описва едно проследимо изпълнение. Не презаписвай неуспешния резултат без история, когато проверяваш поправка. Добави ново изпълнение или използвай историята на тестовия инструмент.
| Поле | Пример |
|---|---|
| ID и бизнес цел | UAT-03 — заявяване на достъп „Редакция“. |
| Критерий / източник | AC-02 — видът достъп се запазва точно. |
| Условия и изпълнител | Тестов служител; 7 дни; UAT среда; build 42. |
| Очаквано / действително | „Редакция“ / записано „Само преглед“. |
| Статус | Неуспешен. |
| Доказателство и задача | Снимка на DEMO-17; BUG-12. |
| Следваща стъпка | Поправка и повторение; отговорник и договорена дата. |
Използвай филтри по статус, бизнес процес и отговорник. Цветът помага, но текстовият статус трябва да остава видим. В шаблона за сценарий има пълната структура.
Напиши проблем, по който може да се работи
Първо провери дали същият проблем вече е описан. Ако е, добави новите условия и доказателства към него. Обикновено отделни проблеми се записват отделно, за да могат да се поправят и проверяват независимо.
Пример за описание
Заглавие: При заявка за „Редакция“ крайният запис показва „Само преглед“.
Контекст: учебната локална форма, версия 4; браузър и версия; дата/час. Няма реални акаунти или предоставяне на достъп.
Условия и стъпки: 1. Попълни валидния пример. 2. Избери „Редакция“. 3. Изпрати. 4. Отвори показания запис и сравни вида достъп.
Очаквано: записът съдържа „Редакция“ според правило 4 на упражнението.
Действително: записът съдържа „Само преглед“. Честотата се попълва след реалните опити.
Въздействие: заявената нужда не е запазена вярно; при такъв реален процес следващият участник би работил с погрешно искане.
Доказателство: снимки на избора и на резултата, ID на учебния запис, линк към сценария.
Не пишем „системата е счупена“, когато можем да посочим поле, действие, стойност и последствие. Не представяме предположение за техническата причина като установен факт.
Въздействие и приоритет
Severity описва тежестта на последствието; priority — реда и спешността за работа. Проблем, който блокира всички заявления, има друго въздействие от сгрешен текст. Малка текстова грешка в задължителен документ обаче може да е важна за приемането. Опиши последствията, броя засегнати случаи и наличен обходен начин; екипът потвърждава оценката по своята скала.
Какво става след записването
Екипът преглежда проблема → изяснява го и назначава отговорник → поправя или записва друго обосновано решение → предоставя версия за проверка → UAT участникът повтаря сценария → резултатът се затваря или проблемът се отваря отново. Конкретните имена на статусите зависят от инструмента.
„Разработчикът го е поправил“ още не е успешна повторна проверка. Изпълни стъпките и провери крайния резултат. При невъзможност за възпроизвеждане запази използваните условия и обсъди разликите.
Пример за регистър на дефекти: Atlassian — Bug tracking.
Покажи точно какво се е случило
Снимка е подходяща за погрешна стойност или съобщение. Кратко видео е полезно, когато проблемът зависи от последователност, превключване между роли или изчезващ елемент. Към тях добави текстовите стъпки; изображението не ги замества.
- Покажи достатъчно контекст: екран, конкретно поле, статус или тестов запис.
- Запиши сценария, версията и часа. При проблем с данни приложи очакваната и действителната стойност.
- Използвай четлив размер. Ако добавяш стрелка или рамка, не закривай резултата.
- Премахни пароли, токени и лични данни, които не са нужни за проблема. Ползвай разрешеното място за споделяне на екипа.
- Свържи файла с правилната задача. Пример за име: UAT-03_build42_резултат.png.
На macOS панелът за снимка и запис се отваря с Shift + Command + 5. На Windows снимка на област може да се направи с Windows + Shift + S. Възможностите за видео зависят от системата и версията.
Apple — Screenshots and screen recordings · Microsoft — Snipping Tool.
Кога са полезни техническите панели
Браузърът изпраща заявки до сървъра и показва получения отговор. API е интерфейсът, чрез който системите обменят данни. Техническите детайли могат да помогнат на екипа да намери причината, но основният UAT резултат остава бизнес поведението.
| Средство | Кога да го ползваш | Какво да не заключаваш |
|---|---|---|
| DevTools → Network | Когато екипът поиска данни за неуспешно запазване: отвори панела преди действието, повтори, запиши заявката, часа и статуса. | HTTP 200 не означава автоматично правилен бизнес резултат; 4xx може да е очакван отказ за невалидна заявка. |
| DevTools → Console | За съобщение, което се появява при точното действие; запиши го заедно със стъпките. | Всеки червен ред не е непременно причина за наблюдавания проблем. |
| Postman | Ако конкретната UAT задача изисква разрешена API заявка и екипът е предоставил адрес, метод, данни и очакване. | Успешна API проверка сама по себе си не потвърждава цялата потребителска работа. |
| SQL / логове | За допълнително потвърждение чрез разрешен достъп и договорена проверка с техническия екип. | Не се правят произволни промени в данните, за да „мине“ сценарият. |
Не е необходимо да изучаваш програмиране или автоматизация, за да подготвиш добър UAT сценарий. Когато проверката изисква техническо доказателство, уговорете кой ще го предостави и как ще се свърже с тестовия запис.
Износ на Network записи като HAR може да съдържа чувствителни заявки и данни. Предавай такъв файл само по установения ред и след преглед с екипа.
При необходимост: Chrome Network, Chrome Console, Postman Quick start, MDN HTTP статуси.
Подготви работното си място
- Имаш адрес на средата, версията и акаунтите за нужните роли.
- Отваряш изискванията, критериите и известните ограничения.
- Имаш регистър със сценарии и място за дефекти и доказателства.
- Можеш да направиш четлива снимка и да я прикачиш към задача.
- Знаеш към кого да се обърнеш за бизнес въпрос, блокер и технически проблем.
- Знаеш кой ще прегледа резултатите и ще вземе решението за приемане.