Речник за
работата в UAT

Бизнес понятия

UAT — User Acceptance Testing

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

Business owner — бизнес собственик

Отговорник за бизнес процеса и неговия резултат. Конкретните правомощия за приемане се определят от организацията.

Stakeholder — заинтересована страна

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

Scope — обхват

Процесите, функциите, ролите, данните и условията, които се проверяват в конкретния цикъл. Изключенията трябва да са изрично описани.

Requirement — изискване

Нужда или условие, което решението трябва да изпълни. Добрият сценарий посочва на кое изискване се основава.

Business rule — бизнес правило

Условие за действие или решение, например кой одобрява над определен праг. То дава очакването за конкретни входни данни.

Acceptance criteria — критерии за приемане

Проверими условия за договореното поведение. Отделно се договарят общите критерии за приключване и приемане на UAT обхвата.

Change request — искане за промяна

Предложение за ново или изменено поведение, което изисква оценка и решение за обхват, срок и последствия.

Сценарии, данни и изпълнения

Scenario — сценарий

Бизнес задача или ситуация за проверка, например корекция и повторно изпращане. Дава целта на работата.

Test case — тестов случай

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

Preconditions — предварителни условия

Какво трябва да е вярно преди теста: роля, версия, налична интеграция, запис в точно състояние.

Test data — тестови данни

Стойности, потребители, записи и файлове, подготвени за нужните варианти. Данните се свързват с конкретното изпълнение.

Expected / actual — очаквано / действително

Очакваното идва от правилото; действителното е наблюдаваният резултат. Разделянето им прави отклонението разбираемо.

Test run — изпълнение

Един конкретен опит в определена версия и условия. Един сценарий може да има много изпълнения.

Happy path — обичаен успешен маршрут

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

Boundary — граница

Място, около което правилото сменя резултата. Ако максимумът е 30 дни, стойностите около 30 са важни за точността на ограничението.

End-to-end — от начало до край

Проверка на цялата договорена задача през участниците и системите до крайния резултат. Границите ѝ трябва да са ясни.

Coverage — покритие

Кои правила, роли, варианти или процеси са включени и проверени. Процент без уточнение „от какво“ лесно подвежда.

Traceability — проследимост

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

Как екипът описва отклоненията

Defect / bug — дефект

Несъответствие с договорено правило или нужна работа. Описва се с условия, стъпки, очаквано, действително и въздействие.

Blocker — блокер

Пречка за продължаване на определена работа. Може да е дефект, липсващ акаунт, недостъпна зависимост или друго условие; причината се посочва.

Severity — тежест

Значимост на последствието. Обяснява се чрез засегнатата бизнес работа, данни, потребители и риск.

Priority — приоритет

Ред и спешност за работа по задача. Отчита тежест, срокове, зависимости и решения на екипа.

Triage — преглед и разпределяне на проблемите

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

Workaround — обходен начин

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

Retest / confirmation testing — повторна проверка

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

Regression — регресионна проверка

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

Residual risk — остатъчен риск

Каква възможност за проблем остава след извършените проверки, например неизпълнен вариант, известно отклонение или различна среда.

Sign-off — формално потвърждение

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

Думи, които помагат да опишеш условията

Environment — среда

Мястото и настройките, в които се изпълнява системата. Тестовата и продукционната среда могат да се различават по данни и интеграции.

Build / version — доставка / версия

Идентификатор на проверяваното състояние на продукта. Един и същ адрес може да обслужва различни доставки в различни дни.

Deployment — разполагане

Поставяне на определена версия в средата. Завършена разработка не означава автоматично разположена промяна.

Configuration — конфигурация

Настройки, които влияят на поведението: активен процес, продукт, правила, роли, интеграции. Промяна в тях може да промени резултата без нов интерфейс.

Session — сесия

Контекстът на текущата работа и входа. Споделен браузърен профил може да споделя и вход между разделите.

API — интерфейс между системи

Договореният начин приложенията да обменят заявки и данни. При UAT може да е нужна помощ от екипа за доказване на свързан резултат.

HTTP status — статус на отговор

Технически код за обработката на заявка. Сам по себе си не доказва изпълнено бизнес изискване.

Mock / simulation — симулация

Заместител на част от реалното поведение за определени условия. Успехът ѝ не доказва работа с реалната заменена зависимост.

Log — журнал

Запис на събития в система. Точен час и ID помагат на отговорния екип да намери съответното събитие.

Терминологична справка: ISTQB Glossary. За уеб обмена: MDN — Overview of HTTP. Поясненията тук са формулирани за практическата работа в ръководството.

Кратки отговори за ежедневната работа

Нужна ли е снимка за всяка стъпка?

Не задължително. Следвай изискванията за доказателства на екипа. Запази достатъчно, за да се потвърдят ключовият резултат, контекстът и отклонението. Много снимки без ID, версия и обяснение не правят резултата по-проследим.

Ако проблемът се появи само веднъж?

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

Мога ли да използвам демонстрацията като UAT резултат?

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

Какво правя, ако липсва изискване?

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

Може ли да има приемане с останал дефект?

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

Кога мога да приключа работа по сценария?

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