Sådan kører du en betatest der giver brugbare svar

Betatest er det sidste trin før en app møder sit publikum: Du lader en udvalgt gruppe bruge en forhåndsversion, fanger det der ikke virker, og retter det før lanceringen. Gjort rigtigt sparer den dig for at opdage pinlige fejl når tusindvis af brugere allerede har downloadet appen. Gjort sjusket bliver den bare en formalitet der ikke giver noget.

Denne guide gennemgår hvordan betatest fungerer set fra din side som kunde: værktøjerne, hvor lang tid det bør tage, hvor mange testere du har brug for og hvordan du gør feedbacken brugbar i stedet for at den bare bliver en bunke indtryk.

Værktøjerne: TestFlight og Play Console

På de to platforme håndteres betatest hver for sig, men princippet er det samme: En forhåndsversion distribueres til testere før den egentlige release.

• TestFlight er Apples løsning til iOS. Testere bliver inviteret, installerer appen via TestFlight-appen og kan give feedback direkte. Så kan rigtige brugere køre appen på deres egne telefoner før lanceringen.
• Testsporene i Play Console er Androids modstykke. Her kan appen udgives til en intern gruppe, en lukket kreds eller et åbent betaprogram, afhængigt af hvor bredt du vil teste. Testerne får appen gennem Play helt som normalt.

Forskellen fra en demo på et kontor er afgørende: Appen kører på testernes egne enheder, i deres hverdag, med deres netværk og deres måde at bruge den på. Det er dér de reelle problemer viser sig.

En praktisk ting at vide er at sporene kan trappes op. I kan starte med en helt intern gruppe (teamet og nogle få tætte relationer) for at fange de groveste fejl og derefter åbne for en bredere kreds når appen er blevet stabil. På Android er det særligt værdifuldt fordi enhederne varierer så meget i skærmstørrelse, ydeevne og version. En app der fungerer perfekt på én telefon, kan opføre sig anderledes på en anden. At teste bredt før lanceringen er ofte den eneste måde at opdage det på.

Den rigtige periode og den rigtige gruppe

To spørgsmål går igen: hvor længe og hvor mange. Svaret på begge er at det passende slår det store.

En betaperiode på et par uger er ofte det rigtige. Længe nok til at testerne kan nå at bruge appen for alvor, men ikke så længe at engagementet løber ud i sandet. Når det gælder antal, slår kvalitet kvantitet: En mindre gruppe der virkelig bruger appen og rapporterer gennemtænkt, er mere værd end hundredvis der installerer og glemmer den. Vælg testere der ligner den tiltænkte målgruppe. De finder de problemer der betyder noget.

Et konkret scenarie

Lad os sige at du skal lancere en booking-app. Du inviterer tyve testere via TestFlight og Play, personer der ligner jeres fremtidige brugere, og beder dem gennemføre en rigtig booking i løbet af to uger. Allerede de første dage opdager I at flere går i stå på samme trin i betalingsflowet, noget I aldrig selv er snublet over fordi I vidste hvordan det var tænkt. I retter det, testerne bekræfter at problemet er løst, og lanceringen sker med et flow der faktisk virker for nye brugere. Netop den slags opdagelser er hele pointen med en beta.

Gør feedbacken brugbar

Den mest almindelige fælde er at indsamle feedback usystematisk og derefter sidde med en bunke indtryk der er svær at bruge til noget. Struktur er det der gør forskellen.

Beslut på forhånd hvad I vil have svar på, og giv testerne en enkel kanal at rapportere i. Indsaml nedbrud automatisk så tekniske fejl bliver fanget, også når ingen gider skrive om dem. Og skeln tydeligt mellem to ting: bugs der skal rettes, og ønsker om nye funktioner der kan gemmes til senere. Blandes de sammen, drukner de reelle fejl i en strøm af idéer.

En sidste ting: Beslut på forhånd hvad der afgør at appen er klar til at blive udgivet. Uden et sådant mål risikerer betaen at vare i en evighed eller at blive afsluttet vilkårligt bare fordi tiden er gået. Et rimeligt kriterium kan være at de alvorlige bugs er rettet, at testerne gennemfører deres kerneopgaver uden at gå i stå, og at der ikke dukker nye nedbrud op i de sidste dage. Når de betingelser er opfyldt, er det tid til at lancere. Ikke før, og ikke længe efter.

Med det på plads bliver betatesten det den skal være: en sidste kontrol der fanger problemerne mens de stadig er billige at rette. Vi hos Weapp bygger beta ind som et naturligt trin før lanceringen. Vil du vide hvordan et forløb kan se ud for din app, kan du læse mere om vores ydelser eller kontakte os.