QAwerk Bug Crawl Digest #3: In-App-Kauf-Testfehler

Das Testen von In-App-Käufen hat einen blinden Fleck, direkt hinter der Zahlung. Sobald das Geld sich bewegt hat, wirkt die Arbeit erledigt, sodass der damit erkaufte Austausch ungeprüft bleibt.

Wir haben ein Beispiel dafür bei Idle Cash – Merge Tycoon gesehen. Die App bietet einen klaren Tausch: Anzeige ansehen, Skin bekommen, doch wir fanden bei einem einzigen Crawl beide Richtungen defekt. Unser Tester sah eine vollständige Anzeige und erhielt Edelsteine, wobei der versprochene Gegenstand 10 bis 15 Minuten zu spät ankam. Bei einem zweiten Durchlauf übersprang er die Anzeige und drehte trotzdem immer wieder das Rad, wobei er unverdiente Belohnungen sammelte.

Keiner der beiden Fälle meldete den Fehler, sodass sich die Kosten in dem zeigen, was die Menschen als Nächstes tun. Ein Absturz sagt zumindest jemandem, dass der Versuch fehlgeschlagen ist, sodass er weiß, es später erneut zu versuchen. Nichts zurückzubekommen lässt sie hingegen im Ungewissen, und sie werden es erneut versuchen, annehmen, eine Abbuchung sei erfolgt, oder einfach gehen.

Diese Fehler zu finden, bevor es Ihre Spieler tun, ist der Zweck unserer Spieletest-Arbeit. Heute berichten wir über die Ergebnisse des QAwerk Bug Crawl-Teams, das neun Produkte testete und 55 Bugs protokollierte. Vier waren iOS-Spiele, eines eine Android-App, und der Rest Web-Tools. Dasselbe Muster tauchte in vielen von ihnen auf.

Die meisten dieser Fehler liegen bei einem von vier Austauschvorgängen zwischen einem Produkt und seinem Nutzer. Geld sollte eine Berechtigung kaufen, Premium-Währung einen Vorteil, eine Anzeigen-Impression eine Belohnung, und eine Wiederherstellungsanfrage die Rückkehr des Zugangs. Diese Crawls brachen drei der vier komplett, und der letzte scheiterte, bevor eine Zahlung überhaupt beginnen konnte. Dasselbe Muster taucht dann dort auf, wo überhaupt kein Geld fließt, bei Berechtigungen und beim Statusreporting.

In diesem Digest behandelte Apps:

Premium-Währung, die Nichts Kauft

Apps: Hay Day, Idle Golf Club Manager Tycoon (beide iOS)
Schweregrad: Kritisch bis Schwerwiegend
Typ: Monetarisierung und Premium-Währung

Hay Day ist Supercells Farmsimulation mit einer Bewertung von 4,7 aus 642.000 Bewertungen und über 700.000 Downloads. Es verkauft einen der vertrautesten Tauschgeschäfte im mobilen Gaming: Premium-Währung bezahlen, schneller fertig werden.

Unser Tester begann, eine Mahlzeit herzustellen, und wartete darauf, dass der Timer erschien. Er hatte genug Premium-Währung zur Hand und tippte auf Beschleunigen. Nichts geschah.

Der Timer sank nicht und die Produktion beschleunigte sich nicht. Infolgedessen bleibt ein Spieler dabei, einen Button anzutippen, den das Spiel als funktionierend präsentierte. Ob die Währung für nichts ausgegeben wurde oder sich nie bewegte, lässt sich nicht sagen. Diese Frage zu klären, kommt zuerst, weil sie einen toten Button von einer stillen Abbuchung trennt.

Unterdessen produzierte Idle Golf Club Manager Tycoon dieselbe Fehlerform bei einem Belohnungszähler. Sein Belohnungsbildschirm zeigte Spins als verfügbar an, während der Spin-Button inaktiv blieb. Das Spiel widersprach sich auch selbst bei der Zählung, indem es an einer Stelle vier anzeigte und an anderer 0/5 verwendet. Keine Zahl erklärt die andere, sodass Spieler am Ende raten müssen.

