Was ist ein Shift-Left-Test?

Je früher Sie sich über Probleme in Ihrem Code informieren, desto weniger Auswirkungen haben sie. Es kostet auch weniger, mit ihnen umzugehen. In diesem Blog untersuchen wir die Methode der Linksverschiebung und wie Sie sich der Linksverschiebung in Ihrem Unternehmen nähern können.

Die Shift-Left-Testmethode

Bei der Verlagerung nach links geht es darum, kritische Testpraktiken zu einem früheren Zeitpunkt im Entwicklungslebenszyklus zu verschieben. Dieser Begriff wird insbesondere in Agile-, Continuous- und DevOps-Initiativen verwendet. Warum müssen Sie frühzeitig Softwaretests durchführen?

Viele Testaktivitäten finden spät im Zyklus statt, wobei es länger dauert, um herauszufinden, was schief gelaufen ist, und die Reparatur mehr kostet. Beim Verschieben nach links geht es darum, die Identifizierung und Verhinderung von Fehlern auf früher zu verschieben. Wenn Sie dies nicht tun und darauf warten, später im Entwicklungszyklus Testpraktiken durchzuführen, sind insbesondere Ihre nicht funktionalen Geschäftsanforderungen (dh Sicherheits- und Leistungstests) so grundlegend in Ihrem Code verankert, dass Sie sie nur noch patchen können anstatt sie richtig zu reparieren.

Wann geben Fehler den Code ein?

Die Teststrategie für die Verschiebung nach links ist in der etwas bekannten Grafik von Capers Jones gut dargestellt, die die steigenden Kosten für Fehler / Defekte zeigt, die in jeder Phase der Softwareentwicklung in die Software eingeführt werden. Der erste Teil der Grafik zeigt, dass die enorme Die meisten Fehler treten während der Codierungsphase auf, was zu erwarten ist.

Unabhängig davon, ob sie tatsächliche Fehler machen oder die Anforderungen falsch verstehen oder die Auswirkungen eines bestimmten Codeteils nicht durchdenken, führen Entwickler bei der Erstellung des Codes Fehler ein.

Fehler werden auch in die Anwendung eingeführt, wenn es an der Zeit ist, die Teile zusammenzufügen, insbesondere wenn mehrere Teams beteiligt sind (und wenn moderne Architekturen wie Microservices komplexer werden).

Wann sind diese Fehler? gefunden?

Es wird interessant, wenn wir die Linie überlagern, die zeigt, wo Fehler sind gefundenüber dem Diagramm der eingeführten Fehler.

Beachten Sie, dass es sich im Grunde genommen um eine Umkehrung der ersten Zeile handelt:

Dies ist natürlich nicht überraschend, da normalerweise Fehler auftreten, wenn Sie mit dem Testen beginnen, und es ohne eine geeignete Infrastruktur schwierig sein kann, mit dem Testen zu beginnen, bevor alles fertig ist (dazu später mehr). Was wir hier sehen ist, dass die Fehler meistens während des Codierens eingeführt werden, aber fast nie in dieser Phase gefunden.

Was macht es kosten um Fehler zu beheben?

Da die meisten Fehler während des Codierens auftreten, aber erst in einer späteren Phase entdeckt werden, ist es wichtig, den Unterschied zu verstehen, den das Beheben von Fehlern in jeder Entwicklungsphase kostet. Dies ist unten dargestellt:

Jetzt wird es wirklich interessant, da wir einen unangenehmen Kostenanstieg sehen, der sich dramatisch erhöht, je später der Defekt gefunden wird. Das Durchschleichen eines Fehlers zum Systemtest ist 40-mal so teuer wie das Auffinden während des Codierens oder 10-mal teurer als das Auffinden desselben Fehlers beim Testen von Einheiten. Und es wird einfach lächerlich teuer, wenn man sich die Anzahl der Fehler ansieht, die bis zur tatsächlichen Bereitstellung durchgehen.

Es gibt Gründe für diese Kosteneskalation, darunter:

• Die Zeit und Mühe, die erforderlich sind, um das Problem aufzuspüren. Je komplexer (größer) der Testfall ist, desto schwieriger ist es herauszufinden, welcher Teil davon der eigentliche Unruhestifter ist.
• Die Herausforderung besteht darin, Fehler auf dem Desktop eines Entwicklers zu reproduzieren, da abhängige Systeme wie Datenbanken oder APIs von Drittanbietern eingeführt werden.
• Die Auswirkungen der Änderung, die zur Behebung eines Fehlers erforderlich ist. Wenn es ein einfacher Fehler ist, ist es nicht so wichtig. Aber wenn Sie dies an vielen Stellen getan haben oder das falsche Framework verwendet haben oder Code erstellt haben, der für die erwartete Last nicht skalierbar genug ist oder der nicht gesichert werden kann ...

Früh testen, oft testen (Linksverschiebung)

Sehen Sie sich nun die orangefarbene Linie an, die der folgenden Grafik hinzugefügt wurde, da sie einen vorgeschlagenen Fehlererkennungszyklus darstellt, der auf früheren Tests basiert (nach links verschoben):

Sie können beobachten, wie die orangefarbene Erkennungskurve auf der billigen Seite größer und auf der teuren Seite kleiner wird, was uns eine ziemlich signifikante Kostenreduzierung ermöglicht.

Die Verschiebung nach links beruht auf einer ausgereifteren Entwicklungspraxis, zum Beispiel einer, die auf der basiert Software-Testpyramide (Entwickler Erstellen einer Reihe von Unit-Tests die den Code einigermaßen gut abdecken, und funktionale Tester und API-Tester, die so viel wie möglich tun und die Abhängigkeit von spätzyklischen Tests minimieren, damit Sie gerade genug manuelle/UI-Tests haben, um zu beweisen, dass alles funktioniert). Auf diese Weise dienen die Late-Cycle-Tests dazu, die Funktionalität zu beweisen, nicht um Fehler zu finden. Test früh, oft testen ist das Mantra des Shift-Lefter.

Noch weiter nach links verschieben

Einige Organisationen, die nach links wechseln, halten an dieser Stelle an. Aber Sie erhalten noch mehr Wert, wenn Sie noch weiter nach links drängen, um sich selbst zu codieren. Schließlich werden hier Fehler eingeführt. Lassen Sie uns also nach ihnen suchen, während die Entwicklung noch funktioniert. Hier profitieren wir von der statischen Code-Analyse - indem wir Fehler noch weiter links finden, wo Fehler am billigsten zu beheben sind:

Mit der statischen Analyse können Sie während der eigentlichen Codierungsphase mit dem Auffinden von Fehlern beginnen, wenn die Kosten für das Auffinden von Fehlern so gering wie möglich sind.

Wie Sie deutlich sehen können, ist es am kostengünstigsten, Dinge zu finden, bevor mit dem „Testen“ begonnen wird. Es ist auch am zeiteffektivsten, da Entwickler keine Probleme damit haben, Fehler zu reproduzieren oder die Fehler zu verstehen. Es ist äußerst hilfreich, einen Fehlerbehebungszyklus von Tagen oder Wochen auf Stunden oder Minuten verkürzen zu können.

Hüten Sie sich davor, die Last nur auf den Entwickler zu verlagern

In diesem Schritt besteht jedoch eine Gefahr, die den Softwareentwicklern versehentlich zu viel Testlast auferlegt. Das Wichtigste, das Sie beim Betrachten des Diagramms beachten sollten, ist, dass die Kosten für die Fehlerbehebung zwar drastisch steigen, wenn Sie nach rechts gehen, die Ressourcen auf der linken Seite jedoch möglicherweise die höchsten Kosten im gesamten Software-Lebenszyklus haben - ganz zu schweigen von Ihnen nehmen sie davon ab, sich auf die Entwicklung von Funktionen zu konzentrieren.

Sie müssen also das Richtige tun und all dies auf die nächste Stufe bringen. Sie möchten Fehler nicht nur früher finden, sondern auch Verringern Sie zunächst die Anzahl der Fehler, die Sie in die Anwendung einfügen. Siehe die Grafik unten mit der schönen reduzierten Blase auf der linken Seite.

Aber warte, da ist eine Falle! Wenn Sie Leute dafür belohnt haben, Fehler zu finden und zu beheben, werden sie jetzt weniger finden, was eigentlich das ist, was Sie wollen, aber nur, wenn Sie die Anzahl der Fehler, die Sie überhaupt einführen, wirklich reduziert haben. Das Messen der Anzahl von Fehlern, die es ins Feld schaffen, ist wahrscheinlich eine nützlichere Metrik.

Wie verschiebt man sich nach links?

Ok, das ist der Kern von allem, was wir bei Parasoft tun. Der Kürze halber gliedert sich der Testansatz der Verlagerung nach links in zwei Hauptaktivitäten.

Wenden Sie Best Practices für Entwicklungstests an

Durch frühere Entwicklungspraktiken wie statische Code-Analyse und Unit-Tests können Fehler früher im Prozess erkannt und verhindert werden.

Es ist wichtig, sich daran zu erinnern, dass das Ziel nicht darin besteht, Fehler zu finden, sondern die Anzahl der Fehler zu verringern (insbesondere diejenigen, die es in die Veröffentlichung schaffen). Letztendlich ist es weitaus wertvoller, weniger Fehler zu erstellen, als mehr Fehler zu finden - und es ist viel billiger. Aus diesem Grund werden sicherheitskritische Codierungsstandards für einen proaktiven, vorbeugenden Ansatz festgelegt, indem Code gekennzeichnet wird, der möglicherweise „funktioniert“, aber dennoch nicht sicher ist.

Codierungsstandards sind das Software-Äquivalent zu technischen Standards und sie sind der Schlüssel zur Reduzierung des Fehlervolumens (zusätzlich zum früheren Auffinden von Fehlern), um Ihre Initiative zur Verlagerung nach links zu unterstützen und den größtmöglichen Nutzen daraus zu ziehen. Codierungsstandards sind die Verkörperung von Software-Engineering-Kenntnissen, mit denen Sie schlechten / gefährlichen / unsicheren Code vermeiden können. Um sie zu verwenden, wenden Sie eine statische Code-Analyse an.

Für die Software-Sicherheit ist dies besonders wichtig, um Ihre Software erfolgreich zu härten. Sie möchten Sicherheit in Ihren Code einbauen, nicht ihn testen. Mit Codierungsstandards können Sie von Anfang an eine sicherere Anwendung erstellen (dh von Natur aus sicher), was sowohl eine gute Idee als auch eine Anforderung ist wenn Sie Vorschriften wie der DSGVO unterliegen.

Nutzen Sie die Service-Virtualisierung, um kontinuierliche Tests zu ermöglichen

Als nächstes müssen Sie die Tests, die in allen Phasen, einschließlich der späteren Phasen des Entwicklungsprozesses, erstellt wurden, durchführen und sie kontinuierlich weiterführen. Dies ist entscheidend für Teams, die agile Entwicklungsmethoden anwenden, um während des gesamten Entwicklungsprozesses kontinuierliches Feedback zu geben. Unit-Tests können problemlos kontinuierlich ausgeführt werden, aber die Ausführung von Funktionstests in späteren Phasen nach links zu verschieben, ist aufgrund externer Systemabhängigkeiten oft schwierig, und hier können Sie die Service-Virtualisierung nutzen kontinuierliches Testen ermöglichen.

Service-Virtualisierung ermöglicht es Ihnen, abhängige Systeme zu simulieren, die möglicherweise eine begrenzte Verfügbarkeit haben, wie z. B. Mainframes, Zugangsgebühren, Dienste von Drittanbietern oder vielleicht Systeme, die einfach noch nicht bereit sind. Indem Sie sie simulieren, können Sie Funktionstests durchführen, ohne das gesamte System verfügbar zu haben, und Sie können die Testausführung nach links bis zum Entwicklungsdesktop verschieben.

In Hinsicht auf Service-Virtualisierung in Performance-Tests, Service-Virtualisierung ermöglicht es Ihnen, zu testen, bevor alles bereit ist, und ohne ein vollständiges Labor für alles im System zu haben. Sie können sogar alle möglichen Was-wäre-wenn-Szenarien ausführen, z. B. was wäre, wenn der Anwendungsserver schnell und die Datenbank langsam ist (etwas, das in der realen Welt nur schwer möglich ist). Oder was ist, wenn mein Server anfängt, lustige Fehler wie einen 500-Fehler auszugeben – wie wirkt sich das auf die Systemleistung aus?

Sie können das System so stark wie Sie möchten und darüber hinaus so früh wie möglich ausführen. (Erfahren Sie mehr darüber, wie es geht Verschieben Sie Ihre Leistungstests nach links.)

Ebenso können Sie Ihre Sicherheitstests früher durchführen. Durch die Entkopplung von physischen Systemen können Sie etwas noch Interessanteres tun, nämlich die simulierten Systeme auf böse Weise verhalten zu lassen. Jetzt können Sie WIRKLICH mit Sicherheitstests beginnen ... Anstatt Ihr System nur nach verschmutzten Daten und DDoS zu durchsuchen, können Sie sich von einem System mit Paketen überfluten lassen oder fehlerhafte Daten oder einen der vielen anderen Exploits senden, die häufig von Angreifern verwendet werden. Sie können also nicht nur früher testen (links), sondern auch viel tiefer testen, als dies mit einem Testlabor oder Produktionssystem möglich ist.

Zusammenfassung

Die über viele Jahrzehnte bewährten Qualitätssicherungsprozesse können genutzt werden, um die Qualität drastisch zu verbessern und gleichzeitig Zeit und Geld zu sparen.

Wenn Sie durch den Einsatz moderner Softwaretesttechnologien nach links wechseln, können Sie Software erzielen, die sicher, zuverlässig und sicher ist. Wenn Sie die Tests nach links verschieben, können Sie die Testkosten senken, indem Sie Fehler früher finden, wenn sie billiger sind, und gleichzeitig die Anzahl der Fehler reduzieren, die Sie zuerst in den Code eingefügt haben.