Så testar du din app före lansering: en praktisk plan

För att testa din app före lansering listar du de få flöden en användare måste kunna genomföra, kör vart och ett som en helt ny användare på dator och telefon, och provar sedan de sätt det kan gå fel på: tom data, felaktig inmatning, ett andra konto, en långsam uppkoppling. Testa allt som rör pengar eller privata uppgifter med extra noggrannhet, och upprepa huvudflödena på den levande webbadressen efter publicering. Avsluta med att se någon som aldrig har sett appen försöka använda den.

Du behöver inget QA-team eller testramverk för detta. Du behöver en lista, en timme eller två och disciplinen att faktiskt klicka igenom den.

Steg 1: Skriv ner de flöden som är viktiga

Ett flöde är en uppgift från start till slut som en användare kommer för att utföra. De flesta appar har tre till sex som verkligen spelar roll. För en bokningsapp:

Registrera dig och bekräfta kontot
Hitta en lektion och boka den
Avboka en bokning
Betala för ett klippkort
Personal: se dagens bokningar

Om du har skrivit användarberättelser är deras acceptanskriterier redan dina testfall. Om inte, skriv en rad per flöde med vad ”lyckat” innebär.

Rangordna dem. Flöden som ger intäkter eller som alla användare möter (registrering, inloggning, kärnåtgärden) testas först och mest.

Steg 2: Testa den lyckliga vägen som en ny användare

Den ”lyckliga vägen” är flödet som går exakt som tänkt. Testa den som en främling skulle uppleva den:

Använd ett privat webbläsarfönster, så att du inte är inloggad och saknar sparad data.
Använd ett nytt konto med en riktig e-postadress du kan kontrollera.
Börja från startsidan eller en länk, inte från en sida du bokmärkte under bygget.

Nya användare har ingen data. Många buggar syns först när en lista är tom, en profil saknar bild eller inget har köpts ännu. Ditt eget konto, fullt av testdata, döljer dem.

Steg 3: Försök att få det att gå sönder

Upprepa nu varje flöde och gör fel med avsikt.

Prova detta	Vad du kontrollerar
Skicka formulär tomma, eller med bara mellanslag	Obligatoriska fält tvingas fram, med ett tydligt meddelande
Mycket lång text, emojis, namn med accenter	Layouten håller, data sparas korrekt
Fel format: bokstäver i ett telefonfält, ett datum i det förflutna	Validering både i sidan och på servern
Dubbelklicka på skicka-knappen	Inga dubbla beställningar eller bokningar
Webbläsarens bakåtknapp mitt i ett flöde	Inget trasigt tillstånd eller förlorad data
Ladda om på varje sida	Data finns kvar; ingen tom sida eller 404
Logga ut och tryck sedan bakåt	Privata sidor visas inte
Två flikar som redigerar samma sak	Den senaste sparningen raderar inte tyst den första

Uppdatering är värd att nämna särskilt: om appen fungerar när du klickar dig igenom men en uppdatering på en djupare sida visar 404, se hur du åtgärdar 404-fel efter driftsättning.

Steg 4: Testa behörigheter med två konton

Detta är det viktigaste testet för varje app med konton, och det som oftast hoppas över.

Skapa två vanliga användare, A och B, och (om din app har det) en admin.

Som A, skapa en post. Logga in som B. Kan B se den, redigera den eller ta bort den? Det borde de inte, om det inte är avsikten i designen.
Som A, kopiera webbadressen till en av dina poster. Logga in som B och öppna den adressen direkt.
Som vanlig användare, öppna adminsidor genom att skriva deras webbadresser.
Logga ut helt och försök med samma adresser.

Om du hittar ett problem här, lansera inte förrän det är åtgärdat. Kontrollen måste ske på servern, inte bara genom att dölja en knapp. Vår säkerhetschecklista för AI-byggda appar går djupare.

Steg 5: Testa på riktiga enheter

Öppna appen på en faktisk telefon, inte bara i ett smalt webbläsarfönster.

Kan du trycka på varje knapp utan att zooma?
Täcker tangentbordet fältet du skriver i?
Scrollar tabeller och bred innehåll eller bryts de, i stället för att skjuta sidan åt sidan?
Är texten läsbar utan att nypa?

Prova minst en iPhone (Safari) och en Android-telefon (Chrome) om du kan låna dem. Safari har särskilt egna egenheter med datum, video och element med fast position.

Steg 6: Testa betalningar och e-post från början till slut

Allt som debiterar kort eller skickar e-post behöver en fullständig genomgång.

Betalningar. Använd din betalningsleverantörs testläge och testkortnummer. Kontrollera en lyckad betalning, ett nekat kort och en avbruten kassa. Bekräfta att beställningen eller prenumerationen visas i din app efter betalning, inte bara i leverantörens instrumentpanel. Om din app förlitar sig på webhooks (meddelanden som betalningsleverantören skickar till din server), kontrollera att de når fram på den publicerade appen, inte bara i utveckling. Byt sedan till skarpa nycklar före lansering och gör ett litet riktigt köp som du återbetalar.

E-post. Registrera dig med riktiga adresser hos två eller tre olika leverantörer. Kontrollera att e-post kommer fram, inte hamnar i skräppost, och att varje länk i dem pekar på den levande domänen, inte på en förhandsvisningsadress.