Dennoch ist das eigentliche Problem nicht die blockierte Aktion, sondern was ein Nutzer daraus schließt. Ein Zähler, der behauptet, Sie besäßen etwas, verbunden mit einem Button, der es nicht ausgibt, bringt Spielern bei, der Oberfläche zu misstrauen. Sobald Käufer aufhören, anderen Salden und Timern zu glauben, beginnen Ihre kostenpflichtigen Extras wie eine schlechte Wette auszusehen.

Was Sie auf Ihrer Seite prüfen sollten: Das Testen von In-App-Käufen beginnt mit einer Ende-zu-Ende-Prüfung bei jeder Währungsausgabe, nicht einer Button-Status-Prüfung. Bestätigen Sie drei Dinge gleichzeitig: Das Guthaben sank korrekt, der Vorteil wurde angewendet, und die Oberfläche zeigt beides. Führen Sie dann die negativen Fälle aus: zu wenig Währung, eine mitten im Ablauf unterbrochene Ausgabe, und zwei schnelle Taps. Jede Zahl, die auf mehr als einem Bildschirm erscheint, verdient einen Vergleich über alle hinweg in einer einzigen Sitzung.

Wie das aufgedeckt wird: Manuelles funktionales Testen, durch jemanden, der die Währung ausgibt und dann sucht, was sie gekauft hat. Automatisierung bestätigt, dass der Button feuert, aber selten, dass sich die Produktion tatsächlich beschleunigt hat. Unser Leitfaden zu Spiele-Funktionstests behandelt den Aufbau von Testabdeckung rund um Wirtschafts- und Belohnungsabläufe statt um Bildschirme.

Rewarded Ads, die in Beide Richtungen Versagen

App: Idle Cash – Merge Tycoon (iOS)
Schweregrad: Schwerwiegend (zwei Befunde)
Typ: Rewarded Ads und Berechtigung

Das ist der lehrreichste Befund in dieser Sammlung, weil ein System sowohl für den Spieler als auch für den Publisher versagte.

Unser Tester wählte einen kostenlosen Skin, der für eine Rewarded Ad angeboten wurde, startete sie und ließ sie zu Ende laufen. Zurück auf dem Skins-Bildschirm hatte sich nichts freigeschaltet. Stattdessen waren Edelsteine angekommen, zusammen mit einer Meldung, dass eine weitere Anzeige noch nicht verfügbar sei. Der Skin erschien etwa 10 bis 15 Minuten später, lange nachdem der Spieler ihn verdient hatte.

Beim zweiten Befund verbrauchte unser Tester den einen kostenlosen Spin und drückte dann den Button erneut. Er zeigte ein Anzeigen-Symbol, eine Anzeige hätte also verpflichtend sein sollen. Das Rad drehte sich trotzdem. Wiederholtes Drücken erzeugte weitere Spins, ohne dass an irgendeiner Stelle eine Anzeige lief.

Zusammengenommen ergibt das ein Monetarisierungssystem, das nicht weiß, was passiert ist. Im Crawl erscheint keine Ursache, doch beide Befunde weisen in dieselbe Richtung. Das Anzeigenereignis, die Berechtigungsvergabe und der Button-Status stimmen nicht überein. Eine Richtung verzögert die Belohnung des Spielers über den Moment hinaus, in dem er sie verdient hat. Im Gegensatz dazu vergibt die andere Spins, für die die Anzeigen-Impression nie bezahlt hat.

Was Sie auf Ihrer Seite prüfen sollten: Das Testen von In-App-Käufen sollte jeden belohnten Austausch als zweiseitigen Vertrag behandeln. Beweisen Sie, dass beide Seiten genau einmal auslösen. Schauen Sie sich ein Rewarded Video bis zum Ende an und bestätigen Sie, dass der versprochene Gegenstand sofort ankommt, kein Ersatz und keine Verzögerung. Greifen Sie dann die Umkehrung an, indem Sie wiederholt tippen, während eine Anzeige lädt tippen, eine früh schließen, und die App in den Hintergrund schicken. Prüfen Sie nach jedem Versuch, ob die Belohnung trotzdem ankam und ob die Abklingzeit überlebte.

