Softwaretesten-Blog

Soak-Tests haben ein Glaubwürdigkeitsproblem. Teams führen sie durch, erhalten einen einwandfreien Bericht, veröffentlichen den Build und stellen dann drei Tage später fest, dass in der Produktion ein Speicherleck auftritt. Der Testlauf war nicht fehlerhaft. Er hat genau das gemessen, wofür er konfiguriert war. Das Problem ist, dass die meisten Soak-Konfigurationen eine engere Fragestellung beantworten, als die Entwickler annehmen – weshalb erfolgreiche Testläufe und Speicherlecks in der Produktion weiterhin nebeneinander existieren.

Kennen Sie die Situation, in der ein über Nacht ausgeliefertes, kleines Update dazu führte, dass ein Kunde am nächsten Morgen den Checkout nicht mehr erreichen konnte? Die Änderung wirkte harmlos, doch sie beschädigte still und leise ein Feature, das monatelang niemand angefasst hatte. Genau diese Lücke zwischen „wir haben nur eine Kleinigkeit geändert“ und „etwas völlig anderes ist ausgefallen“ ist genau das Problem, das Software-Regressionstests lösen soll.

Ein Spieler setzt ein Headset auf, macht drei Schritte in Ihre wunderschön gestaltete Welt und reißt es sofort wieder herunter, weil sich sein Magen gerade umgedreht hat. Dieser Moment taucht in keinem Absturzprotokoll auf, aber er kostet Sie augenblicklich den Verkauf, die Bewertung und das Vertrauen des Spielers. In der virtuellen Realität (VR) entscheidet sich der Unterschied zwischen einem Fünf-Sterne-Meisterwerk und einer sofortigen Rückerstattung in Millisekunden: der Zeit, die ein Frame braucht, um anzukommen, und die eine Bewegung braucht, um sich im menschlichen Körper richtig anzufühlen – und nicht nur auf einem Monitor.

Ihr Team führt bereits negative Tests durch. Ungültige E-Mail-Adressen werden abgelehnt. Leere Pflichtfelder werfen die richtige Fehlermeldung. Grenzwerte sind für jede numerische Eingabe abgedeckt. Und trotzdem füllt sich das Support-Postfach weiterhin mit Dingen, für die niemand einen Testfall geschrieben hat: zwei identische Bestellungen, die durch einen Doppelklick im Abstand von 400 ms ausgelöst werden, eine Analytics-Pipeline, die an einem Emoji in einem Anzeigenamen abstürzt, eine Eindeutigkeitsprüfung, die john@acme.com und dieselbe Adresse mit einem unsichtbaren nachgestellten Leerzeichen als zwei verschiedene Konten behandelt.

Unity treibt einige der größten Titel der Welt an und bringt sie aus einem einzigen Projekt heraus auf Smartphones, Konsolen, Browser und Desktops. Genau diese Reichweite macht Unity-Spieletests so knifflig, denn ein Build muss auf iPhone, Android, Konsole und Desktop bestehen, und jede dieser Zielplattformen versagt auf ihre eigene Art.

Ein Team spielt einen nächtlichen Export aus, der in der Staging-Umgebung bei 999 Nutzern problemlos läuft und in der Produktion bei genau 1.000 einen Timeout erzeugt. Niemand hat „1.000“ ins Lastenheft geschrieben. Es gibt kein Formular zu validieren, keinen Altersbereich zu prüfen. Die Grenze ist real, und die Testsuite hat sie nie berührt.

Ihre App funktioniert einwandfrei auf Englisch. Dann bucht das Marketing einen Launch in Deutschland, Japan und Brasilien, und plötzlich wird der „Weiter“-Button zu „Weitermachen“, die Push-Benachrichtigung trifft um 3 Uhr morgens Ortszeit ein, und die App-Store-Screenshots zeigen immer noch US-Dollar-Preise. Das ist kein Übersetzungsproblem. Es ist ein Mobile-QA-Problem, und es sieht überhaupt nicht wie das QA aus, das Sie für den englischen Build durchgeführt haben.

End-to-End-Testing verifiziert, dass ein echter Nutzer einen echten Workflow über die tatsächliche Oberfläche abschließen kann, mit angebundenen echten Diensten. Integrationstesting verifiziert, dass zwei oder mehr Komponenten über ihre Schnittstellen korrekt kommunizieren.

Sie haben Monate damit verbracht, Ihre Spielmechaniken zu verfeinern und Ihre Grafik zu finalisieren, nur damit der Titel am Launch-Tag bei Spielern abstürzt, die bestimmte GPUs oder Mobilbildschirme verwenden. Das Spiel war nie kaputt. Es ist nur nie auf die Hardware getroffen, die Ihre Spieler tatsächlich nutzen.