Zusammenarbeit für mehr Softwarequalität

DevOps gilt auch für Tester

Andreas Grabner

© Shutterstock / Cylonphoto

Wenn der DevOps-Gedanke konsequent zu Ende gedacht wird, macht er bei den Betrieblern nicht halt. In ein DevOps-Team gehören ebenso die Tester. Dabei geht es nicht nur darum, das richtige Funktionieren der Software zu testen. Es geht darum zu erkennen, ob neue Funktionen auch wirklich dem Geschäft weiterhelfen. Und genau hier sind Tester und automatisierte Tests gefragt.

Eine primäre Aufgabe für Tester ist, Herausforderungen frühzeitig zu identifizieren und Entwickler- und Architektur-Teams dabei zu unterstützen, die Ursachen für problematisches Anwendungsverhalten oder Fehler schnell und zielgerichtet zu analysieren. Das Prinzip DevOps ist dabei die natürliche Evolution der Entwicklungsprozesse in einem agilen Lebenszyklus. Es kann auch als eine unternehmensweite, bereichsübergreifende Kollaboration der Entwickler, Tester, Administratoren und Manager unter Einbeziehung der Kunden verstanden werden. Demzufolge wird der DevOps-Ansatz zunehmend umgesetzt, um nicht nur die reinen Funktionalitäten zu prüfen und ob diese technologisch solide implementiert sind, sondern auch um sicherzustellen, dass die neu gelieferten Features den gewünschten Business-Erfolg tatsächlich realisieren. Für viele Tester dient der DevOps-Ansatz nicht nur als Mittel, um mehr Testszenarien schneller zu erzeugen und eine bessere Testabdeckung zu bieten.

Viel wichtiger ist ihnen oft die Konzentration auf kritische Funktionen, die in den kommenden Versionen ausgerollt werden müssen. Im Mittelpunkt steht dabei die Automatisierung dieser Testszenarien mit dem Entwicklerteam. Der wesentlichste Punkt ist nicht die reine Fokussierung auf das Testen der Funktionalität, sondern die Analyse und Validierung der Architektur, Skalierbarkeit, Performance und des Ressourcenverhaltens für jedes überprüfte Feature.

Das Ziel von DevOps ist es, nicht nur die Fehler zu finden, sondern allen Beteiligten innerhalb des Projektes Lösungsvorschläge für das Beheben eben dieser zur Verfügung zu stellen. Wesentlich ist auch, Informationen zu gewinnen, wie sich die neuen Features im Betrieb auf die Laufzeitkosten und das User-Verhalten auswirken werden. Dies geschieht anhand von Metriken, die für Entwicklung, Betrieb und Business relevant sind. Möglich wird dies, wenn die bestehenden automatisierten Testprozesse mit der Ermittlung von anwendungsinternen Metriken verknüpft werden.

Lesen Sie auch: Testend entwickeln – entwickelnd testen

Z. B. lässt sich durch die Verknüpfung mit Metriken feststellen, dass eine neue Version einer Anwendung zwar weiterhin funktioniert, aber aufgrund einer vermehrtem Anzahl von Datenbank-Statements, erhöhtem Speicherbedarf oder Webservice-Calls im Betrieb nicht skalierbar ist. Tester können somit ebenso wie Entwickler entsprechendes Know-how und Skills für die Optimierung der Architekturen einbringen. So wird sichergestellt, dass jeder Bereich effizient dazu beiträgt, hoch-funktionale, aber auch effiziente, performante, skalierbare und ressourcenschonende Software zu liefern. Denn wer schneller neue Funktionen bereitstellen möchte, muss auch eine optimale Qualität und Performance gewährleisten.

DevOps macht das Leben für Tester in einem Software-Team einfacher. Sie können leichter Probleme erkennen, die Webseiten zum Absturz bringen. Beispielsweise wenn eine Funktion zwar in einem einzelnen Testszenario korrekt arbeitet, aber nicht, wenn diese von hunderttausenden Nutzern in sehr populären Apps verwendet wird. Dies bedeutet auch, dass Tester nicht nur Fehlertickets für funktionale Fehler erstellen, sondern auch Entwickler frühzeitig auf Implementierungsprobleme in der Architektur hinweisen. Durch diesen DevOps-Ansatz können Tester nun direkt auch Lösungen für gefundene Probleme anbieten. Das Team kann diese dadurch schneller und so früh wie möglich beheben.

DevOpsCon Whitepaper 2018

Free: BRAND NEW DevOps Whitepaper 2018

Learn about Containers,Continuous Delivery, DevOps Culture, Cloud Platforms & Security with articles by experts like Michiel Rook, Christoph Engelbert, Scott Sanders and many more.

Es geht nicht nur um mehr Deployments, sondern um Softwarequalität

Viele Unternehmen führen DevOps-Prozesse vor allem deswegen ein, um die Anzahl der Inbetriebnahmen zu erhöhen. Doch das schnellere Erstellen neuer Versionen führt häufig auch zu mehr Fehlern. Dazu zählen z. B. zu aufgeblasene Webseiten, zu viele Objekte auf einer Seite, zu viele und zu große Bilder, zu viele Datenbankabfragen, Implementierung langsamer Drittanbieter-Inhalte oder zu lange Seitenlade- und Verbindungszeiten. Tatsächlich verbringen Entwicklungsteams dadurch oft 80 Prozent ihrer wertvollen Zeit mit der Fehlerbehebung, Tage oder Wochen nachdem neue Versionen eingeführt wurden. Optimal wäre es, diese Zeit in neue Funktionen für fachliche Verbesserungen und eine höhere Wettbewerbsfähigkeit des Unternehmens zu investieren. Denn Softwarefehler und ungenügende Qualität (bei Architektur, Performance, etc.) führen jährlich zu Mehrkosten in einer Größenordnung von 60 Milliarden US-Dollar.