Wie das aufgedeckt wird: Das ist Regressionstest-Terrain, absichtlich auf das Anzeigen-SDK gerichtet statt darum herum. Die eigene Empfehlung des Crawls deckte verzögerte Belohnungen, wiederholte Taps, unterbrochene Anzeigen, Netzwerkwechsel und das In-den-Hintergrund-Schicken der App ab. Genau das ist die Matrix, die ein Happy-Path-Plan überspringt. Anzeigen-Mediation verhält sich auf physischer Hardware unter echten Netzwerkbedingungen anders. Das erfordert mobiles Anwendungstesten auf Geräten statt Simulatoren.

QAwerk Bug Crawl Digest #3: Fehler beim Testen von In-App-Käufen

Derselbe Restore-Purchase-Bug in Drei Unabhängigen Spielen

Apps: Idle Golf Club Manager Tycoon, Idle Cash – Merge Tycoon, Clear Age (alle iOS)
Schweregrad: Schwerwiegend bis Gering
Typ: Kaufwiederherstellung

Im Bug Crawl Digest #1 haben wir eine Abdeckungs-Checkliste veröffentlicht. Eine Zeile hob dies hervor: „Jeder IAP-Ablauf, einschließlich Restore Purchase: Ladeanzeigen, Erfolgszustände und Fehler zeigen.” Zwei Digests später sehen wir dieselben Probleme in einem völlig anderen Satz getesteter Produkte. Drei der vier von uns gecrawlten Spiele lieferten eine defekte Wiederherstellung, eine deutliche Erinnerung daran, wie weit verbreitet das Problem bleibt.

Idle Golf Club Manager Tycoon gab überhaupt nichts zurück. Das Antippen von Restore Purchase erzeugte keine Bestätigung, keinen Ladeindikator, keine Erfolgsmeldung und keinen Fehler. Nutzer können „wiederhergestellt” nicht von „nichts wiederherzustellen” nicht von „dieser Button ist tot” unterscheiden.

Idle Cash – Merge Tycoon antwortete, aber unzusammenhängend. Das Antippen derselben Option ließ den Bildschirm flackern. Nichts anderes wird aufgezeichnet, und was der Tester erwartete, war eine Bestätigung, ein Ladeindikator oder eine Fehlermeldung.

Clear Age war das mildeste der drei und verfehlte trotzdem dieselbe Anforderung. Ohne etwas zurückzuholen, gab das Antippen von Restore Purchases keine Bestätigung, keinen Erfolg und keine Informationsmeldung.

Das bedeutet mehr, als es klingt. Restore Purchase ist der Ort, an dem ein zahlender Kunde landet, wenn bereits etwas schiefgegangen ist: eine Neuinstallation, ein neues Gerät, eine verlorene Berechtigung. Hier still zu bleiben ist kostspielig, denn wer darauf tippt, hat Sie bereits bezahlt und versucht, das zu beweisen. Apples eigene App Store Review Guidelines erwarten von Apps, Nutzern die Wiederherstellung nicht verbrauchbarer Käufe und Abonnements zu ermöglichen. Das macht dies zu einer Store-Compliance-Fläche, nicht nur zu einer Usability-Frage.

Was Sie auf Ihrer Seite prüfen sollten: Das Testen von In-App-Käufen muss Restore Purchase als vier Ergebnisse statt eines behandeln. Decken Sie gefundene und zurückgegebene Käufe ab, nichts gefunden, einen Netzwerkausfall mitten in der Anfrage, und einen zweiten aufeinanderfolgenden Versuch. Jedes verdient seine eigene sichtbare Meldung, und die Steuerung braucht einen Ladezustand, während sie arbeitet. Führen Sie es auf einer frischen Installation aus, angemeldet mit einem Konto, das Käufe besitzt, ein Szenario, das ein Entwicklungs-Build nie sieht.

