Sådan tester du din app før lancering: en praktisk plan

At teste din app før lancering handler om at liste de få forløb, en bruger skal kunne gennemføre, køre hvert enkelt som en helt ny bruger på en computer og en telefon, og derefter prøve de måder, de kan gå galt på: tomme data, forkert input, en anden konto, en langsom forbindelse. Test alt, der involverer penge eller private data, med ekstra omhu, og gentag de vigtigste forløb på den live URL efter udgivelse. Afslut med at se en person, der aldrig har set appen, prøve at bruge den.

Du har ikke brug for et QA-team eller et testframework til dette. Du har brug for en liste, en time eller to og disciplinen til faktisk at klikke dig igennem den.

Trin 1: Skriv de forløb ned, der betyder noget

Et forløb er en opgave fra start til slut, som en bruger kommer for at udføre. De fleste apps har tre til seks, der virkelig betyder noget. For en bookingapp:

Tilmeld dig og bekræft kontoen
Find et hold og book det
Annuller en booking
Betal for et klippekort
Personale: se dagens bookinger

Hvis du har skrevet brugerhistorier, er deres acceptkriterier allerede dine testcases. Hvis ikke, så skriv én linje pr. forløb med, hvad „succes“ ser ud som.

Prioritér dem. De forløb, der tjener penge, eller som alle brugere rammer (tilmelding, login, kerneaktionen), testes først og grundigst.

Trin 2: Test det ideelle forløb som en ny bruger

Det „ideelle forløb“ er forløbet, der går præcis som tiltænkt. Test det, som en fremmed ville opleve det:

Brug et privat browservindue, så du ikke er logget ind og ikke har gemte data.
Brug en frisk konto med en rigtig e-mail, du kan tjekke.
Start fra forsiden eller et link, ikke fra en side du har bogmærket, mens du byggede.

Nye brugere har ingen data. Mange fejl viser sig først, når en liste er tom, en profil ikke har et billede, eller der endnu ikke er købt noget. Din egen konto, fuld af testdata, skjuler dem.

Trin 3: Prøv at bryde det

Gentag nu hvert forløb, og gør det forkerte med vilje.

Prøv dette	Det du kontrollerer
Send formularer tomme, eller kun med mellemrum	Obligatoriske felter håndhæves, med en tydelig besked
Meget lang tekst, emoji, navne med accenter	Layoutet holder, og data gemmes korrekt
Forkerte formater: bogstaver i et telefonfelt, en dato i fortiden	Validering både på siden og på serveren
Dobbeltklik på send-knappen	Ingen dublerede ordrer eller bookinger
Browserens tilbageknap midt i et forløb	Ingen ødelagt tilstand eller tabte data
Opdater på hver side	Data bevares; ingen tom side eller 404
Log ud, og tryk derefter tilbage	Private sider vises ikke
To faner, der redigerer det samme	Det sidst gemte sletter ikke stille det første

Opdatering er værd at fremhæve: hvis appen virker, når du klikker dig igennem, men en opdatering på en dybere side viser en 404, så se sådan retter du 404-fejl efter udrulning.

Trin 4: Test rettigheder med to konti

Dette er den vigtigste test for enhver app med konti, og den, der oftest springes over.

Opret to normale brugere, A og B, og (hvis din app har dem) en administrator.

Som A, opret en post. Log ind som B. Kan B se den, redigere den eller slette den? Det bør B ikke, medmindre det er designet sådan.
Som A, kopiér URL'en til en af dine poster. Log ind som B, og åbn URL'en direkte.
Som en normal bruger, prøv at åbne admin-sider ved at skrive deres URL'er.
Log helt ud, og prøv de samme URL'er.

Hvis du finder et problem her, så lancér ikke, før det er rettet. Kontrollen skal ske på serveren, ikke kun ved at skjule en knap. Vores sikkerhedstjekliste for AI-byggede apps går dybere.

Trin 5: Test på rigtige enheder

Åbn appen på en rigtig telefon, ikke kun i et smalt browservindue.

Kan du trykke på alle knapper uden at zoome?
Dækker tastaturet det felt, du skriver i?
Scroller tabeller og bredt indhold, eller brydes de, i stedet for at skubbe siden sidelæns?
Er teksten læselig uden at knibe fingrene sammen?

Prøv mindst én iPhone (Safari) og én Android-telefon (Chrome), hvis du kan låne dem. Safari har især sine egne særheder med datoer, video og fixed-elementer.

Trin 6: Test betaling og e-mail fra start til slut

Alt, der opkræver kort eller sender e-mails, kræver en fuld gennemgang.

Betalinger. Brug din betalingsudbyders testtilstand og testkortnumre. Kontroller en vellykket betaling, et afvist kort og et afbrudt checkout. Bekræft, at ordren eller abonnementet vises i din app efter betaling, ikke kun på udbyderens dashboard. Hvis din app er afhængig af webhooks (beskeder, betalingsudbyderen sender til din server), så kontroller at de ankommer på den udgivne app, ikke kun i udviklingsmiljøet. Skift derefter til live-nøgler før lancering, og lav ét lille rigtigt køb, som du refunderer.

E-mails. Tilmeld dig med rigtige adresser hos to eller tre forskellige udbydere. Kontrollér, at e-mails ankommer, ikke havner i spam, og at hvert link i dem peger på den live adresse, ikke en forhåndsvisningsadresse.

