Testivus zum Thema Test Coverage

vor einigen Tagen bin ich auf eine nette Anekdote zum Thema "Code Coverage" von Alberto Savoia gestoßen. Ich finde die Geschichte so gut, dass ich sie gerne ins Deutsche übersetzten möchte:

Testivus zum Thema Test Coverage

Am frühen Morgen fragte ein junger Entwickler den Großmeister:

"Ich würde gerne ein paar Unit-Tests schreiben. Welche Code Coverage sollte ich erreichen?"

Der Großmeister antwortete:

"Mache Dir keine Sorgen über Code Coverage. Schreib einfach ein paar gute Tests."

Der junge Entwickler lächelte, verbeugte sich und ging.

Später am Tag kam ein zweiter Entwickler mit der gleichen Frage.
Der Großmeister zeigte auf einen Topf mit kochendem Wasser und sagte

"Wieviele Reiskörner soll ich in den Topf werfen?"

 Der Entwickler schaute ein wenig verstört drein und antwortete

"Wie soll ich das sagen können? Das hängt doch davon ab, wieviele Personen davon essen sollen, wie hungrig sie sind, was sonst noch an Essen angeboten wird und so weiter."

"Genau."

sagte der Großmeister
Der zweite Entwickler lächelte, verbeugte sich und ging.

Gegen Ende des Tages kam ein dritter Entwickler und fragte die gleiche Frage zum Thema Code Coverage.

"Achtzig Prozent und nicht weniger!" 

Antwortete der Großmeister in hartem Ton und schlug mit seiner Faust auf den Tisch.
Der dritte Entwickler lächelte, verbeugte sich und ging.

Nach dieser letzten Antwort ging ein junger Auszubildender auf den Großmeister zu:

"Großmeister, heute habe ich gehört, dass Sie auf die gleiche Frage zum Thema Code Coverage mit drei verschiedenen Antworten reagiert haben. Warum?"

Der Großmeister stand von seinem Stuhl auf:

"Lass uns einen guten Tee trinken gehen und darüber sprechen."

Nachdem sie ihre Tassen mit heißem grünen Tee gefüllt haben erklärte sich der Großmeister:

"Der erste Entwickler ist noch neu und fängt gerade erst mit dem Testen an. Momentan hat er eine Menge Code und keine Tests. Er hat noch einen langen Weg vor sich; sich zu diesem Zeitpunkt auf Code Coverage zu fokussieren wäre nur deprimierend und recht nutzlos. Er wird weiter kommen, wenn er einfach übt gute Tests zu schreiben und auszuführen. Über Code Coverage kann er sich auch später noch Gedanken machen.

Der zweite Entwickler aber ist schon recht erfahren mit Entwicklung und Testen. Als ich ihn gefragt habe, wieviele Reiskörner ich in den Topf werfen soll habe ich ihm geholfen zu verstehen, dass die Menge von Tests abhängt von der Anzahl und dem Gewicht verschiedener Faktoren. Diese Faktoren kennt er weit besser als ich - es ist immerhin sein Code. 

Es gibt nicht die eine richtige Antwort und er ist clever genug mit dieser Wahrheit umzugehen und damit zu arbeiten."

"Ich verstehe", sagte der junge Auszubildende, "aber wenn es nicht die eine einfache Antwort auf diese Frage gibt, warum haben Sie dann dem dritten Entwickler gesagt: 'Achtzig Prozent und nicht weniger'?" 
Der Großmeister lachte so herzlich und laut, dass sein Bauch - der darauf hindeutete, dass er nicht nur Tee trank - auf und ab wippte.

"Der dritte Entwickler will nur einfache Antworten hören - auch wenn es keine einfachen Antworten gibt ... und am Ende folgt er ihnen dann sowieso nicht."

Der junge Azubi und der grauhaarige Großmeister tranken ihren Tee in nachdenklicher Stille fertig.

Hier noch einmal der Link zum Original-Blog.

The Limited Backlog - Addendum

In an earlier post I argued to limit the size of your product backlog. Some days ago, I met a co-worker who told me that some agile experts told him, that product backlogs always have to be limited in size. Superficially, this looks like the very same statement, I made in this former blog post. You might eventually be surprised to read, that I disagreed with the statement, my co-worker made.

Why? Because it is very important to understand why and when limiting the size of your backlog makes sense! The main argument for limiting the size is to avoid the maintenance costs of many backlog items. Especially, if there is a probability, that they will never be implemented at all or the items are deteriorating fastly (what a waste!).

Now comes the pitfall: If limiting the size of your backlog leads to emerging "backlogs" in other places (e.g. at your customer!) you might eventually even increase the overall costs of maintaining the items, if the maintenance costs at the other spots are even higher than they would be in your backlog. This is definitely not what you wanted to achieve in the first place, when you limited your own backlog.

So if you do indeed limit your backlog (which is still extremely valuable), watch out and have a careful look, if the discarded items do indeed vanish, or are only cultivated elsewhere.