Unsere erste Aufgabe war die Recherche zum Thema: „Szenario-basiertes Testen“. Es wurden einige Artikel bereitgestellt, welche selbstständig bearbeitet werden mussten. Als Szenario versteht man eine hypothetische Geschichte. Es ist eine Story über einen User, der etwas Bestimmtes mit dem Produkt erreichen will. Szenarien sollen dabei helfen, das zu testende Produkt zu verstehen und zu lernen. Man erkundet mithilfe der Szenarien das Produkt. Bei der Erstellung von Szenarien sollte man dabei beachten, dass 5 Eigenschaften für das gewählte Szenario erfüllt sind:
- Ein ideales Szenario ist eine Story,
- ist motivierend,
- ist glaubwürdig,
- ist komplex und sollte einfach zu bewerten sein.
Werde jetzt in 6-12 Monaten Software-Tester!
Vorteile vom Szenario-basierten Testen
Der große Vorteil von Szenario-basiertem Testing ist, dass man Probleme aufdecken kann, welche in der Beziehung zwischen verschiedenen Features auftauchen. Es gibt viele verschiedene Möglichkeiten, wie man sich als Tester:innen Szenarien herleiten kann.
In diesem Artikel werden nur einige exemplarische Möglichkeiten erörtert, um Szenario-basierte Tests zu erstellen. Zunächst kann man sich überlegen, wer die User:innen des Produkts sind und deren Ziele und Interessen fokussieren. Ein Beispiel wäre: Als Facebook-Nutzer:innen möchte ich Freunde auf Facebook suchen und meinen Freunden eine Nachricht schicken. Ein weiterer Ansatzpunkt wäre zu überlegen, welche Vorzüge das System bietet und für diese Features, dann End-2-End Checks erstellen.
Ideen für Szenario-basierte Tests
Um weitere Ideen für neue Szenarien zu generieren, kann man auch User:innen interviewen und beobachten, wie das System tatsächlich genutzt wird. Alternativ kann man auch Beschwerden über das System erforschen. Bei der Analyse des Systems kann man auch einen Fokus auf die möglichen Transaktionen und Arbeitssequenzen legen und diese in der Herleitung für neue Szenarien verwenden. Es wird deutlich, dass es wirklich eine Menge Ansatzpunkte gibt, um geeignete Szenarien für das Testing zu entwickeln.
Risiken beim Szenario-basierten Tests
Es sollte allerdings noch beachtet werden, dass das Szenario-basierte Testen auch seine Risiken birgt. Ein Risiko ist, dass manche Szenario-basierte Tests sehr komplex konzipiert werden. Wenn allerdings ein Feature fehlerhaft ist, kann der Rest des Tests nicht ausgeführt werden. Sobald das erste Feature gefixt wurde, könnte die nächste fehlerhafte Funktion den Test blockieren. Daher macht es z.B. bei neuen Features mehr Sinn, wenn zunächst Szenarien entworfen werden, die das neue Feature isoliert testen. Auf diese Weise können früher Fehler gefunden werden. Sobald die Funktionalität des neuen Features sichergestellt wurde, können im nächsten Schritt, komplexere Anwendungsfälle über mehrere Features hinweg getestet werden.
Ein weiteres Risiko ist, dass Szenario-Tests häufig umfassend dokumentiert werden und viel Zeit in Anspruch nehmen. Häufig werden dann, aus Zeitgründen, dieselben Szenario-Tests wiederholt ausgeführt. Man sollte allerdings nicht immer dieselben Szenario-Tests mit denselben Daten wiederholen.
Szenario-basiertes Test – Variation der Parameter
Damit Szenario-Tests nicht an Wirksamkeit verlieren, sollten einzelne Parameter von bereits ausgeführten Szenario-Tests geändert werden, wie z.B. die Testdaten oder die Testumgebung. Die neuen Parameter tragen dazu bei, mehr über das Produkt zu lernen oder unter Umständen neue Probleme aufzudecken.
Fokus von Szenario-basierten Tests
Szenario-basierte Tests sollten nicht den Fokus haben, einfach zu verifizieren, dass die dokumentierten Anforderungen erfüllt wurden. Beim Szenario-basierten Testen sollte der Fokus des Testings darauf liegen, ob die umgesetzten Anforderungen, die Probleme der Nutzer:innen, gut lösen. In diesem Kontext sollten die Szenario-basierten Tests validieren, ob auch tatsächlich das richtige System bzw. Feature für die Nutzer:innen gebaut wird.
Weitere User Stories im Sprint
Als weiteres Sprint-Ticket hatten wir die Aufgabe, die ersten zwei Kapitel eines von der Qcademy selbst erstellen online Kurs durchzuarbeiten. Es handelte sich dabei, um einen Kurs zum Thema: „Web Development“. Im ersten Kapitel wurde allgemeine Fragen zum Thema Frontend Webentwicklung geklärt. Es wurden grundlegende Sachen erläutert, wie z.B. Webseiten aufgebaut sind und wie das Internet funktioniert.
Im zweiten Kapitel musste dann interaktiv mitgearbeitet werden. Zuerst wurden die Grundlagen zu HTML besprochen und dann mussten wir bereits selbst loslegen und eigene HTML-Seiten erstellen. Das hat sehr viel Spaß gemacht und am Ende hatte man eine schöne Homepage mit einigen Webelementen wie z.B. Links, Bildern und Listen erstellt.
Software Testing in der Praxis
Richtig spannend wurde es dann, als wir ein erstes reales Projekt zum Testen bekommen haben. Wir haben eine Software von einem Kunden zur Verfügung gestellt bekommen und durften dann „echtes“ Software Testing machen.
Zunächst mussten alle Teammitglieder:innen in Eigenregie sich anschauen, wie das Produkt funktioniert. Danach gab es eine zeitlich begrenzte explorative Testsession. Jede:r konnte das Produkt eigenhändig erkunden und sollte dabei festgestellte Fehler dokumentieren. Nach der explorativen Testsession, erfolgte dann eine Szenario-basierte Testsession. Hier sollten wir uns eigene Szenarien ausdenken und diese entsprechend durchtesten.
Für mich war dabei die spannende Erkenntnis, dass man sowohl mit dem Szenario-basierten Testen als auch beim explorativen Testen auf kritische Bugs stoßen konnte. Es hat sehr viel Spaß gemacht auf Fehlersuche zu gehen und dem Kunden dabei zu helfen, Qualitätsprobleme zu finden. Nachdem jedes Teammitglied das Produkt in Eigenregie testen durfte, war die nächste Aufgabe, das Produkt in einer gemeinsame Testsitzung mit einem anderen Teammitglied zu testen.
Beim sogenannten Pair Testing testet man zusammen und entwickelt gemeinsam Testideen. Zunächst haben wir uns ausgetauscht, was wir gemeinsam testen wollten und dann zunächst auf meinem Rechner und dann auf dem Rechner meines Kollegen getestet. Auch hier war die spannende Erkenntnis, dass neue Fehler auftauchten. So hatte mein Kollege MS Office nicht auf seinem Rechner installiert und hatte daher im Produkt des Kunden nur eingeschränkte Exportfunktionalitäten.
Diese Tatsache ist mir bei den Einzeltestsitzungen nicht aufgefallen, da ich diese Software bereits auf dem PC vorinstalliert hatte. Uns sind dann auch noch einige Performance- und Usability-Probleme negativ aufgefallen, welche wir dann in unserem gemeinsamen Bericht vermerkt haben.
Mein Sprint Highlight
Mein Sprint HighlightEines meiner wöchentlichen Sprinthighlights sind meine Coding-Sessions mit Jessy. In diesen Sessions werden mir die Grundlagen der Programmierung beigebracht, um mich dann später für die Testautomatisierung fit zu machen.
In unseren ersten Sessions hat mir Jessy beigebracht, wie Java im Detail funktioniert, was ein Compiler ist, was Build-Tools sind und wozu Entwicklungsumgebungen (IDEs) gut sind. Nach der kleinen theoretischen Einführung ging es dann mit der praktischen Einführung weiter. Ich sollte zunächst Java installieren und die JAVA_HOME Umgebungsvariable konfigurieren. Im Anschluss habe ich dann noch IntelliJ installiert und mein erstes eigenes Maven Projekt erstellt.
Nach dem Sprint ist vor dem Sprint und ich bin gespannt, welche Challenges uns in Sprint 3 erwarten.
Wie mein erster Sprint verlaufen ist, erfährst Du im Artikel: Josefs erster Sprint im Lernkonzept der Qcademy
Wie meine ersten Schritte in der Programmierung verlaufen sind, erfährst Du in meinem Artikel: Ein manueller Software-Tester lernt die Programmierung
Mehr über mich und meine Geschichte erfährst Du im Artikel: vom manuellen Softwaretester zum Testautomatisierer
