Akseptansetest: Slik vet du at appen holder mål
Akseptansetest er kundens egen kontroll av at appen gjør det som er avtalt. Den gjøres før leveransen godkjennes. Du gjør akseptansekriteriene i kravspesifikasjonen om til konkrete testtilfeller, lar brukerne i virksomheten teste i en avgrenset periode og klassifiserer funnene etter alvorlighetsgrad. Da er det bare reelle mangler som stopper godkjenningen.
Når byrået sier at appen er ferdig, begynner jobben din. Akseptansetesten er kundens egen kontroll av at leveransen faktisk gjør det som er avtalt, og den gjøres før du godkjenner leveransen og betaler sluttfakturaen. Det som skiller den fra å «klikke litt rundt og se om det fungerer», er strukturen: Du tester mot noe bestemt, med de riktige personene, og tar godkjenningsbeslutningen på grunnlag av fakta i stedet for følelser.
Fra akseptansekriterier til testtilfeller
Grunnlaget for en akseptansetest ligger allerede i kravspesifikasjonen, i akseptansekriteriene dere satte opp for hva appen skal klare. Problemet er at kriteriene ofte er formulert overordnet, og slike kriterier kan ikke testes direkte. Neste steg er å gjøre hvert kriterium om til et konkret testtilfelle.
Et kriterium som «brukeren kan bestille time» blir et testtilfelle med tydelige steg (logg inn, velg tjeneste, velg ledig tid, bekreft) og et forventet resultat: Bestillingen vises under «Mine bestillinger», og det kommer en bekreftelse. Hvert testtilfelle skal ha forutsetninger, steg og et forventet utfall. Da trenger den som kjører det, bare å konstatere om det stemmer eller ikke.
Poenget er å fjerne rommet for tolkning. Et godt testtilfelle kan kjøres av hvem som helst i virksomheten og gi det samme svaret: bestått eller ikke bestått. Da blir godkjenningen summen av konkrete resultater, ikke en generell magefølelse av at appen «virker bra».
Organiser testperioden med de riktige brukerne
En akseptansetest skal gjøres av dem som skal bruke appen i hverdagen, ikke av prosjektledelsen alene. Virksomhetens egne brukere kjenner den reelle arbeidsflyten og finner problemer som ingen andre ser. De tester nemlig appen slik den faktisk kommer til å bli brukt.
Legg opp perioden med en tydelig struktur:
- Avgrens i tid. En fast testperiode med start og slutt skaper fokus og en dato å samle resultatene rundt.
- Utpek testere og roller. Hvem tester hva? Fordel testtilfellene slik at alt dekkes og ingenting faller mellom to stoler.
- Sørg for en kanal for rapportering. Bestem hvordan et funn skal rapporteres, og hva beskrivelsen skal inneholde: hva testeren gjorde, hva som skjedde, og hva som var forventet.
En løst organisert testperiode gir stort sett spredte innspill som er vanskelige å gjøre noe med. En strukturert periode gir en liste med reproduserbare funn som byrået kan rette, og som du kan følge opp.
Klassifiser funnene og bestem hva som blokkerer
Ikke alle funn er like alvorlige, og å behandle dem som om de var det, fører galt av sted. Enten godkjenner du en app med alvorlige feil fordi «det meste fungerer», eller så blir du sittende fast i detaljer og utsetter en fullt brukbar lansering. Løsningen er å klassifisere funnene etter alvorlighetsgrad.
| Klasse | Effekt på godkjenningen |
|---|---|
| Kritisk | Blokkerer: En sentral funksjon fungerer ikke |
| Alvorlig | Bør rettes før lansering |
| Mindre | Rettes etter lansering |
| Ønske | Håndteres som videreutvikling |
En kritisk feil, som at betalingen ikke går gjennom eller at innloggingen svikter, skal stoppe godkjenningen. En kosmetisk feil eller et ønske om en ekstra funksjon skal ikke det, men tas etter lansering. Ved å bestemme klassifiseringen på forhånd slipper du å diskutere hvert enkelt funn i opphetet stemning når tidsplanen presser.
Et konkret scenario
Si at dere akseptansetester en app for timebestilling. Testerne, ansatte som skal bruke den daglig, kjører testtilfellene og rapporterer tolv funn. To er kritiske: En time blir av og til dobbeltbooket, og bekreftelsen uteblir i en bestemt brukerflyt. Resten er mindre: En knapp sitter skjevt, en tekst er uklar. Beslutningen blir enkel takket være klassifiseringen: De to kritiske må rettes før godkjenning, resten håndteres etter lansering. Du godkjenner altså ikke en app med alvorlige feil, men blir heller ikke sittende fast i detaljer.
En grundig akseptansetest bygger på en tydelig kravspesifikasjon med testbare kriterier. Les mer om hvordan vi jobber med krav og leveranse blant tjenestene våre, eller ta kontakt hvis du vil ha hjelp til å legge opp testen.
Ofte stilte spørsmål
Hva er en akseptansetest?
En akseptansetest er kundens strukturerte kontroll av at en levert app oppfyller det som er avtalt, og den gjøres før appen godkjennes. Det er ikke utviklerens testing, men testingen dere selv gjør, ut fra virksomhetens perspektiv. Formålet er å avgjøre om leveransen virkelig holder mål, i stedet for å klikke litt rundt og håpe at alt fungerer.
Hvordan gjør jeg akseptansekriterier om til testtilfeller?
Ta hvert kriterium fra kravspesifikasjonen og skriv det om til et konkret testtilfelle: hva du gjør, med hvilke forutsetninger og hva som skal skje. Kriteriet «brukeren kan logge inn med BankID» blir et trinnvis testtilfelle med forventet resultat. Da kan hvem som helst kjøre testen og avgjøre om den består eller ikke, uten tolkning.
Hvem bør delta i akseptansetesten?
Virksomhetens egne brukere, de som faktisk skal jobbe i appen. De kjenner den reelle arbeidsflyten og finner derfor problemer som verken utviklere eller prosjektledelsen ser. Jo nærmere testerne står hverdagen appen skal støtte, desto mer relevante blir funnene, og desto tryggere blir godkjenningen.
Hvordan organiserer jeg en testperiode?
Avgrens den i tid, utpek testere, og gi dem testtilfellene og en tydelig kanal for å rapportere funn. Sørg for at alle vet hva som testes, og hvordan et funn skal beskrives. En strukturert periode med ansvar og rapportering gir brukbare resultater, mens et løst opplegg stort sett gir spredte innspill som er vanskelige å gjøre noe med.
Hvilke feil kan stoppe en godkjenning?
Klassifiser funnene etter alvorlighetsgrad. Kritiske feil som gjør at en sentral funksjon ikke fungerer, skal blokkere godkjenningen. Mindre kosmetiske feil eller ønsker skal ikke gjøre det, men håndteres etter lansering. Ved å skille blokkerende mangler fra resten unngår du både å godkjenne en app som ikke fungerer, og å bli sittende fast i detaljer.