So verbessern Sie CI / CD durch Linksverschiebungstests

Das Testen von Anwendungen war früher eine technisch anspruchsvolle, zeitkritische Aktivität, die Tage oder Wochen vor der Veröffentlichung einer Anwendung geplant war. Die Entwicklungsteams hatten bis zur elften Stunde die Möglichkeit, Code zu schreiben, und die Tester, die einen Großteil ihrer Arbeit manuell erledigten, hatten keine andere Wahl, als mit der ihnen zur Verfügung stehenden Zeit auszukommen. Das Ergebnis war, dass viele Anwendungen minderwertigen Tests unterzogen wurden und Technologieteams gezwungen waren, auf Produktionsprobleme und Fehler zu reagieren, die von Endbenutzern und Anwendungsüberwachungssystemen eskaliert wurden.

Kontinuierliche Integrationspraktiken von Devops, Unit-Test-Frameworks und Testautomatisierungspraktiken haben dieses Paradigma auf den Kopf gestellt. Anstatt die Qualitätssicherung am Ende des Entwicklungsprozesses durchzuführen, werden viele Testverfahren jetzt während der Codierung, Integration und Bereitstellung gestartet und vollständig ausgeführt. Entwickler und agile Teams automatisieren Testskripte, und CI / CD-Pipelines rufen auf, um die Tests während ihrer Code-Integrations- oder Bereitstellungsphase auszuführen. Das Nettoergebnis ist, dass Entwickler benachrichtigt werden, wenn ihre Codeänderungen den Build beschädigen, und sofort Maßnahmen ergreifen können, um das gemeldete Problem zu beheben.

Das Automatisieren von Tests und das Integrieren von Testskripten in CI / CD-Pipelines wird als Shift-Left-Test bezeichnet. Dies bedeutet, dass in der Entwicklungsphase mehr Qualitätssicherungspraktiken durchgeführt werden können, um Probleme früher im Release-Zeitplan zu erkennen. Die Automatisierung von Tests ist eine der Prioritäten vor der Bereitstellung für agile und Entwickler-Teams, die die Bereitstellungshäufigkeit erhöhen möchten.

Bei der Einführung neuer Funktionen validieren die erstellten Testskripte die neuen Funktionen. Diese Tests können dann automatisiert und in die Erstellungs- oder Bereitstellungsschritte einbezogen werden. Anstatt QS-Ingenieure am Ende eines Release-Prozesses Regressionstests ausführen zu lassen, können Sie viele dieser Tests im Rahmen der Entwicklung ausführen und validieren. Diese Tests verschieben sich vom Ende des Freigabeprozesses nach links zu früheren Entwicklungs- und Codierungsphasen.

Shift-Left-Tests ermöglichen das Engagement agiler Teams für Qualität

Shift-Left-Tests steigern nicht nur die Effizienz und verbessern die Qualität, sondern bewirken auch einen signifikanten Kulturwandel im agilen Entwicklungsprozess.

Einige Entwicklungsteams betrachten Qualitätssicherung und -tests als Hindernis für die Lieferung ihres Codes an die Produktion. Nach all der harten Arbeit, agile Produktbesitzer zufrieden zu stellen und den Code zu vervollständigen, identifizieren QA-Teamkollegen eine Liste von Fehlern, die behoben werden müssen. Wenn die Qualitätssicherung viele Fehler findet, kann dies Auswirkungen auf die Release-Zeitachse haben, um diese zu beheben. Noch schlimmer ist es, wenn wichtige Abschnitte des Codes neu entwickelt werden müssen, da Fehler Logik-, Sicherheits- oder Leistungsprobleme aufzeigen. In diesem Szenario befinden sich Entwickler und QS-Ingenieure möglicherweise im selben agilen Team, agieren jedoch nicht als Team.

Mit Shift-Left-Tests können agile Teams die Qualitätsverantwortung auf das gesamte Team von Entwicklern und Testern übertragen. Wenn Tests als Teil der CI / CD-Pipeline ausgeführt werden, bietet dies Entwicklern eine bessere Möglichkeit, Qualitätsprobleme zu dem Zeitpunkt zu beheben, zu dem sie an dem relevanten Code arbeiten. Die CI / CD-Pipeline warnt den Entwickler vor dem fehlgeschlagenen Build, und die meisten selbstorganisierenden Entwicklungsteams müssen diese Probleme sofort beheben.

Shift-Left-Tests bieten Entwicklern und QS-Ingenieuren auch die Möglichkeit, mehr Tests zu automatisieren. Eine bewährte Methode besteht darin, dass die Teams entscheiden, wer die Automatisierung implementiert, abhängig von den Testarten, die für die entwickelte Funktionalität erforderlich sind. Beispielsweise sind Entwickler häufig für die Automatisierung von Einheiten- und API-Tests verantwortlich, aber QS-Automatisierungsingenieure entwickeln häufig End-to-End-Tests zur Benutzererfahrung und Transaktionstests, die mehrstufige API-Aufrufe an mehrere Dienste simulieren.

Wann ist ein Shift-Left-Test durchzuführen?

Shift-Left-Tests eignen sich am besten für atomare Tests auf Einheitenebene mit kurzen Ausführungszeiten. Es ist wichtig, dass Tests, die in der CI / CD-Pipeline automatisiert sind und immer dann ausgeführt werden, wenn Entwickler einen Build auslösen, schnell ausgeführt werden und die Build-Prozesse nicht verlangsamen.

Komplexere und zeitintensivere Tests wie End-to-End-User-Experience-Tests, Transaktionstests, statische Code-Analysen und Sicherheitstests werden außerhalb von CI / CD-Pipelines und nach täglichen oder häufigeren Zeitplänen häufig besser ausgeführt. Diese Tests bieten Entwicklern immer noch frühes Feedback zu Qualitätsproblemen, werden jedoch außerhalb von CI / CD automatisiert, um Verlangsamungen oder Engpässe bei Builds zu vermeiden.

Thomas J. Sweet, VP für IT-Services bei GM Financial, teilte mir seine persönlichen Erkenntnisse über die Grenzen von Teststrategien für Linksverschiebungen mit. Er schlägt vor: „Die Verschiebung nach links ist immer eine Strategie, außer wenn Integrationstests für Lieferungen von Drittanbietern durchgeführt werden, da Sie häufig keinen Zugriff auf deren Quellcode haben. Selbst wenn Sie über interne Apps mit alten monolithischen Architekturen verfügen, können Sie zunächst grundlegende Check-in-Richtlinien erzwingen, die eine Codeüberprüfung und einen Sicherheitsscan erfordern. Das Einchecken sollte abgelehnt werden, wenn der Scan wichtige Warnungen und Fehler enthält. “

Eine mögliche Lösung für nachgelagerte Tests mit Integrationspartnern ist die Implementierung einer Service-Virtualisierung. Mit dieser Technik können Entwicklungsteams die Reaktion eines nachgeschalteten Systems auf verschiedene Eingaben simulieren. Es funktioniert gut, wenn die nachgeschalteten Systeme gut definiert sind. Tools von Micro Focus, Tricentis und anderen ermöglichen diese Funktion.

Rob Pociluk, ein erfahrener Qualitätssicherungsmanager, ist ein starker Befürworter von Linksverschiebungstests in der agilen Entwicklung. „Wenn Sie bereit und in der Lage sind, kleine Codeabschnitte zu testen, bleibt die Qualitätssicherung während des Sprints flexibel und auf dem Laufenden. Die Teams sollten sich immer noch davor hüten, zu viel nach links zu verschieben, da Sie den Zweck des Codes selbst verlieren können. “

Selbst wenn die Teams das Testen nach links verschieben, gibt es gute Gründe, ein Testfenster für einen Code-vollständigen Build zu planen, der für die Veröffentlichung vorgesehen ist. Es stellt sicher, dass alle automatisierten Tests beim endgültigen Build ausgeführt werden, ermöglicht jedoch auch die Planung zusätzlicher Tests, für die ein voll funktionsfähiges System erforderlich ist.

Einer dieser Tests ist UAT (User Acceptance Testing), bei dem ausgewählte Endbenutzer und Fachexperten validieren und Feedback geben. Einige UAT können während der Entwicklung durchgeführt werden, aber es ist möglicherweise nicht einfach, Benutzer dazu zu bringen, diese Tests häufig durchzuführen oder wenn die Funktionalität nicht vollständig bereit ist.

Voraussetzungen für Teststrategien nach links verschieben

Shift-Left-Tests sind eine wachsende Praxis für Entwickler, haben jedoch ihre Voraussetzungen und Vorabinvestitionen. Einige wesentliche Fähigkeiten und Praktiken sind erforderlich.

  • Es sind ausreichende Testkapazitäten und Umgebungen erforderlich, um die Anzahl der gleichzeitig ausgeführten Builds und Tests zu unterstützen.
  • Agile Teams benötigen ein Toolkit zum Testen von Produkten, die sich problemlos in CI / CD-Pipelines und Job Scheduling-Tools integrieren lassen und die Funktionalität, Codequalität, Sicherheit und Leistung überprüfen können.
  • Architekten, Infosec-Spezialisten, QS-Leiter und andere hochrangige Mitglieder der Organisation sollten Teststandards und Service-Level-Ziele festlegen, die die Standard-Akzeptanzkriterien bilden.
  • Wenn für Anwendungen Benutzereingaben erforderlich sind, benötigen Testteams ausreichende Testdaten und -muster, um genügend Personas, Anwendungsfälle und Eingabemuster zu validieren.
  • Bei Sprint-Verpflichtungen oder früher sollten Scrum-Teams, einschließlich QA-Testautomatisierungsingenieure, eine Teststrategie festlegen, welche Funktionen getestet werden, welche Testtypen implementiert werden, welche Automatisierungsprozesse aktualisiert werden und wer die Tests entwickelt.
  • Entwicklerteams sollten die Dauer der CI / CD-Pipeline-Läufe messen und kennzeichnen, wenn sich automatisierte Testschritte auf die Produktivität auswirken. Devops-Teams benötigen häufig zusätzliche Testpläne außerhalb der CI / CD-Pipelines, um länger laufende Tests durchzuführen.
  • Die Teams sollten regelmäßig Lücken in ihren automatisierten Tests erörtern, insbesondere Validierungen, für die Fachexperten, UAT oder Tests mit Partnern erforderlich sind. Wenn agile Teams diese Lücken nicht mit Automatisierung schließen können, sollten Release-Zyklen den Overhead berücksichtigen, um Risiken zu reduzieren und diese Tests abzuschließen.

Schließlich sollten agile Teams und Entwicklerorganisationen regelmäßig ihre Testabdeckung messen und diskutieren. Die Anwendung einer Teststrategie nach links funktioniert nicht, wenn die Entwicklungsteams und Qualitätsautomatisierungsingenieure nicht genügend Tests implementieren, automatisieren und integrieren, um Probleme zu erkennen und Risiken anzugehen.

Die Beschleunigung der Release-Zyklen oder die Ermöglichung einer kontinuierlichen Bereitstellung ohne ausreichende Testautomatisierung kann zu erheblichen Qualitätsproblemen führen, die die Erfahrung für Endbenutzer beeinträchtigen. Agile Entwicklungsteams, die Releases zu häufig veröffentlichen, müssen sich dann mit Produktionsproblemen und -fehlern befassen, anstatt in mehr und bessere Automatisierung zu investieren.