Slik tester du appen din før lansering: en praktisk plan

For å teste appen din før lansering lister du opp de få flytene en bruker må kunne fullføre, kjører hver av dem som en helt ny bruker på laptop og telefon, og prøver deretter måtene de kan gå galt på: tomme data, dårlig input, en andre konto, en treg forbindelse. Test alt som involverer penger eller private data med ekstra forsiktighet, og gjenta hovedflytene på den live adressen etter publisering. Avslutt med å se på at noen som aldri har sett appen prøver å bruke den.

Du trenger ingen QA-avdeling eller testrammeverk til dette. Du trenger en liste, en til to timer, og disiplinen til faktisk å klikke deg gjennom den.

Steg 1: Skriv ned flytene som betyr noe

En flyt er en oppgave fra start til slutt som en bruker kommer for å gjøre. De fleste apper har tre til seks som virkelig betyr noe. For en bookingapp:

1. Registrere seg og bekrefte kontoen
2. Finne en time og booke den
3. Avbestille en booking
4. Betale for et timekort
5. Ansatt: se dagens bookinger

Hvis du har skrevet brukerhistorier, er akseptansekriteriene deres allerede testtilfellene dine. Hvis ikke, skriv én linje per flyt med hva «suksess» ser ut som.

Rangér dem. Flytene som tjener penger eller som alle brukere møter (registrering, innlogging, kjernehandlingen) testes først og mest.

Steg 2: Test den gode veien som en ny bruker

Den «gode veien» er flyten som går nøyaktig slik den var tenkt. Test den slik en fremmed ville opplevd den:

• Bruk et privat nettleservindu, slik at du ikke er innlogget og ikke har lagrede data.
• Bruk en ny konto med en ekte e-postadresse du kan sjekke.
• Start fra forsiden eller en lenke, ikke en side du bokmerket mens du bygget.

Nye brukere har ingen data. Mange feil dukker bare opp når en liste er tom, en profil mangler bilde, eller ingenting er kjøpt ennå. Din egen konto, full av testdata, skjuler dem.

Steg 3: Prøv å ødelegge det

Gjenta nå hver flyt og gjør det feil med vilje.

Oppdatering er verdt å nevne: hvis appen fungerer når du klikker deg gjennom, men en oppdatering på en dypere side gir 404, se slik fikser du 404-feil etter publisering.

Steg 4: Test tilganger med to kontoer

Dette er den viktigste testen for enhver app med kontoer, og den som oftest hoppes over.

Opprett to vanlige brukere, A og B, og (hvis appen din har dem) en admin.

• Som A, opprett en post. Logg inn som B. Kan B se den, redigere den eller slette den? Det skal de ikke, med mindre det er meningen.
• Som A, kopier adressen til en av postene dine. Logg inn som B og åpne den adressen direkte.
• Som en vanlig bruker, åpne adminsider ved å skrive inn adressene deres.
• Logg helt ut, og prøv de samme adressene.

Hvis du finner et problem her, ikke lanser før det er fikset. Sjekken må skje på serveren, ikke bare ved å skjule en knapp. Vår sikkerhetssjekkliste for AI-bygde apper går dypere.

Steg 5: Test på ekte enheter

Åpne appen på en faktisk telefon, ikke bare i et smalt nettleservindu.

• Kan du trykke på hver knapp uten å zoome?
• Dekker tastaturet feltet du skriver i?
• Scroller tabeller og bredt innhold, eller bryter de linjer, i stedet for å dytte siden sidelengs?
• Er teksten lesbar uten å klype?

Prøv minst én iPhone (Safari) og én Android-telefon (Chrome) hvis du kan låne dem. Safari har spesielt sine egne særheter med datoer, video og elementer med fast posisjon.

Steg 6: Test penger og e-post fra start til slutt

Alt som belaster kort eller sender e-post trenger en fullstendig gjennomkjøring.

Betalinger. Bruk betalingsleverandørens testmodus og testkortnumre. Sjekk en vellykket betaling, et avvist kort og en avbrutt kasse. Bekreft at bestillingen eller abonnementet vises i appen din etter betaling, ikke bare i leverandørens dashbord. Hvis appen din er avhengig av webhooks (meldinger betalingsleverandøren sender til serveren din), sjekk at de kommer frem i den publiserte appen, ikke bare i utvikling. Deretter, før lansering, bytt til live-nøkler og gjør ett lite ekte kjøp som du refunderer.

