DevOps bringt El Nino-Scale-Auswirkungen auf Softwaretests

Slams! Überwältigt! Verursacht Chaos!

Diese Sprache wird in den heutigen Schlagzeilen verwendet, um El Ninos ersten Fortschritt in Kalifornien zu beschreiben - und sie gilt ebenso für die Auswirkungen von DevOps auf Softwaretests.

Mit DevOps führt die ständige Flut neuer Funktionen unbestreitbar zu einer starken Störung der herkömmlichen Tests. Viele Teams halten sich kaum über Wasser, um sicherzustellen, dass jede neue Anforderung tatsächlich funktioniert, bevor sie bereitgestellt wird. Wie können Sie also sicherstellen, dass jede „kleine Änderung“ keine Nebenwirkungen mit sich bringt, die sich auf die gesamte Anwendung auswirken und den Endbenutzer frustrierter machen als einen Fahrer auf einer überfluteten kalifornischen Autobahn?

Wie wirken sich DevOps und Agile auf Softwaretests aus?

Traditionell war das Testen ein zeitlich begrenztes Ereignis. Sie würden auf die Entwicklung warten, um einen brauchbaren Build zu erstellen, und dann gab es eine Zeit für die Qualitätssicherung, um das zu üben, was sie zum Testen benötigten. Wenn sie das Gefühl hatten, „fertig getestet“ zu sein oder keine Zeit mehr zu haben, wurden die Tests abgebrochen.

Mit dem Aufstieg von Agile und DevOps geschahen zwei wichtige Dinge:

• Die (bereits schrumpfende) Spätzykluszeit für die Ausübung der Anwendung verschwand vollständig.
• Die vorherrschenden Testmethoden (manuelle Tests und GUI-Tests) wurden überholt, da sie für eine Welt voller kurzer Iterationen und ständiger Änderungen zu langsam, zeitaufwändig, teuer und fragil waren.

Um trotz der Geschwindigkeit und Häufigkeit der heutigen Veröffentlichungszyklen sicher zu veröffentlichen, müssen wir aufhören zu fragen: "Sind wir mit dem Testen fertig?" Und den Fokus auf "Hat der Veröffentlichungskandidat ein akzeptables Geschäftsrisiko?" Verschieben. Wenn wir diese Frage beantworten können, können wir feststellen, ob die Anwendung wirklich bereit ist, die Bereitstellungspipeline zu durchlaufen.

Angesichts der steigenden Kosten und Auswirkungen von Softwarefehlern können es sich Unternehmen nicht länger leisten, ein Release herauszubringen, das die bestehende Benutzererfahrung stören oder neue Funktionen einführen könnte, die das Unternehmen neuen Sicherheits-, Zuverlässigkeits- oder Compliance-Risiken aussetzen. Um dies zu verhindern, muss die Organisation von der Validierung der Bottom-up-Anforderungen auf die Bewertung der Systemanforderungen im Zusammenhang mit den übergreifenden Geschäftszielen – z. B. durch kontinuierliches Testen – ausdehnen.

Was bedeutet der Übergang vom automatisierten Testen zum kontinuierlichen Testen?

Die Automatisierung von Tests ist ein entscheidender Schritt in Richtung kontinuierlicher Tests. Wenn jedoch einer Ihrer automatisierten Tests fehlschlägt, wissen Sie, was er wirklich bedeutet? Zeigt es ein kritisches Geschäftsrisiko an oder nur einen Verstoß gegen einen Namensstandard, dem sich sowieso niemand wirklich verpflichtet fühlt? Und was passiert, wenn es fehlschlägt? Gibt es einen klaren Workflow, um Fehler gegenüber Geschäftsrisiken zu priorisieren und die kritischsten zuerst anzugehen? Und gibt es für jeden Fehler, der behoben werden muss, ein Verfahren, um alle ähnlichen Fehler aufzudecken, die möglicherweise bereits eingeführt wurden, und um zu verhindern, dass dasselbe Problem in Zukunft erneut auftritt? Hier zeigt sich der Unterschied zwischen automatisiert und kontinuierlich.

Zu Entwickeln Sie sich vom automatisierten Testen zum kontinuierlichen Testenbenötigen Sie Folgendes:

1. Klar definierte Geschäftserwartungen mit Geschäftsrisiken, die pro Anwendung, Team und Release identifiziert werden.
2. Fehler werden automatisch gegenüber den Geschäftstreibern priorisiert und wissen, wie diese Risiken gemindert werden können, bevor der Release-Kandidat live geschaltet wird.
3. Kontinuierliches Testen in vollständigen Testumgebungen mithilfe von Simulationen - dies ist entscheidend, um die aktuelle Benutzererfahrung vor den Auswirkungen von Änderungen zu schützen.
4. Rückkopplungsschleife zur Fehlervermeidung - Suche nach auftretenden Mustern und Nutzung dieser Gelegenheit, um Methoden zur Fehlervermeidung zu entwerfen und umzusetzen, die verhindern, dass ähnliche Fehler eingeführt werden.

Hat manuelles Testen einen Platz in DevOps?

Einfach ausgedrückt, müssen Sie so viel wie möglich automatisieren. Automatisierung muss zur Norm für moderne Tests werden. Abgesehen davon können einige Dinge nicht automatisiert werden, so dass ein gewisses Maß an manuellen Tests unvermeidlich sein kann. Um sicherzustellen, dass manuelle Tests nicht zu einem Engpass in Ihrer Lieferpipeline werden, müssen Sie sicherstellen, dass sie nicht auf Ihrem kritischen Pfad liegen - tun Sie so viel, wie Ihr Prozess erfordert und Ihre Ressourcen dies zulassen, aber machen Sie es nicht zu einem Tor in Ihrem automatisierter Lieferprozess.

Wie muss sich das Konzept der „Qualitätssicherung“ für DevOps entwickeln?

Obwohl der Begriff „QS“ von „Qualitätssicherung“ abgeleitet ist, konzentrierte sich die QA-Rolle in Softwareentwicklungsteams mehr oder weniger auf taktische Tests. Damit sich modernere Initiativen für kollaborative Prozesse (DevOps, Lean, Agile…) durchsetzen können, muss sich die Rolle der Qualitätssicherung wieder auf die Qualitätssicherung verlagern. In diesem Fall ist die Qualitätssicherung dafür verantwortlich, einen kontinuierlichen, proaktiven Prozess zu definieren und zu ermöglichen, der Geschäftsrisiken während des gesamten Software-Lebenszyklus identifiziert und verhindert.

Wenn QA = Qualitätssicherung, erscheint es seltsam, sich auf die Erstellung und Verwaltung von Funktionstestskripten zu konzentrieren. Diese Aufgabe ist weder präventiv noch prozessorientiert. Das Konzept der Qualität und wie es definiert wird, ist eine organisatorische und geschäftliche Verantwortung, die sich in der Unternehmenskultur widerspiegeln sollte. Testen ist nur eine von vielen Aktivitäten, die sicherstellen, dass die organisatorischen Qualitätsziele erreicht werden.

Wie passen Simulationstechnologien in DevOps und Continuous Testing?

Nachdem Unternehmen begonnen haben, ihre Softwarebereitstellungs-Pipeline für Agile und DevOps zu beschleunigen, erreichen sie häufig den Punkt, an dem sie testen müssen, können die AUT jedoch nicht ausführen, da eine vollständige Testumgebung noch nicht bereit ist. Viele Teams verwenden Simulationstechnologien wie EaaS und Service-Virtualisierung, um diese Hindernisse zu umgehen.

Um die Endbenutzererfahrung wirklich zu schützen, müssen wir die Endbenutzererfahrung bei wichtigen End-to-End-Transaktionen aggressiv testen und verteidigen. Bei heutigen Systemen durchlaufen diese Transaktionen eine große Anzahl verschiedener Komponenten, sodass es sehr schwierig ist, diese in einer einzigen abgestuften Testumgebung unterzubringen - Cloud oder nicht. Die Simulation hilft uns, dies zu umgehen. Für die realistischste simulierte Umgebung müssen wir wirklich verstehen, wie Komponenten in einer Betriebsumgebung funktionieren, und dies auf die Simulation übertragen.

Was ist der Unterschied zwischen "Environments-as-a-Service" und "Service-Virtualisierung"?

Die von Ihnen kontrollierten Anwendungsstapel (Cloud-fähig) können über ein Gummiband importiert und abgebildet werden EaaS in einer Wolke. Mit der Servicevirtualisierung können Sie dann das Verhalten der Abhängigkeiten simulieren, die Sie sich nicht leicht vorstellen können (z. B. Dienste von Drittanbietern, SAP-Regionen, Mainframes, noch nicht implementierte APIs usw.) oder die Sie für die Testabdeckung stabilisieren möchten .

Das Ergebnis ist, dass IT-Teams oder Umgebungsadministratoren auf einfache Weise vollständige Entwicklungs- / Testumgebungen einrichten können, die Tester und Entwickler bei Bedarf schnell (und gleichzeitig) konfigurieren und bereitstellen können.