Indhold
- Demo Og Die!
- Træd ind i brugernes sko
- En kort UAT-historie
- UAT fortæller dig, hvor brugbart systemet er
- Hvem kan udføre UAT?
- Ingen fejl, ingen stress - Din trinvis vejledning til oprettelse af livsændrende software uden at ødelægge dit liv
- Succes og svigt
- UAT-fordele
Kilde: Lightcome / iStockphoto
Tag væk:
Når software gennemgår enheds-, integration- og systemtestning, kan behovet for acceptacetest virke overflødigt. Hvorfor er test af brugeraccept (UAT) stadig vigtig? Her kan du godt lære om fordelene ved UAT, og hvorfor det er unikt.
Demo Og Die!
Har du nogensinde leveret en kundepræsentation eller træning, og noget bryder halvvejs igennem? Eller har du nogensinde givet nogen et sæt instruktioner og indset, at du gik glip af noget, eller det virkede ikke helt, som du håbede? I hvert af disse tilfælde vedtager du slutbrugerens perspektiv og arbejder med softwaren i denne persona. Chancerne er, at du gjorde noget andet, fordi du tænkte som en bruger snarere end en udvikler.
Træd ind i brugernes sko
Den unikke vinkel ved brug af accept af test (UAT) er at teste software som slutbruger. Software er bygget til at give brugerne håndgribelige resultater. For eksempel tillader e-handelswebsteder kunder at købe produkter. Når en kunde afgiver en ordre, underretter e-handelssoftwaren butiksadministratoren, så den valgte vare kan trækkes og pakkes til forsendelse. Der kan være forskellige typer softwarebrugere, så denne testfase giver udviklingsholdet mulighed for at verificere, at slutbrugerne opnår forventede softwareresultater.
En kort UAT-historie
Før fremkomsten af internettet blev mest software implementeret til et kendt brugerpublikum. Hvis en virksomhed udviklede software til en kunde, havde en tildelt manager myndighed til at kontrollere, at softwaren opfyldte kontraktvilkårene. Dette var beregnet til at repræsentere et punkt, hvor softwaren var "egnet til formålet", som blev opnået ved at vælge slutbrugerrepræsentanter til at udføre test og give en rapport med resultater. Da brugerne var en kendt, lukket gruppe, kunne hver enkelt trænes i brugen af softwaren, typisk gennem meget detaljerede teststrin. Dagens motto var, at flere detaljer var bedre.
Efterhånden som mere og mere software blev udviklet til kunder på nettet, blev slutbrugergruppen mere åben. Det var ikke længere muligt at identificere og træne alle sandsynlige slutbrugere, så softwaredesign måtte indeholde en meget større vægt på brugervenlighed og måtte være let forståelig - selv med minimalt angivet information. Så UAT måtte ændre sig for at imødekomme disse krav.
UAT fortæller dig, hvor brugbart systemet er
Så ikke kun fortæller UAT os omfanget af funktionalitet for et stykke software, men det fortæller os også, hvor brugbart det er. De fleste UAT udføres bedst af personer, der forstår den målrettede slutbruger, der vil opleve softwaren med ringe forkendskab og kan give en sand indikation af softwarernes brugervenlighed og hvad der skal forbedres.
Hvem kan udføre UAT?
Når udviklere tester software, husker de detaljer om, hvordan et system skrives. Denne viden kan påvirke test, og udviklere kan tage forskellige skridt end slutbrugere, såsom at udføre trin hurtigere eller afvise fine detaljer, som slutbrugerne kan synes at være forvirrende. Således er udviklere ikke de bedste UAT-kandidater. Så hvem er det?
Mange organisationer beskæftiger specifikke testhold, som ikke er involveret i teknisk design og udvikling. Mindre organisationer tildeler enten test til ikke-udviklingspersonale, ligesom dem, der udfører administrative opgaver, eller bruger tjenester fra et eksternt firma. Nogle organisationer bruger det, der kaldes "hallway testing", hvor de bogstaveligt talt hånden vælger medarbejdere, der ikke er aktivt ansat i projektet, og beder dem om at prøve systemet ud fra slutbrugerens perspektiv. Et eksempel ville være at bestille produkt online.
Efter interntestning kan pilot- eller betatestningstrin forekomme, hvor softwaren stilles til rådighed for små grupper af "rigtige" brugere, der opfordres til at bruge produktet gratis eller til en betydelig rabat, til gengæld for detaljeret brugs feedback.
Ingen fejl, ingen stress - Din trinvis vejledning til oprettelse af livsændrende software uden at ødelægge dit liv
Du kan ikke forbedre dine programmeringsevner, når ingen er interesseret i softwarekvalitet.
Progressive UAT-stadier med forskellige målgrupper øger tilliden til softwarebrugervenlighed. Kombineret med faser af iterativ udvikling kan flere UAT-cyklusser udføres for at teste nye funktioner, når de leveres, mens de tidligere funktionaliteter verificeres.
Gode UAT-testere er nysgerrige efter at se, hvad der sker, hvis de kører forskellige ruter til et bestemt mål. Når alt kommer til alt nærmer alle sig brugen af software på forskellige måder, så hvis mange muligheder kan dækkes af en lille gruppe mennesker, er softwarens tillid i driftsform højere.
Succes og svigt
UAT-processer skal verificere, at hver type softwarebruger får de konkrete resultater, der kræves til både succes- og fiasko-strømme.
I en successtrøm går en slutbruger væk med et forventet resultat, såsom at placere en produktordre. I en fejlstrøm understøtter softwaren slutbrugeren gennem en form for fejlscenario, f.eks. Når en kunde leverer ugyldige kreditkortoplysninger.
For at verificere funktionaliteten skal nogle oplysninger leveres til testere. Ellers ved de ikke, hvad softwaren skal gøre. Men for at teste brugervenligheden skal dette være minimalt - bare opgave eller krav baseret, såsom at købe "x" (produkt) og betale "y" (ved hjælp af kreditkortoplysninger). Onus skal placeres på testere for at registrere observationer, succeser og fiaskoer.
UAT-fordele
En vigtig fordel ved god UAT er, at det holder de løbende vedligeholdelsesomkostninger så lave som muligt. Det er billigere at løse problemer med funktionalitet og brugervenlighed tidligt. Det er meget sværere at rette en fejl, når der er mere kode omkring den til regressionstest, eller hvis den oprindelige udvikler ikke er tilgængelig.
UAT, der udføres i flere faser og med forskellige typer testmålgrupper, giver optimale muligheder for at identificere og reparere ødelagte funktioner / brugervenlighedsproblemer i de tidlige faser af testen. At holde UAT-mål på opgave- og kravniveau gør det muligt for testere at observere og bemærke meget mere og endda forsøge trin uden for udviklerens angivne omfang.
Feedback fra UAT-cyklusser kan indføres i efterfølgende iterationer af udvikling, hvilket øger softwarens robusthed og brugervenlighed. Tidsbestemt, selv betatestfaser kan komplementere markedsførings- og salgsaktiviteter ved at give referencer og feedback fra casestudier.