Wie das aufgedeckt wird: Ein Plan, der Kaufwiederherstellung als erstklassigen Ablauf behandelt, von Hand auf einem sauberen Gerät ausgeführt. Wiederherstellungspfade brechen still und tauchen möglicherweise überhaupt nicht in Analytics auf. Die Nutzer, die darauf stoßen, sind bereits frustriert, und manche gehen einfach. Breite zählt hier, und App-Store-Konformitätstests laufen im selben Auftrag wie unsere Spielearbeit.

Offline Ist ein Zustand, Keine Fehlermeldung

Apps: Clear Age, Idle Cash – Merge Tycoon (beide iOS)
Schweregrad: Schwerwiegend bis Gering
Typ: Offline-Handhabung und Store

Clear Age: Clean to Grow Stronger hat eine Bewertung von 4,4 aus 158 Bewertungen und über 20.000 Downloads. Sein Gameplay hielt sich in unseren Händen gut, der Store jedoch nicht.

Bei offline geschaltetem Gerät öffnete unser Tester den Era-Offer-Bereich. Der Kauf-Button zeigte einen Preis von 0 und blieb antippbar. Ihn zu drücken erzeugte einen fehlgeschlagenen Versuch. Null ist kein neutraler Platzhalter, denn er liest sich als kostenlos bei einer Steuerung, zu deren Betätigung die App weiterhin einlädt.

Der zweite Befund ist dieselbe Abwesenheit von der anderen Seite. Ein beliebiges In-Game-Angebot offline zu öffnen, ließ die App unbegrenzt laden, ohne dass irgendetwas sagte, eine Verbindung sei nötig.

Idle Cash – Merge Tycoon kehrte den Fehler um. Beim ersten Start, mit dem Gerät in einem stabilen Netzwerk, zeigte es trotzdem einen „Nicht verbunden”-Fehler. Ein Produkt kann Ihnen nicht sagen, dass es offline ist, wenn es das ist, und das andere sagt es, wenn es das nicht ist.

Einfach gesagt, eine abgebrochene Verbindung ist kein Fehler, den man abfangen und schlucken sollte, sondern ein Zustand, den die Oberfläche darstellen muss. Wenn der Preisabruf fehlschlägt, deaktivieren Sie entweder die Steuerung oder erklären warum. Ein Bildschirm, der seinen Inhalt nicht laden kann, sollte das klar sagen, statt sich unbegrenzt zu drehen.

Was Sie auf Ihrer Seite prüfen sollten: Führen Sie jede Kauf- und Store-Oberfläche mit deaktiviertem Netzwerk aus, und dann mit einem Abbruch mitten in der Anfrage. Bestätigen Sie, dass die App jedes Mal einen echten Zustand rendert, nie einen Platzhalterwert und nie einen endlosen Spinner. Jede von einem entfernten Aufruf ankommende Zahl braucht einen Fallback, der eindeutig kein Preis ist. Gutes Testen von In-App-Käufen deckt auch das Umgekehrte ab und bestätigt, dass die App nicht behauptet, offline zu sein, während sie verbunden ist.

Wie das aufgedeckt wird: Usability-Testing gepaart mit gezielter Netzwerkmanipulation auf echter Hardware. Diese Fehlerklasse ist in einem Büro mit zuverlässigem WLAN fast unsichtbar, was ein Grund ist, warum sie es in die Produktion schafft. Unser Überblick zu Spielkompatibilitätstests behandelt den Aufbau einer Geräte- und Netzwerkmatrix, die diese Pfade absichtlich durchspielt.

Die Oberfläche Bietet, was das Backend Verweigert

Apps: Chefadora: Recipes & AI Chef (Android), Read AI (SaaS)
Schweregrad: Kritisch bis Schwerwiegend
Typ: Übermittlungsfehler und Berechtigungs-UX

