KPIs für Software Tests – Qualitätssicherung für Ihr Produkt

Die Entwicklung einer Software, die einen „pain point“ für den Benutzer löst, ist zweifellos das Fundament eines erfolgreichen Softwareprodukts. Es gibt jedoch noch einen weiteren Aspekt von größter Wichtigkeit: Software Tests. Oft wird das Testen der Software vernachlässigt, obwohl das Testergebnis darüber entscheidet, ob man sich mit seinem Produkt von der Konkurrenz abhebt – oder eben nicht.

In diesem Beitrag beleuchten wir die Wichtigkeit von Software Tests näher und wie man messen kann, ob sich die Produktentwicklung auf dem richtigen Weg befindet. Wir stellen Ihnen die präsentesten Leistungsindikatoren (KPIs) für das Testen der von Ihnen entwickelten Software vor, veranschaulichen die Theorie der Software Tests mit einem praxisnahen Beispiel und geben Ihnen wichtige Informationen an die Hand, wie sie sich durch das Testen Ihrer Software einen Wettbewerbsvorteil verschaffen können.

Wichtige Leistungsindikatoren (KPIs) für Software Tests

Es gibt viele KPIs, die den Erfolg der Testprozesse widerspiegeln. Aus Gründen der Kürze und der impliziten Prioritätensetzung haben wir die wichtigsten dieser KPIs ausgewählt. Hier ist unsere Auswahl:

KPI 1 „Requirements Test Coverage“ – Anforderungen an den Testumfang

Requirements Test Coverage misst den Grad, zu dem die während des Testens ausgeführten Testfälle die Menge der spezifizierten funktionalen und nicht-funktionalen Anforderungen an die Software abdecken. Voraussetzung für die Anwendbarkeit dieser Kennzahl ist, dass die Anforderungen an die Software vollständig spezifiziert worden sind.

Interpretation und Anwendung von Test Coverage als KPI:

• Diese KPI stellt sicher, dass jede Anforderung mit mindestens einem Testfall verknüpft ist, der diese überprüft. Es ist wichtig zu erwähnen, dass jede Anforderung durch mehrere Testfälle getestet werden kann. Gleichzeitig kann ein Test auch mehrere Softwareanforderungen checken. Das heißt, dass es eine viele zu viele Beziehung zwischen Testfällen und Anforderungen gibt.
• Eine 100-prozentige Requirements Test Coverage bedeutet nicht, dass es keine anderen möglichen Tests gibt, die geschrieben werden können. Es bedeutet nur, dass jede Anforderung mit mindestens einem Testfall verknüpft ist. Es gibt jedoch keine Garantie, dass dieser Testfall die gesamte Spezifikation der Anforderung abdeckt.
• Vergessen Sie nicht: Wenn sich die Anforderungen an die Software ändern, müssen sich auch die Testfälle ändern.
• Für die Umsetzung dieses KPI müssen Sie Traceability-Tools verwenden, um Testfälle und Anforderungen miteinander zu verknüpfen. Diese Rückverfolgbarkeit hilft bei der Verfolgung, welche Anforderungen bereits getestet wurden und welche noch ausstehen. Durch diese Rückverfolgbarkeit wird die Abdeckung in Prozent gemessen.

Beispiel „Requirements Test Coverage“

Sie sind in einer leitenden Funktion bei einem E-Commerce-Unternehmen, welches eine umfassende Aktualisierung seiner E-Commerce-Plattform plant, um die Kundenerfahrung zu verbessern. Dabei wurden sowohl funktionale als auch nicht-funktionale Anforderungen definiert. Als Teil des Qualitätssicherungsprozesses ist es entscheidend sicherzustellen, dass alle Anforderungen ausreichend getestet werden.

Ihr Entwicklungsteam verwendet Traceability-Tools, um Testfälle und Anforderungen miteinander zu verknüpfen. Dies ermöglicht es Ihnen, die Test Coverage zu messen und sicherzustellen, dass jede Anforderung zumindest von einem Testfall abgedeckt wird.

