Slik kjører du en betatest for appen din

For å kjøre en betatest må du bestemme hva du trenger å lære, invitere en liten gruppe mennesker som passer til dine reelle brukere, gi dem en tydelig første oppgave, og samle tilbakemeldinger på ett sted etter en fast plan. Fiks det som hindrer dem, utvid gruppen i runder, og avslutt betaen når et sett med utgangskriterier du skrev på forhånd er oppfylt — ikke når tålmodigheten tar slutt.

En beta er ikke en myk lansering. Den er et strukturert eksperiment med en start, en slutt og et spørsmål som skal besvares.

Hvor en beta passer

Validering spør om problemet er verdt å løse. En beta stiller et smalere spørsmål: løser denne versjonen av produktet problemet for ekte folk, under ekte forhold? Lansering kommer etterpå, når svaret i stor grad er ja.

Før du inviterer noen, gjør din egen testing først — slik tester du appen din før lansering dekker det. Testerne skal ikke være de som oppdager at registreringen er ødelagt.

Steg 1: Skriv ned hva betaen må svare på

Velg to eller tre spørsmål. Alt annet i planen følger av dem.

Oppdiktet eksempel: en app for vaktplanlegging for små kafeer setter to mål: «Kan en leder publisere en ukes vaktliste i første økt uten hjelp?» og «Åpner de ansatte appen selv i uke to?»

Steg 2: Velg type beta

For et første produkt er en lukket beta med noen runder vanligvis det riktige valget.

Steg 3: Rekrutter de riktige testerne

De beste testerne har problemet nå, passer til din målbruker og har tid til å prøve appen i betaperioden. Steder å finne dem:

• Ventelisten eller e-postlisten din — se slik bygger du et publikum før lansering.
• Folk du intervjuet under validering.
• Nisjefellesskap der brukerne dine samles, og som følger reglene for promotering.
• Direkte invitasjoner til personer i nettverket ditt som passer profilen.

Still noen siktingsspørsmål så du kan velge en miks: rolle, hvordan de løser problemet i dag, hvilken enhet de ville brukt, og hvor ofte problemet dukker opp. Inviter folk hvis svar stemmer med målbrukeren din, og unngå å fylle betaen med andre gründere med mindre de er målbrukeren.

Invitasjonsmal

Hei [navn] — du nevnte [problem] da du registrerte deg. Jeg åpner en liten privat beta av [produkt], som [resultat]. Den går fra [start] til [slutt]. Jeg ber testerne bruke det til [reell oppgave] minst én gang i uken og svare på en kort innsjekk hver fredag. Til gjengjeld får du gratis tilgang under betaen og [grunnleggerpris / utvidet gratisperiode]. Interessert?

Oppgi tidsforpliktelsen ærlig. Folk som vet hva de har meldt seg på, gir bedre tilbakemeldinger.

Steg 4: Forbered betasettet

Før den første invitasjonen sendes, ha disse klare:

• En velkomstmelding med lenken, hvordan man logger inn, den første oppgaven å prøve, og hvordan man melder fra om problemer.
• En liste over kjente problemer, slik at testerne ikke rapporterer det samme ti ganger.
• Én tilbakemeldingskanal. Et skjema, en delt chatgruppe eller en e-postadresse — ett sted, ikke fem.
• En mal for feilrapporter. Be om hva de gjorde, hva de forventet, hva som skjedde, enhet og nettleser, og et skjermbilde. Slik skriver du en god feilrapport har en versjon du kan dele.
• Enkel analyse eller logger, slik at du kan se hva som skjedde uten å stole på hukommelsen.
• Tydelige forventninger om data. Si fra hvis data kan bli nullstilt under betaen, og be ikke testerne legge inn sensitiv informasjon i en ufullstendig app.
• Grunnleggende vilkår og personvern. En kort betaavtale og en personvernmerknad; sjekk lokale regler eller en rådgiver hvis du håndterer personopplysninger.

Steg 5: Kjør den i runder

Runder lar deg fikse problemer før flere støter på dem.

I runde 1 ber du to eller tre testere dele skjermen sin mens de prøver appen for første gang. Vær stille og se hvor de nøler. Dette er ofte den mest nyttige timen i hele betaen.

Steg 6: Samle tilbakemeldinger i en rytme

Ustrukturerte «noen tilbakemeldinger?»-meldinger gir vage svar. Bruk en kort, regelmessig innsjekk i stedet:

Ukentlig innsjekk (oppdiktede eksempelspørsmål)

1. Hva brukte du [produkt] til denne uken?
2. Hva var frustrerende eller forvirrende?
3. Manglet noe som stoppet deg fra å fullføre en oppgave?
4. Hvordan ville du følt deg om du ikke lenger kunne bruke det? (Svært skuffet / litt / ikke i det hele tatt)
5. Noe annet?

Kombiner det folk sier med det de gjør. Noen som sier at det er flott, men aldri logger inn, forteller deg også noe.

Steg 7: Prioriter det som kommer inn

Sett all tilbakemelding i én liste og sorter den ukentlig.

Unngå å legge til store funksjoner midt i betaen. Hver ny funksjon gjør det vanskeligere å se om kjerneproduktet fungerer.

Steg 8: Lukk sløyfen

Testere fortsetter å gi tilbakemeldinger når de ser at de blir brukt.

• Send en kort endringslogg etter hver runde: «Du rapporterte X; det er fikset.»
• Takk folk med navn, privat, når rapporten deres førte til en løsning.
• Si fra til testerne når betaen slutter, hva som skjer med dataene og kontoen deres, og hva grunnleggertilbudet deres er.

Steg 9: Avgjør om dere er klare

Skriv utgangskriteriene før betaen starter, og sjekk dem ærlig på slutten. En mal:

• Ingen kjente blokkerere eller feil som sletter data
• De fleste nye testere fullfører kjerneoppgaven uten hjelp
• En betydelig andel av testerne kommer tilbake selv i senere uker
• De viktigste forvirringspunktene er fikset og testet på nytt
• Registrering, tilbakestilling av passord og eventuell betalingsflyt fungerer fra start til slutt
• Du har en klar melding om hvem produktet er for, i testernes egne ord

Hvis de fleste boksene er krysset av, gå videre til onboarding-polering og en offentlig lansering. Hvis bruken ved retur er lav, er det et produktspørsmål, ikke en feilliste — gå tilbake til intervjuene før lansering.

Kjøre en beta med Mythex

Hvis du bygger med Mythex, passer noen funksjoner godt til en beta:

• Forhåndsvisningslenker for runde 1. Knappen Share lager en lenke til den levende forhåndsvisningen din som fungerer for folk uten Mythex-konto, slik at en tidlig tester kan prøve ufullstendig arbeid før du publiserer. Lag én lenke per gruppe og slett den når du er ferdig — dokumentasjonen for forhåndsvisning forklarer hvordan lenker vekker prosjektet og bruker kreditter.
• Publiser for lengre runder. En publisert app kjører på sin egen adresse, noe som passer testere som bruker den over flere uker.
• App Testing før hver runde. Skriv /test i chatten, så klikker agenten seg gjennom forhåndsvisningen din og melder fra om ødelagte flyter, en nyttig sjekk før du inviterer noen (App Testing-dokumentasjonen).
• Sjekkpunkter. Hvis en fiks ødelegger noe midt i betaen, kan du gå tilbake til et tidligere sjekkpunkt.

Lim en testers feilrapport rett inn i chatten og be agenten reprodusere og fikse den, og fortell deretter testeren når det er live.

Spørsmål