Warum (und wie) Sie sich vom automatisierten Testen zum kontinuierlichen Testen weiterentwickeln sollten

Heutige DevOps- und „Continuous Everything“ -Initiativen erfordern die Fähigkeit, die mit einem Release-Kandidaten verbundenen Risiken sofort und kontinuierlich zu bewerten. Kontinuierliches Testen bietet eine automatisierte, unaufdringliche Möglichkeit, sofortiges Feedback zu erhalten über die Geschäftsrisiken, die mit einem Software-Release-Kandidaten verbunden sind. Es leitet Entwicklungsteams an, die Geschäftserwartungen zu erfüllen, und hilft Managern, fundierte Entscheidungen zu treffen, um den Geschäftswert eines Release Candidate zu optimieren.

Kontinuierliches Testen ist NICHT einfach mehr Testautomatisierung. Angesichts der Geschäftserwartungen in jeder Phase des SDLC bietet Continuous Testing eine quantitative Risikobewertung sowie umsetzbare Aufgaben, die zur Risikominderung beitragen, bevor sie zur nächsten Phase des SDLC übergehen. Ziel ist es, bedeutungslose Aktivitäten zu eliminieren und Mehrwertaufgaben zu erstellen, die die Entwicklungsorganisation zu einer erfolgreichen Veröffentlichung führen. Dies schützt die Integrität der Benutzererfahrung und schützt das Unternehmen vor den möglichen Auswirkungen von Anwendungsmängeln.

DevOps.com hat kürzlich einen neuen Artikel zum Thema „Continuous Testing“ von Wayne Ariola von Parasoft veröffentlicht. Hier ist ein Auszug aus diesem Artikel…

Vom automatisierten Testen zum kontinuierlichen Testen

Da agile Entwicklungspraktiken ausgereift sind und DevOps-Prinzipien unsere Unternehmenskulturen infiltrieren, erkennen Unternehmen die eindeutige Möglichkeit, die Softwarebereitstellung zu beschleunigen. Wenn Sie jedoch einen Prozess beschleunigen, werden unreife Übungsbereiche wie Tests und Straßensperren viel ausgeprägter. Es ist der Unterschied zwischen dem Fahren über eine Geschwindigkeitsbegrenzung mit 5 Meilen pro Stunde und 50 Meilen pro Stunde ... bei 50 Meilen pro Stunde wird diese Geschwindigkeitsschwelle ziemlich erschütternd sein.

Durch die Beschleunigung eines Geschäftsprozesses werden systembedingte Einschränkungen aufgedeckt, die das gesamte Unternehmen an seine sich am langsamsten bewegende Komponente binden. Im Fall des beschleunigten Softwareentwicklungslebenszyklus (SDLC) ist das Testen zum größten Hindernis geworden, um iterativere Ansätze für die Softwareentwicklung voll auszunutzen. Damit Unternehmen diese transformativen Entwicklungsstrategien nutzen können, müssen sie von der Testautomatisierung zum kontinuierlichen Testen übergehen.

Die Unterscheidung zwischen Testautomatisierung und kontinuierlichem Testen mag wie eine Übung in der Semantik erscheinen, aber die Lücke zwischen der Automatisierung von Funktionstests und der Ausführung eines kontinuierlichen Testprozesses ist erheblich. Diese Lücke wird im Laufe der Zeit geschlossen, wenn der Prozess der Softwarebereitstellung ausgereift ist. Sowohl interne als auch externe Einflüsse werden die Entwicklung kontinuierlicher Tests vorantreiben. Intern werden agile, DevOps- und Lean-Prozessinitiativen die Haupttreiber sein, die die Nachfrage nach Veränderungen erzeugen. Extern werden die Kosten und der Aufwand für die Prüfung staatlicher und branchenbezogener Compliance-Programme der Hauptimpuls für Veränderungen sein.

Eine Roadmap zum Testen

Jede echte Veränderungsinitiative erfordert die Abstimmung von Menschen, Prozessen und Technologie - wobei Technologie ein Wegbereiter und nicht die Silberkugel ist. Es gibt jedoch einige grundlegende Technologiethemen, die wir untersuchen müssen, wenn wir zu einem echten Qualitätssicherungsprozess übergehen. Im Allgemeinen müssen wir uns nicht mehr nur auf die Testautomatisierung konzentrieren, sondern auch den Prozess der Risikomessung automatisieren. Um diese Reise zu beginnen, müssen wir Folgendes berücksichtigen:

Aufgrund der Geschäftsziele müssen Unternehmen auf automatisiertere Methoden zur Qualitätssicherung umsteigen und sich von der taktischen Aufgabe, Software von unten nach oben zu testen, entfernen.

