Bug Crawl Digest #3: In-App-Aankopen Testen Faalt

Testen van in-app-aankopen heeft een blinde vlek, en die zit net na de betaling. Zodra het geld beweegt, lijkt het werk klaar, waardoor de tegenprestatie die het moest kopen ongecontroleerd blijft.

We zagen hier een voorbeeld van in Idle Cash – Merge Tycoon. De app biedt een duidelijke ruil: bekijk de advertentie, ontvang de skin, maar we vonden beide richtingen kapot in één crawl. Onze tester keek een volledige advertentie uit en kreeg gems, terwijl het beloofde item 10 tot 15 minuten te laat aankwam. Bij een tweede poging sloeg de tester de advertentie over en draaide het rad toch keer op keer, waarbij onverdiende beloningen werden verzameld.

Geen van beide gevallen meldde de storing, dus de kosten komen tot uiting in wat mensen daarna doen. Een crash vertelt iemand op zijn minst dat de poging mislukte, zodat diegene weet het later opnieuw te proberen. Niets terugkrijgen laat een gebruiker echter gissen, en die zal het opnieuw proberen, aannemen dat er toch is afgeschreven, of gewoon weglopen.

Deze storingen opsporen voordat uw spelers dat doen, is precies waar ons werk op het gebied van gametesten voor dient. Vandaag rapporteren we de bevindingen van het QAwerk Bug Crawl-team, dat negen producten testte en 55 bugs vastlegde. Vier waren iOS-games, één was een Android-app, en de rest waren webtools. Hetzelfde patroon dook bij veel daarvan op.

De meeste van die storingen zitten op één van vier ruilen tussen een product en de gebruiker ervan. Geld zou een recht moeten kopen, premiumvaluta een voordeel, een advertentieweergave een beloning, en een herstelverzoek de teruggave van toegang. Deze crawls braken drie van de vier volledig, en de laatste faalde nog voordat een betaling kon beginnen. Datzelfde patroon duikt vervolgens op waar helemaal geen geld beweegt, namelijk bij machtigingen en bij statusmeldingen.

Apps in deze editie:

Premiumvaluta die niets koopt

Apps: Hay Day, Idle Golf Club Manager Tycoon (beide iOS)
Ernst: kritiek tot ernstig
Type: monetisatie en premiumvaluta

Hay Day is Supercells boerderijsimulatie, met een score van 4,7 op basis van 642.000 beoordelingen en meer dan 700.000 downloads. Het verkoopt een van de meest herkenbare ruilen in mobiele games: betaal premiumvaluta, wees sneller klaar.

Onze tester begon een maaltijd te bereiden en wachtte tot de timer verscheen. Er was genoeg premiumvaluta beschikbaar, waarna op Versnellen werd getikt. Er gebeurde niets.

De timer liep niet terug en de productie versnelde niet. Een speler blijft daardoor tikken op een knop die de game als werkend presenteerde. Of de valuta ergens aan is uitgegeven of nooit is verplaatst, is niet vast te stellen. Die vraag als eerste sluiten is belangrijk, want het scheidt een dode knop van een stille afschrijving.

Idle Golf Club Manager Tycoon produceerde intussen dezelfde soort storing bij een beloningsteller. Het scherm Beloningen toonde spins als beschikbaar terwijl de Spin-knop inactief bleef. De game sprak zichzelf ook tegen over het aantal, met vier op de ene plek en 0/5 gebruikt op de andere. Geen van beide cijfers verklaart het andere, dus spelers blijven gissen.

Het echte probleem is echter niet de geblokkeerde actie, maar wat een gebruiker daaruit concludeert. Een teller die claimt dat u iets bezit, gekoppeld aan een knop die het niet uitgeeft, leert spelers om andere saldi en timers in twijfel te trekken. Zodra kopers andere balansen niet meer geloven, gaan uw betaalde extra’s op een slechte gok lijken.

