Hoe je je met AI gebouwde app test als je nog nooit software hebt getest
Een praktische gids voor het testen van een met AI gebouwde app als je geen QA-achtergrond hebt. Waar te klikken, wat met opzet te breken, en hoe je weet wanneer hij goed genoeg is om te delen.
Je bouwde een app met AI. Hij werkt op het gelukkige pad — je typt je naam, klikt op de knop, ziet het successcherm. Wat nu? Is hij klaar om naar je drie betagebruikers te sturen? Je team? Je klanten?
Als je geen software-achtergrond hebt, voelt testen als een van die dingen die “echte ontwikkelaars” doen — met frameworks en asserties en CI-pijplijnen. Het goede nieuws: dat is niet wat het meeste testen eigenlijk is. Het meeste testen, vooral wanneer je iets kleins en nieuws lanceert, is één persoon die met bedoeling rondklikt. Dat kun je. Deze post gaat over het bewust doen, zodat je de bugs vindt voordat je gebruikers dat doen.
Het doel is niet om je met AI gebouwde app te testen als een prof. Het is om hem te testen als een paranoïde vriend die oprecht wil dat hij werkt.
De twee-lijsten-truc
Voordat je iets klikt, ga tien minuten zitten met een leeg document en schrijf twee lijsten.
Lijst A — de gelukkige paden. Wat zijn de drie of vier dingen die een gebruiker verondersteld wordt te doen met deze app? Voor een typische SaaS zou dat kunnen zijn: aanmelden, hun eerste project aanmaken, één teamgenoot uitnodigen, een resultaat exporteren. Voor een directory-achtige app: zoeken, filteren, op een listing klikken, hem opslaan. Drie of vier echte flows, in gewone taal.
Lijst B — de ongelukkige paden. Wat als de gebruiker iets bijna goed doet maar niet helemaal? Hun e-mail typt met een typefout. Midden in een flow op de terugknop drukt. Twee tabbladen opent en hetzelfde ding in beide bewerkt. Een leeg formulier indient. De inhoud van een Word-document — opmaak en al — in een tekstveld plakt. De laptop sluit en tien minuten later weer opent. Een teamgenoot probeert uit te nodigen met een e-mailadres dat al in het systeem bestaat.
De gelukkige-pad-lijst is wat je AI-appbouwer optimaliseerde. Het is wat de AI mentaal testte terwijl hij de code schreef. De ongelukkige-pad-lijst is waar de bugs leven, want bijna niemand — niet de AI, niet jij toen je aan het prompten was — dacht aan die gevallen.
Wanneer je echt test, loop eerst lijst A door om te bevestigen dat de basis werkt. Besteed dan het grootste deel van je tijd aan lijst B. Lijst B is waar de waarde zit. Lijst B is ook waar je erachter komt wat je de app echt wilt laten doen wanneer dingen misgaan, wat vaak een verhelderend gesprek met de AI-bouwer afdwingt (“wanneer het formulier half is ingevuld, moet het waarschuwen of automatisch opslaan?”).
Drie dingen om met opzet te breken
Zodra je je lijsten hebt, hier zijn drie categorieën die het merendeel van de echte bugs in met AI gebouwde apps vangen.
Lege en rare invoer. Dien het formulier in zonder iets in te vullen. Dien het in met één veld ingevuld. Dien een naam in van 500 tekens lang. Dien een naam met emoji in. Plak een URL in een veld dat een naam verwacht. Probeer het e-mailveld met “test”, met “test@”, met “test@example”, met het adres “a@b.co” — accepteert het legitieme korte e-mails? AI-appbouwers voegen vaak validatie toe, maar de validatie kan in beide richtingen verkeerd zijn — te strikt (weigert echte gebruikers) of te los (accepteert rommel).
Achteruit en zijwaarts gaan. De meeste apps werken prima als je er als een gehoorzame rondleidingsgroep doorheen loopt. Ze breken op het moment dat iemand verkent. Klik op de terugknop. Klik weer vooruit. Ververs de pagina midden in een flow. Open dezelfde pagina in twee tabbladen en bewerk in beide. Log uit en weer in. Als je een “ongedaan maken”-knop hebt, klik er drie keer achter elkaar op. Dit zijn geen randgevallen. Dit is hoe echte mensen software gebruiken.
De data daarna. Bouw het ding dat je app bouwt. Een project, een post, een record, wat dan ook. Kom dan morgen terug. Is het er nog steeds? Overleefde de opmaak het? Als je het bewerkt, slaat de bewerking op? Als je het verwijdert, is het echt weg, of komt het terug wanneer je ververst? AI-appbouwers krijgen vaak de “aanmaak”-flow voor elkaar en vergeten dat alles wat je aanmaakt moet blijven bestaan en later bewerkbaar moet zijn.
Hoe “goed genoeg” eruitziet
Je zult je met AI gebouwde app nooit tot perfectie testen. Software is te verstrengeld en je tijd is te waardevol. De vraag is niet “is hij perfect” — het is “is hij goed genoeg voor de volgende groep mensen die ik voor hem ga zetten”.
Hier is een ruwe hiërarchie die je kunt lenen.
Goed genoeg om te demonstreren: het gelukkige pad werkt zonder te crashen. Knoppen gaan waar ze horen. Je kunt een schermopname laten zien zonder iets eruit te knippen.
Goed genoeg voor vriendelijke gebruikers: de ongelukkige paden raken geen data kwijt. Formulieren vertellen je wat er mis is in plaats van stilletjes te falen. De pagina verversen breekt dingen niet. Drie vrienden kunnen het gebruiken zonder je een bericht te sturen voor hulp.
Goed genoeg voor betalende gebruikers: de app handelt gebruikers af die je nooit hebt ontmoet. Hun browsers, hun data, hun gewoonten. Je hebt een manier om te zien wanneer dingen breken (basale foutopsporing is genoeg — je hebt geen ingewikkeld dashboard nodig). Je kunt repareren en opnieuw deployen zonder de mensen die het al gebruiken te breken.
De meeste bouwers lanceren op het “vriendelijke gebruikers”-niveau en upgraden dan naarmate feedback binnenkomt. Dat is correct. De fout is proberen te springen van “goed genoeg om te demonstreren” rechtstreeks naar “goed genoeg voor betalende gebruikers” zonder de tussenstap. Vriendelijke gebruikers vinden dingen die echte gebruikers zouden vinden — maar ze worden er niet boos om. Gebruik dat gat.
Wanneer je de AI laat testen voor jou
Je AI-appbouwer kan helpen met testen, maar je moet specifiek zijn over wat je wilt. “Voeg tests toe” is een slechte prompt. Het genereert code die eruitziet als tests en waarschijnlijk slaagt, zonder echt iets te controleren waar je om geeft. De meeste van die automatisch gegenereerde tests bevestigen dat 1+1 nog steeds 2 is.
Een betere prompt: “Ik probeerde net het aanmeldformulier in te dienen met een leeg e-mailveld en het crashte. Vind waar dat wordt afgehandeld en voeg een check toe die in plaats daarvan een vriendelijke fout toont.” Specifieke bug, specifieke fix, specifieke uitkomst. De AI is hier goed in. Hij is slecht in “zorg dat mijn app bugvrij is”, want dat is geen taak — dat is een wens.
Het andere ding waar AI-bouwers goed in zijn, is je bug naspelen. Als je beschrijft wat je deed, wat je verwachtte, en wat er gebeurde, kan de bouwer meestal door de code traceren en een fix voorstellen. De discipline die je nodig hebt, is de discipline van die drie dingen helder opschrijven. De meeste beginner-bugmeldingen zijn een of andere versie van “het werkt niet”. De meeste oplosbare bugmeldingen zijn “ik klikte op X, verwachtte Y, kreeg Z”.
Testen is lezen, niet alleen klikken
Nog één ding. Je hoeft niet elke regel code in je met AI gebouwde app te begrijpen om hem goed te testen. Maar je zou hem op zijn minst moeten doorbladeren. Open het bestand dat de AI net veranderde. Lees de functie die hij toevoegde. Je hoeft niet te weten wat elk sleutelwoord betekent — je moet weten of de functie lijkt te doen wat je vroeg.
Veel met AI gebouwde bugs zijn niet “de code is kapot”. Het zijn “de code doet iets net iets anders dan wat je wilde”. Een veld slaat op naar de verkeerde plek. Een knop werkt het ene ding bij maar niet het gerelateerde ding. Een “verwijder”-knop verbergt in plaats van verwijdert. Je kunt die niet vangen zonder te lezen wat er echt werd gebouwd.
Behandel de code als iets dat je kunt auditen, niet iets dat je moet schrijven. Dat is het verschil tussen een met AI gebouwde app die je vertrouwt en een die je gewoon hoopt dat hij werkt.
De simpele versie
Als je niets anders onthoudt: schrijf de twee lijsten, breek dingen met opzet, en beslis op welk “goed genoeg”-niveau je lanceert. De meeste bugs in een met AI gebouwde app zijn niet subtiel. Ze zitten op de ongelukkige-pad-lijst die niemand de moeite nam op te schrijven.
Als je een klein huiswerkje wilt: kies één app die je hebt gebouwd en probeer vier dingen — dien een leeg formulier in, druk midden in een flow op verversen, bewerk een record en check het morgen, en vraag een vriend om het te gebruiken zonder dat je toekijkt. Wat er ook breekt, is je echte buglijst. Al het andere is uitstelgedrag.