Какво е тестване за приемане от потребителя (UAT): Пълно ръководство

what is user acceptance testing

Научете какво е тестване за приемане от потребителя (UAT), заедно с неговото определение, типове, стъпки и примери:

Моето правило номер едно, когато се опитвам да разбера нова концепция, е, че: името винаги ще бъде от значение и най-вече буквално значение (в технически контекст).

Разберете какво е това, ще даде първоначално разбиране за него и ще ми помогне да започна.

Въпроси и отговори за интервю за бизнес анализатор за банковия домейн

=> Щракнете тук за пълна серия уроци за план за тестване

Нека изпробваме тази концепция.

=> Прочетете всички уроци в нашата серия за изпитване за приемане.

Какво ще научите:

• Какво е тестване за приемане от потребителя?
  • Кога се изпълнява?
  • Кой изпълнява UAT?
  • Необходимост от тестване за приемане от потребителя
  • Процес на тестване за приемане от потребителя
  • Управление на UAT
  • Планиране на тестове на UAT
  • Дизайн за тестване на приемане от потребителя
  • Изпълнение на теста
  • Инструменти и методологии
  • UAT в гъвкава среда
  • Екип на UAT - Роли и отговорности
• 7 Предизвикателства пред UAT и план за смекчаване
• Тестване на системата срещу тестване за приемане от потребителя
• Заключение
  • Препоръчително четене

Какво е тестване за приемане от потребителя?

Знаем какво е тестване, приемането означава одобрение или съгласие. Потребителят в контекста на софтуерен продукт е или потребителят на софтуера, или лицето, което е поискало да бъде изградено за него (клиент).

И така, следвайки моето правило - определението ще бъде:

Тестът за приемане от потребителя (UAT), известен също като бета или тестване на краен потребител, се определя като тестване на софтуера от потребителя или клиента, за да се определи дали той може да бъде приет или не. Това е окончателното тестване, извършено след приключване на функционалното, системното и регресионното тестване.

Основната цел на това тестване е да провери софтуера спрямо бизнес изискванията. Това валидиране се извършва от крайните потребители, които са запознати с бизнес изискванията.

UAT, алфа и бета тестване са различни видове тестове за приемане.

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

Кога се изпълнява?

Обикновено това е последната стъпка преди продуктът да започне да работи или преди да бъде приета доставката на продукта. Това се извършва, след като самият продукт е щателно тестван (т.е. след тестване на системата ).

Кой изпълнява UAT?

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

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

Необходимост от тестване за приемане от потребителя

Разработчиците и функционалните изпитатели са технически хора, които валидират софтуера срещу функционални спецификации . Те интерпретират изискванията според своите знания и разработват / тестват софтуера (тук е важността на знанията за домейн).

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

Това тестване играе важна роля при валидирането дали всички бизнес изисквания са изпълнени или не преди пускането на софтуера за пазарна употреба. Използването на данни на живо и случаи на реална употреба правят това тестване важна част от цикъла на издаване.

Много бизнеси, които са претърпели големи загуби поради проблеми след пускането, знаят колко е важен успешният тест за приемане от потребителя. Разходите за отстраняване на дефектите след освобождаването са в пъти по-големи от поправянето им преди.

Наистина ли е необходим UAT?

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

UAT е тестова фаза, която до голяма степен зависи от перспективата на крайните потребители и знанията за домейна на отдел, който представлява крайните потребители.

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

Процес на тестване за приемане от потребителя

Най-лесният начин да разберете този процес е да мислите за него като за проект за автономно тестване - което означава, че той ще има фази на план, дизайн и изпълнение.

Следват предпоставките преди началото на фазата на планиране:

# 1) Съберете ключовите критерии за приемане

С прости думи, критериите за приемане са списък с неща, които ще бъдат оценени преди да приемете продукта.

Те могат да бъдат от 2 вида:

(i) Функционалност на приложението или свързано с бизнеса

В идеалния случай всички ключови бизнес функционалности трябва да бъдат валидирани, но поради различни причини, включително време, не е практично да се прави всичко. Следователно една или две срещи с клиента или потребителите, които ще участват в това тестване, могат да ни дадат представа за това колко тестване ще бъде включено и какви аспекти ще бъдат тествани.