Wat u zelf moet controleren: testen van in-app-aankopen begint met een end-to-end-toets op elke besteding van valuta, niet met een controle van de knopstatus. Bevestig drie dingen tegelijk: het saldo daalde correct, het voordeel werd toegepast, en de interface toont beide. Voer daarna de negatieve scenario’s uit: te weinig valuta, een besteding die halverwege wordt onderbroken, en twee snelle tikken achter elkaar. Elk cijfer dat op meer dan één scherm verschijnt, verdient een vergelijking op al die schermen binnen één sessie.

Zo wordt dit gevonden: handmatig functioneel testen, door iemand die de valuta uitgeeft en vervolgens zoekt naar wat ermee is gekocht. Automatisering bevestigt dat de knop reageert, maar zelden dat de productie ook echt versnelde. Onze gids over gamefunctionaliteit testen beschrijft hoe u dekking opbouwt rond economie- en beloningsflows in plaats van rond schermen.

Beloonde advertenties die in beide richtingen falen

App: Idle Cash – Merge Tycoon (iOS)
Ernst: ernstig (twee bevindingen)
Type: beloonde advertenties en rechten

Dit is de meest leerzame bevinding in deze set, omdat één systeem faalde voor zowel de speler als de uitgever.

Onze tester koos een gratis skin die werd aangeboden voor een beloonde advertentie, startte deze en liet hem afspelen. Terug op het scherm Skins was er niets ontgrendeld. In plaats daarvan kwamen er gems binnen, samen met een melding dat er nog geen andere advertentie beschikbaar was. De skin verscheen ongeveer 10 tot 15 minuten later, lang nadat de speler hem had verdiend.

Bij de tweede bevinding gebruikte onze tester de ene gratis spin op en drukte daarna opnieuw op de knop. Deze toonde een advertentiepictogram, dus een advertentie zou verplicht moeten zijn. Het rad draaide toch. Herhaaldelijk drukken leverde meer spins op, zonder dat er op enig moment een advertentie werd getoond.

Zet dit bij elkaar en u heeft een monetisatiesysteem dat niet weet wat er is gebeurd. De crawl toont geen hoofdoorzaak, al wijzen beide bevindingen dezelfde kant op. De advertentiegebeurtenis, de toekenning van het recht en de knopstatus zijn het niet met elkaar eens. De ene richting vertraagt de beloning van de speler tot ver na het moment waarop die werd verdiend. De andere richting deelt juist spins uit waarvoor de advertentieweergave nooit heeft betaald.

Wat u zelf moet controleren: testen van in-app-aankopen moet elke beloonde ruil behandelen als een contract met twee kanten. Bewijs dat beide kanten precies één keer afgaan. Bekijk een beloonde video volledig en bevestig dat het beloofde item onmiddellijk aankomt, niet als vervanging en niet vertraagd. Val het daarna aan vanuit de andere richting door herhaaldelijk te tikken, te tikken terwijl een advertentie laadt, een advertentie vroegtijdig te sluiten en de app naar de achtergrond te sturen. Controleer na elke poging of de beloning toch is uitgekeerd en of de afkoelperiode standhield.

Zo wordt dit gevonden: dit is regressietesten-terrein, doelbewust gericht op de advertentie-SDK in plaats van eromheen. De crawl beveelt zelf aan om vertraagde beloningen, herhaalde tikken, onderbroken advertenties, netwerkwisselingen en het naar de achtergrond sturen van de app te testen. Dat is precies de matrix die een happy-path-plan overslaat. Advertentiemediation gedraagt zich anders op fysieke hardware onder live netwerkomstandigheden. Dat vraagt om testen van mobiele applicaties op echte toestellen in plaats van simulators.

Bug Crawl Digest #3: storingen bij het testen van in-app-aankopen

Dezelfde Restore Purchase-bug in drie ongerelateerde games

Apps: Idle Golf Club Manager Tycoon, Idle Cash – Merge Tycoon, Clear Age (alle iOS)
Ernst: ernstig tot licht
Type: herstel van aankopen

