Kasutajate aktsepteerimise testimine (UAT) on üks kõige sagedamini kasutatavaid tarkvara testimise vorme. Kasutaja vastuvõtutest on teatud tüüpi musta kasti testimine.

See on tarkvara testimise viimane etapp enne mis tahes tarkvaratoote tarnimist sidusrühmadele. UAT-d nimetatakse ka beetatestimiseks.

See artikkel annab teile täieliku juhendi UAT kohta.

Sisukord

• Mis on kasutajate vastuvõtutest?
• Millal seda teostatakse?
• Kes vastutab UAT täitmise eest?
• Vajadus kasutajate aktsepteerimise testimiseks (UAT)
• Kasutajate aktsepteerimise testimise kontroll-loend
• Kuidas teha kasutajate aktsepteerimise testimist (UAT)?
• Kuidas kasutajate vastuvõtutesti tõhusalt läbi viia?
• Tööriistad kasutajate aktsepteerimise testimiseks
• Kasutaja aktsepteerimise testimise mall
• Kasutajate aktsepteerimise testimise parimad tavad
• Süsteemi testimine vs kasutaja vastuvõtutest
• Järeldus
• Korduma kippuvad küsimused
  • Mis on kasutajate vastuvõtutest?
  • Kuidas teete UAT kasutajate vastuvõtuteste?
  • Mis on näitega kasutajate aktsepteerimise testimine?
  • Millised on vastuvõtutestide tüübid?
• Soovitatavad artiklid

Mis on kasutajate vastuvõtutest?

Nagu nimigi ütleb, testib kasutaja aktsepteerimise testimine (UAT) mis tahes konkreetset tarkvaratoote kasutaja heakskiitmiseks.

Vaatame, mis on kasutaja määratlus UAT kontekstis.

Kasutaja on isik, kes soovib saada endale kindlat toodet vastavalt nõuetele.

Niisiis, UAT määratlus saab tuletada kasutaja poolt konkreetse tarkvara testimise või kontrollimisena. Kasutaja saab kontrollida, kas tarkvaratoode töötab vastavalt tema vajadustele.

UAT on osa tarkvara testimise protsessist tarkvaraarenduse elutsükkel mis võtab arvesse kasutaja lugu ja loob testimisplaani vastavalt nõutavatele ülesannetele reaalsetes stsenaariumides.

Erinevalt teistest testidest nagu ühiku testimine ja regressioonitestid , mida teeb QA meeskond kunstlikus testimiskeskkonnas, UAT-d teevad tavaliselt sidusrühmad või muud ärikasutajad (nimetatakse ühiselt UAT meeskonnaks). Seda tehakse tarkvaraprojekti protseduuride ühe viimase etapina, mida tuntakse ka kui beetatestimist.

See käivitatakse pärast funktsiooni, integratsiooni, regressioonitesti ja süsteemi testimine kui tarkvaraarenduse meeskond, testimismeeskond ja kvaliteedikontrolli meeskond on teostanud kõik kunstlikud toimingud.

Seda tehakse tootmiskeskkonnas reaalse maailma stsenaariumitega vastavalt tegelikele tarkvarakasutajatele.

Lisaks sellele nimetatakse seda testimist lõppkasutaja testimiseks, töö aktsepteerimise testimiseks (OAT), välitingimustes aktsepteerimise testimiseks ja vastuvõtutestipõhiseks arenduseks (ATDD).

Vastuvõtmise tüübid

Millal seda teostatakse?

UAT testimine või lõppkasutaja testimine viiakse tavaliselt läbi tarkvara testimise viimases etapis, enne kui konkreetne toode on valmis turule sisenema, et see lõppkasutajale tarnida.

Enne kui toode saadetakse kasutajatele kasutajate aktsepteerimistestimise käigus tarkvaraga tutvumiseks, testib kvaliteeditagamise (QA) meeskond tarkvara, et veenduda probleemide puudumises.

Tarkvara kasutajad viivad enne väljatöötamist läbi UAT-teste, et veenduda toote heas töös ja kõikides lepingus sätestatud ärinõuetes.

