Ohne jegliche Vorkenntnisse befragte ich Google und bekam viele Antworten. An einem Blogartikel blieb ich letztlich hängen, er lieferte mir eine Checkliste mit diversen Testfällen. Erleichtert darüber, ein Werkzeug für meinen ersten Testfall gefunden zu haben, machte ich mich ans Werk. Zuerst an das Testen der Registrierungsfunktion. Die erste Checkbox auf meiner Checkliste begann mit dem User Interface: “Klicke auf alle Buttons und finde heraus, ob sie funktionieren”.
Werde jetzt in 6-12 Monaten Software-Tester!
Weiter ging es mit verschiedenen Eingabemöglichkeiten für die Eingabefelder Username und Passwort. Was passiert, wenn man keine Eingaben bei Username und Passwort macht und trotzdem auf Anmelden klickt? Was passiert, wenn man nur einen Usernamen eingibt, aber kein Passwort festlegt? Wie reagiert die Anwendung auf Sonderzeichen? Kann das Passwort kürzer als 8 Zeichen oder länger als 16 Zeichen sein?
Ähnliche Testfälle wurden für das Einloggen vorgeschlagen. Ich testete unter anderem, was passiert, wenn man den korrekten Usernamen, jedoch ein falsches Passwort eingibt. Da Gruyere nun mal laut eigenen Angaben eine “cheesy page” ist, blieb es auch nicht aus, dass ich viele Testfälle aus meiner Checkliste nicht anwenden konnte. Zum Beispiel schlug meine Checklist vor, dass die E-Mail-Adresse aus Sicherheitsgründen zweimal abgefragt werden sollte. Angaben wie E-Mail-Adresse oder Telefonnummer wurden im Registrierungsprozesse bei Gruyere allerdings gar nicht erst abgefragt. Kühn dokumentierte ich solche Erkenntnisse als “Fehlende Features” und testete mich zielstrebig durch die weiteren Fälle. Die Zeit verging dabei zu meinem eigenen Erstaunen rasant schnell, und einige Testfälle später stand mein erster Bug-Bericht.
Gebannt wartete ich dann auf das Feedback von Jakob, und juhu, die Aufgabe wurde abgenommen. Ein Stein fiel mir vom Herzen, ich hatte ja so gar keine Ahnung, was von den Teilnehmern erwartet werden würde. Jakob erklärte mir dann auch noch in einem kurzen persönlichen Call, dass ich bei dieser Aufgabenstellung skript-basiert vorgegangen sei und bat mich, meine Herangehensweise im ersten Review meinen Teamkollegen vorzustellen.
Pair Testing Session und Heuristiken
Aufbauend auf unsere erste Testing Session im Alleingang galt es nun, dieselbe Aufgabe zusammen mit einem Teamkollegen und unter Anwendung von Testheuristiken durchzuführen. Zur Vorbereitung stellten die Coaches uns ein Videotutorial zur Verfügung, in dem wir alles über Heuristiken im Software Testen lernten. Allgemein sind Heuristiken Faustformeln aus Erfahrungen und Wissen aus der Vergangenheit, welche in der Zukunft genutzt werden können, besonders in neuen und unbekannten Situationen, in denen wenig Information vorliegt. Bsp: Wenn ein Computer sich aufhängt, starten wir ihn neu, ohne genau wissen zu müssen, warum das so funktioniert.
Tester haben in der Vergangenheit Erfahrungen gesammelt, welche Datentypen (z.b. Umlaute, Sonderzeichen oder lange Zeichenketten) Fehler verursachen können oder was bei der Navigation schieflaufen kann. Daraus sind Spickzettel entstanden, die frei im Internet verfügbar sind und die genutzt werden können, um neue Testideen zu generieren und strukturiert zu testen. Dabei muss man selbst nicht genau wissen, warum bestimmte Eingaben zu Fehlern führen.
Bei meiner Pairing-Session mit Yassin und Tasso fassten wir noch einmal zusammen, was wir aus dem Video gelernt haben und wählten dann 5 zum Testfall passende Heuristiken aus. Das waren: die maximale Zeichenkettenlänge für den Usernamen, die minimale Zeichenkettenlänge für das Passwort, Zeichenketten mit Leerzeichen am Ende, Zeichenketten mit Leerzeichen in der Mitte der Zeichenkette, asiatische Zeichen im Username und Passwort sowie Rechenzeichen im Username und Passwort.
Außerdem tauschten wir uns über unsere vorherigen Lösungsansätze aus. Ich stellte fest, dass beide ähnliche Features testeten wie ich, allerdings durch den Einsatz vorheriger Erfahrungen und eigenes Erforschen der Webpage die Testfälle selbst kreierten. Zu meiner Verteidigung muss ich aber auch erwähnen, dass Yassin und Tasso bereits einen IT-Hintergrund mitbringen 🙂
Letzter Teil dieser Aufgabe war es dann, sein ursprüngliches Vorgehen zu reflektieren und zu beschreiben, ob und wie sich der zuerst gewählte Ansatz unter Anwendung von Heuristiken geändert hat. Ich stellte fest, dass meine Vorgehensweise eine Mischung aus Skript-basiertem Testen und Testen mit Heuristiken war. Ich habe von Anfang an nach einer gewissen Struktur und Logik für meinen Testablauf gesucht und ein Skript in Form einer Checkliste im Netz gefunden. Mir schien, dass Heuristiken genau das ergänzten, wonach ich anfänglich suchte. Mein Ansatz hat sich entsprechend nicht gänzlich geändert, er wurde weiterentwickelt und fundierter.
First Testing Session mit Coach
Gespannt wartete ich auf den Termin zur ersten Testing Session mit Coach Jakob. Endlich würden wir einem richtigen Profi beim Testen über die Schulter schauen. Wie er das ganze wohl angehen wird, werde ich die Methoden, die er anwendet, überhaupt verstehen?
Um die Antwort vorwegzunehmen: ja, ich habe alles verstanden, außer die letzten 15 Minuten, in denen er die technische Perspektive der Seite untersuchte. Aber beginnen wir von Anfang an. Der Coach schaute sich die Webpage zuerst als Ganzes an und stellte sich dabei die Frage „Bauen wir das richtige System?“ Dieser Ansatz heißt Validierung und beinhaltet Überlegungen zum Kontext der zu testenden Software. Zum Beispiel fragte er sich, um welche Software es sich hier handeln könnte: ein Social Media Account, oder eine Bank? Was bedeutet das unter Sicherheitsaspekten für die Registrierung- und Log-In Voraussetzungen? Sicherlich muss das Passwort für eine Banking-App stärker geschützt sein als für eine einfache Gaming-App.
Wer nutzt die Software? Privatkunden, Geschäftskunden? Welchen Mehrwert soll diese Software den diversen Nutzergruppen bieten? Erst nachdem er das Produkt kritisch hinterfragt, einige Testszenarien gedanklich durchgespielt und eigene Erfahrungen beim Registrieren auf anderen Plattformen abgerufen hatte, beschäftigte er sich mit der Frage „Bauen wir das System richtig?“, der sogenannten Verifizierung. Hier geht es im Wesentlichen darum zu prüfen, ob die dokumentierten Anforderungen umgesetzt wurden. Hier nehmen wir die Anforderungen als gegeben an, während wir sie beim Validieren noch hinterfragen.
Genau in diesem Bereich kann ich meinen ersten Testansatz einordnen. Ich erstellte eine Checkliste, die ich Schritt für Schritt abarbeitete und dabei Abweichungen des Ist-Zustandes vom Soll-Zustand feststellte und diese Abweichungen dokumentierte.
Der Coach beschrieb und demonstrierte dann noch zusätzliche Methoden, wie das spezifikationsbasierte Testverfahren und das Bilden von Äquivalenzklassen.
Eine Mischung aus Validieren und Verifizieren stellt das explorative Testen dar. Hier handelt es sich um erfahrungsbasiertes Testen, zum Beispiel mithilfe eines sogenannten Chartres vorzugehen. Solch ein Charter könnte lauten: „Meine Mission ist es, die Anmeldefunktion aus technischer Perspektive zu erkunden“. Die Untersuchung der technischen Perspektive habe ich fasziniert mitverfolgt, jedoch noch nicht vollständig nachvollzogen. Ich bin aber schon gespannt auf den entsprechenden Sprint, wenn es darum geht, das Verhalten einer Software im Frontend und Backend unter die Lupe zu nehmen.
Zusammenfassend kann ich sagen, dass der größte Unterschied im Vorgehen des Coaches zu meinem Ansatz, neben der offensichtlichen Methodenvielfalt, in seinem Blick auf das große Ganze liegt. Sprich darin, sich erst einmal den Gesamtkontext des zu testenden Objekts anzuschauen und erst dann in die Details einzusteigen. Deshalb lautet ein großes Learning aus dem Workshop für mich: Kontext, Kontext, Kontext!