what is user acceptance testing
Сазнајте шта је тестирање прихватљивости корисника (УАТ), заједно са његовом дефиницијом, типовима, корацима и примерима:
Моје правило број један када покушавам да разумем нови концепт је следеће: име ће увек бити релевантно и углавном дословно значење (у техничком контексту).
Откривање шта је то, даће вам почетно разумевање и помоћи ми да започнем.
које врсте апликација тестирамо
=> Кликните овде за комплетну серију водича за план испитивања
Ставимо овај концепт на тест.
=> Прочитајте све водиче у нашој серији Испитивање прихватљивости.
Шта ћете научити:
- Шта је тестирање прихватљивости корисника?
- 7 изазова УАТ-а и плана ублажавања
- Тестирање система против тестирања прихватљивости корисника
- Закључак
Шта је тестирање прихватљивости корисника?
Знамо шта је тестирање, прихватање значи одобрење или споразум. Корисник у контексту софтверског производа је или потрошач софтвера или особа која је тражила да се он изради за њега (клијента).
Дакле, следећи моје правило - дефиниција ће бити:
Тестирање прихватљивости корисника (УАТ), такође познато као бета или тестирање крајњег корисника, дефинише се као тестирање софтвера од стране корисника или клијента како би се утврдило да ли се може прихватити или не. Ово је завршно испитивање извршено након што се заврше функционална, системска и регресиона испитивања.
Главна сврха овог тестирања је да се софтвер потврди у складу са пословним захтевима. Ову проверу врше крајњи корисници који су упознати са пословним захтевима.
УАТ, алфа и бета тестирање су различите врсте испитивања прихватљивости.
Како је тест прихватања корисника последње тестирање које се спроводи пре него што софтвер почне да ради, очигледно је ово последња шанса за купца да тестира софтвер и измери да ли је примерен за ту намену.
Када се изводи?
Ово је обично последњи корак пре пуштања производа у рад или пре него што се прихвати испорука производа. Ово се изводи након што се сам производ темељито испита (тј након тестирања система ).
Ко изводи УАТ?
Корисници или клијенти - То може бити неко ко купује производ (у случају комерцијалног софтвера) или неко коме је софтвер направљен по наруџби преко добављача софтверских услуга или крајњи корисник ако им је софтвер доступан испред времена и када се траже њихове повратне информације.
Тим се може састојати од бета тестера или купац треба интерно да изабере чланове УАТ-а из сваке групе организације како би свака корисничка улога могла бити тестирана у складу с тим.
Потреба за тестирањем прихватљивости корисника
Програмери и функционални тестери су технички људи који потврђују софтвер против функционалне спецификације . Захтеве тумаче у складу са својим знањем и развијају / тестирају софтвер (овде је значај знања из домена).
Овај софтвер је потпун у складу са функционалним спецификацијама, али постоје неки пословни захтеви и процеси који су познати само крајњим корисницима или су пропуштени у комуникацији или су погрешно протумачени.
Ово тестирање игра важну улогу у валидацији да ли су испуњени сви пословни захтеви или не пре пуштања софтвера у употребу на тржишту. Коришћење података уживо и случајеви стварне употребе чине ово тестирање важним делом циклуса издавања.
Многа предузећа која су претрпела велике губитке због проблема после издавања знају важност успешног теста прихватања корисника. Трошкови отклањања недостатака након пуштања вишеструко су већи од отклањања недостатака пре.
Да ли је УАТ заиста потребан?
Након извођења оптерећења система, интеграцијског и регресијског тестирања, поставило би се питање о неопходности овог тестирања. Заправо, ово је најважнија фаза пројекта, јер је ово време у којем ће корисници који ће заиста користити систем валидирати систем у складу са његовом наменом.
УАТ је фаза испитивања која у великој мери зависи од перспективе крајњих корисника и знања о домену одељења које представља крајње кориснике.
Заправо, заиста би било корисно за пословне тимове ако би били укључени у пројекат прилично рано, тако да могу пружити своје ставове и доприносе који би помогли ефикасном коришћењу система у стварном свету.
Процес тестирања прихватања корисника
Најлакши начин да се овај процес разуме је да се о њему мисли као о пројекту аутономног тестирања - што значи да ће имати план, дизајн и фазе извршења.
Следе предуслови пре почетка фазе планирања:
# 1) Прикупите кључне критеријуме прихватања
Једноставно речено, критеријум прихватљивости је списак ствари које ће се оценити пре прихватања производа.
То могу бити две врсте:
(и) Функционалност апликације или пословно повезано
Идеално би било да се потврди сва кључна пословна функционалност, али из различитих разлога, укључујући време, није практично то све радити. Стога, састанак или два са клијентом или корисницима који ће бити укључени у ово тестирање могу нам дати идеју о томе колико ће тестирања бити укључено и који ће аспекти бити тестирани.
(ии) уговорни - Нећемо улазити у ово, а учешће КА тима у свему томе је готово ништа. Почетни уговор који се састави и пре него што СДЛЦ започне се преиспитује и постиже се споразум о томе да ли су сви аспекти уговора испоручени или не.
Усредсредићемо се само на функционалност апликације.
# 2) Дефинисати обим КА укључености.
Улога КА тима је једна од следећих:
(и) Нема учешћа - Ово је врло ретко.
(ии) Асистирајте у овом испитивању - Најчешћи. У овом случају, наше учешће би могло да обучи кориснике УАТ-а како да користе апликацију и буду у приправности током овог тестирања како бисмо били сигурни да можемо помоћи корисницима у случају било каквих потешкоћа. Или у неким случајевима, поред тога што ћемо бити у стању приправности и помоћи, можда ћемо делити њихове одговоре и снимати резултате или евидентирати грешке итд., Док корисници извршавају стварно тестирање.
(иии) Извршите УАТ и представите резултате - Ако је то случај, корисници ће усмерити подручја АУТ-а која желе да процене, а сам процену врши КА тим. Када се заврше, резултати се представљају клијентима / корисницима и они ће донети одлуку да ли су резултати који су им на располагању довољни или не и у складу са њиховим очекивањима да би прихватили АУТ. КА тим никада не доноси одлуку.
У зависности од случаја који имамо, одлучујемо који је приступ најбољи.
Примарни циљеви и очекивања:
Обично УАТ предузима стручњак за предметна питања (СМЕ) и / или пословни корисник, који би могао бити власник или купац система који се испитује. Слично фази тестирања система, фаза УАТ такође обухвата верске фазе пре него што се приведе крају.
Кључне активности сваке фазе УАТ-а дефинисане су у наставку:
УАТ управљање
Слично тестирању система, за УАТ се примењује ефикасно управљање како би се осигурало да постоје квалитетне капије заједно са дефинисаним критеријумима за улазак и излазак (наведени у наставку **).
** Имајте на уму да је то само смерница. Ово се може изменити на основу потреба и захтева пројекта.
УАТ планирање теста
Процес је готово исти као код редовни план испитивања у фази система.
Најчешћи приступ који се примењује у већини пројеката је планирање и фазе тестирања система и УАТ. За више информација о плану испитивања УАТ-а, заједно са узорком, погледајте одељке УАТ-а у приложеном документу плана испитивања.
План теста за прихватање корисника
(Ово је исто што бисте пронашли и на нашој веб локацији за серију КА тренинга).
Кликните на доњу слику и померите се надоле да бисте пронашли узорак документа теста у различитим форматима. У том предлошку проверите одељак УАТ.
Датуми, окружење, актери (који), комуникацијски протоколи, улоге и одговорности, предлошци, резултати и њихов поступак анализе, критеријуми за улазак-излазак - све ово и све остало што је релевантно наћи ће се у плану тестирања УАТ-а.
Без обзира да ли КА тим учествује, делимично или уопште не учествује у овом тесту, наш посао је да планирамо ову фазу и осигурамо да се све узме у обзир.
=> Ево примера документа о плану за прихватање корисника
Дизајн испитивања прихватљивости корисника
У овом кораку се користе прикупљени критеријуми прихваћености од корисника. Узорци могу изгледати као што је приказано доле.
(Ово су изводи из ЦСТЕ ЦБОК . Ово је једна од најбољих доступних референци о овом тестирању.)
Предложак за тестирање прихватљивости корисника:
На основу критеријума, ми (КА тим) им дајемо корисницима листу УАТ тест случајева. Ови тест случајеви се не разликују од наших уобичајених системских тест случајева. Они су само подскуп док тестирамо све апликације, за разлику од кључних функција.
Поред ових, подаци, предлошци за бележење резултата испитивања, административне процедуре, механизам евидентирања квара итд., Морају да буду на месту пре него што пређемо на следећу фазу.
Извршење теста
Обично, када је то могуће, ово тестирање се дешава у конференцијској или ратној соби, где корисници, ПМ, представници КА тима седе заједно или дан или два и раде на свим случајевима испитивања прихватања.
Или у случају да КА тим врши тестове, покрећемо тест случајеве на АУТ.
Једном када су сви тестови покренути и резултати су на располагању, Одлука о прихватању је направљен. Ово се такође назива Одлука Иди / Не-крени . Ако су корисници задовољни, то је кретање или је то забрањено кретање.
која је одговарајућа маска подмреже за мрежу између два хоста
Доношење одлуке о прихватању обично је крај ове фазе.
Алати и методологије
Типично, тип софтверских алата који се користе током ове фазе тестирања сличан је алатима који се користе током извођења функционалног тестирања.
Алати:
Како ова фаза укључује валидацију комплетних токова апликације од краја до краја, можда ће бити тешко имати један алат за потпуно аутоматизовање ове провере ваљаности. Међутим, донекле бисмо могли да искористимо аутоматизоване скрипте развијене током тестирања система.
Слично тестирању система, корисници би такође користили алате за управљање тестовима и управљање недостацима као што су КЦ, ЈИРА итд. Ови алати могу се конфигурисати за кумулирање података за фазу прихватања корисника.
Методологије:
Иако су конвенционалне методологије, као што су специфични пословни корисници који изводе УАТ производа, и даље релевантне, у истински глобалном свету какав је данас, испитивање прихватљивости корисника понекад мора да укључи различите купце из различитих земаља на основу производа.
На пример, веб локацију е-трговине користили би купци широм света. У оваквим сценаријима, тестирање масе би било најбоља одржива опција.
Тестирање гужве је методологија у којој људи из целог света могу да учествују и потврде употребу производа и дају предлоге и препоруке.
Изграђене су платформе за тестирање гужве које сада користе многе организације. На платформи се хостује веб локација или производ који треба да се тестира у маси, а купци могу сами да се номинују за валидацију. Затим се анализирају и дају се приоритетне повратне информације.
Методологија испитивања гужве показује се ефикаснијом јер се пулс купаца широм света може лако разумети.
УАТ у окретном окружењу
Окретно окружење је динамичније природе. У агилном свету, пословни корисници ће бити укључени током читавог спринта пројекта, а пројекат ће бити унапређен на основу њихових петљи повратних информација.
На почетку пројекта, пословни корисници били би кључни учесници у пружању захтева чиме би се ажурирало заостале производе. На крају сваког спринта, пословни корисници би учествовали у демонстрацији спринта и били би доступни за пружање било каквих повратних информација.
Штавише, планирала би се фаза УАТ пре завршетка спринта, где би пословни корисници вршили валидацију.
Повратне информације добијене током демонстрације спринта и спринта УАТ, сакупљају се и додају назад у заостатак производа који се непрестано прегледава и даје им приоритет. Тако су у агилном свету пословни корисници ближи пројекту и чешће га процењују за његову употребу, за разлику од традиционалних пројеката водопада.
УАТ тим - Улоге и одговорности
Типична организација УАТ-а имала би следеће улоге и одговорности. УАТ тим подржао би менаџер пројеката, развојни и испитни тимови на основу њихових потреба.
Улоге | Одговорности | Испоруке |
---|---|---|
Менаџер пословног програма | • Стварање и одржавање плана испоруке програма • Прегледати и одобрити стратегију и план тестирања УАТ • Осигурајте успешно завршавање програма према распореду и буџету • Повежите се са менаџером ИТ програма и надгледајте напредак програма • Уско сарађујте са тимом за пословну операцију и припремите их за рад 1. дана • Документ о пословном захтеву за одјаву • Прегледајте садржај курса е-учења | • Извештај о напретку програма • Недељни извештај о статусу |
УАТ Тест Манагер | • Стратегија Крета УАТ • Осигурати ефикасну сарадњу између ИТ и Бусинесс БА и ПМО • Учествујте у састанцима са детаљним упутствима • Прегледајте процену напора, план испитивања • Осигурајте сљедивост захтјева • Потакните прикупљање метричких података како бисте квантификовали користи које произилазе из ажуриране методологије испитивања, алата и употребе окружења | • Стратегија мастер теста • Прегледајте и одобрите тест сценарије • Прегледајте и одобрите тест случајеве • Прегледајте и одобрите матрицу сљедивости захтјева • Недељни извештај о статусу |
УАТ тест тим и вођа | • Потврдите и потврдите пословне захтеве у односу на пословни процес • Процена за УАТ • Направите и извршите УАТ тест план • Учествовати у захтеву ЈАД сесије • Припремите сценарије тестирања, тестове и податке о тестовима на основу пословног процеса • Одржавање следљивости • Извршите тест случајеве и припремите евиденције тестова • Пријавите недостатке у алату за управљање тестовима и управљајте њима током њиховог животног циклуса • Израдити УАТ Крај извештаја о испитивању • Пружите подршку за пословну спремност и доказивање уживо | • Тест Лог • Недељни извештај о статусу • Извештај о недостацима • Метрике извршења теста • Резиме теста • Архивирани артефакти за вишекратну употребу |
7 изазова УАТ-а и плана ублажавања
Није битно да ли сте део милијарде долара издања или стартуп тима, требало би да превазиђете све ове изазове за испоруку успешног софтвера за крајњег корисника.
# 1) Постављање окружења и процес примене:
Спровођење овог теста у истом окружењу које користи тим за функционални тест сигурно ће на крају превидети случајеве употребе у стварном свету. Такође, кључне активности тестирања, попут испитивања перформанси, не могу се изводити у тестном окружењу са непотпуним тест подаци .
За овај тест треба поставити посебно окружење налик производњи.
Једном када се УАТ окружење одвоји од тест окружења, морате ефикасно да контролишете циклус ослобађања. Неконтролисани циклус издавања може довести до различитих верзија софтвера у тестном и УАТ окружењу. Драгоцено време теста за прихватање губи се када софтвер није тестиран на најновијој верзији.
У међувремену, време потребно за праћење проблема на нетачној верзији софтвера је велико.
# 2) Планирање теста:
Ово испитивање треба планирати са јасним планом испитивања прихватања у фази анализе захтева и пројектовања.
У стратешком планирању, низ случајева стварне употребе треба идентификовати за извршење. Веома је важно дефинисати циљеве теста за ово тестирање, јер потпуно извршење теста није могуће за велике апликације у овој фази тестирања. Тестирање треба извршити давањем прво приоритета кључним пословним циљевима.
Ово испитивање се врши на крају циклуса испитивања. Очигледно је да је то најкритичнији период за издавање софтвера. Кашњење у било којој од претходних фаза развоја и тестирања појешће време УАТ-а.
Неправилно планирање теста, у најгорим случајевима, доводи до преклапања између системског тестирања и УАТ-а. Због мање времена и притиска да се испоштују рокови, софтвер се примењује у ово окружење чак и ако функционално тестирање није завршено. Основни циљеви овог тестирања не могу се постићи у таквим ситуацијама.
План УАТ теста треба припремити и саопштити тиму пре почетка овог теста. Ово ће им помоћи у планирању теста, писању тест случајева и тест скрипти и стварању УАТ окружења.
# 3) Руковање новим пословним захтевима као инцидентима / недостацима:
Нејасноће у захтевима захваћају се у фази УАТ. УАТ тестери проналазе проблеме који настају услед двосмислених захтева (гледањем комплетног корисничког интерфејса који није био доступан током фазе прикупљања захтева) и пријављују га као квар.
Купац очекује да се то поправи у тренутном издању, не узимајући у обзир време за захтеве за промену. Ако руководство пројекта не донесе благовремену одлуку о овим променама у последњем тренутку, то би могло довести до неуспеха издања.
# 4) Неквалификовани тестери или тестери без пословног знања:
Када нема сталног тима, компанија бира особље УАТ-а из различитих интерних одељења.
Чак и ако је особље добро упознато са пословним потребама или ако није обучено за нове захтеве који се развијају, не могу да изврше ефикасан УАТ. Такође, нетехнички пословни тим могао би се суочити са многим техничким потешкоћама у извршавању тест случајева.
У међувремену, додељивање тестера на крају УАТ циклуса не додаје никакву вредност пројекту. Мало времена за обуку особља УАТ-а може значајно повећати шансе за успех УАТ-а.
# 5) Неправилни комуникациони канал:
Комуникација између даљинског развоја, тестирања и УАТ тима је тежа. Комуникација путем е-поште често је веома тешка када имате офшор технички тим. Мала нејасноћа у извештајима о инцидентима може одложити његово поправљање за један дан.
Правилно планирање и ефикасна комуникација пресудни су за ефикасну тимску сарадњу. Пројектни тимови би требало да користе веб алатку за евидентирање недостатака и питања. Ово ће вам помоћи да равномерно распоредите радно оптерећење и избегнете пријављивање дупликата.
# 6) Затражити од функционалног теста да изврши ово тестирање:
Нема горе ситуације од тражења од функционалног тест тима да изврши УАТ.
Купци пребацују своју одговорност на тест тим због недостатка ресурса. Читава сврха овог тестирања је угрожена у таквим случајевима. Једном када софтвер почне да ради, крајњи корисници ће брзо уочити проблеме које функционални тестери не сматрају стварним сценаријем.
Решење за ово је доделити ово тестирање посвећеним и вештим тестерима који имају пословно знање.
# 7) Игра кривице
Понекад пословни корисници само покушавају да пронађу разлоге за одбијање софтвера. Могло би бити њихово самопоштовање да покажу колико су супериорни или криви тим за развој и тестирање да би стекли поштовање у пословном тиму. То је врло ретко, али се дешава у тимовима са унутрашњом политиком.
Веома је тешко суочити се са таквим ситуацијама. Међутим, изградња позитивног односа са пословним тимом дефинитивно би помогла да се избегне игра кривице.
Надам се да ће вам ове смернице сигурно помоћи да извршите успешан план прихватања корисника превладавањем различитих изазова. Правилно планирање, комуникација, извршавање и мотивисани тим кључеви су успешног тестирања прихватљивости корисника.
Тестирање система против тестирања прихватљивости корисника
Укључивање тима за тестирање започиње прилично рано у пројекту одмах од фазе анализе захтева.
Током читавог животног циклуса пројекта врши се нека врста валидације пројекта, тј. Статичко испитивање , Јединствено тестирање, Системско тестирање, интеграционо тестирање, тестирање од краја до краја или регресијско тестирање. Ово нам оставља да боље разумемо испитивања извршена у фази УАТ и колико се разликује од осталих испитивања извршених раније.
Иако видимо разлике у СИТ и УАТ, важно је да искористимо синергије, али да и даље задржимо независност између обе фазе, што би омогућило брже излазак на тржиште.
како уклонити елемент низа у јави
Закључак
# 1) УАТ се не односи на странице, поља или дугмад. Је основна претпоставка чак и пре него што овај тест започне, све основне ствари су тестиране и раде добро. Не дај Боже, корисници сматрају да је грешка тако основна - то је врло лоша вест за КА тим. :(
#два) Ово тестирање говори о ентитету који је примарни елемент у послу.
Даћу вам пример: Ако је АУТ систем за продају карата, неће трајати УАТ, тражење менија који отвара страницу итд. Ради се о картама и њиховој резервацији, државама које може да предузме, свом путовању кроз систем, итд.
Други Пример, ако је сајт сајт ауто-куће, онда је фокус на „аутомобилу и његовој продаји“, а не на месту. Отуда је основна делатност оно што је верификовано и потврђено и ко је бољи за обављање послова од власника предузећа. Зато је ово тестирање најразумније када је купац у великој мери укључен.
# 3) УАТ је такође облик тестирања у својој основи, што значи да у овој фази постоје добре шансе за идентификовање неких грешака . То се понекад догоди. Поред чињенице да је то велика ескалација КА тима, УАТ грешке обично значе састанак да би се седело и разговарало о томе како са њима поступати, јер након овог тестирања обично нема времена за поправљање и поновно тестирање.
Одлука би била да се:
- Притисните датум покретања, прво решите проблем, а затим идите даље.
- Оставите бубу каква јесте.
- Сматрајте то делом захтева за промену будућих издања.
# 4) УАТ је класификован као алфа и бета тестирање, али та класификација није толико важна у контексту типичних пројеката развоја софтвера у индустрији заснованој на услугама.
- Алфа тестирање је када се УАТ изводи у окружењу произвођача софтвера и значајнији је у контексту комерцијалног софтвера.
- Бета тестирање је када се УАТ врши у производном окружењу или окружењу клијента. Ово је чешће за апликације окренуте купцима. Корисници овде су стварни купци попут вас и мене у овом контексту.
# 5) Већину времена у редовном пројекту развоја софтвера, УАТ се изводи у КА окружење ако нема сценског или УАТ окружења.
Укратко, најбољи начин да сазнате да ли је ваш производ прихватљив и одговара својој намени је да га заправо ставите пред кориснике.
Организације улазе у агилни начин испоруке, пословни корисници се све више укључују, а пројекти се побољшавају и испоручују путем петљи повратних информација. Све је завршено, фаза прихватања корисника сматра се вратом за улазак у имплементацију и производњу.
Какво је ваше УАТ искуство? Да ли сте били у стању приправности или сте тестирали своје кориснике? Да ли су корисници пронашли неке проблеме? Ако јесте, како сте се носили са њима?
=> Овде прочитајте и СВЕ водиче из ове серије
=> Посетите овде за комплетну серију водича за план испитивања
Препоручено читање
- Алфа тестирање и бета тестирање (потпун водич)
- Шта је испитивање прихватљивости (потпун водич)
- Комплетни водич за тестирање верификације израде (БВТ тестирање)
- Функционално тестирање вс нефункционално тестирање
- Најбољи алати за тестирање софтвера 2021. године (КА Тест Аутоматион Тоолс)
- Врсте тестирања софтвера: различите врсте испитивања са детаљима
- Водич за тестирање складишта података ЕТЛ (комплетан водич)
- Водич за ГУИ тестирање: Комплетан водич за тестирање корисничког интерфејса (УИ)