Zu viel Testen schadet der Qualität und ist teuer


20.12.2016 von

https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png iteratec GmbH

Zum Thema Testen von Soft­ware gibt es zwei gegen­sätzliche Stand­punkte, die man immer wieder vorfindet.

Testen ist öde

Auf der einen Seite sind diejenigen, die Testen nicht so spannend finden:

Ich schreibe doch schon die Software. Dabei denke ich genau darüber nach, was passieren wird. Ich muss das nicht wirklich testen, weil es nach Konstruktion schon richtig funktionieren wird.

Testen ist doch nur Zusatzarbeit, die mich von meinem eigentliche Job abhält, Software zu schreiben.

Wie, wir als Fachbereich sollen testen? Wir haben anderes genug zu tun.

Warum sollen wir testen. Wir haben doch den Dienst­leister beauf­tragt, uns funktionierende Soft­ware zu liefern. Das können wir ja punktuell überprüfen.

Testen ist geil

Auf der an­d­eren Seite gibt es die­jenigen die Spaß am Testen haben:

Ich will sehen, wie mein Programm funktioniert.

Tests helfen mir, sicherer zu program­mieren. Ich muss nur die Tests laufen lassen und weiß, dass alles nach der letzten Änderung immer noch korrekt funktioniert.

Automatisierte Tests zu schreiben ist doch auch Program­mieren. Das kann ich gut und das macht Spaß.

Ich bin gerne bei den Testern. Die Fehler von anderen zu finden ist eine Heraus­forderung. Da darf kein Fehler durch­gehen!

Je mehr Tests, desto besser die Qualität

Jetzt bin ich bei einem Kunden – sagen wir einer deutschen Behörde – unterwegs und es geht darum ab­zu­stimmen, was im Rahmen eines Projektes alles er­stellt und abge­liefert werden muss. Dazu gehören natürlich auch Tests und die Test­ergebnisse.

Wir haben hier die Regel, dass keine Software ein­ge­setzt wird, wenn nicht alles ge­testet ist. Für die Test­ab­deckung heißt das, natürlich, dass ein Wert von 100% erreicht werden muss.

Bei uns geht kein Verfahren live, wenn nicht jede Zeile Code ge­testet worden ist.

Wir haben das schon so in der Aus­schreibung gehabt. Also muss das so geliefert werden.

Je höher die Test­ab­deckung, desto höher sind die Kosten

Es ist sicher nicht über­raschend, aber auch die Test­ab­deckung ist nicht ohne Kosten zu haben. Hier schlägt auch wieder die 80-20-Regel zu: 80% der Kosten werden von 20% der Tests erzeugt.

Inhaltlich sind die Zusammen­hänge einfach. Am Anfang muss man in die Test-Infra­struktur investieren. Das zahlt sich aus, weil damit dann viele Test­fälle wie am Fließ­band erzeugt werden können. Irgend­wann kommen dann die kniffligeren Fälle. Dafür muss man mehr Auf­wand betreiben. Für das letzte Quäntchen an Test­abdeckung explo­dieren die Kosten dann geradezu.

Qualitativ ist dieser Zusammen­hang in dem fol­gen­den Diagramm visualisiert:

Bei sehr hoher Test­ab­deckung wird die Qualität der Software schlechter

Erst einmal klingt das paradox. Aber hier gibt es einen Aspekt, den man neben den Kosten betrachten sollte.

Ich programmiere defensiv. Wenn ich ge­zwungen bin 100% Test­ab­deckung zu erreichen, dann muss ich diese Teile weglassen!

Defensiv zu programmieren bedeutet, dass man auch Situationen berück­sichtigt, die vielleicht erst in der Zu­kunft auf­treten. Wenn bei­spiels­weise eine An­nahme im Zuge einer späteren Weiter­ent­wicklung plötz­lich nicht mehr gilt, dann sollte die Soft­ware darauf zumindest mit einem ordentlichen Aus­stieg reagieren und nicht un­kon­trol­liert abstürzen.

Ein Beispiel ist eine Fall­unter­scheidung nach einem Auf­zählungs­typen. Wenn in der Fall­unter­schei­dung alle möglichen Aus­prägungen der Auf­zählung be­handelt werden, dann braucht es doch keinen else-Zweig, oder?

    enumeration EType {
      FIRST, SECOND, THIRD;
    }
    …
    EType type;
    …
    switch (type) {
        case FIRST: …
        case SECOND: …
        case THIRD: …
        default:
           throw new IllegalStateException("EType");
    }

Mit der aktuellen Definition des Aufzählungs­typen ist das auch so. Was passiert aber, wenn im Zug der Weiter­ent­wicklung der Soft­ware in einem Folge-Release weitere Aus­prägungen zu dem Auf­zählungs­typen hinzu­ge­fügt werden? Da zeigt sich dann der Wert der defen­siven Program­mierung.

Die Qualität der Software misst sich in dem Fall auch daran, dass sie auf „un­mög­liche“ Fälle auch noch an­ge­mes­sen reagiert.

Da man solche Situationen mit der ak­tu­el­len Soft­ware nicht er­reichen kann, ist auch die Er­stellung eines Test­falls dafür un­möglich. Die letzte Chance besteht dann darin, das defensive Program­mieren aufzugeben. Das führt zu einer Ver­schlechte­rung der Soft­ware-Quali­tät, was in der folgen­den Ab­bildung qualitativ dar­ge­stellt ist:

Und die Moral…

Und wie hat der Kunde da­rauf rea­giert? Es gab eine Diskus­sion um das Thema Test­ab­deckung und am Ende haben wir uns gütlich darauf ge­einigt, dass ein Ziel von 70–80% Test­ab­deckung an­ge­messen ist.

Das ist immer noch zu viel, weil es dazu geführt hat, dass wir erst einmal Test­fälle für Getter und Setter generiert haben. Damit bekommt man die Test­ab­deckung hoch, ohne viel Auf­wand investieren zu müssen. Aber der Nutzen ist auch nur marginal.

An Ende ist es wichtig, auch bei der Test­ab­deckung eine sinn­volle Balance zu finden. Testen ist wichtig und kann Spaß machen. Wie sonst auch kann ein Zuviel davon uns den Spaß verderben.


Dieser Blog-Artikel steht unter der Lizenz CC-BY-SA 4.0.
Die in den Blog-Beitrag eingebundenen Bilder stammen zum Teil von Pixabay und stehen alle unter der Lizenz CC0.

Diesen Artikel bewerten
 
 
 
 
 
 
 
0 Bewertungen (0 %)
Bewerten
 
 
 
 
 
 
1
5
0
 

Artikel im Warenkorb:

0