Tavaliselt tehakse UAT pärast toote süsteemi testimist. Kuna UAT testimine on toote üks viimaseid etappe, peavad kliendid kaaluma kõiki toodete vaatenurki.

Kes vastutab UAT täitmise eest?

UAT testimise eesmärk on kontrollida, kas tarkvara on lõppkasutajate jaoks töökindel või vastab kõigile kriteeriumidele ning on kasutatav täiusliku lahendusena lõppkasutajatele.

Toote omanik teostab UAT.

Ärikasutajad testivad tarkvara äri- või kasutajanõuete järgi ja mitte selleks, et veenduda, kas tarkvara jookseb kokku, vastab tema nõuetele, esineb kirjavigu või muid defekte. See kõik tehakse enne tarkvararakenduse integratsiooni testimise, süsteemi testimise ja üksuse testimise etappi.

See lõppkasutaja testimine keskendub peamiselt tarkvara toimimisele. Tarkvara peaks sobima ärifunktsioonide ja ärinõuetega.

Vajadus kasutajate aktsepteerimise testimiseks (UAT)

On üksikuid ettevõtteid, kes on oma tarkvaratoodetes enne nende turule laskmist silmitsi seisnud suure probleemiga.

Kui pärast turule sisenemist on tarkvaraga probleeme, võib see kaasa tuua olulise ärikahju.

Ükskõik milline toote defekt võib muutuda lõppkasutajate usalduse ja usu kaotamiseks, mis ei ole ettevõttele kuigi kasulik.

Isegi kui tootel esinevad vead on parandatavad, nõuab see palju aega ja raha.

Tarkvaraprobleemide vältimiseks pärast selle turule toomist on see olemas vajadus UAT testimise järele .

UAT testimine tagab, et tarkvara on hästi maandatud ja töötab hästi konkreetse probleemi lahendusena ning on kooskõlas ärinõuetega.

Konkreetse toote puhul on UAT test hädavajalik, et vältida ärikahju mis tahes defektide või vigade korral.

UAT test säästab ka väärtuslikku aega ja kulutusi selle konkreetse toote omanikule.

Kasutajate aktsepteerimise testimise kontroll-loend

UAT kontrollnimekiri sisaldab täielikku juhendit tarkvaraarenduse UAT-testi läbiviimise ja UAT-testimise etappide kohta.

1. Esialgne kontrollnimekiri hõlmab kasutaja aktsepteerimise testimise (UAT) testi käivitamist.
2. Lõppkasutaja planeerimine, võimaldades pärast seda uurimistööd.
3. Kontseptsiooni tarbijate aktsepteerimise kontrollimine.
4. Kasutaja nõusoleku täitmise kontrollimine.
5. Otsused aktiveerimise kohta
6. Postitustesti käitumine kasutaja heakskiidu saamiseks.

Kuidas teha kasutajate aktsepteerimise testimist (UAT)?

UAT testimise läbiviimiseks on vaja konkreetseid samme. Neid samme selgitatakse lühidalt allpool:

Ärivajaduste uurimine:Esmane ja kõige olulisem samm UAT-s hõlmab ärivajaduste määratlemist ja hindamist ning olukordade testimist. Seda võib öelda ka kui planeerimisfaasi. Reaalses maailmas peaksid lõppkasutajad määrama testi jaoks teststsenaariumid erinevatest dokumentidest, nagu ärikasutusjuhtumid, vooskeemid, süsteeminõuete spetsifikatsioon (SRS) jne.UAT testiplaani väljatöötamine:Järgmine samm hõlmab UAT testiplaani väljatöötamist. See kasutaja väljatöötatud plaan on strateegia, mis tagab, et tarkvara vastab ärivajadustele. See plaan võib sisaldada sisenemis- ja väljumiskriteeriume, testjuhtumeid, testistsenaariume, aktsepteerimiskriteeriume ja lõppkasutaja põhjal testimise ajakavasid.Tuvastage testistsenaariumid ja -juhtumid:Testijad peavad tuvastama kõrgetasemelised äritestimise olukorrad. Testimisolukordade põhjal peavad need testijad looma selged ja puhtad testjuhtumid. Väljatöötatud testjuhtumid peaksid hõlmama kõiki äritegevuse katsestsenaariume.Kasutage reaalajas andmeid:Reaalajas andmete kasutamine UAT protsessis on väga kasulik. See aitab lõppkasutajal näha, kuidas tarkvaratoode praeguse olukorra andmetega töötab. Kasutajad kasutavad rakendust ja testivad reaalajas andmetega, kas tarkvara sobib turule.Käivitage testjuhtumid:Kõrgetasemeliste äritesti olukordade põhjal välja töötatud testjuhtumid tuleks läbi viia ja tulemus üles märkida. Vea või defekti ilmnemine selles etapis ei ole aga hea. Kõik vead või defektid tuvastatakse varasemates etappides. Kuid kui need ilmuvad, peavad testijad esmalt selle parandama ja seejärel viga uuesti testima. Pärast uuesti testimist märkige tulemus üles.Veenduge, et ärinõuded oleksid edukalt täidetud:Pärast iga testjuhtumi tulemuste ülesmärkimist peavad testijad tagama, et kõik ärinõuded on kaetud ja tarkvara töötab reaalajas hästi.

Kuidas kasutajate vastuvõtutesti tõhusalt läbi viia?

Kuna UAT on tarkvaraarenduse ja testimise üks olulisemaid etappe, peavad kasutajad seda testimist hoolikalt ja innukalt läbi viima. Selle testimise läbiviimiseks peavad kasutajad võtma arvesse konkreetseid parameetreid või tegureid. Need parameetrid on loetletud allpool:

Selgete ootuste seadmine:Esimene tegur, mida kasutaja aktsepteerimise testis arvesse võtta, on testimise võimaliku tulemuse suhtes selgete ootuste seadmine. Toote kasutaja või omanik ja testimismeeskonna liige peaksid teadma testi läbiviimise põhjust.UAT läbiviimine varases staadiumis:See kasutaja aktsepteerimise test tehakse vahetult enne toote kliendile tarnimist. Seda lähenemist järgitakse traditsioonilises tootearendusmudelis, kosemudelis ja Agile mudelis kaasaegsetes arendusmudelites. Vigade ja defektide avastamiseks tuleks see läbi viia tootearenduse varases staadiumis.Leidke sobivad testijad:Teine oluline tegur, mida UAT läbiviimisel arvesse võtta, on asjakohaste testijate valimine. Kasutajad peavad valima osalejad, kes on seda tüüpi testimisega sageli varem töötanud.Tehke testülesanded:UAT-s testitakse toodet, kas see töötab hästi reaalsete stsenaariumide ja igapäevaste toimingute puhul. Seega peavad kasutajad koostama tootega tehtavate ülesannete ja testide loendi, et tagada toote hea toimimine igas olukorras. Kuid loodud testülesanne peaks põhinema kõrgetasemelistel äritingimustel, testide kõrgemal kvaliteedil ning sisaldama ülevaatlikke ja selgeid samme.

Kasutajate aktsepteerimise testimine

Tööriistad kasutajate aktsepteerimise testimiseks

UAT läbiviimiseks on turul saadaval mitmeid tööriistu. Allpool on loetletud mõned testimistööriistad.

1. vesi

Watir on rubykeelse veebirakenduste testimise lühivorm. See on üks populaarsemaid tööriistu, mida kasutatakse UAT tõhusaks täitmiseks. Parim osa on see, et see on avatud lähtekoodiga tööriist. See on platvormideülene tööriist, mis toetab kõiki peamisi operatsioonisüsteeme. See hõlmab kolme väikest projekti. Neist kolme kasutatakse peamiselt. Need on Watir-Classic, Watiri veebidraiver ja Watirspec. See on kirjutatud Ruby programmeerimiskeeles ja on litsentsitud MIT litsentsi alusel.

2. FitNesse