Nach der Durchführung der Tests und der Verknüpfung von Anforderungen und Testfällen stellen Sie fest, dass die Test Coverage bei 90% liegt. Das bedeutet, dass 90% der spezifizierten Anforderungen mindestens von einem Testfall überprüft wurden. Dies ist ein gutes Ergebnis, zeigt jedoch, dass es noch Raum für Verbesserungen gibt.

In der Analyse der Test Coverage stellen Sie fest, dass einige der nicht-funktionalen Anforderungen, wie die Leistung der Plattform unter hoher Last, noch nicht ausreichend getestet wurden. In diesem Fall müssen Sie sicherstellen, dass zusätzliche Testfälle erstellt werden, um diese speziellen Anforderungen abzudecken. Darüber hinaus stellt sich heraus, dass einige der Testfälle mehrere Anforderungen abdecken und umgekehrt. Dies verdeutlicht die viele zu viele Beziehung zwischen Testfällen und Anforderungen. Wenn sich während der Entwicklung Änderungen an den Anforderungen ergeben, müssen die Testfälle entsprechend angepasst werden, um sicherzustellen, dass die Rquirements Test Coverage aktuell bleibt.

Durch die Verwendung von Traceability-Tools und die regelmäßige Überprüfung der Requirements Test Coverage stellen Sie sicher, dass die E-Commerce-Plattform den spezifizierten Anforderungen entspricht und potenzielle Probleme frühzeitig erkannt und behoben werden. Eine Requirements Test Coverage von 100% bedeutet nicht zwangsläufig, dass keine weiteren Tests erforderlich sind, sondern dass jede Anforderung zumindest einmal überprüft wurde.

KPI 2 „Code Coverage“ – Abdeckung des Codes

Code Coverage misst, wie viel von Ihrem Quellcode, einschließlich Codezeilen, Anweisungen, Verzweigungen und Pfade, von Ihren Tests tatsächlich ausgeführt wurde.

Interpretation und Anwendung von Code Coverage als KPI:

• Code Coverage wird in der Regel als Prozentsatz ausgedrückt, z. B. 20% oder 90%. Ein höherer Prozentsatz impliziert umfangreichere Tests. Es gibt keine eindeutige Zahl, die einheitlich als Ziel festgelegt werden kann, erreicht der Prozentsatz aber mehr als 70%, ist das ein guter Wert.
• Code Coverage Tools heben oft die spezifischen Codezeilen oder -zweige hervor, die von Ihren Tests nicht ausgeführt wurden.
• Wenn Sie Bereiche mit unentdecktem Code identifizieren, können Sie diese Informationen nutzen, um Testlücken zu schließen. Es ist auch möglich, zusätzliche Testfälle zu erstellen oder bestehende zu modifizieren, um diese unentdeckten Codepfade zu testen.

Beispiel „Code Coverage“

Ihre E-Commerce-Plattform hat kürzlich eine Aktualisierung durchgeführt, bei der neue Funktionen hinzugefügt und einige bestehende Funktionen geändert wurden. Als Teil Ihres Qualitätsversicherungsprozesses ist es wichtig sicherzustellen, dass der gesamte Code, insbesondere nach solchen Updates, ausreichend getestet wurde.

Ihr Entwicklungsteam verwendet ein Code-Coverage-Tool, um sicherzustellen, dass die Testfälle den Code gründlich durchlaufen. Nach der Aktualisierung führen Sie eine Code-Coverage-Analyse durch und stellen fest, dass die Code Coverage bei nur 65% liegt. Das bedeutet, dass nur 65% des Quellcodes von Ihren Testfällen durchlaufen wurden.

Das Code Coverage Tool hebt die spezifischen Codezeilen und -zweige hervor, die von den Tests nicht ausgeführt wurden. In diesem Fall fällt auf, dass einige der neuen Funktionen und Teile des bestehenden Codes nicht ausreichend getestet wurden.

Um die Code Coverage zu verbessern, ergreifen Sie die folgenden Maßnahmen:

1. Identifizierung von Testlücken: Sie analysieren die hervorgehobenen Codezeilen und -zweige, die von den Tests nicht erreicht wurden, und identifizieren die Bereiche mit unentdecktem Code.
2. Erstellung neuer Testfälle: Sie erstellen zusätzliche Testfälle, die diese unentdeckten Codepfade abdecken. Dies kann bedeuten, dass Sie spezifische Szenarien entwickeln, die die neuen Funktionen gründlich testen, oder Testfälle ändern, um diese neuen Bereiche zu berücksichtigen.
3. Modifizierung bestehender Testfälle: Sie überarbeiten bereits existierende Testfälle, um sicherzustellen, dass sie die geänderten Teile des Codes abdecken.

Durch diese Maßnahmen erhöhen Sie die Code Coverage und gewährleisten eine ausreichende Testung der neuen Funktionen und geänderten Teile des Codes.

KPI 3 „Test Automation Coverage“ – Abdeckung der Testautomatisierung

Test Automation Coverage zeigt Ihnen, welcher Anteil aller Testfälle, die Ihnen als Teil Ihres Testsatzes zur Verfügung stehen, automatisiert ist. Die Metrik wird durch eine einfache Division der Anzahl der automatisierten Tests durch die Gesamtzahl der Tests – automatisiert und manuell – gebildet. Dabei ist es wichtig zu erwähnen, dass alle zu berücksichtigenden Testfälle diejenigen sind, die auf der Systemebene ausgeführt werden – also so, dass jeder Endbenutzer der Software sie ausführen kann.

Interpretation und Anwendung von Test Automation Coverage als KPI:

• Test Automation Coverage wird als Prozentsatz ausgedrückt. Ein höherer Prozentsatz bedeutet eine bessere Abdeckung und umgekehrt.
• Die Testautomatisierung ist kein schneller Prozess, sondern braucht Zeit und damit auch eine gute Planung. Um zu wissen, welche Tests zuerst automatisiert werden sollten, müssen Sie Prioritäten setzen. Berücksichtigen Sie dabei z. B. die Häufigkeit der Nutzung der getesteten Funktionalität, die Abhängigkeit von anderen Testfällen und die Komplexität der Implementierung Ihrer Software. Testfälle mit hoher Priorität, starken Abhängigkeiten und geringer Komplexität sind gute Kandidaten für die Automatisierung.
• Die Testautomatisierung findet kaum ein Ende, solange Sie Ihr Produkt kontinuierlich weiterentwickeln. Vergessen Sie nicht, Ihre automatisierten Testfälle regelmäßig zu überprüfen und zu aktualisieren, damit sie die neusten Änderungen an Funktionalität und Leistung widerspiegeln.

Beispiel „Test Automation Coverage“

Bleiben wir bei unserem Unternehmen, das eine E-Commerce-Plattform betreibt, auf der Kunden Produkte kaufen können. Ihre Plattform hat eine Vielzahl von Funktionen, darunter die Produktsuche, den Warenkorb, die Bestellabwicklung und die Kundenbewertungen. Als Qualitätssicherungsmanager sind Sie verantwortlich für die Überwachung der Testautomatisierung und die Sicherstellung einer guten Testabdeckung.

Ihre E-Commerce-Plattform hat insgesamt 500 verschiedene Testfälle, die für die Systemebene relevant sind. Dies sind Tests, die sicherstellen, dass ein Endbenutzer alle wichtigen Funktionen der Plattform nutzen kann. Um Ihre Testautomatisierung Coverage zu berechnen, haben Sie 200 dieser Tests automatisiert. Dies bedeutet, dass 200 Ihrer Testfälle von einem Testautomatisierungs-Framework durchgeführt werden, während die verbleibenden 300 manuell von Testern ausgeführt werden.

Die Test Automation Coverage, in diesem Fall, beträgt:

(Testfälle automatisiert / Gesamtanzahl der relevanten Testfälle) x 100 = (200 / 500) x 100 = 40%

Das bedeutet, dass Ihre Test Automation Coverage bei 40% liegt. Das bedeutet wiederum, dass 40% Ihrer relevanten Testfälle automatisiert sind, während die restlichen 60% manuell durchgeführt werden. Dies kann auf verschiedene Faktoren zurückzuführen sein, wie Zeit- und Ressourcenbeschränkungen oder die Schwierigkeit, bestimmte Tests zu automatisieren.

Um die Test Automation Coverage zu verbessern, sind folgende Schritte möglich:

1. Priorisieren: Sie analysieren, welche Tests am häufigsten von Benutzern durchgeführt werden, wie z. B. die Produktsuche und die Bestellabwicklung. Diese Tests haben höchste Priorität für die Automatisierung.
2. Abhängigkeiten berücksichtigen: Sie identifizieren Testfälle, die stark von anderen abhängen. Die automatisierten Tests sollten diejenigen sein, die den größten Einfluss auf andere Tests haben, um die Effizienz zu steigern.
3. Komplexität berücksichtigen: Tests, die einfach zu automatisieren sind, sollten bevorzugt werden, da sie weniger Zeit und Ressourcen in Anspruch nehmen.
4. Regelmäßige Aktualisierung: Sie stellen sicher, dass die automatisierten Testfälle ständig überarbeitet und an die neuesten Änderungen in der Plattform angepasst werden, um die Testabdeckung auf dem aktuellen Stand zu halten.

Durch die Anwendung dieser Prinzipien sind Sie in der Lage, die Test Automation Coverage zu erhöhen und die Qualität Ihrer E-Commerce-Plattform sicherzustellen, während Sie gleichzeitig Zeit und Ressourcen effizient einsetzen.

KPI 4 „Defect Detection Efficiency – DDE“ – Effizienz der Fehlererkennung

Defect Detection Efficiency (DDE) wird als Prozentsatz ausgedrückt und stellt den Anteil der durch das Testen entdeckten Defekte oder Bugs im Vergleich zur Gesamtzahl der Defekte/Bugs in der Software dar.

Die Formel zur Berechnung der Defect Detection Rate lautet wie folgt:

Fehlerentdeckungsrate (%) = (Anzahl der beim Testen gefundenen Fehler / Gesamtzahl der Fehler) x 100

Interpretation und Anwendung der Formel von DDE als KPI:

• Ein höherer Prozentsatz bedeutet, dass die Tests effektiver sind. Er deutet darauf hin, dass Ihr Testverfahren ausreichend ist und dass nur eine minimale Anzahl von Fehlern in die Produktionsumgebung gelangen wird.
• Ein niedriger Prozentsatz bedeutet, dass Ihr Testprozess bei der Fehlersuche weniger effektiv ist und Sie Ihren Testsatz erweitern müssen. Bei der Entscheidung darüber, wie dies geschehen soll, können Sie die von Ihren Codeabdeckungswerkzeugen bereitgestellten Daten verwenden.

Beispiel „Defect Detection Efficiency“

Ein Softwareentwicklungsteam arbeitet an einem neuen E-Commerce-System. In der Entwicklungsphase wurden 100 Fehler oder Bugs im Code identifiziert. Bevor die Software in die Produktionsumgebung übergeht, werden umfangreiche Tests durchgeführt, um die Fehler zu erkennen und zu beheben. Während dieser Tests werden 80 der 100 Fehler gefunden und behoben.

Um die DDE zu berechnen, verwenden wir die Formel:

DDE (%) = (Anzahl der beim Testen gefundenen Fehler / Gesamtzahl der Fehler) x 100

Setzen wir die Werte in die Formel ein:

DDE (%) = (80 / 100) x 100 = 80%

In diesem Beispiel beträgt die Defect Detection Efficiency (DDE) 80%. Das bedeutet, dass 80% der vorhandenen Fehler während der Tests gefunden wurden. Eine hohe DDE zeigt an, dass die Testbemühungen effizient sind. Nur 20% der Fehler könnten unentdeckt in die Produktionsumgebung gelangen.

In der Praxis würde das Entwicklungsteam bestrebt sein, die DDE so hoch wie möglich zu halten, um die Softwarequalität zu gewährleisten und Kundenbeschwerden oder Qualitätsprobleme nach der Veröffentlichung zu minimieren. Wenn die DDE niedriger wäre, würden die Tester und Entwickler ihre Teststrategie überdenken und möglicherweise die Testabdeckung erhöhen, um eine bessere Fehlererkennung zu gewährleisten. Die Verwendung von Codeabdeckungswerkzeugen könnte dies unter anderem unterstützen und die Bereiche im Code identifizieren, die nicht ausreichend getestet wurden.

KPI 5 „Escaped Defects“ – Entgangene Defekte

Der Begriff „Escaped Defects“, auf deutsch „entgangene Fehler“ bezieht sich auf Fehler oder Probleme in einer Softwareanwendung, die während der Testphase nicht erkannt und behoben wurden und anschließend in die Produktionsumgebung gelangt sind. Sie „entgingen“ dem Testprozess und wurden vom Endbenutzer entdeckt. Endbenutzer sind nicht nur Kunden, sondern auch interne Beteiligte, die außerhalb des Testprozesses auf den Fehler gestoßen sind.

Interpretation und Anwendung von Escaped Defects als KPI:

• Escaped Defects können zu höheren Wartungskosten führen. Die Behebung von Fehlern in der Produktionsumgebung ist oft kostspieliger und zeitaufwändiger als die Behebung in der Testphase.
• Diese Fehler können sich negativ auf das Benutzererlebnis auswirken.
• Das Vorhandensein von entwichenen Defekten kann auf Mängel im Testprozess hinweisen, z. B. auf eine unzureichende Codeabdeckung, eine unzureichende Abdeckung der Anforderungstests oder einen Mangel an effektiven Testfällen.

Beispiel „Escaped Defects“

Ihr E-Commerce-Unternehmen hat kürzlich eine neue Version Ihrer E-Commerce-Plattform in die Produktionsumgebung eingeführt, die einige erhebliche Änderungen und Verbesserungen beinhaltete. Vor der Veröffentlichung durchlief die Software eine umfassende Testphase, bei der die Entwickler und QA-Teams die Anforderungen, die Codeabdeckung und verschiedene Testfälle sorgfältig geprüft haben.

Einige Wochen nach der Veröffentlichung der neuen Version beginnen Sie, Berichte über Probleme und Fehler von Endbenutzern zu erhalten. Diese Fehler beeinträchtigen das Benutzererlebnis und führen zu Kundenbeschwerden. Bei der Untersuchung dieser entgangenen Fehler stellen Sie fest, dass sie auf unerkannte Schwachstellen in der Produktionsumgebung zurückzuführen sind. Diese Schwachstellen wurden während der Testphase nicht erkannt und haben es in die Live-Umgebung geschafft.

Ein solcher entgangener Fehler ist beispielsweise ein Fehler im Bestellprozess, der dazu führt, dass Bestellungen nicht korrekt abgeschlossen werden können. Dies beeinträchtigt das Benutzererlebnis erheblich und führt zu Umsatzverlusten, da Kunden ihre Einkäufe nicht erfolgreich abschließen können.

Die Konsequenzen von entgangenen Fehlern sind vielfältig:

1. Höhere Wartungskosten: Die Behebung von Fehlern in der Produktionsumgebung erfordert zusätzliche Ressourcen und Zeit. Dies führt zu höheren Wartungskosten, da Entwickler und Support-Teams dringend an der Fehlerbehebung arbeiten müssen, anstatt an neuen Funktionen zu arbeiten.
2. Benutzererlebnis: Entgangene Fehler beeinträchtigen das Benutzererlebnis und können dazu führen, dass Kunden unzufrieden sind und möglicherweise zu Konkurrenten wechseln.
3. Qualitätssicherungsprozess: Entgangene Fehler deuten auf mögliche Mängel im Testprozess hin. Dies weißt möglicherweise auf unzureichende Codeabdeckung, unzureichende Abdeckung der Anforderungen oder ineffektive Testfälle hin. Es ist wichtig, den Testprozess zu überprüfen und zu verbessern, um solche Fehler in Zukunft zu vermeiden.

Infolgedessen ist es wichtig, die entgangenen Fehler zu analysieren, sie zu beheben und gleichzeitig den Testprozess zu stärken, damit solche Probleme in zukünftigen Software-Updates vermieden werden. Dies wird dazu beitragen, die Wartungskosten zu senken und das Vertrauen der Benutzer in Ihre E-Commerce-Plattform aufrechtzuerhalten.

KPI 6 „Customer Satisfaction“ – Zufriedenheit der Kunden