Steg 7: Kontrollera hastighet och fel

Öppna webbläsarens utvecklarverktyg (högerklicka → Inspektera) och titta på fliken Konsol på varje huvudsida. Röda fel är värda att åtgärda även om inget ser trasigt ut.
Ladda sajten på en telefon med mobildata, inte Wi-Fi. Om första skärmen tar flera sekunder, titta på bildstorlekar först.
Kör en gratis granskning som Lighthouse i Chromes utvecklarverktyg för en snabb bild av prestanda och tillgänglighet.

Steg 8: Testa den publicerade appen, inte bara förhandsvisningen

En förhandsvisning och en publicerad app är inte samma miljö. Innan du berättar för någon om lanseringen, upprepa huvudflödena på den levande webbadressen:

Är alla miljövariabler och hemligheter satta för den publicerade appen?
Använder den rätt databas, med den data du förväntar dig?
Pekar inloggningsomdirigeringar och e-postlänkar på den levande domänen?
Laddas en uppdatering på en djup sida korrekt?

Steg 9: Se någon annan använda den

Ge en eller två personer ett mål (”boka ett yogapass på lördag”), inte instruktioner. Titta, hjälp inte, och skriv ner var de tvekar. Det är det snabbaste sättet att hitta förvirrande formuleringar och dolda knappar. För en större version av detta, se hur du genomför ett betatest.

När de stöter på en bugg, skriv ner den ordentligt, med steg, förväntat resultat och faktiskt resultat. Vår guide om hur man skriver en bra buggrapport visar formatet.

Använd AI för att hjälpa dig testa

Om du bygger med AI kan du be den hjälpa till att planera och köra tester:

Lista de viktigaste användarflödena i den här appen och, för varje flöde, de kantfall som oftast går sönder: tomma lägen, felaktig inmatning, behörigheter och uppdatering. Sätt det i en checklista jag kan gå igenom.

Logga in med två olika testanvändare och kontrollera om användare B kan se eller ändra något användare A skapade, inklusive genom att öppna A:s postadresser direkt. Rapportera vad du hittar innan du åtgärdar något.

Betrakta AI:ns egen testrapport som ett första pass. Klicka fortfarande igenom pengar- och behörighetsflödena själv.

Testning i Mythex

I Mythex kör kommandot /test App Testing: agenten styr en webbläsare mot din levande förhandsvisning, klickar igenom sidor, tar skärmbilder och rapporterar trasiga flöden i chatten. Det fungerar bäst med ett specifikt flöde, till exempel ”testa registrering och bokning av en lektion”. Åtgärda det som hittas med /fix eller ett vanligt meddelande, och kör sedan /test igen. App Testing använder förhandsvisningen, så kontrollera huvudflödena på den publicerade webbadressen själv efter publicering. Se App Testing i dokumentationen, och vår guide om hur du felsöker en AI-byggd app för när något går fel.

Vanliga misstag

Att bara testa som dig själv. Ditt adminkonto med mycket data döljer buggar för tomma lägen och behörigheter.
Att bara testa på dator. Många besökare på många sajter kommer från en telefon.
Att hoppa över det andra kontot. Data som läcker mellan användare är den allvarligaste bugg en app kan lanseras med.
Att lita på förhandsvisningen. Den levande appen har andra inställningar; testa den också.
Att åtgärda buggar utan att testa närliggande delar igen. En rättning i ett formulär kan bryta ett annat som delar kod.

Checklista före lansering

Huvudflöden listade och rangordnade
Varje flöde fungerar för en helt ny användare i ett privat fönster
Tom, ogiltig, lång och dubblerad inmatning hanterad
Uppdatering fungerar på varje sida
Användare kan inte se eller ändra varandras data, inte ens via webbadress
Adminsidor blockerade för vanliga användare och utloggade besökare
Fungerar på en riktig iPhone och Android-telefon
Betalningar testade: lyckad, nekad, avbruten, och appen uppdateras efteråt
E-post kommer fram, undviker skräppost och länkar till den levande domänen
Inga röda fel i konsolen på huvudsidorna
Huvudflöden upprepade på den publicerade webbadressen
Minst en utomstående person har testat medan du tittat på

Frågor

Hur mycket testning behöver en liten app före lansering?

Tillräckligt för att vara säker på att huvudflödena fungerar för en helt ny användare på telefon och dator, att användare inte kan se varandras data, och att allt som rör pengar fungerar från början till slut. För de flesta små appar handlar det om några fokuserade timmar, inte veckor.

Behöver jag automatiska tester för en MVP?

Inte nödvändigtvis. Manuell testning av kärnflödena fångar de flesta buggar som stoppar en lansering. Automatiska tester blir värdefulla när du ändrar appen ofta och vill veta snabbt att du inte har brutit något som tidigare fungerade.

Ska jag testa i förhandsvisningen eller i den levande appen?

Båda. Testa grundligt i förhandsvisningen, och upprepa sedan huvudflödena i den publicerade appen, eftersom saknade miljövariabler, en annan databas eller routinginställningar kan få den levande versionen att bete sig annorlunda.

Vem bör testa min app förutom mig?

Minst en person som aldrig har sett den. Ge dem ett mål, inte instruktioner, och titta på utan att hjälpa. Byggare undviker omedvetet de vägar som går sönder.