Die XP-Regel

Der Kern dieser Aussage betrifft den Umstand, dass es keine allgemein gültige Regel dafür gibt, welche Elemente in einer Software besonders fehleranfällig sind. Jedes Team, jeder Entwickler macht seine spezifischen Fehler. Betrachtet man diese Fehler über die Zeit hinweg, so stellt man fest, dass sie sich oft ähneln. Daraus können systematisch Lehren gezogen werden, die das eigene Handeln verändern und damit auch die Art der begangenen Fehler. Dies gilt es auch beim Schreiben der Testfälle zu beachten.

Um kritische Teile zu identifizieren, die besonders sorgfältig getestet werden sollten, mag zudem folgender Hinweis helfen: Teste überall dort, wo bereits viele Fehler aufgetreten sind. Gemäss dem Pareto-Prinzip sind im Schnitt 90% der Fehler in weniger als 10% der Klassen in einem System zu finden.

Es stellt sich weiter die Frage nach der richtigen Anzahl von Tests. Auch hier muss jedes Team und jeder Entwickler sein persönliches Testniveau finden. Hier gilt es, sich iterativ an den jeweils optimalen Wert heranzutasten. Werden zum Beispiel viele Fehler erst nach der Freigabe einer Software entdeckt, dann liegt die Vermutung nahe, dass zu wenig Testfälle geschrieben wurden. In diesem Fall lohnt es sich, die aufgetretenen Fehler sorgfältig zu analysieren, um Aufschluss über die Art der gemachten Fehler zu erhalten und das eigene Testverhalten zu verbessern.

Dagegen kann es vorkommen, dass das Schreiben der Testfälle zunehmend Zeit zu verschlingen scheint und die Tests bei Refactorings oder Erweiterungen nicht merklich beim Aufdecken von Fehlern helfen. In einer solchen Situation lohnt es sich darüber nachzudenken, welche Testfälle man weglassen kann, weil keine Fehler der getesteten Art auftreten.

Detaillierte Hinweise zu der vorliegenden Faustregel finden sich in Kapitel 34 von Extreme Programming Installed.

Lesen Sie hierzu auch:  Automatische Tests, Testgewohnheit und Refactoring.