Einführung von TestOps: ein neuer Ansatz in der Qualitätssicherung

Einer der wichtigsten Trends in der heutigen Entwicklung ist die Vereinfachung und Rationalisierung sämtlicher Prozesse. Die Einführung von DevOps als fortschrittliche Methodik und TestOps als entsprechender Ansatz für das Testen trägt zu einer schnelleren und qualitativ besseren Softwareentwicklung bei.    

Ich arbeite seit drei Jahren als Testleiter/Testautomatisierer. Doch obwohl ich im letzten Jahr fast täglich programmiert habe, habe ich keinen einzigen automatisierten Test geschrieben. Um dieses Problem anzugehen, beschloss ich, meine Arbeitstätigkeiten zu analysieren und entdeckte, dass ein großer Teil meiner Arbeitsroutine über die strenge Definition meiner Rolle hinausgeht. Es schien, als gäbe es keine spezifische Bezeichnung für meinen typischen Aufgabenbereich: Ich richte die Infrastruktur ein, überwache sie, teste Microservices, führe sie lokal in Docker aus, was einer normalen DevOps-Aufgabenliste entspricht, abgesehen von der Entwicklung.

Auf der Suche nach einer Definition für meinen aktuellen Arbeitsbereich assoziierte ich ihn sofort mit DevOps, mit dem einzigen Unterschied, dass ich teste, anstatt zu entwickeln. Deshalb könnte man es als TestOps bezeichnen. Diese Schlussfolgerung warf eine Reihe von Fragen auf:

• Gibt es diesen Begriff bereits?

• Ist er klar definiert?

• Handelt es sich um eine Rolle oder einen Arbeitsansatz?

Meine Kollegen und ich beschlossen, diese Fragen systematisch anzugehen:

• Zunächst war es notwendig, die Definition von DevOps zu überprüfen.
• Dann mussten wir die bereits vorhandenen Informationen über TestOps online recherchieren und unsere eigene Definition formulieren.
• Danach versuchten wir vorherzusagen, welche Fähigkeiten und Technologien Tester benötigen würden, um in den nächsten fünf Jahren produktiv arbeiten zu können.

Was ist DevOps

DevOps (Development Operations) ist ursprünglich eine Softwareentwicklungsmethode, die eine enge Interaktion zwischen Entwicklern und IT-Fachleuten (z. B. System- und Netzwerkadministratoren) fördert, um die Entwicklungszeit zu verkürzen und die Qualität zu verbessern. Es ist jedoch wichtig zu erwähnen, dass wir dies nicht als exklusives DevOps-Ziel betrachten, sondern als Ziel für alle, die an der Softwareentwicklung beteiligt sind, unabhängig von ihrer Rolle.

So beschränkt sich die Arbeit eines Entwicklers möglicherweise nicht nur auf das Schreiben von Code, sondern er muss auch Anweisungen geben, wie die Software auf dem Server zu starten und zu konfigurieren ist und wo die Protokolle zu finden sind. In ähnlicher Weise könnte ein Betriebsingenieur an der Fehlersuche sowie an der Einstellung des Servers beteiligt sein. Wie im Agilen Manifest dargelegt, sind Menschen und Interaktionen wichtiger als Prozesse und Tools. Falls Sie Zweifel an Ihrem Fachwissen haben, zögern Sie nicht, einen Kollegen zu konsultieren, denn wir alle haben ein gemeinsames Ziel.

DevOps hat sich mittlerweile von einer Methode zu einer eigenständigen Rolle entwickelt - es ist praktisch, ein Teammitglied zu haben, das den gesamten Zyklus von Entwicklung und Betrieb abdecken kann. Gleichzeitig wird DevOps als Testmodell immer beliebter und erreicht 36 % laut der Umfrage im Jahr 2019.

Entwickeln und Testen von Modellen, %

Quelle

Warum Dev-Test-Ops?

