UAT
от изискване до приемане
Подробно учебно ръководство с разработени примери, практически задачи и работни шаблони. Как разбираш нуждата, подготвяш проверките, изпълняваш сценарии и обосноваваш резултата.
Съдържание на тази страница
Какво означава UAT
UAT — User Acceptance Testing означава тестване за приемане от потребителите. Представители на бизнеса проверяват дали системата изпълнява договорените им нужди и дали могат да завършат реалните си задачи. Проверяват се конкретна версия, определен обхват и известни условия.
Това включва повече от отваряне на екрани: правилният човек започва работа, въвежда данни, предава я на следваща роля и получава правилния краен резултат. Сравняваме случилото се с бизнес правилата и критериите за приемане.
UAT дава доказателства за приемане. Решението се взема от определените за това бизнес отговорници. Участието в тестовете само по себе си не дава право да одобряваш внедряване.
За ролята на бизнеса в приемането: ISTQB — Acceptance Testing.
Уроци, примери и практика
Следвай темите по ред. Ако вече работиш по задача, отвори конкретния урок и използвай свързания шаблон. Общата основа предхожда приложението в Digi.
Как да работиш с материала
Прочети обяснението, проследи разработения пример и изпълни задачата. Запиши собственото очакване преди опита. После сравни с разбора и обсъди неяснотите с отговорника за процеса.
Практическият резултат е комплект за реална работа: изяснени критерии, сценарии и данни, изпълнения с доказателства, описани отклонения и обосновано заключение. Формулирай какво остава непроверено толкова ясно, колкото и успешните резултати.
Какво правиш като участник в UAT
- Разбираш задачата. Кой потребител какво трябва да постигне, защо му е нужно и по кое правило ще познаеш, че е правилно.
- Подготвяш проверката. Версия, среда, акаунти, роли, данни, начално състояние и очакван резултат.
- Изпълняваш сценария. Следваш работата от начало до край, включително действията на други роли и свързаните системи, когато са в обхвата.
- Описваш наблюдаваното. Записваш резултат, доказателства и бизнес въздействие. Разделяш дефектите, въпросите и предложенията.
- Проверяваш поправките. Повтаряш засегнатата работа в посочената нова версия и отразяваш резултата.
- Даваш основание за решение. Обобщаваш кое е потвърдено, кое пречи на работата и кое остава непроверено.
Не е необходимо да откриваш грешния ред код, за да опишеш валиден проблем. Нужно е ясно да покажеш какво направи, какво очакваше, на какво се основава очакването и какво всъщност стана. Когато правило липсва, задаваш въпрос към отговорника, вместо да го измисляш.
Кой за какво отговаря
| Роля | Принос към UAT |
|---|---|
| Бизнес собственик / упълномощен приемащ | Потвърждава нуждите, значимостта на риска и решението за приемане за посочения обхват. |
| Бизнес анализатор / продуктов отговорник | Изяснява правилата, критериите, обхвата и спорните очаквания; помага за сценарии. |
| Участник в UAT | Изпълнява бизнес сценариите, записва резултати, описва въздействието и проверява поправки. |
| Координатор на UAT | Организира участници, график, зависимости, отчет и ескалация на блокерите. |
| QA / тестов екип | Подпомага подготовката, тестовете и възпроизвеждането; предоставя резултати и известни проблеми. |
| Разработчици и отговорници за средата | Диагностицират и поправят дефекти; осигуряват версията, интеграциите и техническите условия. |
В малък екип един човек може да има повече от една роля. Уточняваме отговорностите, а не предполагаме правомощия само по длъжността.
Къде е разликата с QA
QA — Quality Assurance — е по-широката работа по осигуряване на качество чрез подходящи процеси. В екипите „QA“ често е и името на ролята, която извършва софтуерни тестове. UAT е конкретна дейност по приемане от гледната точка на бизнеса. Проверките могат да се застъпват, но бизнес решението за приемане има свой отговорник.
Например техническият екип проверява много варианти на обмена между системите; в UAT следим дали конкретна заявка стига до правилния човек и завършва с правилния бизнес резултат. Намереното отклонение е важно независимо кой го е забелязал.
За значението на QA: ASQ — Quality assurance and quality control.
Следи работата, данните и последствията
| Област | Въпроси при изпълнение |
|---|---|
| Цялата задача | Може ли потребителят да приключи работата? Има ли пропусната стъпка или задължителна ръчна намеса? |
| Данни и изчисления | Съвпадат ли записаните стойности с въведените? Правилни ли са мерни единици, периоди, валута, закръгляване, дати и часове според правилата? |
| Роли и видимост | Правилният участник вижда и изпълнява задачата? Чужда роля получава ли недопустим достъп? |
| Състояния и предаване | Кой е следващият отговорник? Отразен ли е правилният статус? Може ли да се разбере какво предстои? |
| Изключения | Какво става при отказ, корекция, непълни данни, повторно действие или прекъсване? |
| Краен резултат | Правилни ли са документът, справката, известието, крайният запис и историята? Получени ли са от правилния човек? |
| Ежедневно използване | Ясни ли са полетата, действията и съобщенията? Може ли задачата да се изпълни с договорените устройства и нужните средства за достъпност? |
Проверявай както обичайната работа, така и важните отклонения от нея. Ако има 30-дневен максимум, 30 трябва да е допустимо, а 31 — недопустимо. Ако грешка води до неправилен договор, изгубена заявка или неподходящ достъп, запиши точно това въздействие.
Термини, които ще срещаш
- Изискване и бизнес правило
- Нуждата, която трябва да бъде изпълнена, и условията, които управляват поведението. Пример: редактор може да коригира собствена чернова, но не чужда публикувана версия.
- Критерии за приемане — acceptance criteria
- Наблюдаеми условия, по които проверяваме конкретната договорена функционалност. Отделно екипът договаря условията за приемане на целия UAT обхват.
- Сценарий и тестов случай
- Сценарият описва бизнес задачата. Подробният тестов случай добавя условия, данни, действия и очаквани резултати. Имената и формата могат да се различават между екипите.
- Среда, версия, build
- Средата е мястото за работа, например тестовият сайт. Версията или build идентификаторът показва коя доставка проверяваш. Същият адрес може утре да съдържа нова версия.
- Тестови данни
- Подготвени потребители, записи, файлове и стойности, с които могат да се проверят нужните условия. Използват се разрешени данни; личните данни не се копират произволно в отчети.
- Дефект — bug / defect
- Несъответствие с договорено правило или нужна работа. Описанието съдържа очаквано, действително и въздействие. Причината може още да не е известна.
- Повторна проверка — retest
- Изпълнение на засегнатия сценарий след поправка, за да се установи дали конкретният проблем е отстранен.
- Регресионна проверка — regression
- Проверка дали промяната е нарушила друга свързана работа, която преди е функционирала. Обхватът се определя според промяната и риска.
- Приемане — sign-off
- Проследимо решение на упълномощения отговорник за конкретни версия и обхват, с ясни ограничения и оставащи рискове.
Изпълнено, успешно и прието са различни неща. Изпълнен тест може да е неуспешен. Успешен сценарий не доказва целия продукт. Приета версия не означава автоматично разрешено внедряване.
Какво можеш да твърдиш след проверката
Резултатът важи за използваните версия, конфигурация, роли, данни и условия. „Не видях проблем“ не доказва, че проблеми няма. Пиши конкретно: „UAT-03 е успешен в версия X с роля редактор; документът съдържа стойностите от заявка Y“.
- Демонстрацията и обучението не заместват изпълнени и документирани UAT сценарии.
- Непроведеният или блокираният тест няма успешен резултат.
- Симулацията на външна система не доказва работата с реалната интеграция.
- Високият процент успешни тестове не компенсира неприемлив риск в критична бизнес задача.
- Ако версията се промени, уточняваме кои резултати остават приложими и кои се проверяват отново.
Официални материали за справка
Ръководството използва собствени обяснения и учебни примери. Външните материали са допълнение; следвай договорените правила на екипа. Източниците са проверени на 02.10.2026.
- ISTQB — Acceptance Testing: обхват на приемателното тестване и сътрудничество между бизнеса и тестовия екип.
- ISTQB Glossary: речник за термините.
- Atlassian — Acceptance criteria: формулиране на проверими очаквания.
- Microsoft Learn — Testing strategy: пример за организация на тестове при бизнес внедряване; продуктово специфичен контекст.