In Bug Crawl Digest #1 publiceerden we een checklist voor dekking. Eén regel benadrukte dit: “Elke IAP-flow, inclusief Restore Purchase: toon laadindicatoren, succesmeldingen en foutmeldingen.” Twee edities later zien we dezelfde problemen in een compleet andere set geteste producten. Drie van de vier games die we crawlden, leverden een kapot herstelmechanisme, een schrijnende herinnering aan hoe wijdverspreid het probleem blijft.

Idle Golf Club Manager Tycoon gaf helemaal niets terug. Tikken op Restore Purchase leverde geen bevestiging, geen laadindicator, geen succesmelding en geen foutmelding op. Gebruikers kunnen “hersteld” niet onderscheiden van “niets te herstellen” of van “deze knop doet niets”.

Idle Cash – Merge Tycoon reageerde wel, maar incoherent. Tikken op dezelfde optie liet het scherm flikkeren. Er werd verder niets vastgelegd, terwijl de tester een bevestiging, laadindicator of foutmelding verwachtte.

Clear Age was de mildste van de drie en miste toch dezelfde vereiste. Met niets meer om terug te halen, gaf tikken op Restore Purchases geen bevestiging, succes- of informatiemelding.

Dat weegt zwaarder dan het klinkt. Restore Purchase is waar een betalende klant terechtkomt zodra er al iets is misgegaan: een herinstallatie, een nieuw toestel, een verloren recht. Hier stil blijven is kostbaar, want wie erop tikt, heeft u al betaald en probeert dat te bewijzen. Apples eigen App Store Review Guidelines verwachten dat apps gebruikers hun niet-verbruikbare aankopen en abonnementen laten herstellen. Dat maakt dit net zozeer een kwestie van winkelnaleving als van bruikbaarheid.

Wat u zelf moet controleren: testen van in-app-aankopen moet Restore Purchase behandelen als vier uitkomsten in plaats van één. Dek aankopen die worden gevonden en teruggegeven, niets gevonden, een netwerkstoring halverwege het verzoek, en een tweede opeenvolgende poging. Elke uitkomst verdient zijn eigen zichtbare melding, en de knop heeft een laadstatus nodig terwijl hij werkt. Voer dit uit op een verse installatie, aangemeld met een account dat al aankopen bezit, een scenario dat een ontwikkelbuild nooit tegenkomt.

Zo wordt dit gevonden: een plan dat het herstellen van aankopen behandelt als een volwaardige flow, handmatig uitgevoerd op een schoon toestel. Herstelpaden falen stilletjes en komen mogelijk helemaal niet naar voren in analytics. De gebruikers die ertegenaan lopen, zijn al gefrustreerd, en sommigen vertrekken gewoon. Breedte is hier belangrijk, en App Store-nalevingstesten hoort bij hetzelfde traject als ons gamewerk.

Offline is een status, geen foutmelding

Apps: Clear Age, Idle Cash – Merge Tycoon (beide iOS)
Ernst: ernstig tot licht
Type: offline-afhandeling en winkel

Clear Age: Clean to Grow Stronger heeft een score van 4,4 op basis van 158 beoordelingen en meer dan 20.000 downloads. De gameplay hield goed stand in onze handen, maar de winkel niet.

Met het toestel offline opende onze tester het gedeelte Era Offer. De aankoopknop toonde een prijs van 0 en bleef aantikbaar. Erop drukken leverde een mislukte poging op. Nul is geen neutrale plaatshouder, want het leest als gratis op een knop die de app u nog steeds uitnodigt in te drukken.

De tweede bevinding is dezelfde afwezigheid, maar dan van de andere kant. Elk in-game aanbod openen terwijl offline liet de app oneindig laden, zonder dat ergens stond dat een verbinding nodig was.

Idle Cash – Merge Tycoon draaide de fout om. Bij de eerste keer opstarten, terwijl het toestel op een stabiel netwerk zat, toonde de app toch een foutmelding “Niet verbonden”. Het ene product kan u niet vertellen dat het offline is wanneer dat zo is, en het andere zegt het juist wanneer dat niet zo is.