Es wäre nur logisch, sich zu fragen, ob die Einführung einer/mehrerer universeller Rollen die Entwicklung nicht zu sehr verkompliziert. Die Arbeitsteilung erhöht nachweislich die Effizienz. An dieser Stelle ist es notwendig, die aktuellen Trends in der Softwareentwicklung und im Betrieb zu analysieren.

In den letzten zehn Jahren haben Infrastrukturlösungen große Fortschritte gemacht. Früher hatten wir physische Server, auf denen die gesamte Software, vom Betriebssystem bis zu den Anwendungen, manuell installiert und gewartet werden musste. Heute werden die Infrastrukturaufgaben nach und nach an den Provider delegiert. Anstatt einen Server zu kaufen, kann man ihn auch mieten. Betriebssysteme und E-Mail-Services, die installiert werden müssen, werden durch Standardlösungen ersetzt. Das Schreiben einer kompletten Anwendung wird überflüssig, da es ausreicht, die Geschäftslogik als Lambda-Funktionen bereitzustellen und alle anderen Vorgänge zu delegieren.

Diese rasante Entwicklung führte zur Entstehung zahlreicher neuer Begriffe und Abkürzungen wie IaaS, PaaS, SaaS, CaaS und vieler weiterer, die Sie vielleicht noch gar nicht kennen.

Der aktuelle Trend geht dahin, den Entwicklungsprozess zu vereinfachen und die Produktionszeit zu verkürzen. Zugleich wird die Infrastruktur komplizierter. Die Flexibilität wird durch die Erhöhung der Anzahl der Konfigurationsdateien erreicht, und manchmal ist es sehr mühsam, die Ursachen für Probleme zu finden, auf die die Benutzer schließlich stoßen.

Die aktuelle Situation erfordert also einen Spezialisten, der neben den Testprinzipien und einem marktrelevanten Technologie-Stack (Datenbanken, Webservices, Programmiersprache) auch die allgemeine Struktur des Produkts versteht.

Was ist TestOps

Derzeit gibt es keine einheitliche Vorstellung davon, was TestOps ist. Die Definitionen reichen von sehr abstrakt - "eine Methodik, die eine enge Interaktion zwischen Testern und IT-Experten fördert" - bis hin zu konkreteren Definitionen wie:

• Erweiterung der Rolle eines Testautomatisierungs-Ingenieurs mit neuen Aufgaben - Einrichtung und Wartung der automatisierten Testumgebung. Diese Definition impliziert, dass um automatisierte Tests durchzugeführen, ein Ingenieur Tests in Docker packt, die zu testende Software startet, die Tests ausführt, die Ergebnisse sammelt und den Bericht erstellt;
• Erweiterung der Softwaretest-Arten mit obligatorischen Belastungs- und Zuverlässigkeitstests, Erweiterung der Aufgaben des Testers um die Verantwortung für die Überwachung aller Systeme, sowohl in Testumgebungen als auch in der Produktion;
• Eine Methodik, die das Testen in der Produktion fördert, um Ressourcen (Platz) und Zeit zu sparen, welche normalerweise für die Erstellung von Testdaten aufgewendet werden. So bleibt mehr Zeit für die Analyse von Monitoring-Metriken und für Änderungen, die sich auf kleine Testgruppen und nicht auf alle Benutzer gleichzeitig auswirken.

Der letztgenannte Ansatz, so merkwürdig er auch klingen mag, wurde bei einigen mir bekannten Projekten erfolgreich als Teil des Entwicklungsprozesses eingesetzt.

Unter Berücksichtigung all dieser Aspekte versuchen wir nun, unsere Definition zu formulieren.

Stellung von TestOps im Software-Lebenszyklus

TestOps ist eine Methodik, die eine enge Zusammenarbeit zwischen QA, Dev und Ops fördert, um die Entwicklungskosten zu senken und die Qualität zu sichern. Sie berücksichtigt aktuelle Trends in der Softwareentwicklung und -unterstützung und umreißt die folgenden Hauptaktivitäten:

