Bevor wir uns ins Testen stürzen, steht ein entscheidender Schritt an: die Ausarbeitung einer Teststrategie. Zugegeben, das klingt nach harter Arbeit. Als Entwickler, so vermute ich, bist du hier, weil du einfach programmieren möchtest. Die Vorstellung, Zeit für die Entwicklung und Dokumentation einer Teststrategie aufzuwenden, ist wahrscheinlich nicht gerade verlockend. Doch ohne solch eine Strategie navigiert man blind durch unbekanntes Terrain, in der Hoffnung, das Ziel irgendwie schnell zu erreichen. Das Ergebnis sind meist zahlreiche Umwege, verpasste Abbiegungen und das ungern eingestandene Einholen von Wegbeschreibungen – wenn es denn überhaupt dazu kommt. Ich für meinen Teil setze lieber auf die direkteste Route und ein Navigationssystem als Wegweiser.
In diesem Artikel erhältst du Einblicke in die Schlüsselfragen, die für die Entwicklung deiner Teststrategie beantwortet werden müssen. Sobald diese Fragen geklärt sind, verfügst du über dein persönliches Navigationssystem für das Testen. Lass uns also ohne Umschweife loslegen.
Überblick
Erst einmal solltest du dir selbst auf die Schulter klopfen, weil du erkannt hast, wie wichtig die Automatisierung deiner Tests ist. Der Schritt von manuellen oder gar keinen Tests zu automatisierten Verfahren ist enorm und einmal gemacht, willst du bestimmt nicht mehr zurück.
Cypress bietet dir verschiedene Testarten an, wie Komponenten-, Ende-zu-Ende- und UI-Tests mit gemockten Netzwerkanrufen. Welche davon du zuerst in Angriff nimmst oder welche die wichtigste ist, hängt ganz von deinen spezifischen Bedingungen und Zielen ab. Ich weiß, diese „Es kommt darauf an“-Antwort ist nicht gerade das, was du hören möchtest. Am liebsten würde ich dir eine klare Richtung vorgeben, aber das wäre nicht in deinem besten Interesse, da jeder von uns unterschiedliche Testziele verfolgt und je nach diesen Zielen bestimmte Testarten effektiver sind als andere. Letztendlich können alle Testarten für deine Anwendung wichtig sein, oder manche werden nie eine Rolle spielen, je nachdem, was du erreichen möchtest.
Für eine bereits bestehende Anwendung, die du mit automatisierten Tests ausstatten möchtest, empfehle ich, erstmal von einem funktionierenden Code auszugehen. Erstelle Tests, wenn du Änderungen an bestehenden Funktionen vornimmst oder neue Features hinzufügst. So kannst du parallel zu neuen Entwicklungen eine solide Testbasis aufbauen.
Um herauszufinden, mit welchen Testarten du beginnen solltest, gibt es zwei zentrale Fragen zu klären:
1. Wo tauchen die meisten Fehler in deiner Benutzeroberfläche auf?
2. Was ist dein Ziel beim Wechsel von manuellen zu automatisierten Tests?
1. Wo tauchen die meisten Fehler auf?
Häufig führt der Weg zu automatisierten Tests über den Wunsch, die Flut an Fehlermeldungen von Kunden in den Griff zu bekommen. Zu viele Bugs schlüpfen durch, weil einfach nicht genug Zeit bleibt, alles manuell zu prüfen. Die Folge: mehr Zeit für Hotfixes als für neue Features. Unser Ziel ist es, das Vertrauen unserer Kunden in das von uns gelieferte Produkt zu stärken. Wir wollen sicherstellen, dass wir Fehler bereits vor der Veröffentlichung erkennen und so den Aufwand für Hotfixes minimieren. Außerdem wollen wir das beruhigende Gefühl haben, dass unsere Anwendung genau das tut, was sie soll, wenn wir sie veröffentlichen.
Die erste Frage zielt daher darauf ab, herauszufinden, wo die meisten Fehler in der Benutzeroberfläche auftreten, um den Nutzen der automatisierten Tests so schnell wie möglich zu maximieren. Je schneller wir Erfolge erzielen, desto einfacher wird es für alle Beteiligten – das Team, das Management und die Kunden – den Wert der Testautomatisierung zu erkennen und fortzuführen.
Hier ein paar Beispiele für häufige Fehlerquellen und die entsprechenden Testarten, die du in Betracht ziehen solltest:
Kommunikation mit deiner API:
Wenn die meisten Fehler in der Interaktion zwischen Benutzeroberfläche und API auftreten, solltest du mit Ende-zu-Ende-Tests beginnen. Diese Tests überprüfen den gesamten Ablauf deiner Anwendung – von der Benutzeroberfläche über die API bis hin zum Datenspeicher. In der Regel wird dabei nichts simuliert oder ersetzt. Es kann jedoch sinnvoll sein, externe APIs zu mocken, besonders wenn diese schwer zu testen sind, Beschränkungen haben oder kostenintensiv sind.
Benutzeroberflächenverhalten und -interaktion:
Treten die meisten Fehler durch Benutzerinteraktionen auf, lohnt sich ein Blick auf das Mocken von API-Aufrufen. So kannst du dich voll und ganz darauf konzentrieren, was auf der Benutzeroberfläche passiert, während der Nutzer damit interagiert.
Ein paar Beispiele für Verhalten und Interaktionen, die du testen könntest, sind:
- Wird das richtige Dialogfenster geöffnet, wenn ein Benutzer auf einen Button klickt, und sind die richtigen Aktionsbuttons vorhanden?
- Werden unzulässige Zeichen aus einem Eingabefeld entfernt, wenn ein Benutzer tippt oder einfügt?
- Werden Mindest- und Höchstgrenzen in einem Eingabefeld korrekt durchgesetzt?
- Wird ein Element auf der Seite basierend auf den Berechtigungen des Benutzers angezeigt oder ausgeblendet?
Diese und viele weitere Verhaltensweisen und Interaktionen sollten getestet werden, insbesondere wenn sie für die Mehrheit deiner Fehler verantwortlich sind.
Interaktion mit einer Drittanbieter-API:
Wenn du mit einer Drittanbieter-API arbeitest, ist es oft sinnvoll, Cypress für die Tests zu verwenden. Allerdings sollte die Interaktion mit der Drittanbieter-API idealerweise innerhalb deiner eigenen API ablaufen, um sensible Daten wie Geheimschlüssel zu schützen. Wenn die Kommunikation direkt über die Benutzeroberfläche läuft, könntest du entweder vollständige Ende-zu-Ende-Tests oder Tests mit gemockten API-Aufrufen in Betracht ziehen.
Einzelne Komponenten deiner Anwendung:
Falls die meisten Fehler in wiederverwendbaren Komponenten auftreten, sind Komponententests eine Überlegung wert. Damit kannst du die Komponenten isoliert testen.
2. Was ist dein Ziel beim Wechsel von manuellen zu automatisierten Tests?
Meistens entscheidet man sich für die Automatisierung, um bestehende Probleme in der Teststrategie zu lösen. Diese können von der Reduzierung aktueller Fehler bis hin zur Automatisierung von Tests für schwer manuell prüfbare Randfälle reichen.
Hier ein paar Ansatzpunkte:
- Reduzierung aktueller Fehler: Konzentriere dich auf die Behebung von Bugs durch gezielte Tests.
- Zeitersparnis in der QA: Identifiziere langwierige und kritische Tests, die automatisiert werden können.
- Automatisierung von Randfalltests: Bewerte den Einfluss von Randfällen, bevor du sie automatisierst.
- Überprüfung des „Happy Path“: Beginne hier und teste dann mögliche Fehler, die von deiner API zurückgegeben werden könnten.
- Ende-zu-Ende-Tests: Diese sind komplex und zeitaufwendig, aber entscheidend für kritische Funktionen.
Fazit
So verlockend es auch sein mag, direkt mit dem Coden zu beginnen – eine durchdachte Teststrategie ist der Schlüssel, um deine Ziele schnell und effizient zu erreichen. Sie dient als dein Navigationsgerät auf dem Weg zum Ziel. Und auch wenn wir manchmal glauben, es besser zu wissen als unser Navi, ist es erstaunlich, wie präzise es uns leitet.
