Sådan kører du en beta-test af din app

For at køre en beta-test skal du beslutte, hvad du har brug for at lære, invitere en lille gruppe mennesker, der matcher dine rigtige brugere, give dem en klar første opgave og samle feedback ét sted efter en fast plan. Ret det, der blokerer dem, udvid gruppen i runder, og afslut betaen, når et sæt afslutningskriterier, du skrev på forhånd, er opfyldt – ikke når din tålmodighed slipper op.

En beta er ikke en blød lancering. Det er et struktureret eksperiment med en start, en slutning og et spørgsmål, der skal besvares.

Hvor en beta passer ind

Validering spørger, om problemet er værd at løse. En beta stiller et smallere spørgsmål: løser denne version af produktet det for rigtige mennesker, under rigtige forhold? Lancering kommer bagefter, når svaret for det meste er ja.

Før du inviterer nogen, så lav din egen test først – sådan tester du din app før lancering dækker det. Testere bør ikke være dem, der opdager, at tilmeldingen er ødelagt.

Trin 1: Skriv ned, hvad betaen skal besvare

Vælg to eller tre spørgsmål. Alt andet i planen følger af dem.

Opdigtet eksempel: en vagtplanlægningsapp til små caféer sætter to mål: "Kan en leder offentliggøre en uges vagtplan i sin første session uden hjælp?" og "Åbner medarbejderne appen af sig selv i uge to?"

Trin 2: Vælg betaens type

Til et første produkt er en lukket beta med få runder som regel det rigtige valg.

Trin 3: Rekrutter de rigtige testere

De bedste testere har problemet nu, passer til din målbruger og har tid til at prøve appen i betaperioden. Steder at finde dem:

• Din venteliste eller e-mailliste – se sådan bygger du et publikum før lancering.
• Personer, du interviewede under valideringen.
• Nicheforum, hvor dine brugere samles, og følg deres regler for promovering.
• Direkte invitationer til personer i dit netværk, der passer til profilen.

Stil nogle screeningsspørgsmål, så du kan vælge en blanding: deres rolle, hvordan de løser problemet i dag, hvilken enhed de ville bruge, og hvor ofte problemet opstår. Inviter personer, hvis svar matcher din målbruger, og undgå at fylde betaen med andre grundlæggere, medmindre de netop er målbrugeren.

Invitationsskabelon

Hej [navn] – du nævnte [problem], da du tilmeldte dig. Jeg åbner en lille, privat beta af [produkt], som [resultat]. Den kører fra [start] til [slut]. Jeg beder testerne bruge den til [reel opgave] mindst én gang om ugen og svare på et kort tjek-ind hver fredag. Til gengæld får du gratis adgang under betaen og [grundlæggerpris / forlænget gratis periode]. Har du lyst?

Angiv tidsforbruget ærligt. Folk, der ved, hvad de har tilmeldt sig, giver bedre feedback.

Trin 4: Forbered beta-kittet

Før den første invitation sendes, skal disse ting være klar:

• En velkomstbesked med linket, hvordan man logger ind, den første opgave at prøve, og hvordan man melder problemer.
• En liste over kendte problemer, så testerne ikke rapporterer det samme ti gange.
• Én feedbackkanal. En formular, en fælles chatgruppe eller en e-mailadresse – ét sted, ikke fem.
• En skabelon til fejlrapporter. Bed om, hvad de gjorde, hvad de forventede, hvad der skete, enhed og browser og et screenshot. Sådan skriver du en god fejlrapport har en version, du kan dele.
• Grundlæggende analyse eller logs, så du kan se, hvad der skete, uden at stole på hukommelse.
• Klare forventninger til data. Fortæl testerne, hvis data kan blive nulstillet under betaen, og bed dem ikke lægge følsomme oplysninger ind i en ufærdig app.
• Grundlæggende vilkår og privatliv. En kort betaaftale og en privatlivsnote; tjek lokale regler eller en rådgiver, hvis du håndterer persondata.

Trin 5: Kør den i runder

Runder lader dig rette problemer, før flere støder på dem.

I runde 1 skal du bede to eller tre testere dele deres skærm, mens de prøver appen for første gang. Hold dig stille, og se, hvor de tøver. Det er ofte den mest nyttige time i hele betaen.

Trin 6: Indsaml feedback i en fast rytme

Ustrukturerede "har du feedback?"-beskeder giver vage svar. Brug i stedet et kort, fast tjek-ind:

Ugentligt tjek-ind (opdigtede eksempelspørgsmål)

1. Hvad brugte du [produkt] til i denne uge?
2. Hvad var frustrerende eller forvirrende?
3. Manglede noget, der forhindrede dig i at færdiggøre en opgave?
4. Hvordan ville du have det, hvis du ikke længere kunne bruge det? (Meget skuffet / lidt / slet ikke)
5. Andet?

Kombinér det, folk siger, med det, de gør. Én, der siger, at det er fantastisk, men aldrig logger ind, fortæller dig også noget.

Trin 7: Prioritér det, der kommer ind

Samle al feedback på én liste, og sortér den ugentligt.

Modstå fristen til at tilføje store funktioner midt i betaen. Hver ny funktion gør det sværere at se, om kerneproduktet virker.

Trin 8: Luk løkken

Testere bliver ved med at give feedback, når de ser, at det bliver brugt.

• Send et kort changelog efter hver runde: "Du rapporterede X; det er rettet."
• Sig tak til folk ved navn, privat, når deres rapport førte til en rettelse.
• Fortæl testerne, når betaen slutter, hvad der sker med deres data og konto, og hvad deres grundlæggertilbud er.

Trin 9: Afgør, om du er klar

Skriv dine afslutningskriterier, før betaen starter, og tjek dem ærligt til sidst. En skabelon:

• Ingen kendte blokeringer eller databevarende fejl
• De fleste nye testere færdiggør kerneopgaven uden hjælp
• En betydelig andel af testerne vender tilbage af sig selv i de senere uger
• De vigtigste forvirringspunkter er rettet og testet igen
• Tilmelding, nulstilling af adgangskode og eventuelt betalingsflow virker fra start til slut
• Du har en klar besked om, hvem produktet er til, i testernes egne ord

Hvis de fleste felter er afkrydset, så gå videre til onboarding-finpudsning og en offentlig lancering. Hvis brugen efter tilmelding er lav, er det et produktspørgsmål, ikke en fejlliste – gå tilbage til interviews, før du lancerer.

At køre en beta med Mythex

Hvis du bygger med Mythex, passer nogle funktioner godt til en beta:

• Preview-links til runde 1. Knappen Share laver et link til dit live-preview, der virker for folk uden en Mythex-konto, så en tidlig tester kan prøve ufærdigt arbejde, før du publicerer. Lav ét link pr. gruppe, og slet det, når du er færdig – Preview-dokumentationen forklarer, hvordan links vækker projektet og bruger kreditter.
• Publicér til længere runder. En publiceret app kører på sin egen adresse, hvilket passer til testere, der bruger den over flere uger.
• App-test før hver runde. Skriv /test i chatten, og agenten klikker sig igennem dit preview og rapporterer ødelagte flows, et nyttigt tjek, før du inviterer nogen (App-test-dokumentationen).
• Checkpoints. Hvis en rettelse ødelægger noget midt i betaen, kan du rulle tilbage til et tidligere checkpoint.

Sæt en testers fejlrapport direkte ind i chatten, og bed agenten reproducere og rette den, og fortæl derefter testeren, når det er live.

Spørgsmål