Auch wenn die Kundenzufriedenheit nicht direkt und ausschließlich mit Software Tests zusammenhängt, sollten Sie diese KPI sowohl bei der Ausarbeitung als auch bei der Optimierung einer Software Teststrategie berücksichtigen. Customer Satisfaciton ist ein Maß dafür, wie gut Ihre Software die Erwartungen der Benutzer erfüllt. Auf diese Weise kann diese KPI Ihnen – neben den Erkenntnissen über die Funktionalität selbst – zeigen, wie hoch die wahrgenommene Qualität Ihrer Software ist.

Interpretation und Anwendung von Customer Satisfaction als KPI:

• Es gibt viele Umfragen, die der Kunde regelmäßig ausfüllen soll und die einen numerischen Wert für die Kundenzufriedenheit liefern. Beispiele: Net Promoter Score oder Customer Effort Score.
• Obwohl numerische Werte einfach und schnell zu verstehen sind, sollten Sie sich nicht nur auf diese verlassen. Stellen Sie stattdessen sicher, dass Sie auch qualitative Fragen integrieren. Diese Antworten zeigen Ihnen das „Warum“ hinter der Zahl, das in zahlreichen Fällen nicht eine fehlende Funktion, sondern einfach ein unzuverlässiges Softwareprodukt voller Anomalien ist.
• Bewerten Sie den Zusammenhang zwischen den festgestellten Problemen und Ihren Testverfahren. Beurteilen Sie, ob diese Probleme durch umfassendere oder gezieltere Tests hätten entdeckt werden können. Dazu könnten funktionale Tests, Tests zur Benutzerfreundlichkeit, Leistungstests oder Sicherheitstests gehören.

Beispiel „Customer Satisfaction“

Ihr E-Commerce-Unternehmen hat eine Kundenumfrage durchgeführt und den Net Promoter Score (NPS) zur Messung der Kundenzufriedenheit verwendet. Der NPS ergab eine durchschnittliche Bewertung von 7. Obwohl dies auf den ersten Blick positiv ist, zeigten qualitative Antworten, dass Kunden Probleme mit der Website-Leistung hatten, was ihr Einkaufserlebnis beeinträchtigte.

Die qualitative Analyse zeigte, dass diese Leistungsprobleme die wahrgenommene Qualität der Software beeinträchtigten. Die Ursache lag in unzureichenden Leistungstests während der Entwicklung. Als Reaktion darauf optimierten Sie die Teststrategie und integrierten umfassendere Leistungstests.

Die Customer Satisfaction KPI half, die Lücke zwischen Kundenanforderungen und Testverfahren zu erkennen und die Teststrategie anzupassen, um die Kundenzufriedenheit zu steigern und die langfristige Erfolg des Unternehmens sicherzustellen.

Fazit zu KPIs für Software Tests

Software Tests erweist sich oft als ein vernachlässigter Aspekt der Softwareentwicklung. Dabei spielt das Testen Ihrer Software eine zentrale Rolle für den Erfolg eines Produkts. Es gibt eine Vielzahl von KPIs, um zu beurteilen, wie gut die Tests bei jeder Iteration durchgeführt werden.

Es ist unrealistisch und nicht einmal notwendig, alle KPIs anzuwenden. Sie ergänzen sich jedoch oft gegenseitig und sollten in der Kombination betrachtet werden.

Zum Beispiel ist es eine Möglichkeit, die Entwicklung der Leistungskennzahl für Escaped Effects über die verschiedenen Versionen der Software hinweg zu verfolgen. So entscheidet diese KPI letztendlich über die Einschätzung des Erfolgs all Ihrer Teststrategien. Andere KPIs wie Code Coverage, Test Automation Percentage and DDE unterstützen Sie jedoch bei der Entscheidungsfindung, auf welche Teile der Software Sie sich bei Ihren Bemühungen zur Verbesserung Ihrer Teststrategie konzentrieren sollten, falls die Anzahl der Escaped Deffects zunimmt.

Hinweis: Bitte beachten Sie bei der Umsetzung dieser KPIs zusätzlich auch andere bewährte Praktiken der Softwareentwicklung, wie z. B. die Investition von Zeit und Mühe in die Anforderungsanalyse, um einen vollständigen Satz von Anforderungen zu erhalten.

Sie haben Fragen rund um das Thema Software Tests? Schreiben Sie uns eine Nachricht.