Chefadora ist eine Rezeptplattform mit KI-Assistent und lieferte mit 15 Bugs den größten Crawl dieser Sammlung. Zwei ihrer kritischen Befunde sind derselbe Bug an zwei Stellen, und beide passen zu diesem Muster.

Auf einer Rezeptseite scrollte unser Tester zu „Dieses Rezept ausprobiert? Teile deine Erfahrung”, wählte eine Sternebewertung, und tippte auf Bewertung hinzufügen. Bei leerem Textfeld lieferte die Übermittlung „Request failed with status code 400″ und nichts wurde gespeichert.

Dieser Fehler wiederholte sich am Ende des Cook-Step-by-Step-Ablaufs. Arbeiten Sie ihn durch, erreichen Sie den Bildschirm „Enjoy your meal”, wählen Sie eine Bewertung, und derselbe 400er kommt zurück.

Die Oberfläche akzeptierte eine Bewertung ohne Text, und das Backend lehnte sie ab. Niemand sagte dem Nutzer, welche Regel echt war, und ein roher Statuscode ist keine Validierungsmeldung.

Read AI zeigte denselben Fehler bei seinen Berechtigungen. Ein Nutzer mit Viewer-, Nur-Lese-Zugriff auf einen Ordner sah trotzdem eine Bearbeiten-Option, öffnete sie, und nahm Änderungen vor. Erst Speichern stoppte ihn, mit dem Fehler „Failed to update folder. Please try again.” Dasselbe Produkt ließ uns auch schreibgeschützte Beispielberichte bei der Ordnererstellung auswählen und lieferte dann „Failed to update folder reports. Please try again.”

Letzteres verdient eine Pause. Die Aktion wurde abgelehnt und die Meldung nannte nichts, sodass Nutzer eine Berechtigungssperre nicht von einer defekten Funktion unterscheiden können. So oder so lud die Oberfläche sie ein, Aufwand in etwas zu stecken, das nie ankommen würde. Eine Aktion korrekt abzulehnen ist nicht dasselbe wie sie so abzulehnen, dass jemand darauf reagieren kann.

Was Sie auf Ihrer Seite prüfen sollten: Validierungsregeln müssen auf beiden Seiten des Aufrufs übereinstimmen, sodass der Client blockiert, was der Server ablehnen würde. Jede Aktion, die die aktuelle Zugriffsebene verbietet, gehört versteckt oder deaktiviert, nicht präsentiert und dann abgelehnt. Jeder Fehler, den ein Nutzer sieht, muss das eigentliche Problem benennen: welches Feld, welche Berechtigung, was zu ändern ist. Ein nackter Statuscode oder eine generische Wiederholungsaufforderung lässt die Arbeit halb erledigt.

Wie das aufgedeckt wird: Negativpfad-explorative Tests, durchgeführt von jemandem, der absichtlich unvollständige Formulare einreicht und das Produkt auf jeder Berechtigungsstufe nutzt. Als Nutzer mit den niedrigsten Rechten zu arbeiten, gehört hier zu den ertragreichsten Gewohnheiten, und zu den am leichtesten übersprungenen.

Statusmeldungen, auf die Sie Sich Nicht Verlassen Können

Apps: Bluedot (SaaS), Slite (SaaS), Fathom AI (SaaS)
Schweregrad: Schwerwiegend bis Gering
Typ: Fehlendes Feedback und Status

Das Muster reicht über Geld hinaus. Bei drei Web-Tools ließ das Produkt Menschen ohne klare Antwort darüber, was es getan hatte.

Bluedot, ein KI-Meeting-Assistent mit Chrome-Erweiterung, lieferte das schärfste Beispiel. Sein Aufnahme-Timer setzte sich nach einer Pause und Fortsetzung zurück und zeigte schließlich 00:00, während die Aufnahme weiterlief. Da er von 60:00 herunterzählt, war das Element, das die verbleibende Zeit meldete, aktiv falsch.