Im Folgenden möchten wir auf die oben aufgeführten Schwerpunktbereiche des Testens eingehen.

Test Data

Die Aufbereitung von Daten für Tests ist seit jeher eine wichtige Aufgabe für QA-Spezialisten. Die Angabe bestimmter Daten ermöglicht die Erstellung eines regulären Testfalls. Mit der steigenden Popularität von Microservice-Lösungen und der globalen Integration verschiedener Software wird es immer schwieriger, valide Daten zu sammeln. Um zuverlässige Ergebnisse zu erzielen, müssen die Testdaten in allen Systemen konsistent sein. Daher besteht die erste Phase des Tests darin, universelle Datensätze für alle Systeme und entsprechende Mechanismen zur Aktualisierung oder Wiederherstellung des ursprünglichen Zustands vorzubereiten.

Beispiel:

Nehmen wir an, Ihr Team arbeitet an einem großen Projekt, das aus mehreren Services besteht, von denen jeder seine eigene DB hat, sowie aus einigen Integrationen von Drittanbietern. Wenn die Objekte des ersten Service auf Objekt-IDs des zweiten Service und von Drittsystemen verweisen, dann müssen diese spezifischen Objekte angelegt werden. Außerdem beschränkt sich die Datenaufbereitung nicht nur auf die Erstellung von Daten. Wenn die während des Tests zu erstellenden Daten eindeutig sein sollen, müssen Sie sicherstellen, dass diese Daten zuvor aus allen Diensten entfernt werden, in denen sie möglicherweise vorhanden sind.

Funktionstests

Unserer Statistik zufolge sind 80 % aller durchgeführten Tests Funktionstests. Unserer Ansicht nach ist diese Zahl zutreffend und wird sich in naher Zukunft wohl kaum ändern. Der Schwerpunkt verlagert sich jedoch vom Testen einzelner Systeme/Service-Funktionen zum Testen des Systems als Ganzes. Daher sollten die Tests traditionell strukturiert sein:

• Komponententests - jedes System/jeder Service wird separat getestet. Auch Vertragstests können hier miteinbezogen werden.
• Integrationstests - das Zusammenspiel mehrerer Services. In diesem Stadium benötigen wir einen vorab bereitgestellten Satz konsistenter Daten.
• Systemtests - E2E-Tests, d. h. die Überprüfung, ob das gesamte System wie erwartet funktioniert und die erwarteten Fehler behandelt.

Auf der Komponenten- und Integrationsebene erweist sich die Testautomatisierung durch die Anwendung von Unit-Tests und Tests von Webservices als sehr effizient.

Auf der Integrations- und Systemebene sind transaktionale Tests unerlässlich, da es verschiedene Ansätze zur Gewährleistung der Transaktionsfähigkeit gibt. Zumindest sollten sich die Tester dieser Ansätze bewusst sein und die Genauigkeit und Konsistenz der Datenintegrität sowohl in positiven als auch in negativen Szenarien sicherstellen.

Auf der Systemebene müssen die grundlegenden Szenarien der Systemnutzung getestet werden, entweder manuell oder mithilfe automatisierter UI-Tests.

Beispiel:

Während über das Testen von Verträgen und Web-Services bereits viel geschrieben wurde, erfordert das Testen von Transaktionen mehr Forschung, da es sehr eigen und von der Implementierung abhängig ist. Wenn ein Objekt mehrere Services durchläuft und dabei seinen Zustand und seine Eigenschaften ändert, ist es besser, das Systemverhalten in einem Szenario zu testen, in dem eines der Systeme eine Fehlfunktion hat oder das Objekt falsch behandelt. Ist es in einem solchen Fall möglich, die Bearbeitung abzuschließen? Ist es möglich, den Status zu korrigieren, falls er ungültig ist? Ist es möglich, alle Vorgänge abzubrechen und das System in seinen Ausgangszustand zurückzusetzen?

Belastungs- und Zuverlässigkeitstests

Es ist wahrscheinlich, dass sich das Verhalten des Systems und seine Leistung unter Belastung ändern. Da aus Gründen der Skalierbarkeit in der Regel Microservices eingesetzt werden, ist es ratsam, immer Belastungstests durchzuführen, unabhängig davon, ob solche Anforderungen explizit gestellt wurden. Sowohl einzelne Microservices als auch das gesamte System (zur Ermittlung von Engpässen) können Gegenstand von Belastungstests sein. Das Mindestziel ist die Analyse der Systemleistung und die Bereitstellung von Informationen für das Team und den Kunden. Das Maximalziel ist die Vorhersage der Systemfähigkeiten je nach Umfang und die Vermeidung von Defekten, die mit hoher Belastung verbunden sind.

Der nächste Diskussionspunkt ist die Zuverlässigkeit, die eng mit der Effizienz des Systems zusammenhängt. Unser Ziel ist es zu prüfen, ob:

• das System in der Lage ist, Fehler unter Belastung zu bewältigen;
• Microservices im Fehlerfall neu starten können;
• ob die Datenintegrität gewährleistet ist;
• asynchrone Operationen korrekt ausgeführt werden.

Letzteres ist ein typisches Problem, auf das ein Prüfer stoßen kann. Asynchrone Vorgänge, wie z. B. ein Prozess, der einmal pro Stunde abläuft, haben unter Umständen nicht genug Zeit, um mit großen Datenmengen und einer hohen Belastung fertig zu werden. In einem solchen Fall sollte der Prüfer sicherstellen, dass die Daten nicht verloren gehen oder doppelt verarbeitet werden.

Es ist erwähnenswert, dass es eine besondere Methodik und eine Reihe von Tools für die Zuverlässigkeitsprüfung von verteilten und Microservice-Systemen gibt - das Chaos Engineering.

Sicherheit

Ein moderner Ansatz in der Softwareentwicklung setzt voraus, dass in kurzer Zeit eine große Menge an Code geschrieben und veröffentlicht wird. Unter solchen Bedingungen stehen wir vor neuen Sicherheitsherausforderungen in Verbindung mit unbekannten Schwachstellen. Herkömmliche manuelle Sicherheitsverfahren sind nicht in der Lage, den wachsenden Anforderungen gerecht zu werden und das gewünschte Maß an Informationssicherheit zu gewährleisten.

Einer der Ansätze zur Überwindung dieser Herausforderungen ist die Einführung automatisierter Sicherheitstests in den frühen Phasen der Entwicklung, anstelle der traditionellen Kontrolle nach der Freigabe. Jüngste Erhebungen zeigen die Tendenz, das Testen näher an die Entwicklungsphase zu verlagern, was für die Sicherheitsautomatisierung nur von Vorteil wäre.

Einführung von Testverfahren oder -techniken durch die Organisation

Quelle

Das Konzept von TestOps fördert die Idee der Automatisierung von Sicherheitstests während des gesamten Testzyklus. Außerdem können Sicherheitstests zur Gewährleistung der Pipeline-Sicherheit durchgeführt werden. Zum Beispiel das Scannen von Containern während der CD und die Überprüfung von Systemkomponenten bei der CI, um die Sicherheit und Stabilität des Systems während des gesamten Zyklus zu gewährleisten.

CI/CD-Einrichtung

Eines der wichtigsten TestOps-Merkmale ist die Fähigkeit, den Prozess zur Sicherstellung der Produktqualität unabhängig zu konfigurieren und bestehende Prozesse zu verstehen, um sie zu verbessern.

Beispiel:

Wir sind oft auf die Situation gestoßen, dass am Projekt beteilige DevOps-Spezialisten nicht verfügbar sind, da sie Test- und Produktionsumgebungen betreuen. Um den Betrieb zu beschleunigen, können Sie manuell einen Startprozess für automatisierte Tests einrichten oder diese sogar zu einer bestehenden Pipeline hinzufügen.