Von kausalen Beobachtungen zur probabilistischen Risikobewertung

Da die Qualitätssicherung (QS) traditionell manuelle oder automatisierte Tests durchführt, konzentriert sich das Feedback aus dem Testaufwand auf den Fall, dass ein Test bestanden oder nicht bestanden wird - dies reicht nicht aus. Tests sind kausal, was bedeutet, dass Tests so konstruiert sind, dass sie einen ganz bestimmten Funktionsumfang validieren und als isolierte Datenpunkte ausgewertet werden. Obwohl diese eigenständigen Datenpunkte kritisch sind, müssen wir sie auch als Eingabe für eine erweiterte Gleichung zur statistischen Identifizierung von Anwendungs-Hotspots verwenden.

Der SDLC erzeugt eine erhebliche Datenmenge, die relativ einfach zu korrelieren ist. Die Überwachung von Prozessmustern kann zu sehr umsetzbaren Ergebnissen führen. Beispielsweise sollte eine Codeüberprüfung ausgelöst werden, wenn bei einer Anwendungskomponente alle folgenden Probleme in einem bestimmten Build für die kontinuierliche Integration auftreten:

• Regressionsfehler größer als der Durchschnitt
• Statische Analyse Defektdichte größer als der Durchschnitt
• Zyklomatische Komplexität größer als ein vorgeschriebener Schwellenwert
• Von der Fehlerdokumentation zur simulierten Wiedergabe

Das Ping-Pong zwischen Testern und Entwicklern über die Reproduzierbarkeit eines gemeldeten Defekts ist legendär geworden. Es ist schwieriger, einen Defekt in die Entwicklung zurückzuführen, als eine Vorspeise von einem weltberühmten Koch zurückzusenden. Angesichts des aggressiven Ziels, die Software-Release-Zyklen zu beschleunigen, sparen die meisten Unternehmen viel Zeit, indem sie dies nur hin und her eliminieren.

Durch die Nutzung von Service Virtualization zur Simulation einer Testumgebung und / oder von Aufzeichnungs- und Wiedergabetechnologien für virtuelle Maschinen zur Beobachtung der Ausführung eines Programms sollten Tester in der Lage sein, die Entwicklung einer sehr spezifischen Test- und Umgebungsinstanz in einem einfachen Containerpaket zu versenden. Dieses Paket sollte einen Fehler isolieren, indem es mit einem Test gekapselt wird, und Entwicklern das Framework geben, das zur Überprüfung des Fixes erforderlich ist.

Von strukturierten Daten zu strukturierten und unstrukturierten

Die aktuellen Tools und Infrastruktursysteme, die zur Verwaltung des SDLC verwendet werden, haben die Generierung und Integration strukturierter Daten erheblich verbessert (z. B. wie CI-Engines Testergebnisse importieren und präsentieren). Diese Daten sind wertvoll und müssen viel effektiver genutzt werden (wie oben im Abschnitt „Von kausalen Beobachtungen zu probabilistischen“ angegeben).

Die Fülle an unstrukturierten Qualitätsdaten, die sowohl über interne als auch über öffentlich zugängliche Anwendungen verstreut sind, birgt oft die Geheimnisse, die den Unterschied zwischen zufriedenen Endbenutzern und unzufriedenen Interessenten ausmachen, die das Produkt eines Mitbewerbers verwenden …

Neues Buch für kontinuierliche Tests: Kontinuierliche Tests für IT-Führungskräfte

Sind Sie bereit, sich vom automatisierten Testen zum kontinuierlichen Testen zu entwickeln? Lesen Sie das neue 70-seitige Buch Continuous Testing for IT Leaders, um zu erfahren, wie Continuous Testing Ihrem Unternehmen helfen kann, die Frage zu beantworten: "Hat der Release-Kandidat ein akzeptables Geschäftsrisiko?"

Du wirst lernen, wie man:

• Schließen Sie gemeinsam die Lücke zwischen den Geschäftserwartungen und den DevTest-Aktivitäten
• Richten Sie ein Sicherheitsnetz ein, mit dem Sie neue Funktionen schneller auf den Markt bringen können
• Treffen Sie bessere Kompromissentscheidungen, um den Geschäftswert eines Release-Kandidaten zu optimieren
• Richten Sie Feedback-Schleifen ein, die eine schrittweise und kontinuierliche Prozessverbesserung fördern

Dieses Buch bietet eine Geschäftsperspektive zur Beschleunigung des SDLC und zur sicheren Veröffentlichung. Es richtet sich an leitende Entwicklungsmanager und Führungskräfte, die ein optimales Gleichgewicht zwischen Geschwindigkeit und Qualität erreichen müssen.