Så genomför du ett betatest för din app

För att genomföra ett betatest bestämmer du vad du behöver lära dig, bjuder in en liten grupp som matchar dina verkliga användare, ger dem en tydlig första uppgift och samlar feedback på ett ställe enligt ett fast schema. Åtgärda det som hindrar dem, bred gruppen i omgångar och avsluta betatestet när en uppsättning utgångskriterier som du skrev i förväg är uppfyllda, inte när tålamodet tar slut.

Ett betatest är inte en mjuk lansering. Det är ett strukturerat experiment med en start, ett slut och en fråga som ska besvaras.

Var betatestet passar in

Validering frågar om problemet är värt att lösa. Ett betatest ställer en smalare fråga: löser den här versionen av produkten problemet för riktiga människor, under verkliga förhållanden? Lansering kommer efter det, när svaret i stort sett är ja.

Innan du bjuder in någon, gör din egen testning först. Så testar du din app före lansering beskriver det. Testare ska inte vara de som upptäcker att registreringen är trasig.

Steg 1: Skriv ner vad betatestet ska besvara

Välj två eller tre frågor. Allt annat i planen följer av dem.

Påhittat exempel: en schemaläggningsapp för småkaféer sätter två mål: ”Kan en chef publicera en veckas schema under sin första session utan hjälp?” och ”Öppnar personalen appen på egen hand i vecka två?”

Steg 2: Välj typ av betatest

För en första produkt är ett slutet betatest med några omgångar oftast rätt val.

Steg 3: Rekrytera rätt testare

De bästa testarna har problemet just nu, matchar din målanvändare och har tid att prova appen under betatestets period. Här hittar du dem:

• Din väntelista eller e-postlista. Se så bygger du en publik före lansering.
• Personer du intervjuade under valideringen.
• Nischade gemenskaper där dina användare samlas, med respekt för deras regler om marknadsföring.
• Direkta inbjudningar till personer i ditt nätverk som passar profilen.

Ställ några screeningfrågor så att du kan välja en blandning: deras roll, hur de löser problemet idag, vilken enhet de skulle använda och hur ofta problemet uppstår. Bjud in personer vars svar matchar din målanvändare, och undvik att fylla betatestet med andra grundare om de inte själva är målanvändaren.

Mall för inbjudan

Hej [namn], du nämnde [problem] när du registrerade dig. Jag öppnar ett litet privat betatest av [produkt], som [resultat]. Det pågår från [start] till [slut]. Jag ber testarna använda den för [verklig uppgift] minst en gång i veckan och svara på en kort uppföljning varje fredag. I utbyte får du gratis tillgång under betatestet och [grundarpris / förlängd gratisperiod]. Intresserad?

Ange tidsåtgången ärligt. Personer som vet vad de har anmält sig till ger bättre feedback.

Steg 4: Förbered betatestkitet

Innan första inbjudan går ut ska dessa vara klara:

• Ett välkomstmeddelande med länken, hur man loggar in, den första uppgiften att prova och hur man rapporterar problem.
• En lista över kända problem, så att testarna inte rapporterar samma sak tio gånger.
• En enda kanal för feedback. Ett formulär, en gemensam chattgrupp eller en e-postadress: ett ställe, inte fem.
• En mall för buggrapporter. Be om vad de gjorde, vad de förväntade sig, vad som hände, enhet och webbläsare samt en skärmbild. Så skriver du en bra buggrapport har en version du kan dela.
• Grundläggande analys eller loggar, så att du kan se vad som hände utan att förlita dig på minnet.
• Tydliga förväntningar kring data. Säg till om data kan återställas under betatestet, och be inte testarna lägga in känslig information i en oavslutad app.
• Grunder för villkor och integritet. Ett kort betatestavtal och en integritetsnotis; kontrollera lokala regler eller en rådgivare om du hanterar personuppgifter.

Steg 5: Kör det i omgångar

Omgångar låter dig åtgärda problem innan fler stöter på dem.

I omgång 1 ber du två eller tre testare att dela sin skärm medan de provar appen för första gången. Var tyst och titta var de tvekar. Det här är ofta den mest användbara timmen i hela betatestet.

Steg 6: Samla feedback i en rytm

Ostrukturerade meddelanden som ”någon feedback?” ger vaga svar. Använd i stället en kort, regelbunden uppföljning:

Veckouppföljning (påhittade exempelfrågor)

1. Vad använde du [produkt] till den här veckan?
2. Vad var frustrerande eller förvirrande?
3. Saknades något som hindrade dig från att slutföra en uppgift?
4. Hur skulle du känna dig om du inte längre kunde använda den? (Mycket besviken / lite / inte alls)
5. Något annat?

Kombinera det människor säger med det de gör. Någon som säger att den är bra men aldrig loggar in berättar också något.

Steg 7: Prioritera det som kommer in

Lägg all feedback i en lista och sortera den varje vecka.

Avstå från att lägga till stora funktioner mitt i betatestet. Varje ny funktion gör det svårare att se om kärnprodukten fungerar.

Steg 8: Stäng loopen

Testarna fortsätter ge feedback när de ser att den används.

• Skicka en kort changelog efter varje omgång: ”Du rapporterade X; det är åtgärdat.”
• Tacka personer vid namn, privat, när deras rapport ledde till en fix.
• Berätta för testarna när betatestet slutar, vad som händer med deras data och konto och vilket grunderbjudande de får.

Steg 9: Avgör om du är redo

Skriv utgångskriterierna innan betatestet startar och kontrollera dem ärligt i slutet. En mall:

• Inga kända blockerare eller buggar som förlorar data
• De flesta nya testare slutför kärnuppgiften utan hjälp
• En betydande andel av testarna kommer tillbaka på egen hand i senare veckor
• De största förvirringspunkterna är åtgärdade och testade igen
• Registrering, återställning av lösenord och eventuellt betalningsflöde fungerar från början till slut
• Du har ett tydligt budskap om vem produkten är till för, i testarnas egna ord

Är de flesta rutorna ikryssade, gå vidare till polering av onboarding och en offentlig lansering. Om användningen för tillbaka är låg är det en produktfråga, inte en buggförteckning. Gå då tillbaka till intervjuerna innan du lanserar.

Köra ett betatest med Mythex

Bygger du med Mythex passar några funktioner väl in i ett betatest:

• Förhandsgranskningslänkar för omgång 1. Knappen Dela skapar en länk till din levande förhandsgranskning som fungerar för personer utan Mythex-konto, så att en tidig testare kan prova ofärdigt arbete innan du publicerar. Skapa en länk per grupp och ta bort den när du är klar. Dokumentationen för förhandsgranskning förklarar hur länkar väcker projektet och använder krediter.
• Publicera för längre omgångar. En publicerad app körs på sin egen adress, vilket passar testare som använder den under flera veckor.
• App-testning före varje omgång. Skriv /test i chatten så klickar agenten igenom förhandsgranskningen och rapporterar trasiga flöden, en användbar kontroll innan du bjuder in någon (dokumentationen för app-testning).
• Checkpoints. Om en fix förstör något mitt i betatestet kan du återgå till en tidigare checkpoint.

Klistra in en testares buggrapport direkt i chatten och be agenten att återskapa och åtgärda den, och berätta sedan för testaren när det är live.

Frågor