Holen Sie sich die neuesten wichtigen Update-Informationen für die Log4j-Sicherheitslücke. Sehen Sie sich an, wie Sie das Problem mithilfe der Parasoft-Anleitung beheben können. Erfahren Sie mehr >>
Holen Sie sich die neuesten wichtigen Update-Informationen für die Log4j-Sicherheitslücke. Sehen Sie sich an, wie Sie das Problem mithilfe der Parasoft-Anleitung beheben können. Erfahren Sie mehr >>
Lesezeit: 4 MinutenSlams! Ü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?
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:
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.
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:
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.
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.
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.
Die von Ihnen kontrollierten Anwendungsstapel (Cloud-fähig) können über ein Gummiband importiert und abgebildet werden EaaS in einer Wolke. Service-Virtualisierung Anschließend können Sie das Verhalten der Abhängigkeiten simulieren, die Sie nicht einfach abbilden können (z. B. Services von Drittanbietern, SAP-Regionen, Mainframes, noch nicht implementierte APIs usw.) oder die Sie für Testabdeckungszwecke 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.
Die branchenführenden automatisierten Softwaretest-Tools von Parasoft unterstützen den gesamten Softwareentwicklungsprozess, vom Schreiben der ersten Codezeile über Unit- und Funktionstests bis hin zu Leistungs- und Sicherheitstests, wobei simulierte Testumgebungen genutzt werden.