Workshop Testautomatisierung mit Lego Duplo
06.10.2016

Expertenworkshop: Automatisierung im Testing mit Lego Duplo Bausteinen

Bunt, anschaulich und spielerisch begreifbar – die Testwelt verfeinern

Automatisierung spielt sowohl in der Softwareentwicklung als auch im Softwaretest eine immer größere Rolle. Im Berufsalltag begegnet sie uns beispielsweise in Form von Continuous Integration, Behavior Driven Development (BDD) und automatisierten GUI- und Schnittstellentests. Doch wann sind die Grenzen der Automatisierung erreicht? In einem Workshop mit Richard Bradshaw* analysierten drei QualityMinds (Ron, Wiebke und Nicole) gemeinsam mit 19 weiteren IT-Experten in den Räumlichkeiten von MaibornWolff die automatisierte Testdurchführung. Das Ganze lief fernab von der technischen Vorgehensweise mit unzähligen Zeilen an Code und farbig-plastisch mithilfe der großen bunten Bausteine „Lego Duplo“!

Das Workshop Setup zu Beginn

Die erste Aufgabe bestand darin, einen Duplo-Turm aus einem grünen, blauen, gelben und roten Baustein gleicher Größe symmetrisch aufeinandergesteckt zusammenzubauen. Dafür starteten wir in 2er Teams: eine Person übernahm die Rolle des ahnungslosen Roboters und die zweite sich widmete der Testerrolle. Der Roboter hatte nur Skills wie 'Laufen' und 'Sehen', der restliche Input erfolgte über Testschritte mittels Skript durch den Tester. Die Lego Duplo Steine befanden sich im Raum verteilt - an beschilderten Stationen nach Farben sortiert. Allerdings gab es auch verschiedene Größen der Bausteine (4er, 8er, flache 8er) innerhalb einer Farbe. Wer sich als Tester also nicht zuerst einen Überblick im Raum verschaffte, versäumte diese Info an den Roboter zu übergeben. Auch in der Testpraxis liegt der Fokus oftmals auf der Ausarbeitung des Testskripts, um die Anforderungen abzudecken, ohne ein einziges Mal die bisherigen Testschritte überhaupt ausgeführt zu haben. So vergingen im Workshop über 40 Minuten, bis der erste Roboter sich in Bewegung setzte. Ebenso war es nicht unüblich, dass der Roboter auf die Reise geschickt wurde und mit einem wirr zusammengebauten Lego Klotz zurückkam.

„Was wäre wenn ...": Skript anpassen in Phase 2

Nachdem das Testskript angepasst wurde, um z. B. Größe, Ober-/Unterseite des Bausteins und korrektes Zusammenbauen zu berücksichtigen, gab es nochmals erschwerte Bedingungen:

  • Duplo Steine steckten zusammen (... obwohl man doch nur einen benötigte).
  • Die ausgeschilderte Farbe an der Station stimmte nicht mehr mit der Farbe der Bausteine überein oder das Schild wurde komplett verdeckt.
  • Zwischen den Duplos lagen gleichfarbige Smarties.

Der Roboter bekam demnach aktualisierten und/oder ergänzenden Input per Skript, um dynamischer auf Veränderungen zu reagieren. Wie im Testeralltag übrigens auch: Es ist wichtig, sich nicht im "Was wäre wenn ..."-Labyrinth zu verlieren.

Im Anschluss daran wurden die erstellten Testskripte unter den 2er Teams ausgetauscht und erneut auf die Probe gestellt:

  • Sind die Vorbedingungen/Annahmen eindeutig definiert?
  • Sind die jeweiligen Testschritte von anderen Teilnehmern eindeutig nachvollziehbar?
  • Ist das Skript in der vorliegenden Form ausführbar oder wurden zuvor angenommene Bedingungen als Zwischenschritte übersehen?
  • Ist das Skript problemlos bearbeitbar und/oder erweiterbar?

Diese Fragen sind auch im Projektalltag unbedingt zu berücksichtigen, falls z. B. der zuständige Kollege für die Testautomation im Projekt wegfällt oder man als Testexperte in einem neuen Projektteam für die Automatisierung zuständig ist.

Teams durchmischen - Endphase

Für die Endphase bildeten wir neu gemischte 5er Teams. Jedes Team entschied nun selbst über die Anzahl der Automatisierer und Roboter.

Zudem gab es neue Anforderungen: Es galt, zusätzliche Farben und Formen an Duplo Steinen zu berücksichtigen. So bauten wir u. a. die Simpsons und Marvel Superhelden nach :) Für das Skript bedeutete dies weitere Anpassungen hinsichtlich modularem Aufbau und Skalierbarkeit.

Die essentiellen Learnings aus dem Workshop-Tag:

  • „Warum?" Hinterfrage die Anforderung.
  • Beginne minimalistisch und vermeide unnötige Komplexität.
  • Gehe einen Test zunächst manuell durch.
  • Analysiere, ob wirklich jeder Testfall automatisiert umzusetzen ist.
  • Debugge das Skript. (Kein Tester war mit seinem Roboter mitgelaufen, um zu sehen, was passierte.)
  • Baue Exception Handling mit ein, um auf Unvorhergesehenes reagieren zu können.
  • Berücksichtige die Performance des Skripts.
  • Behandle Automationscode wie Produktivcode: er hat hohe Aussagekraft für die Qualität.
  • Verwende bestehende Code-Teile wieder, z. B. um Testumgebungen zu initialisieren und zu starten oder um Testdaten zu erzeugen.
  • „Test early, test often“: Dies war von Runde zu Runde ein immer wieder angesprochenes Thema, welches nicht zu vernachlässigen ist.


Begriffsanpassung führt zu Perspektivwechsel

Darüber hinaus berichtete Richard über einen psychologisch positiven Effekt: Seitdem er bei Kunden nicht mehr von Testautomatisierung, sondern Automatisieren im Testing spricht, habe sich die Richtung der Fragen geändert. Statt um Fragen zu womöglichen Kosten-/Personaleinsparungen durch die Testautomatisierung geht es dann um Aspekte wie „Welche Art von Automatisierung ist möglich?“ oder „Welche Tools sind für unseren Zweck in der Automatisierung nützlich?“. Als Experte hält er es für nicht möglich, das Testen zu automatisieren, sondern den Einsatz von Automatisierung im Softwaretest unterstützend als Werkzeug zu nutzen. Beispielsweise kann es gelingen, durch automatisierte Prüfung Abweichungen der Testkriterien aufzudecken oder automatisiert synthetische Testdaten zu generieren.

Es war ein sehr spannender, interessanter und empfehlenswerter Workshop mit Richard Bradshaw!

Wie ist eure Erfahrung zu Automatisierung im Testing? Schreibt uns gern eure Meinung in die Kommentare.

* Mehr über Richard Bradshaw:
Als leidenschaftlicher Software-Tester teilt er seine Erfahrungen mit der Testing Community über seinen Blog "thefriendlytester.co.uk" und auf sozialen Netzwerken, wie Twitter @FriendlyTester sowie auf YouTube mit seinem Channel Whiteboard Testing. Zudem ist Richard weltweit auf Konferenzen anzutreffen, bietet Workshops an und wirkt bei "Ministry of Testing" www.ministryoftesting.com mit.

back

Kommentare