Seite 4: Fazit

Inhaltsverzeichnis

Gehirn einschalten nicht vergessen

Testautomatisierung und TDD sind kein Allheilmittel (vgl. [6]). Auch wenn sich ein hohes Maß an Abdeckung mit Techniken wie TDD und ATDD erreichen lässt, gibt es stets Risiken, die unabhängig davon anzugehen sind. Sie lassen sich nicht durch Automatisierung adressieren, sondern nur durch das kreative Gehirn eines guten Testers.

Beim explorativen Testen handelt es sich gleichzeitig um Testdesign, Testausführung und Lernen: Durch das Ausführen von Experimenten in Form von Tests ändert sich kontinuierlich das mentale Modell, dass der Entwickler von der zu testenden Software hat. Jede Aktion bestätigt oder widerlegt eine Hypothese, die zum Modell passt. Jede widerlegte Hypothese hingegen ist ein Signal, dass das Modell der Applikation noch nicht zu Ende gedacht ist.

Für exploratives Testen gibt es gute und weniger gute Vorgehensweisen, wobei sich gutes Testen durch die bewusste Nutzung von Testorakeln auszeichnet. Diese dienen dazu, eine Referenz für beobachtete Fehler zu haben. Beispielsweise kann eine Abweichung vom iOS-Plattform-Standard ein kritischer Fehler sein. Die Vorgaben von Apple dienen somit als Orakel für iOS-Applikationen. Außerdem existieren Fehler-Taxonomien, die applikationsunabhängige Fehlerquellen für verschiedene Anwendungsfelder beinhalten, wie unterschiedliche Zeichenketten, bei denen Fehler auftreten können.

Mehr Struktur erhalten explorative Tests durch sogenanntes Session-basiertes Testmanagement. Dabei wird die Testzeit in kleinere Abschnitte unterbrechungsfreien Testens geteilt. Diese Sessions können zwischen 30 und 120 Minuten lang sein. Damit in der Zeit der Fokus auf dem zu bearbeitenden Problem liegt, kann eine Testcharter helfen, die daran erinnert, wonach gerade zu suchen ist [7]. Jede Session hat dann einen gezielten Forschungsauftrag, der vor deren Beginn in der Charter hinterlegt wird – zum Beispiel am Ende einer Entwicklungsphase, vor dem Einchecken des Codes.

Qualität von Anfang an

Agile Softwareentwicklung hat das erste Jahrzehnt dieses Jahrhunderts geprägt. Vor allem durch die technischen Praktiken kann eine hohe Softwarequalität erzielt werden. Automatisierte Tests helfen dabei, den aktuellen Stand der Applikation stets transparent zu halten und Probleme in einer kurzen Feedbackschleife zu erkennen (Abb. 6).

Mit Hilfe von Continuous Integration lassen sich nicht nur die automatisierten Tests selbstständig ausführen, sondern auch Codemetriken über das Projekt ermitteln und Fortschritte – hoffentlich in positiver Richtung – beobachten. Mit TDD kann der Entwickler sicherstellen, dass der Code richtig implementiert ist, während ATDD oder BDD gewährleisten, dass am richtigen Code gearbeitet wird. Trotz massiver Automatisierung existieren noch Lücken in der Abdeckung. Sie lassen sich jedoch häufig durch gezielte explorative Tests schließen, womit letztlich viele Risiken in der Entwicklung vor der Auslieferung adressiert sind.

Markus Gärtner
arbeitet als testender Programmierer, Trainer, Coach und Berater für it-agile. Er gründete 2010 den German Agile Testing and Exploratory Workshop und steuert zur Softwerkskammer der deutschen Software-Craftsmanship-Bewegung bei.

Literatur

1. Gerald M. Weinberg; How we used to do unit testing; 2008
   
2. Gerard Meszaros; xUnit Test Patterns – Refactoring Test Code; Addison-Wesley; 2007
3. Cem Kaner, Walter P. Bond; Software Engineering Metrics – What do they measure and how do we know?; 2004
4. Markus Gärtner; ATDD by Example – A Practical Guide to Acceptance Test-driven Development; Addison- Wesley; 2012
5. Gerald M. Weinberg, Don Gause; Exploring Requirements – Quality Before Design; Dorset House; 1989
6. Frederick Brooks; The Mythical Man-Month; Addison-Wesley; 1985
7. Elisabeth Hendrickson; Explore It! – Reduce Risk and Increase Confidence with Exploratory Testing; Pragmatic Programmers; 2012

(jul)