Wieviele Bugs darf eine Software haben? (Teil 2 - Fehleranzahl abschätzen)

Kann man wissen, wie viele Fehler sich in einer Software verstecken? Exakt kann man das mit akzeptablem Aufwand nie wissen – aber es lässt sich abschätzen. Das ist notwendig zur Bewertung potentieller Risiken einer Software, aber auch zur Abschätzung der Fehlerdichte (siehe Wieviele Bugs darf eine Software haben? (Teil 1 - Fehlerdichte)).

Dazu kann man sich folgender Erkenntnisse aus der Literatur bedienen:

• Während der Entwicklung entstehen programmiersprachenunabhängig zwischen 30 und 50 Fehler pro 1.000 Zeilen Sourcecode (= KSLOC).¹
• Mittels Unit-Tests bzw. TDD können im Schnitt 30-45% der Fehler gefunden bzw. vermieden werden.²
• Formale Code-Inspections finden/verhindern 45-70% der restlichen Fehler³
• Gutes Pair-Programming findet/verhindert 40-60% der (restlichen) Fehler³
• Code-Reviews finden/verhindern 20-40% der restlichen Fehler³

Basierend auf diesen Erkenntnissen kann man nun abschätzen, wieviele Fehler in der Software nach den typischen Entwicklertätigkeiten (Programmieren, Unit-Testen, Reviews) – und somit vor den im Test bzw. später gefundenen Fehlern – vorhanden waren:

Dazu muss man nur die Qualität/Quantität der Unit-Tests, Inspections, Pair-Programming und Code-Reviews kennen, oder grob abschätzen. Typischerweise ist die code-coverage der Unit-Tests bekannt und es gibt keine formalen Code-Inspections - dafür wird üblicherweise 50% des Codes mittels Pair- oder Mob-Programming umgesetzt und 50% des Codes mittels Code-Reviews geprüft.

Im mit Unit-Tests getesteten Code verbleiben also 55-70% der Bugs, im erst danach oder nicht getesteten Code noch 100%. Ohne formale Code-Inspections aber mit 50% Pair-Programming und 50% Code-Reviews bearbeiteten Code verbleiben noch mindestens 100% × (100%-60%×50%) × (100%-40%×50%) = 56% der Bugs. Die Berechnung des Maximums erfolgt analog und ergibt 72%. In der folgenden Formel nenne ich diese revmisses_min und revmisses_max.

Schlussendlich kommt man damit auf folgende Formel:

30 × revmisses_min × (KSLOC_tested × 55% + KSLOC_¬tested)
< Bugs_expected <
50 × revmisses_max × (KSLOC_tested × 70% + KSLOC_¬tested)

Kennt man dazu noch die Anzahl der danach bereits im Test bzw. in Produktion gefundenen Fehler – eine Zahl, die üblicherweise mittels Bugtracker leicht ermittelbar ist – so kann man die Anzahl der noch in der Software vorhandenen Fehler abschätzen.

Diese Abschätzung liefert einen sehr groben, aber wissenschaftlich untermauerten, von-bis Rahmen für die noch vorhandenen Fehler. Sie ist daher weit besser für die Bestimmung des noch offenen Fehlerfindungs- und behebungsaufwandes, die Qualität des Tests und die Einsatztauglichkeit einer Software geeignet als das sonst übliche „wird scho passen“ oder „wir haben ohnedies alles getestet“.

Fazit: Kennt man ein paar typischerweise bekannte bzw. leicht abschätzbare Kennzahlen einer Software, so kann man die Anzahl der noch in der Software vorhandenen Fehler grob abschätzen.

___

1. vgl. Georg Erwin Thaller: "ISO 9001:2000 - Software-Entwicklung in der Praxis", ISBN 978-3-88229-189-6 ↩

2. vgl. Steve McConnell: "Code Complete", S. 470, Capers Jones: "Software Engineering Best Practices", S. 330 ↩

3. vgl. Steve McConnell: "Code Complete", S. 530. ↩