(ii) договорни - Няма да навлизаме в това и участието на екипа за QA във всичко това е почти нищо. Първоначалният договор, който се изготвя още преди да започне SDLC, се преразглежда и се постига споразумение дали всички аспекти на договора са доставени или не.

Ще се съсредоточим само върху функционалността на приложението.

# 2) Определете обхвата на ангажимента за осигуряване на качеството.

Ролята на QA екипа е една от следните:

(i) Без участие - Това е много рядко.

(ii) Помогнете при това тестване - Най-често. В този случай нашето участие може да бъде обучение на потребителите на UAT как да използват приложението и да бъдат в готовност по време на това тестване, за да сме сигурни, че можем да помогнем на потребителите в случай на затруднение. Или в някои случаи, освен че сме в режим на готовност и помагаме, можем да споделим техните отговори и да запишем резултатите или да регистрираме грешки и т.н., докато потребителите извършват действителното тестване.

(iii) Изпълнете UAT и представете резултатите - Ако случаят е такъв, потребителите ще посочат областите на AUT, които искат да оценят, а самата оценка се извършва от екипа за QA. След като приключат, резултатите се представят на клиентите / потребителите и те ще вземат решение дали резултатите, които имат в ръцете си, са достатъчни или не и в съответствие с техните очаквания, за да приемат AUT. Решението никога не е на екипа за QA.

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

Основните цели и очаквания:

Обикновено UAT се извършва от експерт по предметни въпроси (МСП) и / или бизнес потребител, който може да бъде собственик или клиент на тествана система. Подобно на фазата на тестване на системата, фазата на UAT също обхваща религиозни фази, преди да бъде приключена.

Основните дейности на всяка фаза на UAT са дефинирани по-долу:

Управление на UAT

Подобно на системното тестване, ефективното управление се прилага и за UAT, за да се гарантира, че има качествени порти, заедно с дефинираните критерии за влизане и излизане (предоставени по-долу **).

** Моля, обърнете внимание, че това е само насока. Това може да бъде променено въз основа на нуждите и изискванията на проекта.

Планиране на тестове на UAT

Процесът е почти същият като при редовен план за изпитване във фазата на системата.

Най-често срещаният подход, използван в повечето от проектите, е да се планират заедно както фазите на тестване на системата, така и на UAT. За повече информация относно плана за изпитване на UAT заедно с проба, моля, разгледайте разделите за UAT на приложения план за тест.

План за тестване на приемане от потребителя

(Това е същото, което бихте намерили и на нашия сайт за QA серия за обучение).

Кликнете върху изображението по-долу и превъртете надолу, за да намерите пример за документ на тестовия план в различни формати. В този шаблон проверете раздела UAT.

Датите, средата, участниците (кой), комуникационните протоколи, ролите и отговорностите, шаблоните, резултатите и техния процес на анализ, критериите за влизане-излизане - всичко това и всичко друго, което е от значение, ще бъдат намерени в тестовия план на UAT.

Независимо дали екипът на QA участва, участва частично или изобщо не участва в този тест, нашата работа е да планираме тази фаза и да се уверим, че всичко е взето под внимание.

=> Ето пример на документ за план за приемане от потребителя

Дизайн за тестване на приемане от потребителя

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

(Това са извадки от CSTE CBOK . Това е една от най-добрите налични справки за това тестване.)

Шаблон за тестване на приемане от потребителя:

Въз основа на критериите, ние (екип за осигуряване на качеството) им предоставяме на потребителите списък с UAT тестови случаи. Тези тестови случаи не се различават от нашите редовни системни тестови случаи. Те са просто подмножество, докато тестваме всички приложения, за разлика от тях, само за ключовите функционални области.

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

Изпълнение на теста

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

Или в случай, че екипът за QA извършва тестовете, ние пускаме тестовите случаи на AUT.

След като всички тестове бъдат изпълнени и резултатите са налични, Решение за приемане е направен. Това се нарича още Решение Go / No-Go . Ако потребителите са доволни, това е движение или иначе това е забрана.

Постигането на решение за приемане обикновено е краят на тази фаза.

Инструменти и методологии

Обикновено видът на софтуерните инструменти, които се използват по време на тази фаза на тестване, е подобен на инструментите, използвани при извършване на функционално тестване.

най-добрият софтуер за премахване на вируси за компютър

Инструменти:

Тъй като тази фаза включва валидиране на цялостните потоци на приложението от край до край, може да е трудно да има един инструмент за пълна автоматизация на това валидиране. До известна степен обаче бихме могли да използваме автоматизираните скриптове, разработени по време на тестване на системата.

Подобно на системното тестване, потребителите също биха използвали инструмент за управление на тестове и управление на дефекти като QC, JIRA и др. Тези инструменти могат да бъдат конфигурирани да натрупват данни за фазата на приемане от потребителя.

Методологии:

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

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

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

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

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

UAT в гъвкава среда

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

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

Освен това ще бъде планирана фаза на UAT преди завършването на спринта, където бизнес потребителите ще направят валидирането си.

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

Екип на UAT - Роли и отговорности

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

7 Предизвикателства пред UAT и план за смекчаване

Няма значение дали сте част от издание за милиарди долари или стартиращ екип, трябва да преодолеете всички тези предизвикателства за доставяне на успешен софтуер за крайния потребител.

# 1) Процес на настройка и внедряване на околната среда:

Извършването на този тест в същата среда, използвана от екипа за функционални тестове, със сигурност ще пренебрегне реалните случаи на употреба. Също така, решаващи тестови дейности като тестване на производителността не могат да се извършват в тестова среда с непълна данни от теста .

За този тест трябва да се създаде отделна производствена среда.

След като UAT средата се отдели от тестовата среда, трябва да контролирате ефективно цикъла на освобождаване. Неконтролираният цикъл на освобождаване може да доведе до различни версии на софтуера в тестовата и UAT среда. Ценно време за тест за приемане се губи, когато софтуерът не е тестван на последната версия.

Междувременно времето, необходимо за проследяване на проблеми при неправилна версия на софтуера, е голямо.

# 2) Планиране на теста:

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

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

Това изпитване се извършва в края на тестовия цикъл. Очевидно това е най-критичният период за издаване на софтуера. Забавянето в който и да е от предишните етапи на разработване и тестване ще изяде времето за UAT.

Неправилното планиране на теста, в най-лошите случаи, води до припокриване между системното тестване и UAT. Поради по-малко време и натиск за спазване на сроковете, софтуерът е разположен в тази среда, дори ако функционалното тестване не е завършено. Основните цели на това тестване не могат да бъдат постигнати в такива ситуации.

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

# 3) Обработка на нови бизнес изисквания като инциденти / дефекти:

Неяснотите в изискванията се улавят във фазата на UAT. UAT тестерите откриват проблеми, възникващи поради неясни изисквания (като разглеждат пълния потребителски интерфейс, който не е бил достъпен по време на фазата на събиране на изискванията), и го регистрират като дефект.

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

# 4) Неквалифицирани тестери или тестери без бизнес познания:

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

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

Междувременно присвояването на тестери в края на UAT цикъла не добавя никаква стойност към проекта. Малкото време за обучение на персонала на UAT може значително да увеличи шансовете за успех на UAT.

# 5) Неправилен комуникационен канал:

Комуникацията между екипа за дистанционно разработване, тестване и UAT е по-трудна. Комуникацията по имейл често е много трудна, когато имате офшорни технически екип. Малка неяснота в докладите за инциденти може да забави коригирането му за един ден.

Правилното планиране и ефективната комуникация са от решаващо значение за ефективното сътрудничество в екип. Екипите на проектите трябва да използват уеб-базиран инструмент за регистриране на дефекти и въпроси. Това ще помогне да се разпредели равномерно работното натоварване и да се избегне докладването на дублиращи се проблеми.

# 6) Помолете екипа за функционален тест да извърши това тестване:

Няма по-лоша ситуация от това да помолите екипа за функционален тест да извърши UAT.

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

Решението за това е да се възложи това тестване на специализирани и опитни тестери, имащи бизнес познания.

# 7) Виновната игра

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

Много е трудно да се справим с такива ситуации. Изграждането на положителни отношения с бизнес екипа обаче определено би помогнало да се избегне играта на вина.

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

Тестване на системата срещу тестване за приемане от потребителя

Участието на екипа за тестване започва доста рано в проекта още от фазата на анализ на изискванията.

През целия жизнен цикъл на проекта се извършва някакъв вид валидиране за проекта, т.е. Статично тестване , Тестване на единица, Тестване на системата, Тестване на интеграция, Тестване от край до край или Регресия. Това ни оставя да разберем по-добре за тестването, извършено във фазата на UAT и колко различно е от другите тестове, извършени по-рано.

Въпреки че виждаме разликите в SIT и UAT, важно е да използваме синергии, но все пак да запазим независимостта между двете фази, което би позволило по-бързото пускане на пазара.

Заключение

# 1) UAT не е за страниците, полетата или бутоните. Основното предположение още преди този тест да започне е, че всички основни неща са тествани и работят добре. Не дай Боже, потребителите намират грешка като основна като тази - това е много лоша новина за екипа за QA. :(

# две) Това тестване е за субекта, който е основният елемент в бизнеса.

Позволете ми да ви дам пример: Ако AUT е система за продажба на билети, UAT няма да бъде, търсене на менюто, което отваря страница и т.н. Става въпрос за билетите и тяхната резервация, състоянията, които може да предприеме, пътуването си през системата, и т.н.

Друг Пример, ако сайтът е сайт за автокъщи, тогава фокусът е върху „автомобила и продажбите му“, а не всъщност на сайта. Следователно основният бизнес е това, което е проверено и валидирано и кой е по-добре да го направи от собствениците на бизнеса. Ето защо това тестване е най-смислено, когато клиентът е ангажиран в голяма степен.

опашка от указатели c ++

# 3) UAT също е форма на тестване в основата си, което означава че има голям шанс да се идентифицират някои грешки и на този етап . Понякога се случва. Освен факта, че това е голяма ескалация на екипа за осигуряване на качеството, грешките на UAT обикновено означават среща, за да седят и да обсъдят как да се справят с тях, тъй като след това тестване обикновено няма време за поправяне и повторно тестване.

Решението ще бъде или:

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

# 4) UAT е класифициран като алфа и бета тестване, но тази класификация не е толкова важна в контекста на типичните проекти за разработване на софтуер в индустрия, базирана на услуги.

• Алфа тестване е, когато UAT се извършва в средата на производителя на софтуер и е по-важно в контекста на търговския софтуер, който не е на разположение.
• Бета тестване е когато UAT се извършва в производствената среда или в средата на клиента. Това е по-често за приложения, ориентирани към клиентите. Потребителите тук са действителните клиенти като вас и мен в този контекст.

# 5) По - голямата част от времето в редовен проект за разработване на софтуер, UAT се извършва в QA среда ако няма сценична или UAT среда.

Накратко, най-добрият начин да разберете дали вашият продукт е приемлив и подходящ за целта е да го поставите пред потребителите.

Организациите навлизат в Agile начина на доставка, бизнес потребителите се включват по-активно и проектите се подобряват и доставят чрез цикли за обратна връзка. Всичко свършено, фазата на приемане от потребителя се счита за врата за влизане в изпълнение и производство.

Какво беше вашето преживяване в UAT? Бяхте ли в режим на готовност или тествахте ли за вашите потребители? Потребителите откриха ли някакви проблеми? Ако да, как се справихте с тях?

=> Също така прочетете ВСИЧКИ уроци от тази поредица тук

=> Посетете тук за пълна серия уроци за план за тестване

Препоръчително четене

• Алфа тестване и бета тестване (Пълно ръководство)
• Какво е тестване за приемане (Пълно ръководство)
• Пълно ръководство за тестване за проверка на компилация (BVT тестване)
• Функционално тестване срещу нефункционално тестване
• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Видове тестване на софтуер: Различни видове тестване с подробности
• Урок за тестване на хранилище на данни за ETL (Пълно ръководство)
• Урок за тестване на GUI: Пълно ръководство за тестване на потребителския интерфейс (UI)