Table of Content
Also, es ist kein Geheimnis, dass Softwarequalitätsmanager zunehmend unter Druck geraten, qualitativ hochwertige Software in Rekordgeschwindigkeit zu liefern. Aber wenn es um die Softwarequalität geht, wie genau können wir da unseren Erfolg messen? Time-to-Market ist eine viel einfachere Berechnung, aber die Messung unserer Performance bei der Auslieferung von Software in guter Qualität hängt von einer Vielzahl von Faktoren ab, wie der Projektmethodik (Wasserfall, Hybrid, Agile), der Komplexität der Software und der Höhe der technischen Schulden, die Anzahl der Schnittstellen und vieles mehr. Kurz gesagt, die Anzahl der Variablen, die in ein akzeptables Niveau von schwerwiegenden Fehlern mit hineinspielen, sollte nicht unterschätzt werden.
Um in diesem Markt zu überleben, müssen wir uns stetig weiterentwickeln – sowohl in unseren Ansichten als auch unseren Maßstäben. Deshalb haben wir 8 KPIs zusammengestellt, die Sie Ihrer Quality-Scorecard hinzufügen sollten. Beginnen Sie ab heute damit, sie nachzuverfolgen und so das Release-Risiko zu mindern, die Qualität zu verbessern und Ihren Erfolg zu messen.
Effektivität der Fehlererkennung (Defect Detection Effectiveness, DDE, oder auch Prozentsatz der Fehlererkennung)
Die Gesamt-Effektivität Ihrer Regressionstests wird als Verhältnis von Fehlern berechnet, die vor und nach dem Release von Ihren Kunden gefunden wurden. Defekte, die nach der Veröffentlichung gefunden werden, werden üblicherweise als „Incidents“ bezeichnet und in einem Helpdesk-System protokolliert, während die während der Testphasen (Unit, System, Regression oder UAT) gefundenen Defekte vor dem Release identifiziert und mit Tools wie Panaya Test Center dokumentiert werden. Um diesen KPI richtig zu berechnen, sollten Sie vor dem Release in Ihre Produktivumgebung immer kategorisieren, in welcher Softwareversion der jeweilige Fehler identifiziert wurde.
Die Formel, die häufig für DDE verwendet wird:
Anzahl der Defekte, die beim Softwareversions-Release entdeckt wurden /
Anzahl der Defekte beim Software-Release und entgangenen Defekten, die von End-User identifiziert wurden (z. B. Incidents)
Hier ist eine einfache Illustration. Nehmen wir an, dass während Ihres Regressionstests in diesem letzten monatlichen SAP Service Pack 95 Fehler gefunden wurden und nach dem Release 25 Fehler protokolliert wurden. Die DDE würde mit 95 geteilt durch (95 + 25) = 79% berechnet werden.
Beachten Sie, dass die DDE mit einem Liniendiagramm überwacht werden sollte, das am Tag nach dem Release in die Produktion bei 100% beginnt. Wenn Ihre internen End-User und Kunden dann zum Beispiel mit Ihrem neuesten SAP Service Pack arbeiten, werden sie unweigerlich einige Vorfälle protokollieren. Wir sehen häufig das Auftreten eines „Eingabe-Rausches“ innerhalb der ersten Woche, zwei Tage nach dem Eintreffen eines Service Packs in der Produktivumgebung. Das ist der Zeitpunkt, an dem Sie einen schnellen Rückgang von 100% auf ca. 95% bemerken, da Incidents protokolliert werden. Wenn Ihr Unternehmen Service Packs monatlich releast werden, messen Sie die DDE für 30 Tage für jedes Service Pack. Wenn Ihr Unternehmen dagegen nur vier (4) Haupt-Releasezyklen pro Jahr durchführt, dann messen Sie sie für 90 Tage, um zu sehen, wie sie in diesem Zeitraum abnimmt.
Was gilt als „gute DDE“? Ähnlich wie Blutdruckmesswerte, entwickelt sich jede Organisation und Person im Laufe der Zeit weiter. Obwohl die Medizin den „optimalen“ Blutdruckwert als 120/80 definiert, ist es natürlich, dass wir mit zunehmendem Alter einen Anstieg des systolischen Blutdrucks beobachten. Bei der DDE sagten Branchenexperten und Thought-Leader, dass 90% in den meisten Branchen vorbildlich seien. Einige Unternehmen erreichen jedoch konstant mehr als 95% DDE, indem sie mit Tools für die Impact-Simulation von Änderungen, wie z. B. Panaya’s Impact Analysis, früher im Prozess starteten.
Systemweite Defekte (SWD)
Haben Sie schon einmal mehrere Fehler erlebt, die mit denselben Objekten verknüpft sind? Natürlich haben Sie das, es ist ein häufig auftretendes Phänomen, auf das viele Testmanager stoßen. Plötzlich sehen Sie einen großen Anstieg in der Anzahl der in einem UAT-Zyklus gemeldeten Fehler.
Also, was sind Ihre Möglichkeiten, um das unvermeidliche Drama der “Fehlerinflation?” zu bewältigen? Es ist ganz einfach: fangen Sie an, das zu verfolgen, was Panaya „systemweite Defekte“ nennt. Das manuelle Nachverfolgen dauert ewig. Es ist außerdem mühsam, alte ALM-Tools zu verwenden, bei denen Sie nur die Möglichkeit haben, Fehler miteinander zu verknüpfen und einen Kommentar hinzuzufügen. Aber wenn Sie zurzeit keine Wahl bei den Tools haben, müssen Sie die Zeit für die korrekte Nachverfolgung von systemweiten Defekten einplanen, um „richtig“ zu erklären, warum sich die Bug-Trendlinie gegen Ende eines Testzyklus nach oben bewegt, statt nach unten. Wenn Sie die Möglichkeit haben, sich das Panaya Test Center anzuschauen – es hat SWD in die Engine eingebaut und berechnet die SWD auf Knopfdruck.
Das ‚Spider Web‘ – Diese aussagekräftige und dennoch einfache Darstellung von 6 zusätzlichen Key-Performance-Indikatoren innerhalb des „Risk Cockpits“ der Panaya-Plattform rundet die wichtigsten KPIs ab, die jeder Qualitäts-, Test- und Release-Manager verfolgen sollte
Erfüllung der Anforderungen
QA-Manager müssen Risiken auf einer tieferen Ebene verstehen, die nur mit Code- oder Transportebenen-Transparenz für jede Anforderung erkannt werden kann. Dies erfordert die richtigen Tools. Panaya ist das einzige Tool, das die Erfordernisse von Organisationen, die SAP im Einsatz haben und die intelligente Empfehlungen für Unit-Tests, Code-Korrekturen und Risikoanalysen basierend auf Transportaktivitäten suchen, erfüllt. Dieses Maß an Nachverfolgung ist in Panaya Release Dynamix (RDx) verfügbar.
Abschluss der Entwicklung
Wir leben im Zeitalter des Kunden, was die digitale Transformationsstrategie jedes Unternehmens vorantreibt. Heutzutage können wir es uns nicht leisten, uns in unserem Denken oder unserer organisatorischen Herangehensweise an Software-Qualitätssicherung und -bereitstellung zu isolieren. Unsere traditionellen ALM-Modelle von damals sind nicht für Continuous Delivery Modell von heute ausgelegt. Um diese alte Denkweise zu bekämpfen, müssen sich QA- und Testmanager in die Entwicklung von Anwendungen einbringen – und das bedeutet, ein Gefühl für die Bereitstellung von User Stories zu haben. Es reicht nicht aus, zu warten, bis eine User Story den Status „erledigt“ erreicht. Wir müssen die Entwicklung einer User Story verfolgen, an täglichen Scrum-Meetings teilnehmen und offen über die sich entwickelnden Risiken sprechen, die entstehen, wenn wichtige Änderungen an der getesteten Anwendung vorgenommen werden. Dies ist auch in Panaya Release Dynamix (RDx) verfügbar-
Testplanabdeckung
Dies ist ein großartiger KPI, da Sie nicht nur auf das Tracking von System-, Integrations-, Regressions- und UAT-Abdeckung beschränkt siind. Ganz im Sinne von „shifting-left“ wächst die Wichtigkeit der Verfolgung der Unit-Test-Abdeckung. Klingt verrückt, oder? Das ist es nicht – vor allem, wenn Sie die richtigen Tools haben, um nicht nur die Durchführung von Unit-Tests zu erleichtern, sondern auch die Erfassung der tatsächlichen Ergebnisse (Beweise) noch einfacher zu machen. Mit der integrierten Test Record-and-Play-Funktion von Panaya Test Center wird Ihre Beteiligung am Unit-Test in die Höhe schießen. Nicht nur das, Sie können eine Nachverfolgungs-Matrix vorzeigen, die eine End-to-End-Abdeckung zeigt, und gleichzeitig einfach die tatsächlichen Ergebnisse Ihrer Audit-Abteilung von den Unit- bis zu den Regressionstests präsentieren.
Risikoanalyse der Änderungen
Jede Änderung, die wir an einer getesteten Anwendung vornehmen, birgt Risiken. Wir wissen jedoch nicht immer, ob wir die richtigen Dinge testen. Viele Organisationen haben ihre eigene Definition dessen, was „Änderungsrisiko“ für sie bedeutet. Innerhalb des „Risk Cockpits“ von Panayas Release Dynamix (RDx) können Sie mit der Impact-Analyse für Ihr Projekt oder das nächste Release Änderungen mit Gewissheit nachverfolgen. RDx berechnet systematisch das Risiko für jede Anforderung und hält Sie auf dem Laufenden, wie es im Laufe des Delivery-Zyklus verändert.
Testausführungsrisiko
Für Unternehmen ist es nur allzu üblich, KPIs wie verfasste Tests, bestandene Tests, automatisierte Tests und durchgeführte Tests zu verfolgen. Aber was ist mit der Verfolgung der tatsächlichen Schritte, die in jedem der Tests ausgeführt werden? Viele der beliebten ALM-Plattformen stellen keine vorgefertigten Reporting-Funktionen zur Verfügung, um den Ausführungsfortschritt der Testschritte zu verfolgen. Wenn während eines UAT-Zyklus viele verschiedene Übergaben auftreten, ist es sinnvoll, das Testausführungsrisiko und den Teststatus nicht nur auf Test-, sondern auch auf Geschäftsprozessebene zu verfolgen. Das Panaya Test Center erledigt genau das standardmäßig.
Fazit
Mit Panaya können Software-Qualitätsmanager und alle relevanten Stakeholder ihre Test-KPIs erfüllen, um mehr Innovationen voranzutreiben und gleichzeitig den Aufwand um 30 bis 50% zu reduzieren, ohne Abstriche bei Umfang und Qualität zu machen. Standardisieren Sie Ihre Testprozesse und messen Sie den Erfolg genau, während alle Beteiligten die gleiche Testmethodik anwenden, um Transparenz in Echtzeit über alle Testzyklen hinweg zu erhalten, einschließlich umfangreicher UAT.
