Så kör du en betatestning som ger användbara svar

Betatestning är det sista steget innan en app möter sin publik: du låter en utvald grupp använda en förhandsversion, fångar det som inte fungerar och rättar det innan lansering. Gjord rätt sparar den dig från att upptäcka pinsamma buggar när tusentals användare redan laddat ner appen. Gjord slarvigt blir den bara en formalitet som inte ger något.

Den här guiden tar upp hur betatestning fungerar ur din synvinkel som beställare: verktygen, hur lång tid det bör ta, hur många testare du behöver och hur du gör feedbacken användbar i stället för att den bara blir en hög av intryck.

Verktygen: TestFlight och Play Console

På de två plattformarna sköts betatestning på var sitt håll, men principen är densamma – en förhandsversion distribueras till testare innan den skarpa releasen.

• TestFlight är Apples lösning för iOS. Testare bjuds in och installerar appen via TestFlight-appen, och kan lämna feedback direkt. Det låter riktiga användare köra appen i sina egna telefoner före lansering.
• Play Consoles testspår är Androids motsvarighet. Här kan appen släppas till en intern grupp, en sluten krets eller ett öppet betaprogram, beroende på hur brett du vill testa. Testarna får appen genom Play precis som vanligt.

Skillnaden mot en demo på ett kontor är avgörande: appen körs på testarnas egna enheter, i deras vardag, med deras nät och deras handhavande. Det är där de verkliga problemen visar sig.

En praktisk sak att känna till är att spåren går att trappa upp. Ni kan börja med en helt intern grupp – teamet och några nära – för att fånga de grövsta felen, och sedan öppna för en bredare krets när appen stabiliserats. På Android är det särskilt värdefullt eftersom enheterna varierar så mycket i skärmstorlek, prestanda och version; en app som fungerar perfekt på en telefon kan bete sig annorlunda på en annan. Att testa brett innan lansering är ofta enda sättet att upptäcka det.

Rätt period och rätt grupp

Två frågor återkommer: hur länge, och hur många. Svaret på båda är att lagom slår mycket.

En betaperiod på ett par veckor är ofta rätt. Tillräckligt länge för att testarna ska hinna använda appen på riktigt, men inte så länge att engagemanget rinner ut. När det gäller antal slår kvalitet kvantitet: en mindre grupp som verkligen använder appen och rapporterar genomtänkt är mer värd än hundratals som installerar och glömmer bort den. Välj testare som liknar den tänkta målgruppen – de hittar de problem som betyder något.

Ett konkret scenario

Säg att du ska lansera en bokningsapp. Du bjuder in tjugo testare via TestFlight och Play, personer som liknar era framtida användare, och ber dem genomföra en riktig bokning under två veckor. Redan första dagarna märker ni att flera fastnar på samma steg i betalningsflödet – något ni själva aldrig snubblat på, eftersom ni visste hur det var tänkt. Ni rättar det, testarna bekräftar att det löste sig, och lanseringen sker med ett flöde som faktiskt fungerar för nya användare. Just den sortens upptäckt är hela poängen med en beta.

Gör feedbacken användbar

Den vanligaste fällan är att samla in feedback lösryckt och sedan sitta med en hög intryck som är svår att göra något av. Struktur är det som gör skillnad.

Bestäm i förväg vad ni vill ha svar på, och ge testarna en enkel kanal att rapportera i. Samla in krascher automatiskt, så att tekniska fel fångas även när ingen orkar skriva om dem. Och skilj tydligt på två saker: buggar som ska rättas, och önskemål om nya funktioner som kan sparas till senare. Blandas de ihop drunknar de verkliga felen i en flod av idéer.

En sista sak: bestäm i förväg vad som avgör att appen är redo att släppas. Utan ett sådant mål riskerar betan att pågå i evighet, eller att avslutas godtyckligt bara för att tiden är slut. Ett rimligt kriterium kan vara att de allvarliga buggarna är åtgärdade, att testarna genomför sina kärnuppgifter utan att fastna, och att inga nya krascher dyker upp under de sista dagarna. När de villkoren är uppfyllda är det dags att lansera – inte förr, och inte långt senare.

Med det på plats blir betatestningen vad den ska vara: en sista kontroll som fångar problemen medan de fortfarande är billiga att laga. Vi på Weapp bygger in beta som ett naturligt steg före lansering. Vill du veta hur ett upplägg kan se ut för din app kan du läsa mer om våra tjänster eller höra av dig.