Bottleneck Systemverifizierung: Verwendung von Metriken


Ein häufig unterschätztes Thema in der Verifizierung aber auch in der Entwicklung allgemein sind die Definition und Auswertung von geeigneten Metriken. Das liegt daran, dass die Metriken häufig als unnötige „Erbsenzählerei“ und nicht als essentielles Instrument zur Steuerung der Verifizierung gesehen werden. Daher möchte ich in diesem dritten Teil meiner Blogreihe den Blick auf dieses meiner Meinung nach wichtige Thema schärfen und den Nutzen von geeigneten Metriken aufzeigen.

Oft werden Verzögerungen bei der Verifizierung sowie der Reifegrad des Produktes falsch eingeschätzt. Dies ist häufig auf fehlende Metriken zurückzuführen, durch die so etwas frühzeitig zu erkennen wäre. Die Auswahl von geeigneten Metriken ist somit notwendig, um den Erfolg oder Misserfolg sowie den Fortschritt messbar zu machen. Sie liefern fundierte Daten für die Steuerung und Bewertung von Projekten, in diesem Fall der Verifizierung. Grundlegende Metriken sollten bereits in der allgemeinen Teststrategie definiert und für das jeweilige Projekt skaliert angewendet werden.

Es gilt der Grundsatz: Zu viele Metriken sind genauso schlecht wie gar keine Metriken.

Deshalb sollte die Definition von Metriken immer hinsichtlich des Nutzens stattfinden.

Innerhalb der Verifizierung sollten mindestens folgende zwei Arten erhoben werden, um den Erfolg der Verifizierung und auch die frühzeitige Aufdeckung von Problemen sicherzustellen:

1. Spezifikation- und Testfortschritt

Diese Metrik soll zunächst den Fortschritt bei der Definition der Testfälle in Abhängigkeit von der Gesamtanzahl der zu spezifizierenden Testfälle darstellen. Im späteren Verlauf sind dann hiermit die durchgeführten Testfälle in Abhängigkeit von der Gesamtanzahl der durchzuführenden Testfälle darzustellen. Der Nutzen dieser Erhebung ist die Steuerung und Überwachung des definierten Zeitplans. Es ermöglicht frühzeitiges Gegensteuern, insofern eine Abweichung gegenüber des Zeitplans erkannt wird.

Diese Metrik sollte in regelmäßigen Abständen der Projektleitung sowie dem Verifizierungsteam zur Verfügung gestellt werden. Darüber hinaus sollte sie als Endkriterium für eine Test- bzw. Entwicklungsstufe herangezogen werden.

2. Fehlerfindungsrate

Diese Metrik spiegelt die Fehlerfindungsrate in der jeweiligen Teststufe wieder. Sie stellt die Anzahl der gefunden Fehler in Abhängigkeit von der aufgewendeten Zeit oder durchgeführten Testfälle dar. Die Fehlerfindungsrate spiegelt den Reifegrad des Produkts wieder und hilft bei der Entscheidung, ob die Testaufwände ausreichend sind. Hierbei gilt der Grundsatz, dass bei einer hohen Fehlerfindungsrate in einer Komponente oder einem Modul die Wahrscheinlichkeit weiterer Fehler in der jeweiligen Komponente oder dem Modul groß ist. Somit wäre ein weiterer Testaufwand ratsam, wenn nicht sogar notwendig, um die Qualität des Produkts sicherzustellen.

Die Fehlerfindungsrate sollte ebenso wie der Spezifikations- und Testfortschritt als Endkriterium für eine Teststufe oder Entwicklungsstufe herangezogen werden und ebenfalls der Projektleitung und dem Verifizierungsteam zur Verfügung gestellt werden. Weitere Varianten der Fehlerfindungsrate sind die gefundenen Fehler in Abhängigkeit von ihrem Schweregrad, Anzahl der Fehler pro Modul und Fehleranzahl in Abhängigkeit von der Teststufe.

Über diese beiden Arten von Metriken hinaus können auch noch beliebig Weitere definiert werden, wie zum Beispiel:

  • Anforderungsänderungen pro definierten Zeitraum

  • Testspezifikationsfehler pro definierten Zeitraum

Diese dienen häufig der Überwachung der Qualität des Anforderungsmanagements und des Testfalldesigns. Dabei sollten aber immer die grundlegenden Kriterien für die Verwendung von Metriken beachtet werden, um die Gesamtanzahl der Metriken schlank zu halten.

Kriterien für die Verwendung von Metriken

Die Metriken, die während der Verifizierung erhoben werden, sollten bereits vor Beginn definiert und etabliert sein. Es sollten dabei folgende Kriterien und Fragestellungen beachtet werden:

  • Was möchte man messen?

  • Welche Aussage soll die Metrik treffen?

  • Welche Grenzwerte gelten?

  • Welche Entscheidung resultiert aus der Metrik und deren Grenzen?

Ist man sich bei der Beantwortung einer dieser Fragen unsicher, sollte man insgesamt den Nutzen der Metrik hinterfragen und begründen zu welchem Zweck man die Metrik dennoch benötig.

Grundsätzlich gilt, dass aus den zu erhabenen Metriken immer Entscheidungen abgeleitet werden sollten. Dies bedeutet, dass bereits zu Beginn des Projekts klar ist, welche Grenzwerte als Start- und Endkriterium oder als Indikator zum Handeln dient. Dient eine Metrik nicht der Steuerung oder Entscheidung ist diese in den meisten Fällen überflüssig und sollte nicht erhoben werden. In diesem Fall wäre sie dann tatsächlich nur „Erbsenzählerei“.

Metriken dienen immer der Bewertungen von Teams oder Projektteilen. Mit Metriken sollten nie die Arbeit von einzelnen Personen gemessen werden. Dies führt häufig zu Konflikten innerhalb der Teams. Ein einzelnes Teammitglied sollte also nicht daran gemessen werden, wie viele Fehler er findet. Denn die Anzahl der gefundenen Fehler ist häufig abhängig von dem getesteten Objekt und der Anforderung und lässt nicht zwingend einen Rückschluss auf die Qualität der Arbeit des Teammitglieds zu.

Fazit

Zusammenfassend kann man sagen, dass Metriken die geeigneten Instrumente sind, um

  • Abweichungen vom Projektplan frühzeitig zu erkennen

  • Die Qualität der durchgeführten Verifizierungsmaßnahmen zu bewerten

  • Objektive und fundierte Entscheidungen zu treffen

Dabei sollte aber immer darauf geachtet werden, dass neue Metriken nicht leichtfertig erhoben werden, sondern immer die oben genannten Kriterien erfüllen.

#Metriken #Testen #Verifzierung #Projekt #Fehlerfindungsrate #Testfortschritt #Spezifikationsfortschritt

Kontakt: 0431 - 888 2111 0

E-Mail: marketing@scope-engineering.de

  • YouTube
  • Twitter
  • XING
  • LinkedIn

© 2020 SCOPE Engineering GmbH

Impressum

Datenschutz

Kontakt

SCOPE Engineering Website       I       test!t     I     t(ea)talk     I     Dezentrales Arbeiten