Häufig wird die Qualität leider erst sehr spät im Entwicklungsprozess überprüft. Manchmal sogar erst im laufenden Betrieb. Die ideale Vorgehensweise ist jedoch, bereits bei Design, Codierung und Entwicklung diese Analysen durchzuführen. Um diese Situation zu verändern, ist es wichtig Problemmuster frühzeitig zu erkennen und automatisierte Tests bereits in den Entwicklungszyklus zu integrieren. Dies ist weniger komplex, als es sich anhört. Denn in der Regel werden 80 Prozent der Probleme von nur 20 Prozent der Problemmuster erzeugt. Mit einer Konzentration auf diese häufigsten Muster lässt bereits der überwiegende Teil der Probleme lösen.

Problemmuster kennen und somit identifizieren

Nach der Erfahrung von Dynatrace sind dies die zehn häufigsten Problemmuster:

  1. Datenbankzugriff: Ineffizientes Laden von zu vielen Daten
  2. Aufruf von Microservices: Ineffizienter Zugriff und schlecht entwickelte Service-APIs
  3. Schlechte Frameworks: Engpässe unter Last oder Konfigurationsfehler
  4. Schlechte Codierung: CPU, Synchronisation und Warte-Hotspots
  5. Ineffizientes Logging: Zu viele Daten selbst für Splunk oder ELK
  6. Unsichtbare Ausnahmen: Wildgewordene Frameworks
  7. Ausnahmen: Overhead durch Erzeugung von Stack Trace
  8. Pools und Warteschlangen: Engpässe durch falsche Größenbestimmung
  9. Multi-Threading: Probleme bei Locks, Synchronisationen und Wartezeiten
  10. Speicher: Einfluss von Memory Leaks und Garbage Collection

Das häufigste Problem ist dabei der ineffiziente Datenbankzugriff. Das bedeutet, es werden zu viele Datenbank-Statements aufgerufen oder Datensätze in die Applikation geladen, die in der Anwendung statt in der Datenbank verarbeitet werden. Auch verteilte Microservice-Architekturen erzeugen häufig Probleme in den Bereichen Performance und Skalierbarkeit. Sie transportieren z. B. zu große Mengen an Daten über eine Verbindung mit geringer Latenz oder erzeugen zu viele Service Calls aufgrund eines schlechten Designs der Service-Oberfläche oder schöpfen den Thread/Connection Pool aus.

Lesen Sie auch: Auf dem Weg zur DevOps-Kultur: „Denken in DevOps ist eine Revolution im Kopf“

Tester können also sehr viel dazu beitragen, dass sich die Qualität der Software erhöht. Eine Voraussetzung ist, in die Automatisierung der Testprozesse zu investieren sowie sich in Architektur und Problemmuster einzuarbeiten. Der Tester kann diese Probleme durch automatisierte Tools erkennen, die teilweise bereits installiert sind. Dazu sehen sie sich als wichtigste Metriken die Anzahl an Service Calls, Container, Threads, Synchronisationen, Wartezeiten, SQL-Ausführungen und gleicher SQLs sowie die Dateigröße der Service Calls an. Aber auch die Aufrufe der Schnittstellen, JMS Messages, zugeteilten Objekten, Ausnahmen, Log Messages, HTTP4/5-Befehle, Anfrage- und Antwortgrößen sowie Seitenlade- und Rendering-Zeiten sollten betrachtet werden.

Wenn diese Schlüsselmetriken in der Entwicklung und im Betrieb überwacht werden, lässt sich deutlich besser entscheiden, welche Versionen installiert werden sollen. Schließlich erkennen die Teams Verschlechterungen sofort und können sie beheben. Damit kommen keine problematischen Versionen mehr in die Produktion. Wenn Nutzungsraten gemessen werden, lassen sich zudem Funktionen herausnehmen, die niemand verwendet. Damit reduziert sich der Code, der von den Systemen verarbeitet sowie von den IT-Teams gewartet und getestet werden muss. Dies spart Zeit und vermeidet Fehler.

Entsprechenden Lösungen zur Testautomatisierung sollten Tester umfassend nutzen sowie Basiskonzepte für die Architektur und Umgebung wie Java, .NET oder Application Server verstehen. Dann können sie nicht nur schneller mehr Probleme automatisiert erkennen, sondern auch zur Lösungsfindung beitragen. Mit diesen Maßnahmen wird ein Prozess zur kontinuierlichen Entwicklung einer qualitativ hochwertigen Software etabliert.

Fazit

Durch die Automatisierung von arbeitsintensiven, manuellen Prozessen werden die Zyklen der Testausführung, die andernfalls notwendig wären, um Performance-Probleme zu beseitigen, beschleunigt und Fehler minimiert. Der klassische Graben zwischen Entwicklung und Betrieb wird überwunden, da Tester in der Lage sind, dem Development und Betrieb belegbare und aussagefähige Informationen auf Grundlage von Messwerten zur Verfügung zu stellen.

Geschrieben von
Andreas Grabner
Andreas Grabner
Andreas Grabner hat mehr als 15 Jahre Berufserfahrung als Architekt, Entwickler und DevOps Advokat. In seiner derzeitigen Funktion als Technology Strategist bei Dynatrace ist er Teil des Innovation Labs. Dabei arbeitet er mit Kunden bei der Implementierung von Performance-Management-Lösungen über den gesamten Anwendungslebenszyklus zusammen. Zu Performance-, Architektur- und DevOps- relevanten Themen ist er ein vielgefragter Sprecher auf internationalen Technologie-Konferenzen. Als Blogger publiziert Andreas Grabner regelmäßig Fachartikel. https://www.linkedin.com/in/grabnerandi/; @grabnerandi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: