Kūrimo proceso metu labai svarbu užtikrinti, kad programinė įranga prieš ją išleidžiant veiktų taip, kaip tikėtasi.
Tam reikia atlikti itin kruopštų testavimą per visą kūrimo laikotarpį ir įsitikinti, kad jūsų produktas yra tinkamas naudotojui.
Būtent čia pradedamas naudotojo priimtinumo testavimas (UAT).
Sužinokite daugiau apie tai, kas yra naudotojo priėmimo testavimas, kokie yra skirtingi naudotojo priėmimo testavimo tipai ir kaip užbaigti šį procesą, taip pat apie kai kuriuos programinės įrangos įrankius, kurie supaprastins jūsų UAT testavimo procesus.
Ką reiškia UAT testavimas?
UAT testavimas – tai paskutinis programinės įrangos kūrimo proceso etapas.
Šiame proceso etape parengiamas galutinis produktas ir siunčiamas įvairiems realios programinės įrangos naudotojams ir klientams, kad šie pateiktų atsiliepimus. Taip užtikrinama, kad programinė įranga pagal pradines projektavimo specifikacijas galėtų veikti pagal realaus pasaulio scenarijus, ir nustatoma, ar klientai yra patenkinti jūsų sukurtu produktu.
Naudodamiesi šia grįžtamąja informacija, paskutinę minutę atlikite būtinus programinės įrangos pakeitimus ir išsiųskite galutinį produktą, kuris patiks klientams.
Kai kurie kiti terminai, apibūdinantys šią testavimo formą, yra beta testavimas, programų testavimas ir galutinio vartotojo testavimas, o ankstyvosios prieigos žaidimai yra viena iš labiausiai paplitusių šios strategijos formų.
1. Kada reikia atlikti UAT testavimą (User Acceptance Testing)?
UAT testai yra palyginti nelankstūs laiko atžvilgiu. Norint atlikti UAT bandymus, reikia, kad visos programinės įrangos funkcijos būtų suprogramuotos produkte.
Taip yra todėl, kad jūsų potencialūs klientai bando produktą taip, kaip jie tai darytų įprastomis darbo dienomis, todėl reikia visų funkcijų ir ypatybių, kuriomis, kaip tikitės, žmonės naudosis kasdien.
Taip pat būtina turėti išsamią vartotojo sąsają, nes naudotojai turi veiksmingai naršyti sistemoje, kad galėtų maksimaliai išnaudoti laiką, praleistą su programa.
Prieš išleisdami produktą į plačiąją rinką taip pat įsitikinkite, kad užbaigėte UAT. Jei tai darote kartu su išleidimu, tai reiškia, kad siunčiate produktą, kuris gali turėti klaidų, prastą funkcionalumą ir grafinių trikdžių.
Priešingai, prieš išleisdami produktą prieš išleidžiant jį į rinką, turite laiko išspręsti visas problemas, kurios vis dar yra programinėje įrangoje, ir turite trumpą laiką, per kurį galite patobulinti savo produktą prieš jį išleidžiant į rinką.
2. Kai nereikia UAT testų
Yra keletas atvejų, kai UAT testų nereikia.
Pirmasis iš jų yra susijęs su produktais, kuriems reikia atlikti UAT bandymus, bet ne šiame proceso etape. Atlikdami naudotojo patvirtinimo testavimą ankstesnėje proceso stadijoje, rizikuojate praleisti problemas, kurios bus galutinėje produkto versijoje.
Nereikia atlikti UAT testų bet kuriuo metu, kol nebaigtas viso projekto kūrimas, nes galutiniam naudotojui pateiksite neužbaigtą produktą. Projekto pradžioje šio testavimo neprireiks, nes neturėsite išankstinio produkto, kurį galėtumėte išbandyti.
Yra keletas kraštutinių atvejų, kai vykstant kūrimo procesams UAT iš viso nenaudojamas testavimui, o produktas paleidžiamas į rinką netestuojant programinės įrangos naudojant galutinį naudotoją.
Kai kurie iš tokių atvejų:
Pavėluotai pradedamas gaminti produktas
Kai kuriose pramonės šakose taikomi labai griežti projektų pradžios laiko reikalavimai.
Jei programinės įrangos produktas vėluoja, kai kurie leidėjai, norėdami pasiekti galutinį terminą, gali jį paleisti nebaigę UAT ir vėliau pataisyti programinę įrangą.
Vartotojų trūkumas
Kai kurie kūrėjai kuria produktus, skirtus itin specifinėms situacijoms, ir jei klientas yra vienintelis, kuris susiduria su jų funkcijomis, tuomet UAT bandymų nereikia, nes šie bandymai iš tikrųjų būtų minkštas paleidimas.
Programinės įrangos paprastumas
Jei išleidžiama programinė įranga yra paprastas žiniatinklio įrankis, kuris atlieka vieną užduotį, UAT testavimo nereikia, nes paleidus programinę įrangą galima greitai ištaisyti problemas ir pateikti atnaujinimą be didelių pertvarkymų.
gatavi produktai
Kai kurios įmonės savo programose naudoja gatavą kodą, kad suteiktų papildomų funkcijų. Tokiais atvejais pradinis pardavėjas atliko UAT bandymus, todėl kūrėjui, naudojančiam šiuos sprendimus, jie nėra būtini.
3. Kas dalyvauja atliekant naudotojo priimtinumo testavimą?
Vartotojo patvirtinimo testavimo procese dalyvauja kelios šalys, kurių kiekviena turi savo unikalius vaidmenis ir atsakomybę. Keletas svarbiausių asmenų, dalyvaujančių UAT procese, yra šie:
Kūrėjai
Programos kūrėjai parengia naujausią programinės įrangos versiją ir išsiunčia ją testuotojams, o gavę testavimo rezultatus atlieka reikiamus pakeitimus.
Testeriai
Testuotojai paprastai yra žmonės, kurie programinę įrangą naudos darbe arba kaip hobį. Prieš pateikdami savo rezultatus įmonei, jie iš anksto suplanuotais bandymais patikrina visas programinės įrangos funkcijas.
Vadovai
Vadovybės darbuotojai organizuoja darbą su testuotojais, be to, pateikia UAT testui keliamų reikalavimų sąrašą ir kai kuriais atvejais užbaigia testų planavimo ir parengimo procesus.
Domeno ekspertas
Jei įmanoma, pasitelkite „srities ekspertą” arba asmenį, turintį atitinkamos srities patirties, kad jis kartu su galutiniais vartotojais atliktų naudotojo priėmimo testus ir pateiktų išsamesnę informaciją, kai apie problemas praneša kūrimo komandai.
UAT testavimo gyvavimo ciklas
Atliekant UAT procesą reikia užbaigti itin kruopštų gyvavimo ciklą, o kiekvienas etapas padeda geriau suprasti, kaip veikia programinė įranga, ir nustatyti galimas tobulinimo sritis.
1. UAT bandymų planavimas
Pirmasis šio proceso etapas – naudotojo patvirtinimo testavimo proceso planavimas.
Planuodami UAT bandymus, užsirašykite esmines proceso dalis, įskaitant verslo reikalavimus, keliamus programinei įrangai, laiką, kurį įmonė turi bandymams atlikti, ir kai kuriuos galimus bandymų scenarijus.
Išsamus planavimas nuo pat pradžių suteikia komandai daugiau aiškumo dėl užduočių, kurias ji atlieka, ir nustato aiškų galutinį tikslą, kurio visi dalyviai turi siekti.
2. Vartotojo priimtinumo testų projektavimas
Kai jau turite galutinį testavimo proceso tikslą, pradėkite kurti naudotojo priėmimo testus.
Tam reikia sukurti strategiją, kuri leistų patikrinti, ar programinė įranga atitinka visus jai keliamus reikalavimus, sukurti bandymų atvejus ir aplinkas, kurios atkartoja realų programinės įrangos naudojimą, ir dokumentuoti UAT išėjimo ir įėjimo kriterijus, kad ji veiktų labai konkrečiose ribose.
Tokiu būdu UAT testams suteikiama daugiau struktūros ir užtikrinama, kad kiekvienas testas būtų atliekamas pakartotinai ir nuosekliai.
3. Bandymų duomenų rengimas
Paruoškite visus duomenis, kuriuos naudosite UAT.
Jei įmanoma, stenkitės naudoti realius duomenis, nesvarbu, ar tai būtų tiesioginiai duomenys, kuriuos įmonė gauna tuo metu, ar ankstesnio laikotarpio pavyzdiniai duomenys.
Saugumo sumetimais anonimizuokite duomenis.
Naudodami realaus pasaulio duomenis, užtikrinate, kad programinė įranga galėtų dirbti aplinkoje, kurioje jūsų klientai dirba kiekvieną dieną.
Tai yra aukštesnis testavimo standartas nei iki šiol taikytas programinei įrangai, todėl, norint, kad UAT testavimo procesas būtų maksimaliai naudingas, duomenis reikia paruošti kuo panašiau į realias, gyvas situacijas.
4. UAT vykdymas
Atlikę kruopštų pasiruošimo ir projektavimo procesą, pradėkite vykdymo procesą.
Tai reiškia, kad reikia atlikti naudotojo priėmimo testą ir pranešti apie bet kokias klaidas, atsiradusias testo metu, įskaitant klaidos atsiradimo laiką, pranešimą, kuriuo programinė įranga reagavo, ir tai, kas paskatino problemą.
Kai kuriais atvejais testų valdymo įrankiai gali automatizuoti šį vykdymo procesą. Jei įmanoma, pakartokite tyrimus, kad įsitikintumėte, jog gauti rezultatai yra patikimi.
5. Palyginti su verslo tikslais
Baigę UAT testavimo procesą, palyginkite ir sugretinkite rezultatus su verslo tikslais.
Jei programinė įranga neatitinka jos tikslų, kūrėjai gali ją ištaisyti prieš kitą bandymų etapą. Šiuo konsolidavimo etapu nustatomas programinės įrangos funkcionalumas ir tai, ar ji yra paruošta išsiuntimui, todėl jis yra toks pat svarbus veiksmingam programinės įrangos kūrimui, kaip ir pats testavimas.
Kai programinė įranga atitinka visus tikslus, ją galima perduoti naudotojams.
UAT testavimo valdymas
Valdymas suteikia UAT testavimo procesui įgaliojimus ir atskaitomybę, užtikrina aukštesnį struktūros lygį ir padeda organizacijoms efektyviau testuoti.
Geras valdymas užtikrina, kad kiekvienas naudotojo priėmimo testas būtų toks pat kaip ir ankstesnis, todėl atskirų testų rezultatai yra nuoseklesni, o komanda geriau žino, kaip tobulinti programinę įrangą.
Valdymo personalas yra atsakingas už UAT testavimo valdymą, ypač siekiant aukštesnės kokybės įvesties vartų ir galutinio patvirtinimo, kuris padeda išspręsti programinės įrangos problemas ir padeda įmonei pristatyti geresnį produktą klientams.
Paaiškinti painiavą – vartotojo priėmimo testavimas vs. sistemos testavimas vs. regresijos testavimas
Programinės įrangos kūrimo srityje yra daug skirtingų testavimo formų, kurių kiekviena skirta unikaliems programinės įrangos tikslams pasiekti ir atliekama skirtingais kūrimo proceso etapais.
Sužinokite daugiau apie tai, kas yra sistemos testavimas ir regresijos testavimas, taip pat kodėl šios dvi testavimo formos skiriasi nuo UAT ir kodėl šis skirtumas yra toks svarbus.
1. Kas yra sistemos testavimas?
Sistemos testavimas – tai sistemos kaip visumos testavimas, integruojant ir pridedant visus paketo modulius ir komponentus, siekiant nustatyti, ar programa veikia taip, kaip tikisi įmonė.
Vienas iš sistemos testavimo pavyzdžių – nustatyti, ar kompiuteris veikia, kai kiekvienas atskiras komponentas kuriamas atskirai ir testuojamas nepriklausomai.
Atliekant sistemos testą tikrinama, ar sistema veikia kaip visuma, o ne bandoma kiekviena atskira sistema atskirai.
Kūrėjai sistemos testus atlieka tada, kai visi atskiri moduliai sujungiami tarpusavyje ir tai daroma kontroliuojamoje aplinkoje.
Kokie yra UAT testavimo ir sistemos testavimo skirtumai
Vienas iš pagrindinių UAT ir sistemos testavimo skirtumų yra tai, ko ieško testuotojas.
Sistemos testavimu nustatoma, ar programinė įranga veikia taip, kaip tikimasi, ar ji yra saugi ir atlieka pagrindines funkcijas, o UAT testavimas – tai išsamesnis režimas, kuriuo nustatoma, ar produktas atitinka kliento arba naudotojo reikalavimus.
Be to, sistemos testavimas yra vidinis procesas, kurį atlieka kūrimo komanda, o UAT atlieka kartu su klientais ir būsimais naudotojais, kad nustatytų funkcionalumą.
2. Kas yra regresijos testavimas?
Regresinis testavimas – tai testavimo procesas, kurio metu tikrinama, kaip naujausi kodo ar sistemų pakeitimai veikia platesnę programą, ir užtikrinama, kad atlikus šiuos pakeitimus platesnė programinė įranga veiktų taip, kaip tikitės.
Grįžtant prie kompiuterio pavyzdžio, jei kompiuteryje pakeičiate operatyviosios atminties modulius, regresijos testas būtų lygiavertis užtikrinimui, kad viskas veiktų taip, kaip anksčiau, be jokių netikėtų klaidų.
Kūrėjai naudoja regresijos testavimą iš karto po to, kai baigia keisti programinę įrangą, norėdami patikrinti, ar viskas vis dar veikia taip, kaip tikėtasi.
Kokie yra skirtumai tarp naudotojo priėmimo ir regresijos testavimo
Tarp regresijos testavimo ir naudotojo priėmimo testavimo yra reikšmingų skirtumų, iš kurių pirmasis – testavimo laikas.
UAT atliekamas tik prieš pradedant naudoti produktą, o regresinis testavimas atliekamas tada, kai testuojama programinė įranga buvo reikšmingai pakeista.
Kitas skirtumas yra tas, kas testuoja produktą: testavimo komanda atlieka regresijos testus, o UAT testus atlieka klientai ir srities ekspertai.
Vartotojo priėmimo testavimo (UAT) tipai
Atliekami įvairūs naudotojo patvirtinimo testai, kurių skirtingi tipai atlieka skirtingas funkcijas ir idealiai tinka įvairiems poreikiams. Tai:
1. Beta testavimas
Atliekant beta bandymus, programinė įranga perduodama galutinių naudotojų grupėms, kurios atlieka tam tikrus bandymus ir ištiria programinę įrangą prieš ją išleidžiant plačiau.
Tai suteikia kūrėjų komandai laiko atlikti pakeitimus iki viešo produkto pateikimo rinkai.
Šio tipo naudotojų priėmimo testavime paprastai dalyvauja žmonės, neturintys jokių ryšių su įmone.
2. Juodosios dėžės testavimas
„Juodosios dėžės” testavimas – tai toks testavimo būdas, kai UAT testuotojai neturi prieigos prie testuojamo galinio kodo, o gali matyti tik vartotojo sąsają ir programinės įrangos dalis, su kuriomis paprastai sąveikauja naudotojai.
Šis procesas pavadintas pagal skrydžio registratorių, naudojamų stebėti, kas įvyko po incidento lėktuve, pavadinimą.
3. Eksploatacinis priėmimo bandymas
Operacinio priėmimo testavimo metu dėmesys sutelkiamas tik į programinės įrangos funkcionalumą ir užtikrinama, kad ji atitiktų visas būtinas darbo eigas.
Tai reiškia, kad reikia įsitikinti, ar ji tinkamai integruota su kitomis programomis, ar patikimai veikia ir ar atitinka įmonės keliamus reikalavimus.
4. Sutarties priėmimo bandymai
Atliekant sutarties priėmimo testavimą tikrinama, ar programinė įranga atitinka sutartį, pagal kurią ji kuriama, ir užtikrinama, kad kūrėjai pasiektų bendrus projekto tikslus.
Tokiais atvejais pats klientas dažnai būna svarbi UAT testavimo proceso dalis, o atnaujinimai padeda suderinti galutinį produktą su kliento lūkesčiais.
5. Taisyklių priėmimo bandymai
Taisyklių priėmimo testavimo (RAT) tikslas – užtikrinti, kad programinė įranga veiktų pagal visas teisines taisykles ir reglamentus, susijusius su atitinkamu sektoriumi.
Tai apima tiek konkrečiam sektoriui būdingą informaciją, pavyzdžiui, bankų programinės įrangos finansų teisę, tiek bendresnius programinės įrangos įstatymus, pavyzdžiui, BDAR ir Duomenų apsaugos įstatymą.
UA testavimo procesas
UA testavimo atlikimas gali būti ilgas ir sudėtingas procesas, kurio kiekvienas žingsnis padeda gauti tikslesnius rezultatus. UA testavimo proceso etapai yra šie:
1. Nustatykite testavimo tikslus
Pačioje UAT proceso pradžioje reikia nustatyti testavimo tikslus.
Tai reiškia, kad reikia nurodyti, ko siekiate testavimo procese, ką jūsų programinė įranga idealiai atlieka naudotojui, ir užrašyti kitus pagrindinius parametrus, pavyzdžiui, laiką, per kurį sistema turėtų atlikti testus.
Testavimo tikslų naudojimas nuo pat pradžių nustato testavimo ribas ir toliau nukreipia testavimo komandą.
2. Parengti logistiką
UAT testavimas yra didelis logistinis iššūkis, kuriam reikia iš anksto pasiruošti. Logistikos užduočių vykdymas apima galutinių naudotojų, kurie atliks bandymus kaip UAT komandos dalis, samdymą, be to, reikia susitarti, kada ir kur bus atliekami bandymai.
Įmonės, kurių plėtrai reikia diskretiškumo, taip pat rengia dokumentus, pavyzdžiui, NDA, ir ruošia saugią erdvę.
3. Įdiegti testavimo aplinką į testavimo įrankį
Suprojektuokite realią bandymų aplinką naudodami pasirinktą testavimo įrankį.
Neskubėkite kurti aplinkos ir koduoti testų, nes nedidelė klaida duomenyse arba testo sintaksėje gali turėti įtakos testų veiksmingumui.
Pasikvieskite kelis komandos narius, kad užbaigę šį etapą jį patikrintų.
4. Atlikite testus
Pradėkite vykdyti naudotojo patvirtinimo testus.
Atlikdami bandymus įsitikinkite, kad turite kontroliuojamą aplinką, kurioje visi naudotojai sutelkia dėmesį į bandymų procesą, kad sumažintumėte žmogiškųjų klaidų tikimybę.
Be to, atlikite UAT automatinių testų atrankinius patikrinimus, nes taip užtikrinsite, kad jie būtų vykdomi tinkamai ir nereikalautų testavimo komandos priežiūros.
5. Įvertinti rezultatus
Gavę testavimo rezultatus, įvertinkite gautus duomenis ir informaciją.
Idealus rezultatas – išsami ataskaita, kurioje nurodomos pagrindinės programos klaidos ir galimos veiklos tobulinimo sritys, taip pat planas, kaip kūrėjų komanda reaguos į naudotojų priėmimo testavimo rezultatus.
6. Atnaujinkite programinę įrangą
Nors tai nėra griežtai testavimo proceso dalis, po UAT testavimo visada reikia atnaujinti programinę įrangą, kad būtų išspręstos problemos.
Jei tai padarysite kuo greičiau, tai reiškia, kad kuo greičiau išsiųsite kuo geresnės būklės gaminį.
Naudotojo priimtinumo testų rezultatų tipai
Skirtingos UAT testų formos duoda unikalius rezultatus ir duomenų formatus. Kai kurie iš pagrindinių rezultatų, kuriuos galite gauti atlikę UAT testavimą, yra šie:
1. Rašytinis grįžtamasis ryšys
Kūrėjai gauna raštišką grįžtamąjį ryšį iš testuotojų, kai jie atlieka naudotojo priėmimo testus. Šiuos duomenis gana sunku analizuoti, nes tai yra ne kiekybinė, o kokybinė informacija, o tai reiškia, kad atsakymuose yra daugiau niuansų.
2. Klaidų pranešimai
Kai kurie testai grąžina klaidų pranešimus, kuriuose nurodoma, kas ir kodėl testavimo procese nepavyko. Kūrėjai sukuria klaidų pranešimų struktūrą, kurioje informuojami apie problemą ir jos priežastis, o tai padeda ateityje rasti galimą pataisymą.
3. Duomenys
Kita išvesties forma yra skaitiniai duomenys, įskaitant testo metu rastų klaidų skaičių, vėlavimą tarp naudotojo įvesties ir programos atsakymų ir kitus skaičius, tiesiogiai susijusius su programos atliekamu darbu. Ši informacija suteikia galimybę atlikti analizę ir peržiūrą po bandymų.
UAT testavimo atvejų pavyzdžiai
Testavimo atvejis – tai veiksmų, kuriuos testuotojas atlieka su sistema, siekdamas užtikrinti, kad ji tinkamai veiktų, rinkinys, o atvejų skaičius gali būti labai įvairus – nuo labai sudėtingo sistemos įvertinimo iki pagrindinio funkcionalumo nustatymo.
Keletas UAT bandymų pavyzdžių:
1. Pirkimo testai
Kai įmonė turi svetainę, kurioje parduoda produktus, idealu atlikti vidutinės klientų sąveikos testą.
Pirkimo testai apima naudotojo bandymą įsigyti įmonės produktą, bandymą įsigyti kelių kiekių produktų, prieš įsitikinant, kad sistema apdoroja visą informaciją, kurią bandytojas įvedė pirkdamas.
2. Duomenų bazės testai
Kai kurios programinės įrangos dalys rūšiuoja informaciją į duomenų bazę ir ją suskirsto į lenteles. Atlikdami bandymus, UAT testuotojai įveda ilgas duomenų eilutes, idealiai atitinkančias realias situacijas, ir laukia, kol platforma apdoros informaciją duomenų bazėje.
Po to testuotojai peržiūri duomenis ir nustato, ar informacija teisingai surūšiuota, kad patikrintų rezultatus.
3. Funkcijų testavimas
Funkcijų testavimas – tai pagrindinių programos funkcijų veikimo patikrinimas, geriausia, jei tai yra su žmonių sąveika susijusios programos, pvz., žaidimai.
Tokiais atvejais UAT testuotojai užtikrina, kad visos atskiros funkcijos veiktų taip, kaip tikimasi, ir kad jos veiktų greitai, o naudotojai greitai ir išsamiai perduotų atsiliepimus apie bet kokias iškilusias problemas.
Klaidų ir klaidų, aptiktų atliekant naudotojo priimtinumo testavimą, tipai
Atliekant UAT testus susiduriama su kelių skirtingų tipų klaidomis. Kadangi UAT testus atliekate vėlesniuose kūrimo etapuose, šios klaidos paprastai būna smulkesnės nei proceso pradžioje pasitaikančios klaidos, įskaitant:
1. Vizualinės klaidos
Vizualinės klaidos atsiranda tada, kai programinė įranga atrodo kitaip, nei naudotojas tikisi (pvz., vartotojo sąsajos požiūriu ), o grafika neįkeliama arba įkeliama neteisingai.
Tai daro įtaką žmonių sąveikai su programa ir yra funkcija, kurią kūrėjai stengiasi ištaisyti prieš išleidimą, kad pagerintų naudotojų patirtį.
2. Veikimo problemos
Veikimo problemos susijusios su tuo, kad programinė įranga atlieka visas savo užduotis, tačiau tai daro neefektyviai. Šie neveiksmingumo atvejai apima tai, kad reikia daugiau išteklių, nei būtų idealu, arba paprastoms užduotims atlikti sugaištama daugiau laiko nei įprastai.
Vėliau kūrėjai jas ištaiso optimizacijos pataisomis.
3. Nesėkmingi procesai
Taip atsitinka, kai procesas visiškai nepavyksta arba jo tikslai įgyvendinami netiksliai. Šios problemos rodo esminį kodo trūkumą ir tai, kad kūrėjai turi reaguoti, kad programinė įranga vėl tinkamai veiktų.
Bendrieji UAT rodikliai
Kai įmonė gauna išmatuojamus duomenis, gautus atlikus UAT bandymus, šie duomenys būna įvairūs. Nepamirškite, kad patys rodikliai nepasako visos istorijos, ir atidžiai diskutuodami supraskite, ką ir kodėl naudotojai mano apie produktą.
Kai kurie iš dažniausių įmonių naudojamų UAT rodiklių yra šie:
1. Iš viso PASS/FAIL
Bendras teigiamų arba neigiamų rezultatų, kuriuos pasieksite automatinio testo metu, skaičius. Pagal šį rodiklį matuojamas pasitaikančių klaidų skaičius, o stebint šį rodiklį galima sužinoti, ar tolesni atnaujinimai sumažino bendrą klaidų skaičių.
2. Testų vykdymo aprėptis
Procentinė reikšmė, kuri parodo, kokia dalis kodo buvo patikrinta pagal jūsų UAT testavimo režimą.
Didesni procentai rodo, kad testai yra išsamesni, o 100 % aprėptis užtikrina, kad visas kodas yra funkcionalus.
3. Klientų pasitenkinimas
Kadangi UAT yra etapas, kuriame klientai sąveikauja su produktu, labai svarbu suprasti jų jausmus. Paklauskite bandytojų, kaip jie patenkinti, pagal skalę nuo vieno iki dešimties, gaukite vidurkį, tada pakartokite bandymus su tais pačiais žmonėmis po atnaujinimų, siekdami didesnio pasitenkinimo.
Ko reikia norint pradėti vykdyti UA testavimą
Prieš pradėdami vykdyti UA testavimą su savo programine įranga, turite įvykdyti keletą išankstinių sąlygų, įskaitant:
1. Visiškai sukurtas programos kodas
Norint atlikti UAT testavimą, reikia visiškai sukurtos programos. Taip yra todėl, kad kūrėjai programas kuria moduliniu principu, užbaigia vieną modulį ir tik tada pereina prie kito, tęsdami kūrimo procesą.
Vartotojų priėmimo testai – tai pirmas kartas, kai naudotojai mato baigtą programinės įrangos versiją, todėl iš anksto parengtas visas kodas reiškia, kad jie gali išbandyti kiekvieną atskirą funkciją, nenutraukdami testavimo ir neklausdami, kurios proceso dalys yra nepasiekiamos.
Be to, kad funkcionalumas būtų užbaigtas, kūrėjai turėtų būti užbaigę daugumos sistemų atnaujinimus per visą sistemų testavimo procesą, taip užtikrindami, kad visi moduliai veiktų izoliuotai.
2. Atlikti išankstinius bandymus
Testavimas nėra tik tai, ką kūrimo komanda atlieka proceso pabaigoje, o daugelyje įmonių jis yra nuolatinis ir nuolatinis darbas. Tai reiškia, kad atliekami standartiniai kokybės užtikrinimo testai, pavyzdžiui, žvalgomasis testavimas, galinis testavimas, „dūmų” testavimas, tinkamumo testavimas, apkrovos testavimas, našumo testavimas, funkcijų testavimas, standartinis integravimo testavimas ir t. t., kuriais užtikrinama, kad atskiri moduliai veiktų tinkamai.
Kai kurios įmonės, prieš pradėdamos UAT testavimą, atlieka išsamesnius galutinius testus, kurie apima visą programą, nes taip suteikiama daugiau pasitikėjimo programine įranga prieš ją perduodant naudotojo priėmimo testavimo komandai.
3. Prieinami verslo reikalavimai
testavimo komandai pateikti išsamius verslo reikalavimus UAT testavimo proceso pradžioje.
Testuotojų paskirtis – užtikrinti, kad programa veiktų taip, kaip kūrėjai yra numatę, o kūrėjai perduoda programinės įrangos tikslus, pateikdami testavimo komandai verslo reikalavimus.
Tai paprastas punktų sąrašas, kuriame nurodoma, kokia yra programa ir kokios yra jos funkcijos, o UAT testavimo komanda, peržiūrėdama šį sąrašą po vieną punktą, užtikrina, kad programinė įranga atitiktų visus verslui keliamus reikalavimus produktui.
4. Nuoseklus vartotojo sąsajos dizainas
UAT testavimas – tai pirmoji galimybė įmonei pristatyti savo produktus žmonėms, nepriklausantiems organizacijai, testavimo tikslais.
Daugeliu atvejų tai reiškia, kad naudotojas nežino, ko tikėtis iš programinės įrangos, ir ne iki galo supranta, kaip naudotis platforma, ypač todėl, kad neturi jokio supratimo apie kūrimo procesą.
Sukūrus nuoseklią naudotojo sąsają (UI), naudotojai gali sąveikauti su programine įranga taip, kaip numatyta, be jokios painiavos, o tai naudinga ir galutiniam naudotojui po produkto išleidimo.
5. Kruopštūs pranešimai apie klaidas ir jų stebėjimas
Įdiekite išsamius pranešimus apie klaidas ir klaidų stebėjimą, kad testuotojas gautų informaciją, jei kas nors nepavyktų. Gauti atsakymą, kuriame paprasčiausiai nurodoma „Procesas nepavyko”, nėra naudinga nei bandytojui, nei kūrėjui, nes paliekama daug erdvės interpretuoti, kas ir kodėl nepavyko.
Šiai problemai išspręsti naudokite lengvai suprantamus klaidų kodus, nes bandytojai ir kūrėjai gali perskaityti klaidos kodą ir tiksliai nustatyti, kas nepavyko. Klaidų kodai pagreitina atnaujinimo procesą ir padeda kūrėjų komandai nustatyti konkrečias tobulintinas programinės įrangos sritis.
6. Visapusiška UAT aplinka
Atlikdami UAT testus, norite būti tikri, kad testai atspindi realius naudojimo atvejus. Tam įmonės sukuria kuo tikroviškesnę UAT bandymų aplinką, tiksliai atspindinčią aplinką, kurioje klientas naudotų programinę įrangą.
Kurdami aplinką, kai tik įmanoma, naudokite tiesioginius duomenis, kad geriau imituotumėte, kaip programinė įranga reaguoja į vykstančius įvykius. Jei tai neįmanoma, pabandykite naudoti panašaus laikotarpio užfiksuotus duomenis arba sukurti tikrovišką realių duomenų imitaciją.
Geriausia UAT testavimo praktika
Geriausia praktika – tai tam tikros užduotys ir elgsena, kurią žmonės naudingai taiko atlikdami užduotį ir kuri galiausiai padeda pasiekti tikslesnių rezultatų.
Keletas geriausios UAT testavimo praktikos pavyzdžių:
1. Pažinkite tikslinę auditoriją
Supraskite, kokia yra įmonės tikslinė auditorija ir ko ji tikisi iš produkto. Nustatydami tikslinę auditoriją, atrenkate tinkamus naudotojus, su kuriais atliekami bandymai, ir nustatote jiems labiausiai rūpimus klausimus, taip sukurdami produktą, kuriuo jie noriai naudojasi, nes jis pritaikytas jų poreikiams.
2. Dėmesys testavimo atvejų detalumui
Realių atvejų tyrimai yra labai sudėtingi, nes juose yra daug skirtingų duomenų iš unikalių šaltinių, gaunamų nereguliariu laiku. Tikslūs testai turi kuo tiksliau tai atkartoti, todėl daug laiko skirkite UAT testavimo atvejui detalizuoti ir kuo tiksliau atspindėti realią situaciją.
3. Būkite nuoseklūs
Visiems moksliniams tyrimams naudingas nuoseklumas, kai bandymai kartojami vis tomis pačiomis sąlygomis, kad rezultatai būtų patikimi.
Atlikdami UAT bandymus, nekeiskite bandymų aplinkos, kurią testuojate tarp bandymų, ir nekeiskite naudojamų įrankių, nes tai gali turėti įtakos gautiems rezultatams.
4. Standartizuoti bendravimą
Sukurkite standartinį kūrimo ir testavimo komandų bendravimo metodą. Tai gerokai sumažina trintį tarp grupių ir reiškia, kad kūrėjai gali greičiau pradėti taisyti klaidas ir geriau suprasti, kokia yra problema.
Rankiniai UAT testai ir automatizuoti naudotojo patvirtinimo testai
Yra dvi galimybės, kaip kūrėjui atlikti UAT testus, nes tiek rankiniai, tiek automatiniai UAT testai turi savų privalumų testuotojams ir kūrėjams, siekiantiems sukurti visų suinteresuotųjų šalių lūkesčius atitinkantį programinės įrangos paketą.
Skaitykite toliau ir sužinokite, kas yra rankinis ir automatinis UAT, kokie jų privalumai ir iššūkiai bei kada juos naudoti.
Rankinis UAT testavimas
Rankinis UAT testavimas – tai procesas, kai UAT testas atliekamas visiškai rankiniu būdu, nenaudojant trečiųjų šalių įrankių ar automatizavimo.
Daugiausia dėmesio skiriant rankiniam testavimui, reikia, kad žmonės patys atliktų testus, naršytų po programinę įrangą ir ieškotų klaidų ar problemų, o po to patys jas užfiksuotų ir praneštų testų administratoriams.
Tai pasakytina apie rankinio UAT testavimo procesus, pvz., atviros beta versijos testavimą, kai vartotojai užpildo formą ir atsako kūrėjams į bet kokias rastas problemas.
1. Vartotojo patvirtinimo testų atlikimo rankiniu būdu privalumai
Priklausomai nuo programinės įrangos pobūdžio ir įmonės, kurioje dirbate, struktūros, rankiniu būdu atliekami UAT testai turi daug privalumų. Pagrindiniai UAT testų atlikimo rankiniu būdu, o ne naudojant automatizavimo įrankius privalumai:
Atlikti sudėtingesnius bandymus
Pirmasis rankinio testavimo privalumas – galimybė atlikti sudėtingesnius testus nei naudojant automatizuotą testavimo įrankį.
Automatizavimas apima testų scenarijų programinėje įrangoje, o tai gali reikšti, kad sudėtingesni testai užtrunka ilgiau, nes komanda rašo ilgas kodo eilutes, kad išnagrinėtų išsamias problemas.
Rankiniu būdu atliekamiems testams nereikia tokių sudėtingų kodavimo reikalavimų, nes testuotojas eina į programinę įrangą ir, gavęs nurodymus, ką daryti, atlieka testą, todėl testavimo komandos vaidmuo labai supaprastėja.
Integruoti vartotojo sąsajos ir tinkamumo naudoti bandymus
Kai siunčiate visą programinę įrangą, reikia atsižvelgti ne tik į funkcionalumą, bet ir į daugelį kitų dalykų.
Naudojant automatinį testavimą galima gauti išskirtinę informaciją apie programinės įrangos funkcionalumą, o rankinio testavimo specialistai gali reaguoti į dalykus, kuriuos pastebi vartotojai. Tai apima kūrėjų informavimą apie galimas programinės įrangos vartotojo sąsajos problemas, rekomendacijas keisti svetainėje naudojamą šriftą ir suprasti darbo eigos, kurios turi laikytis naudotojai, problemas.
Tokie rankinių naudotojų atsiliepimai padeda padaryti svetainę patogesnę naudotojui, o ne tik suteikti galimybę naudotis funkcijomis.
Nustatyti konkretesnes problemas
Automatizuotas testavimas skirtas labai konkrečiam scenarijui vykdyti ir nustatyti, ar programinė įranga veikia, ar ne, tačiau tai reiškia, kad jame nėra vietos detalėms.
Rankiniu būdu dirbantys naudotojų priėmimo testuotojai gali tiksliau nustatyti programos problemas ir trūkumus, o tai prieštarauja automatizuotos sistemos binarinei PASS/FAIL sistemai.
Tokia išsami grįžtamoji informacija reiškia, kad kūrėjai žino tikslią problemos vietą ir gali ją išspręsti daug greičiau nei kitu atveju, taip padidindami įmonės operatyvumą ir greičiau užtikrindami klientams geresnius rezultatus.
Pateikite atsakymus su daugiau niuansų
Naudodami rankinį UAT testavimo procesą gausite atsakymus su daugiau niuansų nei naudodami automatinį testavimą.
Pirmiausia reikia išnagrinėti programinės įrangos prekės ženklą ir galimą patobulintą integraciją su išorine programine įranga, nes į tai automatinis testas nėra skirtas atsižvelgti.
Be to, žmogus testuotojas gali rengti ad hoc ataskaitas apie tai, kaip jaučiasi darbo eiga, ir teikti konkrečius patarimus ir rekomendacijas, o ne QA komanda, žiūrinti į automatinio UAT testo metu gautus duomenis ir remiantis šia informacija daranti prielaidas.
Lankstesnis darbas testavimo srityje
Lankstumas yra esminė testavimo dalis, kurią puikiai atitinka rankinis testuotojas. Kuriant testus visada atsiras dalykų, į kuriuos programuotojas ar kokybės užtikrinimo komanda neatsižvelgs, pavyzdžiui, programinė įranga bus naudojama tam tikru būdu arba funkcija turės keletą nenumatytų funkcijų.
Rankiniu būdu su programine įranga netikėtai sąveikaujantis UAT testuotojas aptinka klaidų ir problemų, apie kurias kūrėjai galėjo nepagalvoti, ir padeda jiems ištaisyti tas programinės įrangos sritis, apie kurias jie galbūt net nepagalvojo.
Tai ypač svarbu, nes daugiau naudotojų susiduria su naujoviškais funkcijų naudojimo būdais, todėl beveik neabejotina, kad jie bus rasti ir po viešo paleidimo.
2. Rankinio UAT iššūkiai
Nagrinėjant rankinio UAT klausimą, reikia spręsti keletą problemų. Išspręsti šiuos iššūkius ir aktyviai stengtis juos sušvelninti privalo kiekvienas, norintis pradėti rankinį testavimą ir nesusidurti su didelėmis kliūtimis viso proceso metu.
Kai kurie iš pagrindinių iššūkių, susijusių su rankiniu UAT diegimu į testavimo procesus, yra šie:
Didesnės finansinės išlaidos
Vienas iš rankinio testavimo, o ne automatizuoto UAT testavimo darbų trūkumų yra tas, kad rankinio testavimo atlikimas kainuoja daug brangiau. Kiekvienam rankiniam testui atlikti reikia apmokamo darbuotojo, o patikimiausi testai yra tie, kuriuos atliekate kartas nuo karto, kad gautumėte nuoseklesnius rezultatus.
Tai daug pinigų, kuriuos turite investuoti į kokybės užtikrinimo procesus.
Sąnaudos dar labiau padidėja, jei atsižvelgsime į tai, kad tikslesnius testavimo rezultatus gauna aukštesnės kvalifikacijos darbuotojai, o šių darbuotojų įdarbinimas kainuoja dar daugiau. Daugeliui įmonių rankinis naudotojų priėmimo testavimas nėra pats prieinamiausias būdas.
Aukšti techninių įgūdžių reikalavimai
Rankinis UAT testavimas – tai sritis, kurioje reikia daug sąveikos su programine įranga ir konkrečiomis paslaugomis, taip pat reikia turėti reikiamų žinių, įskaitant supratimą, iš kur gali kilti problemų, ir rekomendacijų dėl galimų atsakymų į jas.
Tokiais atvejais jums naudinga turėti rankinius testuotojus, turinčius aukštą kokybės užtikrinimo užduočių atlikimo kompetenciją, pvz., „srities ekspertą”. Jei naudotojo priėmimo testavimo procesuose trūksta srities eksperto, rizikuojate, kad rezultatai bus netikslūs, o testuotojai, aprašydami problemas, gali naudoti netinkamą kalbą, todėl kūrimo komanda, norėdama pataisyti programinę įrangą ir išspręsti bet kokias problemas, pasuks netinkamu keliu.
Žmogiškųjų klaidų tikimybė
Kompiuteriai ir mašinos yra sukurti taip, kad galėtų atlikti tą pačią užduotį be nukrypimų, o žmonėms taip nėra. Žmonės yra neklystantys ir kartais gali padaryti klaidų, nepriklausomai nuo to, kokio lygio darbuotojai dirba jūsų organizacijoje.
Atliekant rankinius testus, lieka vietos žmogiškoms klaidoms, dėl kurių gali būti pateikti netikslūs rezultatai arba kai kurie testai testavimo proceso pabaigoje gali būti neužbaigti. Dėl šios priežasties rankiniu būdu atliekami UAT testai paprastai kartojami kartas nuo karto, o daugiau atvejų, kuriuos atlieka keli testuotojai, užtikrina, kad vienas netikslaus testavimo atvejis neturėtų neigiamos įtakos bendram kūrimo proceso rezultatui po testavimo.
Sunku išbandyti pasikartojančias užduotis
Vienas iš pagrindinių UAT testavimo automatizavimo privalumų yra tas, kad kūrėjas gali kaskart atlikti tą patį testą su tais pačiais duomenimis ir tais pačiais veiksmais. Nėra jokios tikimybės praleisti žingsnį ar nebaigti tam tikros proceso dalies.
Tai negalioja rankinio testavimo specialistams. Atlikdamas kai kurias labai pasikartojančias užduotis, rankiniu būdu dirbantis UAT testuotojas kartais gali praleisti vieną iš testo etapų arba netiksliai užrašyti informaciją. Užduotys, kurias reikia kartoti, gali būti sudėtingos testuotojams, kurie programinę įrangą tikrina rankiniu būdu, ypač jei užduotys kartojamos kelias valandas ir šimtus ciklų.
Dideli išteklių poreikiai
Vartotojo priėmimo testavimas rankiniu būdu yra daug įmonės išteklių reikalaujantis metodas.
Tai susiję ne tik su finansinėmis išlaidomis, bet ir su didesnėmis programinės įrangos dalimis, kurios gali kelti didesnį krūvį darbuotojams, nes jie nagrinėja duomenis, kuriuos organizacija gauna iš UAT testų, be to, atlieka rankinius testus su savo naudotojų baze.
Toks didelis išteklių poreikis reiškia, kad kiti įmonės skyriai gali būti įtempti, nes testavimo procesas reikalauja daugiau dėmesio nei dauguma kitų kūrimo projektų.
3. Kada naudoti rankinį vartotojo patvirtinimo programinės įrangos testavimą
Derinant rankinio UAT testavimo privalumus ir iššūkius, yra keletas konkrečių atvejų, kai rankiniai testai yra ideali išeitis.
Pirmasis iš jų – kai testuojamos palyginti nedidelės priemonės ir programos, nes tokiais atvejais testai užima daug mažiau laiko nei didelės daugialypės programos, kuri palaiko viską, ką daro įmonė, tikrinimas.
Didelės įmonės taip pat gali gauti daug naudos iš rankinio UAT diegimo, nes jos turi lėšų ir išteklių, kad galėtų palaikyti kuo išsamesnį testavimo procesą.
Tačiau rankinio UAT procesai nebūtinai turi veikti visiškai nepriklausomai, nes kai kurios įmonės gauna naudos derindamos automatizuotą testavimą su naudotojo atliekamais bandymais. Naudodamos automatizavimą kaip priemonę išbandyti daugumą programėlės sistemų ir funkcijų, įmonės gali atlikti rankinį testavimą, kad užtikrintų, jog programėle būtų patogu naudotis ir ji būtų patogi vartotojui.
Šis hibridinis naudotojų priėmimo testavimo metodas sujungia teigiamas rankinio testavimo savybes su sistemomis, kurios padeda išvengti pagrindinių sunkumų, su kuriais susiduriama taikant rankinio testavimo strategiją, todėl gaunami tikslesni testavimo rezultatai ir geresnis įmonės kūrimo procesas.
UAT testavimo automatizavimas
UAT testavimo automatizavimas – tai procesas, kurio metu naudojant išorinę priemonę UAT testai atliekami automatiškai. Tai reiškia, kad kuriami scenarijaus testai, kurie atliekami automatiškai, nesikišant naudotojui ar kokybės užtikrinimo komandos nariui.
Proceso pabaigoje kokybės užtikrinimo komanda gauna rezultatus, kuriais nustatoma, ar programinė įranga veikia pagal numatytus standartus.
Priklausomai nuo naudotojo priėmimo testavimo proceso sudėtingumo, kai kurie automatiniai testai pateikia paprastus dvejetainius rezultatus, t. y. ar sistema atitinka numatytus standartus, o kiti pateikia sudėtingesnius duomenis apie tai, kaip programa veikė.
1. UAT testavimo automatizavimo privalumai
Naudojant UAT bandymų automatizavimą galima gauti daugybę privalumų, kurių nėra, kai kaip alternatyva naudojamas rankinis testavimas.
Pagrindiniai UAT testavimo automatizavimo privalumai jūsų organizacijoje yra šie:
Mažesnės sąnaudos
Viena iš pagrindinių priežasčių, kodėl įmonės naudoja bandymų automatizavimą, yra ta, kad taip išlaikomos kuo mažesnės bandymų vykdymo sąnaudos.
Rankiniam testavimui atlikti reikia žmonių, kurie atliktų kelis testus, o už darbą jiems reikia mokėti. Tai ypač aktualu, kai tai yra didelė programinė įranga su daugybe funkcijų, kurias reikia išbandyti.
Naudodami UAT automatizuotą testavimą, turite sumokėti tik už programinės įrangos licenciją ir tada jūsų išlaidos bus baigtos, todėl sumažės išlaidos darbo jėgai ir sutaupysite įmonės išteklių, kuriuos galėtumėte skirti kūrimo procesui.
Padidinti pakartojamumą
Kompiuterių programos ir sistemos sukurtos taip, kad kartas nuo karto atliktų tą pačią užduotį ir būtų siekiama nuoseklių rezultatų ir procesų.
Dėl to automatizuota sistema puikiai tinka kartojamiems bandymams atlikti, nes automatizavimas pašalina žmogiškųjų klaidų tikimybę, kuri egzistuoja atliekant rankinį testavimą programinės įrangos kūrimo procesuose.
Didesnis pakartojamumo lygis reiškia, kad galite būti tikri, jog jūsų naudotojo priėmimo testo rezultatai bus kuo tikslesni, ir galite atlikti lygiai tokius pačius programinės įrangos testus po to, kai atliksite keletą pataisymų, kad jūsų testų rezultatai būtų kuo reprezentatyvesni.
Greičiau užbaigti bandymus
Žmonės gali ilgai užtrukti atlikdami užduotis dėl kelių priežasčių. Rankinis testavimas užtrunka, nesvarbu, ar jie išsiblaško, ar jiems tiesiog reikia laiko apdoroti ekrane esančią informaciją prieš atliekant kitą veiksmą.
Įdiegus automatizavimą UAT testuose, sistema greičiau atlieka atskiras užduotis ir greičiau pateikia rezultatą nei rankinio testavimo alternatyva.
Dėl ankstesnio rezultato kokybės užtikrinimo komanda turi laiko įvertinti problemas, o kūrėjai laiku pateikia atnaujinimus, kuriais išsprendžiamos visos programos problemos.
Paprasti atsakymai
Priklausomai nuo įmonės naudojamo rankinio testavimo tipo, gaunami atsakymai gali būti įvairūs – nuo labai naudingų iki keliančių sumaištį QA komandoje.
Pavyzdžiui, jei beta testavimą atlieka ne srities ekspertai, o standartinių naudotojų komanda, tai reiškia, kad gauta grįžtamoji informacija gali nukreipti kūrėjus netinkama linkme arba suteikti ribotą įžvalgą. Automatiniai testai pateikia gana paprastus atsakymus, pavyzdžiui, dvejetainį PASS/FAIL, kai sistema paleidžiama.
Tai suteikia komandai daugiau aiškumo ir leidžia imtis veiksmų negaištant brangaus laiko atsakymams interpretuoti.
Kūrėjų pasitikėjimo kūrimas
Nors tai yra neapčiuopiama programinės įrangos kūrimo proceso dalis, kūrėjų pasitikėjimas ir pasitikėjimas yra labai svarbūs siekiant geresnių gamybos rezultatų UAT proceso pabaigoje.
Komanda, kuri pasitiki savo darbo kokybe, gali imtis sudėtingesnių funkcijų ir pridėti funkcionalumo, kuris sužavės klientą, o tai galiausiai lemia, kad įmonė ateityje iš kliento gaus daugiau darbo.
Automatiniai naudotojų priėmimo testai suteikia greitą grįžtamąjį ryšį, kuris parodo, ar programa iki šiol sėkmingai veikė, ir suteikia komandai daugiau pasitikėjimo judant pirmyn kūrimo ciklo pabaigoje.
2. Vartotojų priėmimo testų automatizavimo iššūkiai
Nepaisant visų automatizuoto testavimo proceso privalumų, automatizuojant UAT testavimą reikia atsižvelgti į keletą svarbių iššūkių. Išsprendę šias problemas ir jas apeidami, gausite nuoseklesnius rezultatus, o testavimas taps daug veiksmingesnis.
Kai kurie iš pagrindinių iššūkių, į kuriuos reikia atsižvelgti ir kuriuos reikia išspręsti automatizuojant UAT bandymus, yra šie:
Santykinai nelankstus
Kai kurios iš pagrindinių su automatizuotu testavimu susijusių problemų yra tai, kad testai gali būti šiek tiek nelankstūs.
Kai testą už jus atlieka kitas asmuo, jis gali pritaikyti ir reaguoti į programą, taip pat pateikti papildomų atsiliepimų, papildančių pradinę trumpą informaciją, pavyzdžiui, aptarti, kaip atrodo vartotojo sąsaja ir kaip su ja sąveikaujama.
Priešingai, UAT testavimo automatizavimas negali suteikti tokios įžvalgos, o pateikia paprastą atsakymą į užklausą, kuri yra užkoduota.
Nors testuotojai gali koduoti savo sistemas, kad jos atsakytų į kelis skirtingus klausimus, nėra tokio lankstumo ir įžvalgumo, kokį gali suteikti žmogus testuotojas.
Priklauso nuo tikslios aplinkos
Kai naudojate automatinio testavimo įrankį, esate šiek tiek priklausomi nuo aplinkos, kurioje testuojate programinę įrangą. Tai susiję su duomenimis, kuriuos įrašote į programinę įrangą, ir su tuo, ar jie tiksliai atspindi realų pasaulį, taip pat su supratimu, ar UAT bandymai, kuriuos prašote atlikti programinės įrangos, tiksliai atspindi realų naudojimą.
Jei testavimo aplinka nėra tiksli, jūsų naudotojo priėmimo testai praranda savo vertę, nes klientai nėra tikri, kad programinė įranga veiks pagal jų konkrečius reikalavimus.
Skirkite laiko aplinkos kūrimui, nes taip padidinsite produkto testavimo svarbą.
Gali būti didelės pradinės išlaidos
Kai pirmą kartą pradedate testavimo procesą, gali tekti investuoti į programinės įrangos testavimo platformą, kuri padėtų jums automatizavimo procese. Priklausomai nuo pasirinktos platformos ir konkrečios platformos, kurią naudojate, tai gali būti nemažos išlaidos.
Tačiau, nepaisant to, kad šis iššūkis sukelia trumpalaikių problemų, jei ir toliau testuosite naudodami automatizavimą, ilgainiui pradinės investicijos kaina sumažės. Įmonėms naudingiau ilgesnį laiką naudoti UAT testavimo automatizavimą daugumoje projektų, nes laikui bėgant gerokai sumažėja vieno naudojimo kaina.
Reikalingi kodavimo įgūdžiai
Priklausomai nuo platformos, kurią naudojate UAT bandymų automatizavimui, kai kurioms sistemoms reikia nemažai programavimo įgūdžių. Šie įgūdžiai priklauso nuo konkrečių testo reikalavimų ir pačios platformos, tačiau sudėtingesniems testams atlikti reikalingi pažangesni įgūdžiai.
Be to, pagal gerąją praktiką kūrimo komanda ir kokybės užtikrinimo komanda turi būti atskirtos viena nuo kitos, todėl į kokybės užtikrinimo pozicijas reikia samdyti žmones, turinčius daug kodavimo ir programinės įrangos automatizavimo platformų naudojimo patirties.
Kodavimo įgūdžių reikalavimai iš pradžių gali būti iššūkis, tačiau jį galima lengvai išspręsti, kai įmonėje dirba patyrę darbuotojai.
Nuolatinė priežiūra
Laikui bėgant automatizuotus UAT testavimo įrankius ir scenarijus reikia prižiūrėti. Taip gali nutikti dėl kelių priežasčių, įskaitant platformos atnaujinimus ir papildomas funkcijas, testavimo scenarijų nebetinkamumą programinei įrangai vystytis ir testavimo platformos bei programos nesuderinamumą.
Atliekant testavimo sistemos techninę priežiūrą padidėja laiko ir dėmesio, kurį turite skirti automatizuotam testavimo procesui, o tai gali panaikinti dalį naudos, kurią gavote pasirinkę UAT automatizavimą, o ne rankinį testavimą.
Palaikydami testavimo programinę įrangą darbo eigoje, sumažinate riziką, kad teks sugaišti daug laiko per trumpą laiką sprendžiant problemas.
3. Kada diegti UAT testavimo automatizavimą
Subalansavus teigiamas ir neigiamas UAT testavimo automatizavimo savybes, UAT testavimo automatizavimą geriausia diegti, kai dirbama su didesniais programinės įrangos paketais, turinčiais daug testuotinų aspektų. Tai galite padaryti greičiau ir gauti aiškų bei suprantamą rezultatą, ar testas buvo sėkmingas.
Tas pats pasakytina ir apie tuos atvejus, kai operacija turi palyginti nedidelį biudžetą ir negali sau leisti tokio masto rankinio testavimo, kokio reikia norint gauti nuoseklius rezultatus. Naudojant hibridinę sistemą kartu su rankiniu testavimu taip pat verta naudoti naudotojo priėmimo testų automatizavimą, kad būtų sumažintas kiekvienos atskiros sistemos trūkumų poveikis kūrėjų komandai.
Išvados: UAT testavimo automatizavimas ir rankinis naudotojo priėmimo testavimas
Galiausiai abu UAT testų atlikimo būdai turi savų privalumų.
Automatinis testavimas yra perspektyvesnis būdas atlikti didelės apimties bandymus ir įsitikinti, kad produktas apskritai yra paruoštas paleidimui, o rankiniu būdu galima gauti tikslingesnę ir tikslingesnę grįžtamąją informaciją, kurią galima panaudoti norint gerokai patobulinti programą prieš paleidimą.
Idealiu atveju stenkitės sujungti abi metodikas į vieną vientisą sistemą, pasinaudodami ir automatinės sistemos sparta, ir didesniais niuansais, kuriuos galima rasti atliekant rankinį testavimą. Dėl testavimo procesų, kuriuose maksimaliai išnaudojamos visos jums prieinamos galimybės, pagerėja jūsų programų standartas, o klientai ir naudotojai tampa laimingesni.
Geriausi UAT testavimo įrankiai
Kai įmonė nusprendžia automatizuoti savo testavimo sistemas, ji remiasi testavimo priemone, kuri palengvina šį darbą. Rinkoje yra daugybė galimybių naudotojams, kurie gali naudotis tiek nemokamomis parinktimis, tiek ir pramonės lygio kainomis, nes kiekvienas produktas siūlo daugybę funkcijų.
Pasirinkus tinkamą gaminį, galima veiksmingai atlikti bandymus ir sunkiai pasiekti nuoseklių rezultatų.
Dabar aptarsime keletą geriausių nemokamų ir įmonėms skirtų UAT testavimo įrankių ir kiekvienos platformos galimybes.
5 geriausi nemokami naudotojų priimtinumo testavimo įrankiai
Kai dirbate kaip nepriklausomas kūrėjas arba mažoje įmonėje, atlikdami bet kokias viešųjų pirkimų funkcijas turite atsižvelgti į savo įmonės biudžetą. Kai kurios iš jų užtikrina ir testavimo, ir bendrąsias hiperautomatizavimo funkcijas, o kitos yra tiesiog naudingi proceso priedai.
Toliau rasite keletą geriausių nemokamų UAT įrankių ir kai kurias jų funkcijas:
1. ZAPTEST FREE Edition
„ZAPTEST” vartotojams siūlo nemokamą automatizavimo programinės įrangos versiją, kuria galima automatizuoti bet kokią užduotį ir kuri veiksmingai veikia įvairiose skirtingose platformose.
Čia trūksta kai kurių įmonės lygio funkcijų, pavyzdžiui, ZAP sertifikuoto eksperto, dirbančio visą darbo dieną kartu su kliento komanda, arba neribotų licencijų funkcijos, tačiau tai yra viena geriausių nemokamų parinkčių bet kuriai organizacijai, norinčiai automatizuoti UAT testavimą turint tam tikrą biudžetą.
2. QADeputy
Integruojama su klaidų stebėjimo įrankiais, kad būtų galima rasti programinės įrangos klaidas ir jas kataloguoti, nustatant, ar vėlesnėse iteracijose pavyko jas išspręsti.
3. Qase
Tvarko bandymų atvejus, kuriuos organizacijos naudoja UAT procesuose, stebėdamos atliktus ir dar neatliktus bandymus, naudodamos paprastą saugyklą.
4. Obkio
Idealiai tinka problemoms registruoti ir klasifikuoti pagal jų rimtumą, tačiau neautomatizuoja paties UAT testavimo proceso.
5. RedLine13
Gera priemonė apkrovos testams, kurie kartais atliekami kaip platesnių programų, pavyzdžiui, internetinių paslaugų ar žaidimų, UAT testavimo dalis, valdyti. Tai nėra lankstus įrankis ir sunkiai pritaikomas kitose srityse, ne tik apkrovos testavimo srityje.
5 geriausi įmonės naudotojo patvirtinimo testavimo automatizavimo įrankiai
Jei jūsų produktui skirtas didelis kūrimo biudžetas ir jis išleidžiamas klientams su dideliais lūkesčiais, norite būti tikri, kad jūsų bandymai bus kuo išsamesni ir duos kuo patikimesnius rezultatus.
Šiuo atveju būtina naudoti įmonės UAT įrankį, kuris suteikia daugiau funkcijų ir palaikymą, atitinkantį jūsų klientų lūkesčius.
Toliau rasite keletą geresnių įmonių UAT testavimo įrankių:
1. ZAPTEST Enterprise Edition
„ZAPTEST Enterprise Edition” versijoje panaudotos originalios versijos privalumai, todėl organizacijoms suteikiama neribotas licencijų skaičius, prieiga prie nuotolinių ZAP sertifikuotų ekspertų visą darbo dieną ir papildoma aukščiausios klasės RPA funkcijų nauda.
Naudotojai dažnai gauna iki dešimties kartų didesnę investicijų grąžą naudodamiesi ZAPTEST. Tai išsamus ir galingas automatizavimo rinkinys, skirtas bet kuriai įmonei, ieškančiai programinės įrangos testavimo ir RPA automatizavimo.
2. Marker.io
Siūloma atkūrimo priemonė, kuri padeda rasti ir atkurti klaidas, tačiau jos galimybės automatizuoti yra gana ribotos. Gerai tinka rankiniam testavimui, sunkiai pereina prie automatinio vertinimo.
3. Amplitudė
padeda naudotojams stebėti įvykius naudojant jų programinę įrangą, ypač naudojant didelius naudotojų duomenų rinkinius. Tačiau platformoje būta tam tikrų problemų, nes kai kuriems naudotojams sunku atlikti gana paprastas užduotis, pvz., el. pašto patikrą.
4. Watir
„Watir” yra lengvas įrankis, skirtas specialiai naršyklės testavimui, ir palaiko kai kuriuos pagrindinius automatizavimo veiksmus. „Watir” neveikia su įvairia atskira programine įranga, todėl jos testavimo galimybės yra ribotos.
5. ContentSquare
Stebi, kaip naudotojas naudojasi svetaine ar priemone, įskaitant gaunamas klaidas. Tai kruopštus įrankis, tačiau jis naudingesnis po išleidimo, kai norima sužinoti, ką naudotojai daro natūraliai, o ne specialiai pritaikytoje bandymų aplinkoje.
Kada turėtumėte naudoti įmonių, o kada – nemokamus UAT testavimo įrankius?
Tiek nemokamos, tiek įmonių UAT testavimo priemonės turi savo vietą programinės įrangos kūrimo erdvėje, tačiau jos puikiai tinka skirtingais atvejais.
„Enterprise Edition” yra galingesnis variantas įmonei, siekiančiai saugumo ir užtikrintumo žinant, kad jos viso kamino testavimas atitinka standartus, tačiau tai ne visada yra organizacijos biudžeto ribose.
Jei valdote pradedančiąją įmonę su ribotu biudžetu, apsvarstykite galimybę pradėti nuo nemokamos versijos, o laikui bėgant programą atnaujinti, kai jos populiarumas ir pajamos didės.
UAT testavimo kontrolinis sąrašas, patarimai ir gudrybės
Yra keletas patarimų ir gudrybių, kurių reikia laikytis kuriant savo UAT testus ir sudarant planą, kurio reikia laikytis. Keletas svarbiausių patarimų, kuriais galite pasinaudoti atlikdami testavimo procesus:
1. Dėmesys aiškumui
Jei įmanoma, užtikrinkite, kad visų atliekamų tyrimų rezultatai būtų kuo paprastesni ir glausti.
Tai sumažina laiko, kurį žmonės turi praleisti dekoduodami rezultatus, ir padeda jūsų komandai greičiau pradėti produktyviau dirbti, greičiau išspręsti problemas ir klientams pateikti aukšto lygio galutinį programinės įrangos paketą.
2. Leiskite testuotojams būti nepriklausomiems
Pateikite UAT testuotojams apytiksles gaires, ką reikia išbandyti ir ko jie ieško, tačiau suteikite jiems galimybę testuoti ne tik tai.
Tai padeda jums pasinaudoti rankinių testuotojų kūrybiškumu, kurie naudoja unikalius metodus, kad patikrintų jūsų programinės įrangos ribas ir išnagrinėtų funkcijas tokiais būdais, į kuriuos jūsų komanda kitu atveju neatsižvelgtų.
3. Klaidos nėra svarbiausia
Atliekant UAT testavimą daugiausia dėmesio skiriama ne klaidų paieškai, o funkcionalumo nustatymui.
Jei per daug laiko praleidžiate ieškodami klaidų, pradedate tikrinti mažiau svarbias proceso dalis, užuot įsitikinę, kad sistema veikia.
Užsirašykite klaidas, kai jas aptinkate, bet aktyviai jų neieškokite ne pagal standartines darbo eigos taisykles.
5 klaidos ir spąstai, kurių reikia vengti įgyvendinant naudotojo priimtinumo testus
Yra keletas klaidų, kurias testuotojai nuolat daro atlikdami naudotojo priėmimo testavimo procesus. Kai kurie pagrindiniai dalykai, kurių reikia vengti, kai procesą vykdote patys:
1. Vartotojo testavimas
Kai kuriomis programinės įrangos dalimis naudotis sudėtinga ir reikia daug žinių, kad būtų galima visapusiškai išnaudoti visas funkcijas.
Naudokite darbuotojus arba testuotojus, turinčius įgūdžių, reikalingų programinei įrangai naudoti, nes priešingu atveju rizikuojate išbandyti naudotoją, o ne programinę įrangą.
Paprasčiau tariant, dėl žemos kvalifikacijos bandytojų nepavyksta ištirti visų gaminio aspektų.
2. Neįvykdytos „sausos” treniruotės
Bandomasis bandymas – tai ankstyvas naudotojo priėmimo testo užbaigimas, kai naudotojai iš anksto atlieka testą.
Atliekant šį testą duomenys nerenkami, o tik įsitikinama, kad pats testas veikia taip, kaip tikimasi.
Neįvykdžius bandomojo testavimo, UAT testavimas gali tapti mažiau veiksmingas, nes susidursite su netikėtomis kliūtimis, kurias būtų buvę galima išspręsti iš anksto suplanavus.
3. Netikslūs klausimai
Labai svarbu, ar klausimai, kuriuos užduodate, yra tinkami.
Jei užduodate netinkamus klausimus, rizikuojate, kad jūsų organizacija išeis iš UAT proceso neturėdama reikiamos informacijos ir paleis prastesnį produktą, nes negalės jo atnaujinti pagal naudotojų atsiliepimus.
4. Netinkamos auditorijos naudojimas
Skirtingi produktai kuriami skirtingoms auditorijoms, turinčioms skirtingus skonius, gebėjimus ir patirtį.
Tai gali skambėti paprastai, tačiau įsitikinkite, kad savo produktą išbandėte su tinkama auditorija. Naudojant netinkamą auditoriją kyla rizika, kad bandytojai nesupras programinės įrangos esmės ir padarys esminių klaidų, o jų pateiktos rekomendacijos gali paskatinti kūrėjų komandą atlikti atnaujinimus, kurie iš tikrųjų ne pagerins, o pablogins produktą.
5. Dokumentacijos procesų trūkumas
Kai kurios įmonės įsitraukia į patį naudotojo priėmimo testavimo procesą, įsitikindamos, kad procedūros yra tikslios, o testuotojai yra patenkinti jiems pateikta programine įranga.
Tokiais atvejais kai kurios įmonės pamiršta, kad programinės įrangos testavimo tikslas – gauti aiškias pastabas ir dokumentus.
Taigi… turėkite aiškų duomenų rinkimo ir stebėjimo procesą, kad pernelyg neužsiimtumėte praktine testavimo puse.
Išvada
Apibendrinant galima teigti, kad UAT testavimas yra būtinas programinės įrangos kūrimo srityje. Taip užtikrinama, kad jūsų organizacija pristatytų išbaigtą produktą, kuris būtų pakankamai aukštos kokybės, ir kartu užtikrinama, kad klientai visapusiškai naudotųsi jiems prieinama programine įranga.
Nesvarbu, ar naudojate rankinį testavimą, kad sužinotumėte naudotojų požiūrį ir jų sąveiką su naudotojo sąsaja, ar automatizavimą, kad kuo greičiau patikrintumėte funkcionalumą, sukūrę testavimo procesą, kurio metu tikrinama programa, galite paskutinę minutę atlikti atnaujinimus ir pristatyti geriausią įmanomą produktą.
Rinkdamiesi naudotojo priėmimo testavimo platformas neskubėkite. Šie bandymai gali būti brangūs ir reikalauti daug žinių, todėl pasirinkę patikimą UAT testavimo įrankį, kuris sukurtas atsižvelgiant į naudotojus, sutaupysite laiko ir pagerinsite testavimo kokybę.
Kuo greičiau įtraukite UAT testavimą į savo darbo eigą, kad gautumėte visus geresnio kokybės užtikrinimo privalumus paleisdami kitą programinę įrangą.
DUK ir ištekliai
Jei domitės UAT testavimu ir norite sužinoti daugiau, susipažinkite su toliau pateiktais dažniausiai užduodamais klausimais ir šaltiniais, iš kurių galite sužinoti apie šį naudingą testavimo metodą:
1. Geriausi kursai apie UAT testavimą
– „Vartotojo priėmimo testavimas UAT mokymai – Jungtinė Karalystė” – Žinių akademija
– „iSQI vartotojo priėmimo testavimas (UAT)” – TSG Training
– „Vartotojų testavimas” – „Udemy
– „Vartotojo priėmimo testavimas UAT mokymo kursai” – Projecting IT
– „Visiškas kokybės užtikrinimo kursas – mokykitės kokybės užtikrinimo nuo nulio” – „Skillshare”, Viktoras Gorinovas
2. Kokie yra 5 svarbiausi interviu klausimai apie UAT testavimą?
Kai kurie iš dažniausių kandidatų interviu klausimų, susijusių su UAT testavimu, yra šie:
– Kokios patirties turite atliekant UAT testavimą?
– Kokia buvo viena sudėtingiausių jūsų patirčių atliekant UAT testavimą?
– Kokie yra rankinių ir automatinių UAT testų privalumai ir trūkumai?
– Kaip apibūdintumėte UAT testus žmogui, nesusijusiam su programinės įrangos kūrimu?
– Kaip manote, kokie yra pagrindiniai programinės įrangos testavimo darbo vietoje iššūkiai?
3. Geriausios „YouTube” pamokos apie UA testavimą
– „Kaip rašyti priimtinumo testus” – Continuous Delivery
– „Kaip suplanuoti UAT – Vartotojo priėmimo testų planai, kurie veikia!” – Karaleise | Verslo analitikų mokymai
– „Vartotojo priimtinumo testavimas | Programinės įrangos testavimas” – Deepak Rai
– „Vartotojo priėmimo testavimo (UAT) vaidmuo verslo analitikams” – Business Analyst & Scrum Master In-Demand
– „Programinės įrangos testavimo procesas: Kas yra vartotojo priimtinumo testavimas – UAT?” – Internetiniai PM kursai – Mike Clayton
4. Kaip išlaikyti naudotojo priimtinumo testus?
Palaikykite UAT testus nuolat atnaujindami bet kokią programinę įrangą, kurią naudojate kartu su testavimo platformomis, taip pat nuolat tikrinkite testavimui naudojamą kodą.
Taip išvengsite abiejų aspektų tarpusavio sinchronizacijos ir pakenksite testų veiksmingumui.
5. Ką UAT reiškia Agile?
” Agile” sistemoje UAT vis dar yra galutinis testavimo proceso etapas, tačiau jis vyksta kelis kartus. Kadangi programinė įranga turi keletą atnaujinimų, kurių kiekvienas siunčiamas naudotojams, kūrėjas, prieš pradėdamas teikti atnaujinimus, išbando kiekvieną programos versiją.
6. Kas yra UAT ir QA testavimas
QA testavimas, arba kokybės užtikrinimo testavimas, yra visa sritis, kuri užtikrina, kad programinės įrangos produktai atitiktų pakankamai aukštus standartus viso kūrimo proceso metu.
UAT – tai kokybės užtikrinimo testavimo forma, kai prieš pat paleidžiant programinę įrangą iš karto įsitikinama, kad ji atitinka aukštus standartus.
