Acceptanstest – så vet du att appen håller måttet

När byrån säger att appen är klar börjar ditt jobb. Acceptanstest är beställarens egen kontroll av att leveransen faktiskt gör det som avtalats, innan du godkänner den och betalar slutfakturan. Skillnaden mot att “klicka runt lite och se om det funkar” är strukturen: du testar mot något bestämt, med rätt personer, och fattar godkännandebeslutet på fakta i stället för på känsla.

Från acceptanskriterier till testfall

Grunden för ett acceptanstest ligger redan i kravspecen, i de acceptanskriterier ni satte upp för vad appen ska klara. Problemet är att kriterier ofta är formulerade övergripande, och sådana går inte att testa rakt av. Steget är att göra om varje kriterium till ett konkret testfall.

Ett kriterium som “användaren kan boka en tid” blir ett testfall med tydliga steg: logga in, välj tjänst, välj ledig tid, bekräfta, och ett förväntat resultat, bokningen syns i mina bokningar och en bekräftelse kommer. Varje testfall ska ha förutsättningar, steg och ett förväntat utfall, så att den som kör det bara behöver konstatera om det stämmer eller inte.

Poängen är att ta bort tolkningsutrymmet. Ett bra testfall kan köras av vem som helst i verksamheten och ge samma svar: passerar eller passerar inte. Då blir godkännandet en summa av konkreta resultat, inte en allmän magkänsla om att appen “verkar bra”.

Organisera testperioden med rätt användare

Ett acceptanstest ska göras av dem som ska använda appen på riktigt, inte av projektledningen ensam. Verksamhetens egna användare känner det verkliga arbetsflödet och hittar problem som ingen annan ser, för de testar appen så som den faktiskt kommer att användas.

Lägg upp perioden med tydlig struktur:

• Avgränsa i tid. En bestämd testperiod med start och slut skapar fokus och ett datum att samla resultaten kring.
• Utse testare och roller. Vem testar vad? Fördela testfallen så att allt täcks och inget faller mellan stolarna.
• Ge en rapporteringskanal. Bestäm hur ett fynd ska rapporteras och vad beskrivningen ska innehålla: vad testaren gjorde, vad som hände och vad som förväntades.

En löst upplagd testperiod ger mest spridda synpunkter som är svåra att agera på. En strukturerad ger en lista med reproducerbara fynd som byrån kan rätta, och som du kan följa upp.

Klassa fynden och besluta vad som blockerar

Alla fynd är inte lika allvarliga, och att behandla dem som om de vore det leder fel. Antingen godkänner du en trasig app för att “det mesta funkar”, eller så fastnar du på detaljer och skjuter upp en fullt användbar lansering. Lösningen är att klassa fynden efter allvar.

Ett kritiskt fel, som att betalningen inte går igenom eller att inloggningen fallerar, ska stoppa godkännandet. Ett skönhetsfel eller ett önskemål om en extra funktion ska det inte, utan tas efter lansering. Genom att bestämma klassningen i förväg slipper du diskutera varje enskilt fynd i affekt när tidsplanen pressar.

Ett konkret scenario

Säg att ni acceptanstestar en bokningsapp. Testarna, som är personal som ska använda den dagligen, kör testfallen och rapporterar tolv fynd. Två är kritiska: en bokning dubbelbokas ibland, och bekräftelsen uteblir vid ett visst flöde. Resten är mindre: en knapp sitter snett, en text är otydlig. Beslutet blir enkelt tack vare klassningen: de två kritiska måste rättas innan godkännande, resten hanteras efter lansering. Du godkänner alltså inte en trasig app, men fastnar heller inte på detaljer.

Ett skarpt acceptanstest bygger på en tydlig kravspec med testbara kriterier. Läs mer om hur vi arbetar med krav och leverans bland våra tjänster, eller hör av dig om du vill ha stöd i att lägga upp testet.