Code Qualität beim Testwerkzeug

Jan 21
2012

Wie gut muss die Qualität des Codes beim Testwerkzeug sein? Die Schulbuchantwort ist klar: (Mindestens) Gleich gut wie diejenige des produktiven Codes. Dafür gibt es verschiedene Gründe. Da wäre beispielsweise die Lebensdauer des Codes zu nennen: Der Code, mit dem die Regressionstests ausgeführt werden, lebt ebenso lang, wenn nicht sogar noch länger, wie das System under Test (SUT). Oft überleben sie das SUT sogar und werden als Referenz für das Nachfolgesystem weiter benützt.

Die Notwendigkeit ist also klar gegeben. Trotzdem ist es schon hart genug, die Testautomatisierung synchron zur Entwicklung hochzuziehen und eine ausreichende Abdeckung mit automatisierten Systemtests zu erreichen. Bereits dafür fehlt oft die nötige Zeit oder die Ressourcen. Und deshalb bleibt dann manchmal eben die Codequalität  auf der Strecke.

Die bei uns eingesetzten Werkzeuge Findbugs, PMD und Checksyle kennen da keine Gnade. Die Rulesets sind die gleichen wie beim produktiven Code und entsprechend fliegen uns auch die Violations um die Ohren. Und dann ist da noch das Problem, dass ich beim neuen Code darauf achte, regelkonform zu sein, aber dann sind da noch die Hunderte von Violations, die eben schon vorher drin waren. Und das schlägt dann eben auch noch etwas auf die Motivation.

Ähnliche Probleme stellen wir auch bei unseren Unittests fest. Auch da fällt es schwer, die gleiche Qualität zu erreichen und einzufordern.

Da bleibt wohl nichts anderes übrig, als sich wieder einen Ruck zu geben – und dann los auf die Violations. Heute wird aufgeräumt!

Embedded Testing in Scrum

Jan 14
2012

Als Teammitglied mit dem Fokus Testing im Scrum Team drin. So macht es meiner Meinung nach Sinn. So sind die Wege wirklich kurz, Bugs werden gefunden und gefixt mit minimalem Overhead und ich bin als Tester wirklich embedded – mitten im Team drin. Soweit die guten Neuigkeiten.

Die Schwierigkeiten, die wir zuvor mit konventionellen Testphasen nach der Implementierungsphase hatten, sind aber natürlich nicht verschwunden. Wie erfahre ich, was wirklich implementiert wurde und was Req Engineering und Entwicklung noch bilateral abgesprochen haben? Wie vermeide ich Doppelspurigkeiten zwischen Test auf verschiedenen Stufen – üblicherweise Integrationstest, die der Entwickler in JUnit schreibt und meinen automatisierten Systemtest?

Basierend auf einem Workshop bei Janet Gregory  haben wir zwei Synchronisierungspunkte in unserem Prozess eigeführt zwischen dem Entwickler und dem Tester eines bestimmten Features:

Das Meeting “Share-Test-Ideas” zur Absprache, wer welche Tests macht. Diese Synchronisierung findet bevor oder zu Beginn der Umsetung eines Features statt.

Und dann noch die “Show-Me-Session” sobald das Feature testbar und im Nightly Build drin ist, um zu besprechen, was nun wirklich realisiert wurde.

Diese Klammer um die Umsetzung bewirkt zwar keine Wunder, bringt aber enorm viel für die Zusammenarbeit und die Effizienz.

Im März 2012 werde ich am Swiss Testing Day einen kurzen Vortrag zu diesem Thema halten: Überleben als Embedded Tester im Scrum Team -Heisse Drähte, enge Verknüpfungen und gordische Knoten

 

Categories