Sisu
- Demo ja sure!
- Astuge kasutaja kingadesse
- Lühike UAT ajalugu
- UAT ütleb teile, kui süsteem on kasutatav
- Kes saavad UATi teha?
- Pole vigu ega stressi - teie samm-sammuline juhend elumuutva tarkvara loomiseks ilma oma elu hävitamata
- Edu ja ebaõnnestumine voolab
- UAT eelised
Allikas: Lightcome / iStockphoto
Ära võtma:
Kui tarkvara on läbinud ühiku-, integratsiooni- ja süsteemitesti, võib aktsepteerimistestide vajadus tunduda ülearune. Miks on kasutajate aktsepteerimise testimine (UAT) endiselt oluline? Siit saate teada ka UAT eeliste ja selle ainulaadsete omaduste kohta.
Demo ja sure!
Kas olete kunagi esitlenud kliendi tutvustust või koolitust ja midagi laguneb poole pealt? Või kas olete kunagi andnud kellelegi juhiseid ja mõistnud, et olete millestki ilma jäänud või ei töötanud see päris nii, nagu lootsite? Kõigi nende juhtumite ajal võtate omaks lõpptarbija vaatenurga ja töötate selle isiku tarkvaraga. Võimalik, et tegite midagi teisiti, kuna mõtlesite pigem kasutaja, mitte arendajana.
Astuge kasutaja kingadesse
Kasutajate aktsepteerimise testimise (UAT) ainulaadne nurk on tarkvara testimine lõpptarbijana. Tarkvara on loodud selleks, et anda kasutajatele käegakatsutavaid tulemusi. Näiteks võimaldavad e-kaubanduse saidid klientidel tooteid osta. Kui klient tellimuse esitas, teavitab e-kaubanduse saitide tarkvara poe administraatorit, et valitud üksuse saaks veoks tõmmata ja pakkida. Tarkvara kasutajaid võib olla erinevat tüüpi, nii et see testimisetapp võimaldab arendusmeeskonnal kontrollida, kas lõppkasutajad saavutavad oodatud tarkvaratulemused.
Lühike UAT ajalugu
Enne Interneti tulekut kasutati enamikku tarkvara teadaolevale kasutajaskonnale. Kui ettevõte arendas kliendi jaoks tarkvara, oli määratud halduril volitus kontrollida tarkvara vastavust lepingutingimustele. See pidi tähistama punkti, kus tarkvara oli "otstarbeks sobiv", mis saavutati valides lõpptarbija esindajad testimiseks ja tulemuste aruande esitamiseks. Kuna kasutajad olid teadaolevad suletud rühmad, sai igaüks tarkvara kasutamise koolitada, tavaliselt väga üksikasjalike testimistoimingute kaudu. Päeva moto oli, et rohkem detaile oli parem.
Kuna veebis arendati üha enam klientidele mõeldud tarkvara, muutus lõppkasutaja vaatajaskond avatumaks. Enam ei olnud võimalik kõiki tõenäolisi lõppkasutajaid tuvastada ja välja õpetada, seetõttu pidi tarkvara kujundamine sisaldama palju suuremat rõhku kasutatavusele ja see pidi olema hõlpsasti mõistetav - isegi minimaalselt pakutava teabe korral. Niisiis, UAT tuli nende nõuete täitmiseks muuta.
UAT ütleb teile, kui süsteem on kasutatav
Niisiis, mitte ainult ei ütle UAT meile tarkvaraosa funktsionaalsuse ulatust, vaid ka seda, kui kasutatav see on. Enamikku UAT-i saavad kõige paremini teostada inimesed, kes mõistavad sihtrühma kuuluvat lõppkasutajat, kellel on tarkvara kasutamisel vähe eelteadmisi ja mis suudavad anda tõestuse tarkvara kasutamismugavusest ja sellest, mida on vaja parandada.
Kes saavad UATi teha?
Kui arendajad tarkvara testivad, mäletavad nad süsteemi kirjutamise üksikasju. Need teadmised võivad mõjutada testimist ja arendajad võivad astuda lõppkasutajatest erinevaid samme, näiteks teostada samme kiiremini või jätta kõrvale peeneid detaile, mis lõppkasutajate jaoks võivad segadust tekitada. Seega pole arendajad parimad UAT-i kandidaadid. Kes siis on?
Paljud organisatsioonid võtavad tööle spetsiaalseid testimisrühmi, kes ei tegele tehnilise disaini ja arendusega. Väiksemad organisatsioonid eraldavad testid arendustöötajatele, näiteks neile, kes täidavad haldusülesandeid, või kasutavad välise ettevõtte teenuseid. Mõned organisatsioonid kasutavad nn koridori testimist, kus nad sõna otseses mõttes valivad töötajad, kes pole projektiga aktiivselt seotud, ja paluvad neil süsteemi proovida lõppkasutajate vaatenurgast. Näiteks võiks toote Internetist tellida.
Pärast ettevõttesisest testimist võib toimuda piloot- või beetatestimise etapp, mille käigus tarkvara tehakse kättesaadavaks väikestele „päris“ kasutajate gruppidele, kellele kutsutakse toodet kasutama tasuta või märkimisväärse allahindlusega, vastutasuks üksikasjaliku kasutusalase tagasiside eest.
Pole vigu ega stressi - teie samm-sammuline juhend elumuutva tarkvara loomiseks ilma oma elu hävitamata
Te ei saa oma programmeerimisoskusi parandada, kui keegi tarkvara kvaliteedist ei hooli.
Progressiivsed UAT-etapid mitmekesise vaatajaskonnaga suurendavad usaldust tarkvara kasutatavuse vastu. Koos iteratiivse arengu etappidega saab uute funktsioonide testimiseks nende esitamisel läbi viia mitu UAT-tsüklit, kontrollides samal ajal ka eelnevaid funktsioone.
Heatel UAT-testijatel on uudishimulik näha, mis juhtub, kui nad suunavad konkreetse eesmärgi saavutamiseks erinevaid teid. Lõppude lõpuks lähenevad kõik tarkvara kasutamisele erinevalt, nii et kui väike grupp inimesi suudab paljusid võimalusi katta, on tarkvara kindlus töörežiimis kõrgem.
Edu ja ebaõnnestumine voolab
UAT-i protsessid peaksid kontrollima, et igat tüüpi tarkvara kasutajad saaksid käegakatsutavaid tulemusi nii edu kui ka ebaõnnestumise korral.
Edukuse voolavuses lõppkasutaja eemaldub oodatava tulemusega, näiteks tootetellimuse esitamisega. Tõrkevoo korral toetab tarkvara lõppkasutajat mingisuguse veastsenaariumi kaudu, näiteks kui klient edastab kehtetu krediitkaardimakse teabe.
Funktsionaalsuse kontrollimiseks tuleb testijatele anda teatud teave. Muidu ei tea nad, mida tarkvara peaks tegema. Kuid kasutatavuse kontrollimiseks peab see olema minimaalne - lihtsalt ülesandel või nõuetel põhinevad, näiteks "x" (toode) ostmine ja "y" maksmine (krediitkaardi andmete kasutamine). Testijatele tuleb panna tähelepanekud vaatluste, õnnestumiste ja ebaõnnestumiste registreerimiseks.
UAT eelised
Hea UAT-i peamine eelis on see, et see hoiab jooksvad hoolduskulud võimalikult madalad. Funktsionaalsuse ja kasutatavusega seotud probleemide lahendamine on odavam. Seda on palju raskem parandada, kui regressioonitesti jaoks on rohkem koodi või kui algne arendaja pole saadaval.
Mitmes etapis ja erinevat tüüpi testpublikuga teostatav UAT pakub optimaalseid võimalusi katkiste funktsioonide / kasutatavusega seotud probleemide tuvastamiseks ja parandamiseks testimise varajastes etappides. UAT-eesmärkide hoidmine ülesannete ja nõuete tasemel võimaldab testijatel palju rohkem jälgida ja märgata ning proovida isegi samme väljaspool arendaja pakutavat ulatust.
UAT-tsüklite tagasisidet saab kasutada edasistes arengu iteratsioonides, suurendades tarkvara vastupidavust ja kasutatavust. Hästi ajastatud, isegi beetaversiooni testifaasid saavad turundus- ja müügitegevusi täiendada, pakkudes viiteid ja juhtumianalüüsi tagasisidet.