Simpel gezegd is een weggevallen verbinding geen fout om op te vangen en te negeren, maar een status die de interface moet weergeven. Wanneer het ophalen van de prijs mislukt, schakelt u de knop uit of legt u uit waarom. Een scherm dat zijn inhoud niet kan laden, moet dat gewoon zeggen in plaats van te blijven draaien.

Wat u zelf moet controleren: voer elk aankoop- en winkelonderdeel uit met het netwerk uitgeschakeld, en daarna met een verbinding die halverwege wegvalt. Bevestig dat de app telkens een echte status weergeeft, nooit een plaatshoudende waarde en nooit een eindeloze laadanimatie. Elk cijfer dat van een externe aanroep komt, heeft een terugvaloptie nodig die duidelijk geen prijs is. Goed testen van in-app-aankopen dekt ook het omgekeerde: bevestig dat de app niet beweert offline te zijn terwijl er wel verbinding is.

Zo wordt dit gevonden: usability testen gecombineerd met bewuste netwerkmanipulatie op echte hardware. Dit soort bug is bijna onzichtbaar op een kantoor met betrouwbare wifi, en dat is precies waarom hij de productie haalt. Ons overzicht van game-compatibiliteit testen beschrijft hoe u een toestel- en netwerkmatrix opbouwt die deze paden doelbewust test.

De interface biedt wat de backend weigert

Apps: Chefadora: Recipes & AI Chef (Android), Read AI (SaaS)
Ernst: kritiek tot ernstig
Type: mislukte indiening en machtigingen-UX

Chefadora is een receptenplatform met een AI-assistent, en leverde de grootste crawl in deze set op met 15 bugs. Twee van de kritieke bevindingen zijn dezelfde bug op twee plekken, en beide passen in dit patroon.

Op een receptpagina scrollde onze tester naar “Heeft u dit recept geprobeerd? Deel uw ervaring”, koos een sterbeoordeling en tikte op Beoordeling toevoegen. Met het tekstveld leeg gelaten, gaf de indiening “Request failed with status code 400” terug en werd er niets opgeslagen.

Die storing herhaalde zich aan het eind van de flow Stap-voor-stap koken. Doorloop de flow, bereik het scherm “Geniet van uw maaltijd”, kies een beoordeling, en dezelfde 400 komt terug.

De interface accepteerde een score zonder tekst, en de backend weigerde die. Niemand vertelde de gebruiker welke regel echt gold, en een kale statuscode is geen validatiebericht.

Read AI vertoonde dezelfde storing bij zijn machtigingen. Een gebruiker met alleen-lezen toegang tot een map als Viewer zag toch een optie Bewerken, opende die en bracht wijzigingen aan. Pas Opslaan hield de gebruiker tegen, met de melding “Failed to update folder. Please try again.” Datzelfde product liet ons ook alleen-lezen voorbeeldrapporten kiezen tijdens het aanmaken van een map, waarna “Failed to update folder reports. Please try again.” verscheen.

Dat laatste verdient even stilstaan. De actie werd geweigerd en het bericht noemde niets concreets, waardoor gebruikers een machtigingsmuur niet kunnen onderscheiden van een kapotte functie. Hoe dan ook nodigde de interface hen uit om moeite te steken in iets wat nooit zou lukken. Een actie terecht weigeren is niet hetzelfde als die weigeren op een manier waar iemand iets mee kan.

Wat u zelf moet controleren: validatieregels moeten aan beide kanten van de aanroep overeenkomen, zodat de client blokkeert wat de server toch zou weigeren. Elke actie die het huidige toegangsniveau verbiedt, hoort verborgen of uitgeschakeld te zijn, niet getoond en vervolgens geweigerd. Elke foutmelding die een gebruiker ziet, moet het echte probleem benoemen: welk veld, welke machtiging, wat er moet veranderen. Een kale statuscode of een generieke oproep om het opnieuw te proberen laat het werk half af.

Zo wordt dit gevonden: negatief-pad exploratief testen, uitgevoerd door iemand die bewust onvolledige formulieren indient en het product op elk machtigingsniveau gebruikt. Werken als de gebruiker met de laagste rechten is een van de meest opbrengstrijke gewoontes hier, en een van de makkelijkste om over te slaan.

Statusmeldingen waar u niet op kunt vertrouwen

Apps: Bluedot (SaaS), Slite (SaaS), Fathom AI (SaaS)
Ernst: ernstig tot licht
Type: ontbrekende feedback en status

Het patroon reikt verder dan geld. Bij drie webtools liet het product mensen zonder eenduidig antwoord over wat er was gebeurd.

Bluedot, een AI-vergaderassistent met een Chrome-extensie, leverde het scherpste voorbeeld. De opnametimer werd na een pauze en hervatting gereset, en liep uiteindelijk terug naar 00:00 terwijl de opname doorging. Aangezien hij aftelt vanaf 60:00, was het element dat de resterende tijd toonde actief onjuist.

Datzelfde product verwerkte ook uploads zonder enig teken. Het toevoegen van een werkruimtelogo via Instellingen en Algemeen liet niets zien dat de overdracht was begonnen. Er verscheen geen voortgangsindicator, en een ongeldig bestand leverde geen validatiefout op.

We activeerden een handmatige synchronisatie vanaf Slites pagina Agent Sources, en “Laatst gesynchroniseerd” bleef ongewijzigd totdat iemand handmatig de pagina vernieuwde. Of de taak zelf werd voltooid, blijft onzichtbaar voor de gebruiker. De oude tijdstempel bleef gewoon staan, dus wie zijn bronnen controleerde, kreeg een verouderd antwoord.

Fathom AI kwam via een andere route tot hetzelfde punt. Het veld Naam voor de API-sleutel heeft geen maximale lengtevalidatie, waardoor een te lange invoer “Failed to generate API client” oplevert. De gebruiker verneemt dat de bewerking is mislukt en krijgt geen enkel pad om het alsnog te laten werken.

Geen van deze gevallen kost iemand geld, en de schade is toch reëel. Gebruikers kunnen namelijk niet vaststellen of het product deed wat ze vroegen. Die onzekerheid is precies wat supporttickets, dubbele acties en verlaten workflows veroorzaakt.

Wat u zelf moet controleren: alles wat het netwerk oversteekt heeft drie zichtbare statussen nodig: bezig, geslaagd en mislukt. Geef elke bestandsoverdracht een voortgangssignaal en een afwijzingsbericht. Elke waarde die actualiteit weergeeft, moet bijwerken vanuit de actie zelf, niet vanuit het laden van de pagina. Dat geldt voor tijdstippen van laatste synchronisatie, lopende klokken en statuslabels.

Zo wordt dit gevonden: testen van webapplicaties door een mens in plaats van een testsuite, want iemand moet een afwezigheid opmerken. Opmerken wat er niet is, is lastiger dan een crash opvangen, en het verschijnt nooit in een stacktrace. In Bug Crawl Digest #2 signaleerden we om dezelfde reden een bevriezing van tien seconden zonder enige feedback, want stilte leest als storing.

Checklist voor het testen van in-app-aankopen op basis van deze crawls

Maak hier een screenshot van en deel die met uw team.