Trin 7: Tjek hastighed og fejl

Åbn browserens udviklerværktøjer (højreklik → Undersøg), og kig på fanen Konsol på hver vigtig side. Røde fejl er værd at rette, selv om intet ser ud til at være i stykker.
Indlæs siden på en telefon med mobildata, ikke Wi-Fi. Hvis den første skærm tager flere sekunder, så kig først på billedstørrelserne.
Kør en gratis revision som Lighthouse i Chromes udviklerværktøjer for et hurtigt overblik over ydeevne og tilgængelighed.

Trin 8: Test den udgivne app, ikke kun forhåndsvisningen

En forhåndsvisning og en udgivet app er ikke det samme miljø. Før du fortæller nogen om lanceringen, skal du gentage de vigtigste forløb på den live URL:

Er alle miljøvariabler og hemmeligheder sat for den udgivne app?
Bruger den den rigtige database, med de data du forventer?
Bruger login-omdirigeringer og e-mail-links det live domæne?
Indlæses en opdatering på en dyb side korrekt?

Trin 9: Se en anden bruge den

Giv en eller to personer et mål („book en yogatime til lørdag“), ikke instruktioner. Observer, hjælp ikke, og skriv ned, hvor de tøver. Det er den hurtigste måde at finde forvirrende formuleringer og skjulte knapper. Til en større version af dette, se sådan kører du en betatest.

Når de rammer en fejl, så skriv den ordentligt ned med trin, forventet resultat og faktisk resultat. Vores guide til at skrive en god fejlrapport viser formatet.

Brug AI til at hjælpe dig med at teste

Hvis du bygger med AI, kan du bede den om at hjælpe med at planlægge og køre tests:

List de vigtigste brugerforløb i denne app, og for hvert af dem de kantsager, der oftest går i stykker: tomme tilstande, ugyldigt input, rettigheder og opdatering. Læg det i en tjekliste, jeg kan arbejde igennem.

Log ind med to forskellige testbrugere, og kontrollér om bruger B kan se eller ændre noget, som bruger A har oprettet, herunder ved at åbne A's postadresser direkte. Rapportér det, du finder, før du retter noget.

Betragt AI'ens egen testrapport som et første gennemløb. Klik stadig selv igennem betalings- og rettighedsforløbene.

Test i Mythex

I Mythex kører kommandoen /test App Testing: agenten styrer en browser mod din live forhåndsvisning, klikker sig igennem siderne, tager skærmbilleder og rapporterer ødelagte forløb i chatten. Den fungerer bedst med et bestemt forløb, for eksempel „test tilmelding og booking af et hold“. Ret det, den finder, med /fix eller en normal besked, og kør derefter /test igen. App Testing bruger forhåndsvisningen, så kontroller de vigtigste forløb på den udgivne URL selv efter udgivelse. Se App Testing i dokumentationen, og vores guide til fejlfinding i en AI-bygget app, når noget fejler.

Almindelige fejl

Kun at teste som dig selv. Din adminkonto med masser af data skjuler fejl i tomme tilstande og rettigheder.
Kun at teste på en computer. Mange besøgende på mange sites kommer fra en telefon.
At springe den anden konto over. Data, der lækker mellem brugere, er den alvorligste fejl en app kan lancere med.
At stole på forhåndsvisningen. Den live app har andre indstillinger; test den også.
At rette fejl uden at teste det omkringliggende. En rettelse i én formular kan ødelægge en anden, der deler kode.

Tjekliste før lancering

Vigtigste forløb listet og prioriteret
Hvert forløb består som en helt ny bruger i et privat vindue
Tomt, ugyldigt, langt og dubleret input håndteret
Opdatering virker på alle sider
Brugere kan ikke se eller ændre hinandens data, heller ikke via URL
Admin-sider blokeret for normale brugere og udloggede besøgende
Virker på en rigtig iPhone og Android-telefon
Betalinger testet: succes, afvisning, annullering, og appen opdateres bagefter
E-mails ankommer, undgår spam og linker til det live domæne
Ingen røde fejl i konsollen på vigtige sider
Vigtigste forløb gentaget på den udgivne URL
Mindst én udenforstående har prøvet den, mens du observerede

Spørgsmål

Hvor meget test har en lille app brug for før lancering?

Nok til at være sikker på, at de vigtigste forløb virker for en helt ny bruger på både computer og telefon, at brugere ikke kan se hinandens data, og at alt, der involverer penge, virker fra start til slut. For de fleste små apps er det nogle få fokuserede timer, ikke uger.

Har jeg brug for automatiserede tests til en MVP?

Ikke nødvendigvis. Manuel test af kerneforløbene fanger de fleste fejl, der forhindrer lancering. Automatiserede tests begynder at betale sig, når du ændrer appen ofte og vil vide hurtigt, at du ikke har ødelagt noget, der tidligere virkede.

Skal jeg teste på forhåndsvisningen eller på den live app?

Begge dele. Test grundigt i forhåndsvisningen, og gentag derefter de vigtigste forløb på den udgivne app, for manglende miljøvariabler, en anden database eller routing-indstillinger kan få den live version til at opføre sig anderledes.

Hvem bør teste min app ud over mig selv?

Mindst én person, der aldrig har set den. Giv dem et mål, ikke instruktioner, og observér uden at hjælpe. Byggere undgår ubevidst de stier, der bryder.