Was ist ein Shift-Left-Test?

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 kommen Bugs in den Code?

Das Shift-Left-Teststrategie wird in der ziemlich berühmten Grafik von Capers Jones gut illustriert, die die steigenden Kosten von Bugs/Defekten zeigt, die in jeder Phase der Softwareentwicklung in die Software eingebracht werden. Der erste Teil der Grafik zeigt, dass die überwiegende Mehrheit der Bugs während der Codierungsphase entsteht, was zu erwarten war.

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 werden 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 kostet es, 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 interessant, denn wir sehen eine üble Kostenentwicklung, die dramatisch ansteigt, je später der Defekt entdeckt wird. Einen Fehler bis zum Systemtest durchschleichen zu lassen, ist 40-mal so teuer, ihn beim Codieren zu finden, oder 10-mal teurer, als denselben Fehler beim Unit-Test zu finden. Und es wird einfach lächerlich teuer, wenn man sich anschaut, wie viele Fehler bis zur eigentlichen Bereitstellung durchschlüpfen.

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 ...

Testen Sie früh, testen Sie oft: Der Shift-Left-Ansatz

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 auf den Entwickler abzuwälzen

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 also der Kern von allem, was wir bei Parasoft tun. Aber der Kürze halber sei gesagt, Shift-Left-Testansatz gliedert sich 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 reduzieren (insbesondere derjenigen, die es in die Veröffentlichung schaffen). Letztendlich ist es weitaus wertvoller, von vornherein weniger Fehler zu verursachen, als mehr Fehler zu finden, und es ist viel billiger. Deshalb setzen sicherheitskritische Codierungsstandards auf einen proaktiven, präventiven Ansatz, indem Code gekennzeichnet wird, der möglicherweise „funktioniert“, aber dennoch nicht sicher ist.

Codierungsstandards sind das Software-Äquivalent zu technischen Standards und von entscheidender Bedeutung für die Reduzierung des Fehleraufkommens (zusätzlich zum früheren Auffinden von Fehlern), um Ihre Shift-Left-Initiative zu unterstützen und den größtmöglichen Nutzen daraus zu ziehen. Codierungsstandards sind die Verkörperung von Software-Engineering-Wissen, die Ihnen helfen, schlechten/gefährlichen/unsicheren Code zu vermeiden. Um sie zu verwenden, wenden Sie eine statische Codeanalyse an.

Für die Softwaresicherheit ist dies besonders wichtig, um Ihre Software erfolgreich zu härten. Sie möchten Sicherheit in Ihren Code integrieren und ihn nicht testen. Mithilfe von Codierungsstandards können Sie von Anfang an eine sicherere Anwendung erstellen (d. h. „Secure by Design“), was sowohl eine gute Idee als auch eine Voraussetzung 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.

Mit der Servicevirtualisierung können Sie abhängige Systeme simulieren, die möglicherweise nur begrenzt verfügbar sind, z. B. Mainframes, Zugangsgebühren, Dienste von Drittanbietern oder möglicherweise Systeme, die noch nicht bereit sind. Indem Sie sie simulieren, können Sie Funktionstests durchführen, ohne dass das gesamte System verfügbar sein muss, und Sie können die Testausführung nach links bis zum Entwicklungsdesktop verlagern.

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 früher mit Ihren Sicherheitstests beginnen. Durch die Entkopplung von physischen Systemen können Sie etwas noch Interessanteres tun, nämlich die simulierten Systeme dazu zu bringen, sich auf böse Weise zu verhalten. Jetzt können Sie WIRKLICH mit Sicherheitstests beginnen … Anstatt Ihr System einfach nur auf infizierte Daten und DDoS-Angriffe zu untersuchen, können Sie sich von einem System mit Paketen überfluten lassen, fehlerhafte Daten senden oder eine der vielen anderen von Angreifern häufig genutzten Exploits nutzen. So können Sie nicht nur früher testen (links), sondern auch viel tiefer, 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.