Slik gjennomfører du en betatest som gir nyttige svar

Betatesting er det siste steget før en app møter publikummet sitt: Du lar en utvalgt gruppe bruke en forhåndsversjon, fanger opp det som ikke fungerer, og retter det før lansering. Gjort riktig sparer den deg for å oppdage pinlige feil når tusenvis av brukere allerede har lastet ned appen. Gjøres den slurvete, blir den bare en formalitet som ikke gir noe.

Denne guiden tar for seg hvordan betatesting fungerer sett fra deg som kunde: verktøyene, hvor lang tid det bør ta, hvor mange testere du trenger, og hvordan du gjør tilbakemeldingene nyttige i stedet for at de bare blir en haug med inntrykk.

Verktøyene: TestFlight og Play Console

På de to plattformene håndteres betatesting hver for seg, men prinsippet er det samme: En forhåndsversjon distribueres til testere før den endelige lanseringen.

• TestFlight er Apples løsning for iOS. Testere blir invitert og installerer appen via TestFlight-appen, og de kan gi tilbakemeldinger direkte. Det lar ekte brukere kjøre appen på sine egne telefoner før lansering.
• Testfunksjonene i Play Console er Androids motstykke. Her kan appen slippes til en intern gruppe, en lukket krets eller et åpent betaprogram, avhengig av hvor bredt du vil teste. Testerne får appen gjennom Google Play som vanlig.

Det som skiller dette fra en demo på et kontor, er avgjørende: Appen kjører på testernes egne enheter, i hverdagen deres, med nettet de har og slik de selv håndterer telefonen. Det er der de virkelige problemene viser seg.

En praktisk ting å vite er at testingen kan trappes opp. Dere kan begynne med en helt intern gruppe, teamet og noen i nærmeste krets, for å fange de groveste feilene, og deretter åpne for en bredere krets når appen har stabilisert seg. På Android er det spesielt verdifullt fordi enhetene varierer så mye i skjermstørrelse, ytelse og versjon. En app som fungerer perfekt på én telefon, kan oppføre seg annerledes på en annen. Å teste bredt før lansering er ofte den eneste måten å oppdage det på.

Riktig periode og riktig gruppe

To spørsmål går igjen: hvor lenge, og hvor mange. Svaret på begge er at passe slår mye.

En betaperiode på et par uker er ofte riktig. Lenge nok til at testerne rekker å bruke appen på ordentlig, men ikke så lenge at engasjementet dabber av. Når det gjelder antall, slår kvalitet kvantitet: En mindre gruppe som virkelig bruker appen og rapporterer gjennomtenkt, er mer verdt enn hundrevis som installerer og glemmer den. Velg testere som ligner den tiltenkte målgruppen. Det er de som finner problemene som betyr noe.

Et konkret scenario

Si at du skal lansere en bookingapp. Du inviterer tjue testere via TestFlight og Google Play, personer som ligner dem som skal bruke appen, og ber dem gjennomføre en ekte booking i løpet av to uker. Allerede de første dagene merker dere at flere står fast på samme steg i betalingsflyten, noe dere selv aldri har snublet over fordi dere visste hvordan det var tenkt. Dere retter det, testerne bekrefter at det løste seg, og lanseringen skjer med en flyt som faktisk fungerer for nye brukere. Akkurat den typen oppdagelse er hele poenget med en betatest.

Gjør tilbakemeldingene nyttige

Den vanligste fellen er å samle inn tilbakemeldinger løsrevet og så sitte igjen med en haug inntrykk som er vanskelig å gjøre noe med. Det er strukturen som gjør forskjellen.

Bestem på forhånd hva dere vil ha svar på, og gi testerne en enkel kanal å rapportere i. Samle inn krasj automatisk slik at tekniske feil fanges opp også når ingen orker å skrive om dem. Og skill tydelig mellom to ting: feil som skal rettes, og ønsker om nye funksjoner som kan vente til senere. Blandes de sammen, drukner de virkelige feilene i en flom av ideer.

En siste ting: Bestem på forhånd hva som avgjør at appen er klar til å slippes. Uten et slikt mål risikerer dere at betatesten varer evig, eller at den avsluttes vilkårlig bare fordi tiden er ute. Et fornuftig kriterium kan være at de alvorlige feilene er rettet, at testerne gjennomfører kjerneoppgavene sine uten å stå fast, og at ingen nye krasj dukker opp de siste dagene. Når de betingelsene er oppfylt, er det på tide å lansere, ikke før og ikke lenge etter.

Med dette på plass blir betatestingen det den skal være: en siste kontroll som fanger opp problemene mens de fortsatt er billige å rette. Vi i Weapp bygger inn betatest som et naturlig steg før lansering. Vil du vite hvordan et opplegg kan se ut for appen din, kan du lese mer om tjenestene våre eller ta kontakt.