Accepttest af din app: Sådan ved du at den holder mål
Accepttest er kundens egen kontrol af at appen gør det der er aftalt, og den laves før leverancen godkendes. Du omsætter acceptkriterierne fra kravspecifikationen til konkrete testcases, lader organisationens brugere teste i en afgrænset periode og klassificerer fundene efter alvor så kun reelle mangler blokerer godkendelsen.
Når bureauet siger at appen er færdig, begynder dit arbejde. Accepttest er kundens egen kontrol af at leverancen faktisk gør det der er aftalt før du godkender den og betaler slutfakturaen. Forskellen fra at “klikke lidt rundt og se om det virker” er strukturen: Du tester mod noget fastlagt, med de rigtige personer, og træffer beslutningen om godkendelse på fakta i stedet for på fornemmelse.
Fra acceptkriterier til testcases
Grundlaget for en accepttest ligger allerede i kravspecifikationen, i de acceptkriterier I satte op for hvad appen skal kunne. Problemet er at kriterier ofte er formuleret overordnet, og den slags kan ikke testes direkte. Næste skridt er at omsætte hvert kriterium til en konkret testcase.
Et kriterium som “brugeren kan booke en tid” bliver en testcase med klare trin (log ind, vælg ydelse, vælg ledig tid, bekræft) og et forventet resultat: Bookingen vises under mine bookinger, og der kommer en bekræftelse. Hver testcase skal have forudsætninger, trin og et forventet udfald så den der kører den, kun skal konstatere om det stemmer eller ej.
Pointen er at fjerne fortolkningsrummet. En god testcase kan køres af hvem som helst i organisationen og give det samme svar: består eller består ikke. Så bliver godkendelsen summen af konkrete resultater, ikke en generel mavefornemmelse af at appen “virker fin”.
Organiser testperioden med de rigtige brugere
En accepttest skal laves af dem der skal bruge appen i praksis, ikke af projektledelsen alene. Organisationens egne brugere kender det reelle arbejdsflow og finder problemer som ingen andre ser, for de tester appen sådan som den faktisk kommer til at blive brugt.
Tilrettelæg perioden med en klar struktur:
- Afgræns i tid. En fastlagt testperiode med start og slut skaber fokus og en dato at samle resultaterne om.
- Udpeg testere og roller. Hvem tester hvad? Fordel testcasene så alt er dækket og intet falder mellem to stole.
- Giv en kanal til rapportering. Bestem hvordan et fund skal rapporteres og hvad beskrivelsen skal indeholde: hvad testeren gjorde, hvad der skete og hvad der var forventet.
En løst tilrettelagt testperiode giver først og fremmest spredte synspunkter der er svære at handle på. En struktureret giver en liste med reproducerbare fund som bureauet kan rette, og som du kan følge op på.
Klassificer fundene og beslut hvad der blokerer
Ikke alle fund er lige alvorlige, og at behandle dem som om de var det, fører galt af sted. Enten godkender du en defekt app fordi “det meste virker”, eller også går du i stå på detaljer og udskyder en fuldt brugbar lancering. Løsningen er at klassificere fundene efter alvor.
| Klasse | Betydning for godkendelsen |
|---|---|
| Kritisk | Blokerer: En central funktion virker ikke |
| Alvorlig | Bør udbedres før lancering |
| Mindre | Rettes efter lancering |
| Ønske | Håndteres som videreudvikling |
En kritisk fejl, f.eks. at betalingen ikke går igennem eller at login fejler, skal stoppe godkendelsen. En kosmetisk fejl eller et ønske om en ekstra funktion skal ikke stoppe den, men tages op efter lanceringen. Ved at fastlægge klassificeringen på forhånd slipper du for at diskutere hvert enkelt fund i affekt når tidsplanen presser.
Et konkret scenarie
Lad os sige at I laver accepttest af en booking-app. Testerne, som er medarbejdere der skal bruge den dagligt, kører testcasene og rapporterer tolv fund. To er kritiske: En booking bliver indimellem dobbeltbooket, og bekræftelsen udebliver i et bestemt flow. Resten er mindre: En knap sidder skævt, en tekst er uklar. Beslutningen bliver enkel takket være klassificeringen: De to kritiske skal rettes før godkendelse, resten håndteres efter lancering. Du godkender altså ikke en defekt app, men går heller ikke i stå på detaljer.
En solid accepttest bygger på en klar kravspecifikation med testbare kriterier. Læs mere om hvordan vi arbejder med krav og levering under vores ydelser, eller kontakt os hvis du vil have hjælp til at tilrettelægge testen.
Ofte stillede spørgsmål
Hvad er en accepttest?
En accepttest er kundens strukturerede kontrol af at en leveret app lever op til det der er aftalt før den godkendes. Det er ikke udviklerens test, men jeres egen, lavet ud fra forretningens perspektiv. Formålet er at afgøre om leverancen reelt holder mål, i stedet for at klikke lidt rundt og håbe at alt virker.
Hvordan gør jeg acceptkriterier til testcases?
Tag hvert kriterium fra kravspecifikationen og omskriv det til en konkret testcase: hvad du gør, under hvilke forudsætninger og hvad der skal ske. Kriteriet "brugeren kan logge ind med MitID" bliver en trin-for-trin-case med et forventet resultat. Så kan hvem som helst køre testen og afgøre om den består eller ej, uden fortolkning.
Hvem bør deltage i accepttesten?
Organisationens egne brugere, dem der faktisk skal arbejde i appen. De finder problemer som hverken udviklere eller projektledelse ser fordi de kender det reelle arbejdsflow. Jo tættere testerne står på den hverdag appen skal understøtte, desto mere relevante bliver fundene og desto tryggere bliver godkendelsen.
Hvordan organiserer jeg en testperiode?
Afgræns den i tid, udpeg testere og giv dem testcasene og en klar kanal til at rapportere fund i. Sørg for at alle ved hvad der testes og hvordan et fund skal beskrives. En struktureret periode med ansvar og rapportering giver brugbare resultater mens et løst setup først og fremmest giver spredte synspunkter der er svære at handle på.
Hvilke fejl må stoppe en godkendelse?
Klassificer fundene efter alvor. Kritiske fejl der gør at en central funktion ikke virker, skal blokere godkendelsen. Mindre kosmetiske fejl eller ønsker skal ikke blokere, men håndteres efter lancering. Ved at skelne blokerende mangler fra resten undgår du både at godkende en defekt app og at gå i stå på detaljer.