Suche
Kolumne

Der Selbsttest: In vier Stunden zum Softwaretester?

Marvin Bodziuk

© Shutterstock.com / Maksim M

 

In dieser Ausgabe unserer Kolumne über Qualitätssicherung und Testing erklärt Marvin Bodziuk von BREDEX, was der Four-hour Tester ist und was er bei seiner Recherche gelernt hat. Außerdem gibt er anhand von konkreten Ergebnissen aus seinem Selbstversuch eine Übersicht über das Erlernte und beantwortet die Frage, ob es möglich ist, in vier Stunden ein Tester zu werden.

Was ist der Four-hour Tester?

Das Ziel der Übungen ist konkret, neuen Testern wichtige Skills beizubringen. Die ursprüngliche Idee kam von Timothy Ferriss mit dem Konzept „The 4-Hour Chef“, und es wurde von Helena Jeret-Mäe und Joep Schuurkes adaptiert. Die zentrale Frage hierbei ist:

Can you learn the skills of a tester in four hours?

Diese Frage soll mithilfe von Übungen zu den folgenden Bausteinen erreicht werden:

  • Interpretation
  • Modeling
  • Testdesign
  • Note Taking
  • Bug Reporting

Als Testanwendung wird der Google-Kalender verwendet, der Ablauf zu den jeweiligen oben aufgeführten Übungen ist immer der gleiche.

  1. Zuerst erfolgt ein Briefing, um die Motivation hinter der Übung zu erklären und die anzuwendende Methode vorzustellen.
  2. Danach erfolgt die Übung. Es gibt eine Beschreibung der Aufgabe und das Zeitfenster (ca. 1 Stunde pro Übung).
  3. Nach der Übung macht der Tester eine Evaluierung der Übung anhand von Fragen, die ihm dazu gestellt werden. Der Nutzen der Übung für das Testen soll ihm dadurch klar werden.
  4. Obwohl es nicht explizit gefordert ist, haben wir intern eine kleine Diskussionsrunde zu der Übung eingeführt. Der Mentor und der Tester nehmen daran teil. So können weiterführende Themen und Ideen angesprochen werden.

Erste Aufgabe: Die Interpretation

Diese Übung handelt davon, wie die gleichen Wörter auf unterschiedliche Art und Weise verstanden werden können. Das Ziel der Übung ist es, Anforderungen und Annahmen in Frage stellen zu können. Der Satz für die Übung lautet:

Reminders carry over to the next day until you mark them as done.

Durch den Fokus auf unterschiedliche Worte merkt man, wie die Aussage unterschiedlich verstanden werden kann. In der Tabelle sind ein paar Ergebnisse von mir enthalten. Das hervorgehobene Wort wurde dabei fokussiert.

Statement In contrast to
Reminders carry over to the next day until you mark them as done. Reminders, not meetings or anything else
Reminders carry over to the next day until you mark them as done. Via multi-select? Or is only single-select available?
Reminders carry over to the next day until you mark them as done. Only to the next day, not longer. Also, how are we defining “day”, especially in different time zones?
Reminders carry over to the next day until you mark them as done. Yourself not someone else
Reminders carry over to the next day until you mark them as done. You need to mark them, not swipe them or carry out some other action

Bei der Evaluation wurde unter anderem gefragt, wie unterschiedlich zwei Implementierungen sein können, wenn ihre Entwickler unterschiedliche Interpretationen eines Satzes als Grundlage verwendeten und welche Verhaltensweisen nach welcher Interpretation als Bugs identifiziert werden würden.

An diesen Fragen lässt sich gut die Idee hinter der Aufgabe erkennen. Die Übung hilft sehr zu verdeutlichen, wie wichtig Kommunikation in der Softwareentwicklung (und überall anders, wo Menschen gemeinsam arbeiten) ist. Mangelnde oder schlechte Kommunikation führt schnell zu unerfreulichen Resultaten. Deshalb ist es wichtig, dass Tester Fragen stellen. So können Funktionen besser implementiert und auch getestet werden.

Modeling unter Zuhilfenahme von Tours

Die zweite Übung beschäftigt sich mit sogenannten Testing Tours. Der Fokus liegt dabei auf Konfiguration-, User- und Data-Tours. Diese sollen explorativ für den Kalender von Google angewandt werden.

In der Ausarbeitung und Diskussion haben wir für die Data-Tour noch das CRUD-Akronym (Create Read Update Delete) verwendet, um Datenelemente der Anwendung ausfindig zu machen. Eine weitere Hilfestellung in Bezug auf den Google-Kalender war die folgende Aufteilung:

Attributes  Data elements  Data objects
Time  Appointment  Calendar
Place  Reminder  User
Person  Calendar

Für die Übung sollen für jede Tour frei Funktionen aufgeschrieben werden, die man gerne testen würde. Danach soll beschrieben werden, wie die Tours einem geholfen haben, unterschiedliche Testideen zu kreieren.

Ich fand es sehr hilfreich, die Touren als Testidee zu nehmen und mich so durch die Anwendung führen zu lassen. So wird einem leichter klar, wie die Anwendung funktioniert, welche Bereiche eventuell Probleme aufweisen und es fallen einem dabei weitere Testideen ein.

Vom Ansatz zur konkreten Idee: Testdesign