FitNesse on veel üks populaarne UAT-i jaoks kasutatav tööriist. See pakub võimalust Wiki veebilehtedele testjuhtumite kirjutamiseks ja nende käivitamiseks Wiki kaudu. Kasutajad saavad luua uusi Wiki lehti või redigeerida olemasolevaid Wiki lehti ja loetleda oma testjuhtumid. See tööriist on spetsiaalselt välja töötatud Agiilse arendusmetoodika ja UAT.

Kasutaja aktsepteerimise testimise mall

Rakendust testiv UAT-meeskond nõudis ülesandeid vastavalt UAT mall . See erineb oluliselt kvaliteedi tagamise meeskonna jaoks kasutatavatest tarkvaraarenduse testimismallidest. Kasutaja aktsepteerimise testimise mallil võib olla järgmine teave.

Testjuhtumi ID:Testjuhtumi ID kasutaja aktsepteerimise testimise mallis peaks olema iga testjuhtumi jaoks kordumatu. See on number, mis tuvastab kordumatult iga testjuhtumite loendis oleva testjuhtumi.Funktsionaalne piirkond:Funktsionaalne ala on malli teine ​​parameeter. Testjuhtumid kombineeritakse vastavalt nende funktsionaalsele alale.Ettevõtte nõude ID:Nagu testjuhtumi ID, on ka ärinõude ID kordumatu number, mis tuvastab ettevõtte iga nõude.Kasutaja roll:Toote kasutaja vastutab kasutaja aktsepteerimistesti läbiviimise eest. Seega on väga oluline tuvastada kasutaja roll esitatud ärivajaduste põhjal.Testi sammud: Testimistoimingute organiseerimine muudab testimisprotsessi tõhusaks ja lihtsaks. Testietapid hõlmavad kõiki järjestikuseid toiminguid, mis tuleb täitmise ajal läbi viia.Oodatud Tulemus:See malli moodul sisaldab iga testjuhtumi eeldatavat tulemust või süsteemi käitumist iga testjuhtumi täitmisel.Tegelik tulemus:See veerg sisaldab tegelikke tulemusi pärast iga testjuhtumi täitmist reaalses maailmas. Kui oodatav ja tegelik tulemus on samad, peavad kasutajad sellesse veergu sisestama Same as Expected.Testi olek:Testi olek näitab, kas konkreetne testjuhtum läbib või ebaõnnestub. Kui see läheb läbi, edastatakse olek ja kui see ebaõnnestub, peavad kasutajad esitama probleemi arendusmeeskonnale.Mõju ärile:See veerg sisaldab olulist teavet ja seda kasutatakse ülesannete prioriteedi määramiseks.Kommentaarid:See moodul sisaldab kommentaare testjuhtumite kohta.

Kasutajate aktsepteerimise testimise parimad tavad

Teadke tarkvara kasutajaid:Oluline on teada, kes seda tarkvara reaalses maailmas kasutab. Millised on klientide vajadused seoses konkreetse tarkvaraga? Mida nad tarkvaralt ootavad? Kui kõik need andmed on saadaval, muutub kasutajate aktsepteerimise testimine mugavamaks.Valmistage eelnevalt ette testi ülevaade:Kasutajate aktsepteerimise testimise läbiviimiseks on oluline koostada üksikasjalik ülevaade protsessi läbiviimisest. Kasutajate vastuvõtutestide eelnev planeerimine võib aidata testijatel kõiki katsejuhtumeid katta ja neid tõhusalt läbi viia.Hästi struktureeritud kasutajate vastuvõtuhalduse testimine:Kuna kasutajate aktsepteerimise testimine on testimise üks viimaseid etappe enne selle turule jõudmist, peab tarkvara töötama hästi vastavalt klientide vajadustele. Seda tüüpi testimiseks kasutatav juhtimissüsteem peaks olema hästi struktureeritud ja organiseeritud.Töötage välja testisituatsioonid:Testijad peaksid kasutama kõrgetasemelisi äritesti olukordi ja looma neist testjuhtumeid. Kuid need katsestsenaariumid peavad põhinema ettevõtte vajadustel.Määratlege vastuvõtustandardid:Aktsepteerimisstandard hõlmab reegleid ja standardeid, mille alusel otsustatakse, kas tarkvaratoode on läbitud või ebaõnnestunud. Seega, et teha kindlaks, kas toode sobib turul kasutamiseks või mitte, on vaja põhilisi aktsepteerimisstandardeid.

Süsteemi testimine vs kasutaja vastuvõtutest

Süsteemi testimine ja UAT on kaks erinevat terminit. Süsteemi testimine viiakse läbi enne UAT-d. Allpool toodud tabel aitab teil mõista erinevust süsteemi testimise ja UAT vahel.

Süsteemi testimine vs kasutaja vastuvõtutest

Järeldus

Pärast kõigi ülaltoodud UAT elementide ülevaatamist mõistame, et see etapp tarkvara testimine on iga toote jaoks väga oluline, enne kui see ettenähtud kasutajatele turule tarnitakse.

Need testid tagavad, et kasutajad kasutavad rakendust enne selle turuleviimist ja veenduvad, et see saab hakkama tegelike kasutusjuhtudega.

See testimine kontrollib, kas konkreetne toode vastab tõhusalt ärinõuetele, ja kontrollib, kas tarkvara saab serveerida tõhusa ärilahendusena.

Korduma kippuvad küsimused

Mis on kasutajate vastuvõtutest?

Testimise viimase etapina teostatav UAT on testimise tüüp, mille käigus lubatakse tegelikel kasutajatel arendatud tarkvara testida ja vigu leida. Mõnikord juhtub, et testijad ei suuda kõiki vigu leida ja seega pakuvad tegelikud kasutajad värske pilgu. Erinevalt arenduskeskkonnast, milles muud testimised toimuvad, tehakse UAT tootmiskeskkonnas. Seda tuntakse ka kui rakenduste testimist või lõppkasutaja testimist.

Kuidas teete UAT kasutajate vastuvõtuteste?

UAT tehakse tavaliselt alltoodud samme järgides:
Analüüsige ärinõudeid sellistest dokumentidest nagu tarkvaranõuete spetsifikatsioonid (SRS), ärinõuete dokument (BRD), protsessi vooskeemid jne.
UAT-plaan luuakse selleks, et otsustada, millist strateegiat tarkvara kontrollimiseks järgida. Sellesse on kaasatud kõik sisenemise ja väljumise kriteeriumid, testjuhtumid, teststsenaariumid jne.
Kõrgetasemeliste ärinõuete alusel luuakse erinevad testistsenaariumid, mis sisaldavad mitut testjuhtumit koos selgete juhistega nende täitmiseks.
UAT jaoks kasutatakse enamasti reaalajas andmeid, mida privaatsus- ja turvaprobleemide tõttu segatakse.
Kui plaan, stsenaariumid ja juhtumid on kõik seadistatud, käivitatakse testjuhtumid ja testitakse võimalikke vigu. Kõik testimise käigus leitud vead parandatakse ja seejärel testitakse uuesti, et tagada paranduse toimimine. Mõned organisatsioonid ja testijad kasutavad testide haldamise tööriistu.
Kui kõik kasutajate vastuvõtmise testimise juhtumid on läbi viidud ja vead teatatud või parandatud, kirjutavad ärianalüütikud või UAT testijad alla, andes mõista, et tarkvara on tootmiseks valmis.

Mis on näitega kasutajate aktsepteerimise testimine?

Kasutajate aktsepteerimise testimine on teatud tüüpi testimine, mille käigus tegelikud kasutajad kontrollivad tarkvara vigade suhtes pärast seda, kui arendusmeeskond on selle parandanud. Näiteks kui osaleme mõnes Play poes olevate rakenduste beetaprogrammis, juurutame rakenduse tegelikus keskkonnas ning leiame ja teatame vead, mille järel see lahendatakse. Seega on beetatestimine ka osa kasutajate aktsepteerimistestimisest.

Millised on vastuvõtutestide tüübid?

Kasutajate vastuvõtuteste on viit tüüpi:
Beeta- ja alfatestimine
Musta kasti testimine
Lepingu vastuvõtmise testimine
Töötamise vastuvõtmistestimine
Musta kasti testimine