TestOps-Fähigkeiten

In diesem Kapitel möchten wir die Kenntnisse und Fähigkeiten zur Diskussion stellen, die heute erforderlich sind, um die potenzielle Rolle von TestOps zu erfüllen:

• Datenbanken - Fachwissen über SQL und NoSQL;
• Grundlegendes Verständnis moderner Datenaustauschkonzepte und -protokolle: REST, SOAP, JMS, WebSocket;
• Kenntnisse der Datenformate: XML, JSON, CSV;
• Kenntnisse über Unix-Systeme;
• Skripting-Kenntnisse in Betriebssystemen: bash, PowerShell;
• Verständnis von Betriebssystemen: wie Software funktioniert, was ein Dienst ist, usw.;
• Programmierfähigkeiten: Python, JS. Skriptsprachen werden bevorzugt, da die Fähigkeit, bei Bedarf ein Skript zu schreiben, oft wichtiger zu sein scheint als die Fähigkeit, eine Anwendung zu entwerfen;
• Belastungstest-Fähigkeiten. Es reicht nicht aus, sich mit Tools wie JMeter, Locust und Gatling auszukennen. Die TestOps-Rolle erfordert ein Verständnis für die Art der Metriken, die gesammelt werden müssen, wie sie gesammelt werden und unter welchen Bedingungen;
• Automatisierungsfähigkeiten. Es ist erwähnenswert, dass dieser Begriff eine breitere Bedeutung hat als nur das Schreiben von automatisierten Tests: Er umfasst die Automatisierung der Arbeit eines jeden Teams;
• Kenntnisse der CI/CD-Konfiguration (Jenkins, TeamCity).

Empfehlungen für TestOps

Eine der wichtigsten Vorgehensweisen bei der Anwendung der TestOps-Methodik besteht darin, stets auf dem neuesten Stand der sich ständig weiterentwickelnden Technologien zu bleiben. Um mit den Branchentrends Schritt zu halten, ist es notwendig:

• regelmäßig sein Wissen aufzufrischen;
• sich regelmäßig über neue Ansätze in der Softwareentwicklung und -prüfung zu informieren. Vielleicht müssen Sie schon morgen Entwicklungen testen, über die heute nur gesprochen wird;
• regelmäßig an Meetings und Konferenzen teilzunehmen. Dort können Sie Ideen aufgreifen, die Ihre Konzepte für das Testen und verwandte Disziplinen erheblich bereichern können;
• Ihr Wissen regelmäßig mit Kollegen auf Konferenzen und in Veröffentlichungen zu teilen. Dies scheint eine der schwierigsten Aufgaben zu sein, denn wir neigen dazu, die Bedeutung und das potenzielle Interesse an unseren Projekten zu unterschätzen. Da es jedoch für jedes Problem in der Regel eine Reihe von Lösungen gibt, ist diejenige, die auf Ihrer einzigartigen Erfahrung beruht, möglicherweise die am besten geeignete.

Nachwort

Dieser Artikel ist lediglich ein sachkundiger Versuch, ein Konzept zu definieren, das in der Fachwelt noch nicht vollständig entwickelt ist. Er ist ein Versuch, dieses Konzept zu verfeinern, damit es zumindest im Kontext unseres Teams konsistent und präzise ist. Wir sind in der glücklichen Lage, ein Arbeitsumfeld zu haben, in dem die Diskussion neuer Ideen willkommen ist, so dass wir bereits einige nützliche Rückmeldungen zu der in diesem Artikel gegebenen Definition von TestOps erhalten haben. Wir freuen uns darauf, diese lebhafte Diskussion mit der Community fortzusetzen.

Stellen Sie mit Infopulse die makellose Qualität Ihrer Produkte sicher. Hier erfahren Sie mehr über unsere Test(TestOps)-Services.