Elke besteding van valuta: bevestig dat het saldo veranderde, het voordeel werd toegepast, en de interface beide toont. Een responsieve knop bewijst niets van dit alles.
Elke beloonde advertentie: controleer of het beloofde item aankomt op het moment dat het afspelen eindigt. Bevestig daarna dat niemand het kan krijgen zonder er een te bekijken.
Elke Restore Purchase: test aankopen die worden gevonden, niets te herstellen, een netwerkstoring, en een tweede poging. Elke uitkomst heeft zijn eigen melding nodig.
Elke externe prijs: definieer een terugvaloptie die niemand kan aanzien voor een echt bedrag. Schakel de koopknop uit zolang het bedrag onbekend is.
Elk winkelonderdeel offline: bevestig dat het een expliciete foutmelding toont in plaats van eindeloos te laden. Controleer daarna dat het geen verbroken verbinding meldt terwijl er wel verbinding is.
Elke teller die op twee plekken staat: vergelijk de waarde overal waar hij verschijnt, binnen één sessie.

Bug van de maand

Onze keuze is de logica voor beloonde advertenties van Idle Cash – Merge Tycoon, omdat die binnen dezelfde crawl in beide richtingen faalde. Iemand die een volledige advertentie bekeek, kreeg de skin niet op het moment waarop die was verdiend. In plaats daarvan kwamen er gems binnen, met een melding dat er nog geen andere advertentie beschikbaar was. Wie de advertentie helemaal oversloeg, kon het rad ongeacht het pictogram op de knop toch blijven draaien. Eén systeem benadeelde de speler en gaf tegelijk spins weg waarvoor de advertentieweergave nooit heeft betaald. Een beloonde flow werkt niet alleen omdat de advertentie afspeelt en de knop reageert. De advertentiegebeurtenis, het recht en de interface moeten het met elkaar eens zijn over wat er zojuist is gebeurd.

Een eervolle vermelding gaat naar Hay Days Versnellen. Een speler met genoeg premiumvaluta tikt erop, en de productie gaat ongewijzigd door. Het is de kortste versie van dit patroon. Het product bood een ruil aan, de speler ging akkoord, en er volgde niets.

Wilt u dit liever opsporen voordat uw gebruikers dat doen? Vertel ons wat u uitbrengt en wij stemmen het testen van in-app-aankopen erop af.

Veelgestelde vragen

Hoe test u in-app-aankopen op iOS?

Voer het testen van in-app-aankopen uit tegen echte StoreKit-sandboxaccounts op fysieke toestellen, nooit op simulators, en behandel elke aankoop als een keten. Bevestig dat de betaling wordt afgerond, het recht wordt toegekend, dit een herstart en een herinstallatie overleeft, en de interface elke stap weerspiegelt. Dek daarna herstel, onderbroken aankopen en offline pogingen. Veel gaten zitten na een geslaagde betaling, niet tijdens de betaling zelf.

Wat moet het testen van in-app-aankopen dekken naast een geslaagde betaling?

De dekking moet het recht volgen, niet het betaalbewijs. Zodra een betaling wordt afgerond, bevestig dan dat het gekochte item daadwerkelijk verschijnt en blijft bestaan over sessies en toestellen heen. Bewijs daarna dat het niet zonder betaling te verkrijgen is, want een gratis weggegeven beloning kost u ook geld. Beide richtingen faalden ergens in deze set.

Kunnen geautomatiseerde tests bugs in in-app-aankopen opsporen?

Deels. Automatisering bevestigt dat een aankoopaanroep afgaat en een antwoord teruggeeft, en controleert de status van rechten in de tijd via regressietests. Ze is zwak bij de storingen die we hier vonden, waar de tik wordt geregistreerd maar het voordeel nooit aankomt. Winkel-sandboxes, advertentiemediation en live netwerkomstandigheden verzetten zich tegen betrouwbare automatisering, dus blijft de sterkste dekking handmatig en exploratief.

Hoe vaak moeten beloonde-advertentieflows opnieuw worden getest?

Bij elke build die de advertentie-SDK, de beloningslogica of de mediationconfiguratie raakt, plus sowieso een geplande regressieronde. Beloonde flows leunen op componenten van derden die buiten uw releasecyclus om veranderen. Iets dat vorige maand nog werkte, kan deze maand falen zonder dat u zelf iets heeft aangepast. Dat maakt een vaste testsuite veel veiliger dan steekproeven op het moment van release.