Metriken, die für End-to-End-Tests wichtig sind

Wie misst man Softwarequalität?

Aus den Ergebnissen mehrerer Marktstudien geht klar hervor, dass sich die Führungskräfte der Branche einig sind, dass die Softwarequalität oberste Priorität hat, wenn es darum geht, den Kunden geschäftlichen Mehrwert zu bieten. Die Herausforderung besteht darin, zu definieren, was das bedeutet, und wie es erreicht werden kann. Dazu gehört die Auswahl und Anwendung geeigneter Metriken auf Ihre Softwareentwicklungs- und Testprozesse.

Eine Möglichkeit, die Softwarequalität zu verbessern, besteht darin, Ihrem Entwicklungsworkflow Testautomatisierung hinzuzufügen. Auf diese Weise können Sie das Testen früher im Lebenszyklus verlagern und Fehler früher mit robusteren Tests finden und beheben, als dies manuell möglich wäre. End-to-End-Tests umfassen die Anwendung mehrerer Testtechniken, um alle Facetten der Anwendung zu berücksichtigen, vom Code über die APIs bis hin zur Benutzeroberfläche.

Kürzlich hatten wir die Gelegenheit, mit Diego Lo Giudice, Vice President und Principal Analyst bei Forrester Research, über seine Gedanken zu Metriken für Softwarequalität zu sprechen. Seine Experteneinblicke werden hier vorgestellt und in der On-Demand-Webinar-Wiedergabe geteilt, Bieten Sie herausragende Erfahrungen mit End-to-End-Tests und wichtigen Metriken.

Fragen und Antworten zu End-to-End-Tests

Mit Gastdarsteller Diego Lo Giudice, VP & Principal Analyst bei Forrester Research

F: Im Webinar Bieten Sie herausragende Erfahrungen mit End-to-End-Tests und wichtigen Metriken, Sie haben erwähnt, dass Agile und DevOps zwei Seiten derselben Medaille sind. Wie helfen diese Praktiken Unternehmen bei der Anwendung und Integration von End-to-End-Tests in ihre CI/CD-Workflow?

A: Agile und DevOps sind zwei Seiten derselben Medaille, das eine geht nicht ohne das andere.

Warum?

Denn während Agile dabei hilft, die Mauer zwischen Entwicklungsteams und Unternehmen einzureißen und Dinge zu beschleunigen, während es sich an Anforderungen ausrichtet, setzt DevOps die Arbeit zwischen Entwicklungsteams und I&O-Operationen fort. Agile + DevOps bringt vollständige End-to-End-Business-Agilität.

Aus organisatorischer und praktischer Sicht müssen Agile + DevOps es ertragen, das Testen nach links zu verlagern und es zu einem Teil dessen zu machen, was im Sprint erledigt werden muss. Ist dies nicht der Fall, kann Continuous Delivery/Deployment nicht stattfinden. Zu spät durchgeführte Tests unterbrechen die kontinuierliche DevOps-Schleife.

Die Verwendung von CI/CD-Tools in Agile + DevOps kann jetzt einen Workflow orchestrieren, bei dem Code eingecheckt wird, Komponententests ausgeführt werden, Funktionstests ausgeführt werden, Leistungstests ausgeführt werden und bei jedem Schritt, basierend auf Abdeckung und bestanden vs. nicht bestanden Tests können automatische Entscheidungen getroffen werden, um den Code vor- oder zurück an das Team zu schicken, um weitere Fehler zu beheben und zu testen.

Sie können also jetzt sehen, dass wir das, was früher ein langer manueller Governance-Prozess war, durch einen automatisierten End-to-End-Test-Workflow ersetzt haben, der normalerweise viele Übergaben, Release-Meetings und mehr erfordert hätte, um dasselbe zu tun. Es reduziert die Testzykluszeit durch die Automatisierung der Governance. Das ist die Hilfe, die Unternehmen dabei bekommen.

F: Zu Beginn der Präsentation haben Sie angemerkt, dass die Softwarequalität ein Anliegen der Führungskräfte ist. Wie können IT und Führungskräfte Qualität am effektivsten messen und quantifizieren? Was sind einige der wichtigsten Metriken für Softwaretests und -qualität?

A: Bei der Suche nach wirklich wichtigen modernen Anwendungsmetriken konzentrieren sich die wichtigsten Ergebnismetriken auf den Geschäftswert. Entscheidend für den Geschäftswert sind jedoch Qualitätsmetriken.

Die wichtigsten Qualitätsmetriken sind immer noch Metriken, die die Softwarequalität in der Produktion messen – entgangene Fehler. Niemand möchte, dass Fehler in die Produktion gelangen, weil sie Umsatzeinbußen verursachen, mit einem schlechten Ruf in die Schlagzeilen kommen und die Benutzererfahrung beeinträchtigen.

Zu den üblichen Metriken, die nachverfolgt werden müssen, gehören Fehler in der Codedichte auf Unit-Test-Ebene, entgangene Fehler von der Entwicklung bis zum Testen, die Ausführungszeit der Testautomatisierung, die Anzahl der fehlgeschlagenen Commit-Tests und die Anzahl der fehlgeschlagenen Automatisierungstests. Ich würde jedem von ihnen „Trends“ hinzufügen.

Geht der Trend zur Geschwindigkeit der Ausführung automatisierter Tests zurück? Wenn ja, könnte das ein Hinweis auf Probleme bei den Tests sein.

F: Sie haben auch davon gesprochen, ein „Meer von Metriken“ zu vermeiden. Woher weiß ich also, ob ich zu viele habe? Woher weiß ich, welche ich beschneiden muss?

A: Hier kommen Frameworks wie OKRs (Objective Key Results) oder GQM (Goal, Question, Metrics) ins Spiel. Wenn Sie sich an das Prinzip halten, dass Sie nicht verwalten können, was Sie nicht messen, müssen Sie entscheiden, was Sie verwalten müssen.

Was sind die Teamziele (oder die Produktziele)? Leiten Sie von dort aus die nützlichen Metriken ab, die Sie benötigen. Es hat keinen Sinn, Leistungsmetriken zu haben, wenn die Leistung nicht der Hauptschmerz Ihres Unternehmens ist und daher kein Ziel für die Organisation ist.

Wenn es sich stattdessen um technische Fehler handelt, sollten Sie die Abdeckung der Dashboard-Einheitentests einfügen und Metriken übergeben.

F: Wie können aussagekräftige Metriken helfen, den Wert der Testautomatisierung zu rechtfertigen?

A: Normalerweise ist Qualität gemäß dem oben genannten Rahmen eine führende Metrik, die zum Geschäftswert beiträgt. Dies ist ein Ausgangspunkt, um sich mit den Interessengruppen zu einigen. Infolgedessen beschleunigt das Ersetzen manueller Tests durch automatisierte Tests den Bereitstellungszyklus, da auch die Zykluszeit für die Testausführung abnimmt.

Die gesamte Entwicklungszykluszeit, sogar von Cash bis Code, wird durch die Testautomatisierung positiv beeinflusst. Die Qualität steigt auch, wenn die Automatisierung richtig ist, weil Sie dieselben Tests (denken Sie an Regression) immer wieder ausführen können. Sie bauen einmal, führen aber viele Male aus. Beachten Sie jedoch, wie schwierig die Automatisierung sein kann, da schlecht codierter Code und schlecht codierte Systeme schwer zu testen sein können. Oder wenn ein Test nicht wiederholt werden muss, warum ihn automatisieren? Obwohl dies selten vorkommt, insbesondere in Agile.