E-post. Registrer deg med ekte adresser hos to eller tre ulike leverandører. Sjekk at e-postene kommer frem, ikke havner i spam, og at hver lenke i dem peker til det live domenet, ikke en forhåndsvisningsadresse.

Steg 7: Sjekk hastighet og feil

• Åpne nettleserens utviklerverktøy (høyreklikk → Inspiser) og se på Konsoll-fanen på hver hovedside. Røde feil er verdt å fikse selv om ingenting ser ødelagt ut.
• Last inn siden på en telefon med mobildata, ikke Wi-Fi. Hvis første skjerm bruker flere sekunder, sjekk bildestørrelsene først.
• Kjør en gratis revisjon som Lighthouse i Chromes utviklerverktøy for en rask vurdering av ytelse og tilgjengelighet.

Steg 8: Test den publiserte appen, ikke bare forhåndsvisningen

En forhåndsvisning og en publisert app er ikke det samme miljøet. Før du forteller noen om lanseringen, gjenta hovedflytene på den live adressen:

• Er alle miljøvariabler og hemmeligheter satt for den publiserte appen?
• Bruker den riktig database, med dataene du forventer?
• Bruker innloggingsomdirigeringer og e-postlenker det live domenet?
• Laster en oppdatering på en dyp side riktig?

Steg 9: Se på at noen andre bruker den

Gi én eller to personer et mål («book en yogatime lørdag»), ikke instruksjoner. Se på, ikke hjelp, og skriv ned hvor de nøler. Det er den raskeste måten å finne forvirrende formuleringer og skjulte knapper. For en større versjon av dette, se slik gjennomfører du en betatest.

Når de støter på en feil, skriv den ned ordentlig, med trinn, forventet resultat og faktisk resultat. Vår guide om å skrive en god feilrapport viser formatet.

Bruk AI til å hjelpe med testing

Hvis du bygger med AI, kan du be den hjelpe med å planlegge og kjøre tester:

List opp hovedflytene for brukere i denne appen, og for hver av dem kantsituasjonene som mest sannsynlig går i stykker: tomme tilstander, ugyldig input, tilganger og oppdatering. Sett det opp i en sjekkliste jeg kan gå gjennom.

Logg inn med to ulike testbrukere og sjekk om bruker B kan se eller endre noe som bruker A opprettet, også ved å åpne A sine postadresser direkte. Rapporter det du finner før du fikser noe.

Behandle AI-ens egen testrapport som et første gjennomsyn. Klikk fortsatt gjennom penge- og tilgangsflytene selv.

Testing i Mythex

I Mythex kjører kommandoen /test App Testing: agenten styrer en nettleser mot den live forhåndsvisningen, klikker seg gjennom sider, tar skjermbilder og rapporterer ødelagte flyter i chatten. Den fungerer best med en bestemt flyt, for eksempel «test registrering og booking av en time». Fiks det den finner med /fix eller en vanlig melding, og kjør deretter /test igjen. App Testing bruker forhåndsvisningen, så sjekk hovedflytene på den publiserte adressen selv etter publisering. Se App Testing i dokumentasjonen, og vår guide om feilsøking av en AI-bygd app for når noe feiler.

Vanlige feil

• Å teste bare som deg selv. Admin-kontoen din med mye data skjuler feil i tomme tilstander og tilganger.
• Å teste bare på laptop. De fleste besøkende på mange nettsider kommer via telefon.
• Å hoppe over den andre kontoen. Data som lekker mellom brukere er den alvorligste feilen en app kan lanseres med.
• Å stole på forhåndsvisningen. Den live appen har andre innstillinger; test den også.
• Å fikse feil uten å teste det som ligger nær. En endring i ett skjema kan ødelegge et annet som deler kode.

Sjekkliste før lansering

• Hovedflyter listet opp og rangert
• Hver flyt fungerer for en helt ny bruker i et privat vindu
• Tomme, ugyldige, lange og dupliserte input håndtert
• Oppdatering fungerer på hver side
• Brukere kan ikke se eller endre hverandres data, heller ikke via adresse
• Adminsider blokkert for vanlige brukere og utloggede besøkende
• Fungerer på en ekte iPhone og Android-telefon
• Betalinger testet: vellykket, avvist, avbrutt, og appen oppdateres etterpå
• E-poster kommer frem, unngår spam, og lenker til det live domenet
• Ingen røde feil i konsollen på hovedsidene
• Hovedflyter gjentatt på den publiserte adressen
• Minst én utenforstående har prøvd den mens du så på

Spørsmål