Dasselbe Produkt behandelte auch Uploads wortlos. Das Hinzufügen eines Workspace-Logos über Einstellungen und Allgemein erzeugte kein Zeichen, dass die Übertragung begonnen hatte. Kein Fortschrittsanzeiger erschien, und eine ungültige Datei löste keinen Validierungsfehler aus.

Wir lösten eine manuelle Synchronisierung von Slites Agent-Sources-Seite aus, und „Zuletzt synchronisiert” blieb unangetastet, bis jemand von Hand aktualisierte. Ob die Aufgabe selbst abgeschlossen wurde, bleibt für den Nutzer unsichtbar. Der alte Zeitstempel blieb einfach bestehen, sodass jeder, der seine Quellen prüfte, eine veraltete Antwort erhielt.

Fathom AI kam auf anderem Weg an denselben Punkt. Sein API-Key-Name-Feld hat keine Validierung für die Maximallänge, sodass ein zu langer Eintrag „Failed to generate API client” zurückgibt. Der Nutzer erfährt, dass der Vorgang fehlschlug, und erhält keinen Weg, ihn zum Laufen zu bringen.

Keines davon nimmt jemandem Geld weg, und der Schaden ist trotzdem real. Infolgedessen können Nutzer nicht sagen, ob das Produkt getan hat, worum sie gebeten hatten. Diese Unsicherheit erzeugt Support-Tickets, doppelte Aktionen und abgebrochene Workflows.

Was Sie auf Ihrer Seite prüfen sollten: Alles, was das Netzwerk durchquert, braucht drei sichtbare Zustände: in Bearbeitung, erfolgreich und fehlgeschlagen. Geben Sie jeder Dateiübertragung ein Fortschrittssignal und eine Ablehnungsmeldung. Jeder Wert, der Aktualität darstellt, muss sich aus der Aktion selbst aktualisieren, nicht aus einem Seitenaufruf. Das deckt Zeitstempel der letzten Synchronisierung, laufende Uhren, und Status-Badges ab.

Wie das aufgedeckt wird: Webanwendungstests, durchgeführt von einer Person statt einer Suite, weil jemand eine Abwesenheit bemerken muss. Zu bemerken, was nicht da ist, ist schwieriger, als einen Absturz zu erwischen, und taucht nie in einem Stack Trace auf. Im Bug Crawl Digest #2 haben wir aus demselben Grund ein zehnsekündiges Einfrieren ohne Feedback markiert, da Stille sich wie ein Defekt liest.

In-App-Kauf-Test-Checkliste Basierend auf Diesen Crawls

Machen Sie einen Screenshot davon und teilen Sie ihn mit Ihrem Team.

Jede Währungsausgabe: bestätigen Sie, dass sich das Guthaben geändert hat, der Vorteil angewendet wurde, und die Oberfläche beides zeigt. Ein reagierender Button beweist nichts davon.
Jede Rewarded Ad: überprüfen Sie, dass der versprochene Gegenstand in dem Moment ankommt, in dem die Wiedergabe endet. Bestätigen Sie dann, dass niemand ihn bekommen kann, ohne eine anzusehen.
Jedes Restore Purchase: testen Sie gefundene Käufe, nichts zu wiederherstellen, einen Netzwerkausfall, und einen zweiten Versuch. Jedes braucht seine eigene Meldung.
Jeder Remote-Preis: definieren Sie einen Fallback, den niemand mit einer echten Zahl verwechseln könnte. Deaktivieren Sie die Kauf-Steuerung, solange der Betrag unbekannt ist.
Jede Store-Oberfläche offline: bestätigen Sie, dass ein deklarierter Fehler statt eines endlosen Ladevorgangs angezeigt wird. Prüfen Sie dann, dass sie online keine verlorene Verbindung meldet.
Jeder an zwei Stellen angezeigte Zähler: vergleichen Sie den Wert überall dort, wo er innerhalb einer Sitzung erscheint.

Bug des Monats

Unsere Wahl ist Idle Cash – Merge Tycoons Rewarded-Ad-Logik, weil sie innerhalb desselben Crawls in beide Richtungen versagte. Jemand, der eine vollständige Anzeige ansah, bekam den Skin nicht in dem Moment, in dem er ihn verdiente. Stattdessen kamen Edelsteine, mit einer Meldung, dass eine weitere Anzeige noch nicht verfügbar sei. Jeder, der die Anzeige komplett übersprang, konnte trotzdem weiter am Rad drehen, unabhängig vom Symbol auf dem Button. Ein System betrog den Spieler und verschenkte Spins, für die die Anzeigen-Impression nie bezahlt hat. Ein belohnter Ablauf funktioniert nicht nur, weil die Anzeige läuft und der Button reagiert. Das Anzeigenereignis, die Berechtigung und die Oberfläche müssen sich alle darüber einig sein, was gerade passiert ist.

Lobende Erwähnung geht an Hay Days Beschleunigen. Ein Spieler mit genug Premium-Währung tippt darauf, und die Produktion läuft unverändert weiter. Es ist die kürzeste Version dieses Musters. Das Produkt bot einen Tausch an, der Spieler akzeptierte, und nichts folgte.

Wenn Sie das lieber abfangen möchten, bevor es Ihre Nutzer tun, erzählen Sie uns, was Sie ausliefern, und wir stecken das Testen von In-App-Käufen darum herum ab.

FAQ

Wie Testet Man In-App-Käufe unter iOS?

Führen Sie das Testen von In-App-Käufen gegen echte StoreKit-Sandbox-Konten auf physischen Geräten durch, niemals Simulatoren, und behandeln Sie jeden Kauf als Kette. Bestätigen Sie, dass die Zahlung abgeschlossen wird, die Berechtigung ankommt, einen Neustart und eine Neuinstallation übersteht, und die Oberfläche jeden Schritt widerspiegelt. Decken Sie dann Wiederherstellung, unterbrochene Käufe und Offline-Versuche ab. Viele Lücken liegen nach erfolgreicher Zahlung, nicht während ihr.

Was Sollte das Testen von In-App-Käufen über eine Erfolgreiche Zahlung Hinaus Abdecken?

Die Abdeckung muss der Berechtigung folgen, nicht der Quittung. Sobald eine Zahlung durchgeht, bestätigen Sie, dass das Gekaufte tatsächlich erscheint und über Sitzungen und Geräte hinweg bestehen bleibt. Beweisen Sie dann, dass es ohne Bezahlung nicht erlangt werden kann, denn eine kostenlos herausgegebene Belohnung kostet auch Sie. Beide Richtungen versagten irgendwo in dieser Sammlung.

Können Automatisierte Tests In-App-Kauf-Bugs Erkennen?

Teilweise. Automatisierung bestätigt, dass ein Kaufaufruf auslöst und zurückkehrt, und prüft den Berechtigungsstatus über die Zeit per Regression. Sie ist schwach genau bei den Fehlern, die wir hier fanden, wo der Tap registriert wird und der Vorteil nie ankommt. Store-Sandboxes, Anzeigen-Mediation, und echte Netzwerkbedingungen widersetzen sich zuverlässiger Automatisierung, sodass die stärkste Abdeckung manuell und explorativ bleibt.

Wie Oft Sollten Rewarded-Ad-Abläufe Erneut Getestet Werden?

Jeder Build, der das Anzeigen-SDK, die Belohnungslogik, oder die Mediations-Konfiguration berührt, plus ein geplanter Regressionsdurchlauf ohnehin. Belohnte Abläufe stützen sich auf Drittanbieterkomponenten, die sich außerhalb Ihres Release-Zyklus verschieben. Etwas, das letzten Monat bestand, kann diesen Monat ohne jede Änderung Ihrerseits scheitern. Das macht eine Dauersuite weit sicherer als Stichproben zum Release-Zeitpunkt.