In der dritten Übung geht es darum, Testideen feiner zu granulieren, um von einer High-Level-Idee zu einem konkreten Testfall zu kommen. Dieser Schritt steht stellvertretend für das Testdesign.

Als Hilfestellung wird Elizabeth Hendricksons ​„Test Heuristics Cheat Sheet“​ vorgegeben. Anhand dieser Hilfe soll man 20 Minuten lang Bereiche aus der vorherigen Aufgabe explorativ testen. Anstatt nur die Ideen aus dem Cheat Sheet zu nutzen, habe ich mir selbst zusätzliche Gedanken gemacht und versucht, eigene Tests zu designen. Für meine Ideen habe ich eine Mind Map erstellt:

Nachdem ich diese Ideen gesammelt hatte, wurden die Ideen im nächsten Schritt explorativ im Google-Kalender angewandt und die Beobachtungen notiert.

Das Note Taking – warum Notizen wichtig sind & wie man sie strukturieren kann

Die Aufgabe besteht darin, innerhalb von 20 Minuten ein Feature des Kalender zu erkunden. Dabei sollen Dinge ausgetestet werden und Notizen zum Beobachteten gemacht werden. Um die Notizen zu strukturieren, werden folgende Markups vorgeschlagen:

  • Zeit und Datum des Tests
  • ?: Frage
  • !: Neugierde / Darauf aufmerksam machen
  • B: Bug
  • Glühbirne: Idee für weiterführendes Testing
  • OK: – Sieht für mich gut aus

Ich habe mir den Termin als Feature ausgesucht, weil es dort besonders viele Möglichkeiten und Features zu erkunden gibt. Ein Auszug aus meinen Notizen sah so aus:

  • ?: Sollte die Ortsliste alphabetisch sortiert werden? Es ist möglich, einen Termin ohne Datum und Uhrzeit zu speichern
  • OK: Ungültige Emails werden erkannt

Die Krux an dieser Aufgabe ist, dass man die Notizen am nächsten Tag lesen soll, um zu testen, ob man sie noch versteht. Durch diesen zeitlichen Abstand zu den eignen Notizen merkt man, wie wichtig es ist, überhaupt Notizen anzufertigen und diese strukturiert, ausführlich und verständlich aufzuschreiben. Resultierend aus dieser Erfahrung habe ich mein eigenes „Test Report Sheet“ erstellt.

Wie man einen Bugreport strukturiert

Im letzten Teil geht es um die PEW Heuristik von Michael Bolton. Diese beschreibt die Basics eines guten Bugreports. PEW steht dabei für:

  • Problem – Beschreibung des Problems
  • Example – Anhand eines Beispiels soll das Problem erklärt werden
  • Why – Warum ist es ein Problem

Als Aufgabe soll mit Hilfe der Heuristik ein alter Bug des Kalenders beschrieben werden. Im Nachgang soll der selbst geschriebene Report sowie die Unterstützung der PEW-Aufteilung bewertet werden und mit dem alten Bugreport verglichen werden.

Ich empfinde die Heuristik als sehr hilfreich. Wendet man diese an, sind automatisch die wichtigsten Punkte in dem Bugreport enthalten. Zusätzlich hilft sie dem Verfasser des Reports dabei, nicht zwischen Themen hin und her zu springen und somit die Struktur beizubehalten.

Bin ich jetzt Tester?

Nach den Übungen war ich insgesamt zwar etwas länger als vier Stunden unterwegs, vor allem aber, weil wir viel dazu diskutiert und recherchiert haben.

„Can you learn the skills of a tester in four hours?”

Natürlich nicht!

Die meiner Meinung nach vorgestellten Skills sind:

  • Durch die Interpretation wird die Tragweite des Requirements Engingeering verdeutlicht.
  • Durch das Modeling werden mögliche Wege der Generierung von Testideen aufgezeigt.
  • Durch das Test Design erfolgt eine Granulierung von Testideen. Es wird klar, wie die gefundenen Ideen sich verfeinern lassen.
  • Note Taking: Man lernt, warum Reporting hilfreich für einen selbst und für andere ist.
  • Bug Reporting: Die Bedeutung von gut strukturierten Bugreports wird transparent.

Diese Skills können nur durch regelmäßiges praktisches Anwenden erlernt werden. Das heißt, sie müssen anhand weiterer Aufgaben vertieft und immer wieder in der Praxis umgesetzt werden. Zusätzlich sollte gerade am Anfang die Möglichkeit gegeben sein, offene Fragen zu stellen. Idealerweise können regelmäßige Reviews durch einen Mentor bzw. durch erfahrene Kollegen duchgeführt werden.

Sind diese Möglichkeiten gegeben und werden die Skills regelmäßig praktisch angewandt und weiter vertieft, kann man auf der Grundlage des 4-hour testers, sehr gut zum Tester werden.

Qualitätssicherung & TestingQualitätssicherung und Testing

In der Kolumne „Test IT“ zu Qualitätssicherung und Testing teilen die Test Consultants der BREDEX GmbH mit unseren Lesern regelmäßig ihre Erfahrungen sowie Tipps & Tricks für das Testen und die Testautomatisierung.

Bisher erschienen:

Geschrieben von
Marvin Bodziuk
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: