Je app testen voor de lancering: een praktisch plan

Om je app te testen voor de lancering, maak je een lijst van de paar reizen die een gebruiker moet kunnen afronden, doorloop je elke reis als volledig nieuwe gebruiker op een laptop en een telefoon, en probeer je daarna de manieren waarop het mis kan gaan: lege gegevens, verkeerde invoer, een tweede account, een trage verbinding. Test alles wat met geld of privégegevens te maken heeft met extra zorg, en herhaal de belangrijkste reizen op de live URL na het publiceren. Sluit af door iemand te observeren die de app nog nooit heeft gezien terwijl die hem probeert te gebruiken.

Je hebt hiervoor geen QA-team of testframework nodig. Je hebt een lijst nodig, een uur of twee, en de discipline om er echt doorheen te klikken.

Stap 1: Schrijf de reizen op die ertoe doen

Een reis is een taak van begin tot eind die een gebruiker komt uitvoeren. De meeste apps hebben er drie tot zes die er echt toe doen. Voor een boekingsapp:

Aanmelden en het account bevestigen
Een les zoeken en boeken
Een boeking annuleren
Betalen voor een lespas
Personeel: de boekingen van vandaag bekijken

Als je gebruikersverhalen hebt geschreven, zijn hun acceptatiecriteria al je testgevallen. Zo niet, schrijf dan per reis één regel op met hoe „geslaagd” eruitziet.

Rangschik ze. De reizen die geld opleveren of die elke gebruiker doorloopt (aanmelden, inloggen, de kernactie) worden het eerst en het meest getest.

Stap 2: Test het ideale pad als nieuwe gebruiker

Het „ideale pad” is de reis die precies verloopt zoals bedoeld. Test hem zoals een vreemde hem zou ervaren:

Gebruik een privévenster van de browser, zodat je niet bent ingelogd en geen opgeslagen gegevens hebt.
Gebruik een nieuw account met een echt e-mailadres dat je kunt controleren.
Begin op de startpagina of via een link, niet op een pagina die je tijdens het bouwen hebt bewaard als bladwijzer.

Nieuwe gebruikers hebben geen gegevens. Veel bugs komen pas naar boven als een lijst leeg is, een profiel geen foto heeft of er nog niets is gekocht. Je eigen account, vol testgegevens, verbergt ze.

Stap 3: Probeer het stuk te maken

Herhaal nu elke reis en doe bewust het verkeerde.

Probeer dit	Wat je controleert
Formulieren leeg versturen, of met alleen spaties	Verplichte velden worden afgedwongen, met een duidelijke melding
Heel lange tekst, emoji’s, namen met accenten	De opmaak blijft kloppen, gegevens worden correct opgeslagen
Verkeerde formaten: letters in een telefoonveld, een datum in het verleden	Validatie op zowel de pagina als de server
Dubbelklik op de verzendknop	Geen dubbele bestellingen of boekingen
Browserterugknop midden in een flow	Geen kapotte status of verloren gegevens
Vernieuw elke pagina	Gegevens blijven behouden; geen lege pagina of 404
Uitloggen en dan terug drukken	Privépagina’s worden niet getoond
Twee tabbladen die hetzelfde bewerken	De laatste opslag wist de eerste niet stilzwijgend

Vernieuwen verdient extra aandacht: als de app werkt wanneer je erdoorheen klikt, maar een vernieuwing op een diepere pagina een 404 geeft, zie dan hoe los je 404-fouten op na het uitrollen.

Stap 4: Test rechten met twee accounts

Dit is de belangrijkste test voor elke app met accounts, en de test die het vaakst wordt overgeslagen.

Maak twee gewone gebruikers aan, A en B, en (als je app die heeft) een beheerder.

Maak als A een record aan. Log in als B. Kan B het zien, bewerken of verwijderen? Dat zou niet mogen, tenzij dat zo ontworpen is.
Kopieer als A de URL van een van je records. Log in als B en open die URL rechtstreeks.
Open als gewone gebruiker beheerpagina’s door hun URL in te typen.
Log helemaal uit en probeer dezelfde URL’s.

Als je hier een probleem vindt, lanceer dan niet voordat het is opgelost. De controle moet op de server gebeuren, niet alleen door een knop te verbergen. Onze beveiligingschecklist voor met AI gebouwde apps gaat dieper in op dit onderwerp.

Stap 5: Test op echte apparaten

Open de app op een echte telefoon, niet alleen in een smal browservenster.

Kun je elke knop aantikken zonder in te zoomen?
Bedekt het toetsenbord het veld waarin je typt?
Scrollen tabellen en brede inhoud, of lopen ze door naar de zijkant van de pagina?
Is de tekst leesbaar zonder te knijpen?

Probeer minstens één iPhone (Safari) en één Android-telefoon (Chrome) als je die kunt lenen. Safari heeft in het bijzonder eigen eigenaardigheden met datums, video en elementen met vaste positie.

Stap 6: Test geld en e-mail van begin tot eind

Alles wat kaarten belast of e-mails verstuurt, heeft een volledige doorloop nodig.

Betalingen. Gebruik de testmodus van je betaalprovider en testkaartnummers. Controleer een geslaagde betaling, een geweigerde kaart en een geannuleerd afrekenen. Bevestig dat de bestelling of het abonnement na de betaling in je app verschijnt, en niet alleen in het dashboard van de provider. Als je app afhankelijk is van webhooks (berichten die de betaalprovider naar je server stuurt), controleer dan dat ze aankomen op de gepubliceerde app, en niet alleen in de ontwikkelomgeving. Schakel daarna vóór de lancering over naar live-sleutels en doe één kleine echte aankoop die je terugbetaalt.

E-mails. Meld je aan met echte adressen bij twee of drie verschillende providers. Controleer of e-mails aankomen, niet in de spam terechtkomen, en of elke link erin naar het live domein wijst, niet naar een previewadres.

Stap 7: Controleer snelheid en fouten

Open de ontwikkeltools van de browser (klik met rechts → Inspecteren) en kijk op elke belangrijke pagina naar het tabblad Console. Rode fouten verdienen aandacht, ook als er niets kapot lijkt.
Laad de site op een telefoon met mobiele data, niet via wifi. Als het eerste scherm meerdere seconden duurt, kijk dan eerst naar de afmetingen van de afbeeldingen.
Voer een gratis audit uit, zoals Lighthouse in de ontwikkeltools van Chrome, voor een snelle indruk van prestaties en toegankelijkheid.

Stap 8: Test de gepubliceerde app, niet alleen de preview

Een preview en een gepubliceerde app zijn niet dezelfde omgeving. Voordat je iemand over de lancering vertelt, herhaal je de belangrijkste reizen op de live URL:

Zijn alle omgevingsvariabelen en geheimen ingesteld voor de gepubliceerde app?
Gebruikt hij de juiste database, met de gegevens die je verwacht?
Gebruiken inlogredirects en e-maillinks het live domein?
Laadt een vernieuwing op een diepe pagina correct?

Stap 9: Kijk hoe iemand anders hem gebruikt

Geef een of twee mensen een doel („boek een yogales voor zaterdag”), geen instructies. Kijk toe, help niet, en schrijf op waar ze aarzelen. Dit is de snelste manier om verwarrende teksten en verborgen knoppen te vinden. Voor een grotere versie hiervan, zie hoe voer je een bètatest uit.

Als ze op een bug stuiten, schrijf die dan goed op, met stappen, het verwachte resultaat en het werkelijke resultaat. Onze gids over een goed bugrapport schrijven laat het formaat zien.

AI gebruiken om te helpen testen

Als je met AI bouwt, kun je haar vragen om tests te plannen en uit te voeren:

Maak een lijst van de belangrijkste gebruikersreizen in deze app en noteer voor elk de randgevallen die het meest waarschijnlijk breken: lege staten, ongeldige invoer, rechten en vernieuwen. Zet het in een checklist die ik kan afwerken.

Log in als twee verschillende testgebruikers en controleer of gebruiker B iets kan zien of wijzigen dat gebruiker A heeft aangemaakt, ook door de record-URL’s van A rechtstreeks te openen. Rapporteer wat je vindt voordat je iets repareert.

Beschouw het testrapport van de AI als een eerste ronde. Klik de geld- en rechtenreizen zelf nog steeds door.

Testen in Mythex

In Mythex voert het commando /test App Testing uit: de agent bestuurt een browser tegen je live preview, klikt door pagina’s, legt schermafbeeldingen vast en meldt kapotte flows in de chat. Het werkt het best met één specifieke reis, zoals „test aanmelden en een les boeken”. Repareer wat het vindt met /fix of een gewoon bericht, en voer daarna /test opnieuw uit. App Testing gebruikt de preview, dus controleer na het publiceren zelf de belangrijkste reizen op de gepubliceerde URL. Zie App Testing in de docs, en onze gids over een met AI gebouwde app debuggen voor als er iets misgaat.

Veelgemaakte fouten

Alleen als jezelf testen. Je beheerdersaccount met veel gegevens verbergt bugs bij lege staten en rechten.
Alleen op een laptop testen. Veel websites krijgen de meeste bezoekers op een telefoon.
Het tweede account overslaan. Gegevens die tussen gebruikers lekken, zijn de ernstigste bug waarmee een app kan worden gelanceerd.
Vertrouwen op de preview. De live app heeft andere instellingen; test die ook.
Bugs repareren zonder de omliggende onderdelen opnieuw te testen. Een fix in het ene formulier kan een ander formulier breken dat dezelfde code deelt.

Checklist vóór de lancering

Belangrijkste reizen opgeschreven en gerangschikt
Elke reis slaagt als volledig nieuwe gebruiker in een privévenster
Lege, ongeldige, lange en dubbele invoer wordt afgehandeld
Vernieuwen werkt op elke pagina
Gebruikers kunnen elkaars gegevens niet zien of wijzigen, ook niet via de URL
Beheerpagina’s zijn geblokkeerd voor gewone gebruikers en uitgelogde bezoekers
Werkt op een echte iPhone en Android-telefoon
Betalingen getest: geslaagd, geweigerd, geannuleerd, en de app wordt daarna bijgewerkt
E-mails komen aan, belanden niet in spam en linken naar het live domein
Geen rode fouten in de console op de belangrijkste pagina’s
Belangrijkste reizen herhaald op de gepubliceerde URL
Minstens één buitenstaander heeft het geprobeerd terwijl jij toekeek

Veelgestelde vragen

Hoeveel testen heeft een kleine app nodig vóór de lancering?

Genoeg om zeker te zijn dat de belangrijkste gebruikersreizen werken voor een volledig nieuwe gebruiker op een telefoon en een laptop, dat gebruikers elkaars gegevens niet kunnen zien, en dat alles met geld van begin tot eind werkt. Voor de meeste kleine apps is dat een paar gerichte uren, geen weken.

Heb ik geautomatiseerde tests nodig voor een MVP?

Niet per se. Handmatig testen van de kernreizen vangt de meeste bugs op die de lancering zouden blokkeren. Geautomatiseerde tests gaan zich pas terugbetalen als je de app vaak verandert en snel wilt weten of je niets hebt stukgemaakt dat eerder werkte.

Moet ik de preview testen of de live app?

Beide. Test grondig in de preview en herhaal daarna de belangrijkste reizen op de gepubliceerde app, want ontbrekende omgevingsvariabelen, een andere database of routeringsinstellingen kunnen ervoor zorgen dat de live versie zich anders gedraagt.

Wie moet mijn app testen naast mijzelf?

Minstens één persoon die hem nog nooit heeft gezien. Geef die een doel, geen instructies, en kijk toe zonder te helpen. Bouwers vermijden onbewust de paden die kapotgaan.