Das Feedback aus der Exploration stammt von den Menschen. Welche Art von Informationen können diese Menschen liefern, und wie lässt sich dieses Feedback sammeln? Die Tests, die während der Entwicklung durchgeführt werden, sollten vor allem der Exploration dienen: dem Suchen nach unbekannten Aspekten des Systems, dem Einnehmen verschiedener Perspektiven, um unterschiedliche subjektive Rückmeldungen zu erhalten, dem Versuchen, Sicherheitsmaßnahmen durch schadhafte Aktivitäten zu umgehen, oder dem Testen der Leistungsgrenzen der Anwendung. Es ist entscheidend, sich auf Bereiche zu konzentrieren, in denen das menschliche Gehirn gefragt ist: Ideen zu generieren, Ergebnisse zu verarbeiten und Meinungen zu bilden. Die Ergebnisse einer solchen Exploration während der Entwicklung werden am wahrscheinlichsten durch Gespräche erfasst. In einem Umfeld, in dem das Entwicklungsteam eng zusammenarbeitet, können Probleme und Fragen direkt angesprochen werden. Eine interessante Entdeckung kann eine ebenso interessante Diskussion auslösen.

Der Übergang zu DevOps verändert die Methoden zur Rückmeldungserfassung nicht grundsätzlich – Automatisierung und Exploration bleiben bestehen. Allerdings erweitert DevOps den Umfang beider Praktiken, indem es Tests in neue Bereiche verlagert und die Feedbackzyklen beschleunigt. Eine engere Zusammenarbeit mit dem Operations-Team wird deren Fähigkeiten und Anliegen in die Bereitstellungspipeline integrieren. Der letzte Schritt der Pipeline könnte näher an der Bereitstellung rücken oder „nach rechts verschoben“ werden, um auch die Ausführung von Testautomatisierung in der Produktionsumgebung einzuschließen. Anstatt den Code in dedizierte Testumgebungen zu deployen, könnte sich die Pipeline dahin gehend ändern, dass neue Umgebungen nach Bedarf erstellt werden.

Die Unterstützung der Testpraktiken in der Produktion – wie A/B-Tests, Beta-Tests und Monitoring als Tests – erfordert eine Veränderung des Ansatzes des Entwicklungsteams. Beispielsweise könnte es dazu übergehen, Feature-Toggles zu verwenden. Diese Änderungen im Ansatz werden die Testaufwände sowohl in der Entwicklung als auch im Betrieb beeinflussen. Die Anzahl der Personen, die Tests durchführen, könnte wachsen – vom Entwicklungsteam hin zu einer breiteren Zielgruppe. Dies könnte durch einen „Bug Bash“ oder eine interne Beta-Version geschehen. Frühzeitiges Feedback könnte ebenfalls von Personen außerhalb der Organisation eingeholt werden, die potenzielle oder bestehende Nutzer des Produkts sind, während crowdsourcing-basiertes Testen ebenfalls eine breite Zielgruppe für allgemeine Rückmeldungen erreichen kann. Eine User-Experience-Sitzung könnte tiefgehendes Feedback von einer Person sammeln, die eine bestimmte Nutzergruppe repräsentiert.

DevOps und die Veränderung der Testpraktiken des Entwicklungsteams durch die Bereitstellungspipeline, Feature-Toggles, Bug Bashes und Crowd-Tests werden in diesem Abschnitt erläutert.

Die Bereitstellungspipeline

Automatisiertes Feedback kann in die Bereitstellungspipeline integriert werden, die den Code vom Commit bis zur Produktion führt. Die Pipeline umfasst dabei nicht nur alle automatisierten Prüfungen, sondern auch Build- und Deployment-Skripte, die den Code durch verschiedene Umgebungen bewegen. „Auf einer abstrakten Ebene ist eine Bereitstellungspipeline eine automatisierte Manifestation des Prozesses, Software vom Versionskontrollsystem in die Hände der Nutzer zu bekommen“ (Humble & Farley, Continuous Delivery). Eine Pipeline ist ein Kommunikationsweg, der durch ein Tool gekennzeichnet ist. Das Entwicklungsteam kann die Pipeline nutzen, um das Verhalten ihrer Software zu überprüfen, während das Betriebsteam die Pipeline nutzt, um das Verhalten der Bereitstellung zu überprüfen. Durch die Integration der Automatisierung in ein einziges Tool haben beide Teams die Möglichkeit, die Aktivitäten des jeweils anderen nachzuvollziehen.

Was gehört in eine Pipeline? Traditionell beginnt eine Pipeline, wenn ein Mitglied des Entwicklungsteams eine Änderung am Anwendungscode committet, und endet mit dem Deployment in die Produktion. Zwischen diesen beiden Punkten kann die Pipeline Folgendes umfassen:

  • Statische Analyse der Codequalität

  • Der Build des Quellcodes zu einem produktionsfähigen Produkt

  • Automatisierung von Unit-, Integrations- und End-to-End-Tests

  • Funktionale und nicht-funktionale Testautomatisierung

  • Deployment-Skripte für verschiedene Umgebungen

Ein Beispiel für eine Pipeline wird nachfolgend gezeigt. Bereitstellungspipelines sind gut bekannt und machen seit vielen Jahren einen festen Bestandteil des agilen Testansatzes aus. Wenn das Konzept der Bereitstellungspipeline neu für Sie ist, kann das Abstract aus dem Buch von Jez Humble und David Farley „Continuous Delivery: Anatomy of the Deployment Pipeline“ ein nützlicher Ausgangspunkt sein.

Es gibt einen Trend hin zu automatisierten Bereitstellungspipelines, bei denen der Prozess vom Code-Commit bis zum Produktions-Deployment vollständig automatisiert ist. Dieser Ansatz verlagert die Exploration auf die beiden Enden der Pipeline. Das Entwicklungsteam könnte die Anwendung beispielsweise durch einen Bug Bash oder durch Crowdsourcing einer breiteren Gruppe testen. Sobald die Software in Produktion ist, könnte die Organisation A/B-Tests oder Beta-Tests durchführen. Einige Entwicklungsteams fügen der Pipeline auch einen Exploration-Schritt hinzu. Die Pipeline könnte statische Analysen und Unit-Tests auf dem Code ausführen, einen Build erzeugen, der in einer Testumgebung bereitgestellt wird, und dann funktionale Testautomatisierung gegen diese Bereitstellung ausführen – und dann stoppen. An diesem Punkt hätte ein Mitglied des Entwicklungsteams die Gelegenheit, das Produkt in dieser Testumgebung zu erkunden.

Was in eine Pipeline aufgenommen wird, hängt von der allgemeinen Entwicklungsstrategie des Teams ab. Die Pipeline ist eine Möglichkeit, visuell darzustellen, was man tut, was dabei hilft, die eigene Arbeitsweise zu überdenken und Verbesserungsmöglichkeiten zu identifizieren. In einer DevOps-orientierten Organisation könnte sich die Pipeline in zwei wichtigen Bereichen weiterentwickeln: Infrastruktur als Code und Testautomatisierung in der Produktion. Anstatt Deployment-Skripte zu verwenden, die Code in dedizierte Testumgebungen installieren, kann die Pipeline die on-demand Erzeugung von Infrastruktur einbeziehen. Wenn das Betriebsteam mehr Erfahrung in Entwicklungspraxen wie Programmierung und Versionskontrollmanagement gewinnt, kann es beginnen, Infrastruktur als Code zu schreiben. Das Entfernen von Abhängigkeiten von spezifischen Umgebungen kann dem Entwicklungsteam helfen, die Pipeline schneller und parallel auszuführen.

Das Ende der Pipeline könnte sich verschieben, sodass der letzte Schritt darin besteht, Automatisierungstests in der Produktionsumgebung auszuführen. Das Erweitern der Pipeline bis in die Produktion ermöglicht es dem Entwicklungsteam, das Verhalten und die Leistung der Anwendung nach jeder vorgenommenen Änderung zu überprüfen. Die Ausführung von Testautomatisierung in der Produktion gibt dem Betriebsteam ebenfalls schnelles Feedback zur Implementierung von Monitoring, Alerts, Analytics und Logging.

Ein Beispiel, wie sich eine Pipeline entwickeln könnte, wird weiter unten gezeigt:

Wie testet man eine Pipeline?

Während die Bereitstellungspipeline Testautomatisierung ausführt, muss sie auch selbst getestet werden. Eine Pipeline wird in der Regel von Entwicklern erstellt, die eine „Bauernmentalität“ an den Tag legen. Sie streben danach, etwas funktionierendes zu schaffen und überprüfen, ob die Schritte der Pipeline linear und erfolgreich ausgeführt werden können. Eine Testmentalität ist jedoch erforderlich, um zu verstehen, wie die Pipeline fehlschlagen könnte. Ein guter Ausgangspunkt ist es, festzustellen, was passiert, wenn die Pipeline an irgendeinem Schritt stoppt. Was passiert mit dem Produkt und der Plattform zu diesem Zeitpunkt? Welche Auswirkungen könnte es haben, wenn die Pipeline zwischen den Schritten stoppt? Welche Schritte werden ausgeführt und welche Möglichkeiten gibt es, dass diese Befehle fehlschlagen? Wie kann man sich erholen oder zurückrollen, wenn etwas schiefgeht?

Die Tests der Pipeline werden umso wichtiger, je mehr sie Schritte umfasst, die auf die Produktionsumgebung abzielen. Es muss sehr sorgfältig überlegt werden, was genau in der Produktion ausgeführt wird und wie oft. Es ist entscheidend, mögliche Fehlerquellen zu erkennen und diese zu minimieren.

Wie kann ein Bug Bash in DevOps die Qualität und Teamdynamik verbessern?

Theresa erkennt die Vorteile eines Bug Bashes als mehrdimensional: Es geht nicht nur darum, Probleme zu identifizieren, sondern auch darum, das Team zu stärken und das Vertrauen in das entwickelte Produkt zu festigen. Ein Bug Bash kann die Teamdynamik positiv beeinflussen, indem er nicht nur das Finden von Fehlern ermöglicht, sondern auch das gemeinsame Arbeiten an der Qualität des Produkts fördert. Ein solcher Testprozess, bei dem das gesamte Team zusammenarbeitet, hilft, die Qualitätskontrolle auf ein gemeinsames Ziel auszurichten und das Vertrauen in die Produktentwicklung zu steigern. Scott Berkun, ein Experte auf diesem Gebiet, stellt in seinem Artikel „How to run a bug bash“ einige praktische Überlegungen an, die den Erfolg dieser Methode sicherstellen können. Er schlägt vor, das Event im Voraus zu planen, um Panik zu vermeiden, und sicherzustellen, dass der Code während des Bug Bashes stabil ist, um Probleme besser isolieren zu können. Besonders wichtig ist es, eine klare Vorstellung davon zu haben, wie ein „guter“ Bug Report aussieht, da dies die Richtung des Bashes vorgibt. Ein effektiver Bug Bash sollte darauf abzielen, eine handvoll bedeutender Probleme zu entdecken, anstatt eine Fülle trivialer Fehler zu melden.

In einigen DevOps-Umgebungen kann ein Bug Bash die Entwicklungs- und Betriebsteams zusammenbringen, um sich auf die Qualität zu konzentrieren, insbesondere dort, wo es keine dedizierten Tester gibt. Hier könnte es sinnvoll sein, eine ganzheitliche Betrachtung der Qualität einzuführen, bei der sich das Team auf kleine, aber essentielle Arbeitseinheiten fokussiert. In anderen DevOps-Umgebungen könnte ein Bug Bash jedoch weniger sinnvoll sein. Wenn das Team täglich mehrere Releases durchführt, gibt es möglicherweise keinen geeigneten Zeitraum, um eine stabile Version eingehend zu testen, oder es könnte keinen zusätzlichen Mehrwert bringen, wenn die Nutzer ohnehin in der Produktion testen. Wenn zudem ein Beta-Testprogramm vorhanden ist, könnte der Wert eines parallelen Bug Bashes geringer ausfallen. Eine sorgfältige Prüfung des gesamten Entwicklungsansatzes ist daher ratsam, bevor diese Praxis übernommen wird.

Crowdsourced Testing ist eine weitere Methode, um Feedback über ein Produkt zu sammeln. Hierbei werden Tester aus unterschiedlichen geografischen und sozialen Hintergründen eingeladen, das Produkt zu testen. Dies kann sowohl während der Entwicklung als auch nach der Veröffentlichung sinnvoll sein, um ein breites Spektrum an Perspektiven zu gewinnen, ohne dass das Produkt bereits in Produktion gehen muss. Die meisten Diskussionen über Crowdsourced Testing stammen aus Organisationen, die diese Dienstleistung verkaufen möchten, was es schwierig macht, die tatsächliche Effektivität dieser Methode zu beurteilen. Dennoch sind die Vorteile und Nachteile von Crowdsourced Testing weitgehend anerkannt. Die Vorteile beinhalten eine Vielzahl von Testumgebungen und eine unvoreingenommene Perspektive, da die Tester extern sind. Gleichzeitig gibt es jedoch auch Nachteile: die Gefahr der Offenlegung vertraulicher Informationen und die Herausforderung, eine große Gruppe von Testern zu koordinieren. Für Unternehmen, die gerade den DevOps-Weg einschlagen oder stärker auf Produktqualität als auf Geschwindigkeit setzen, kann Crowdsourced Testing eine interessante Alternative zum Beta-Test darstellen. Beide Methoden bieten ähnliches Feedback, jedoch mit unterschiedlichen Risiken und Kosten.

Testen in der Produktion ist eine Praxis, die in vielen modernen Entwicklungsansätzen zunehmend an Bedeutung gewinnt. Hier geht es darum, Software schneller freizugeben und sie in der realen Nutzung durch den Endverbraucher zu testen. Der Vorteil liegt in der unmittelbaren Reaktion auf tatsächliche Nutzerdaten, die helfen, Risiken zu minimieren, sobald die Software in Betrieb ist. Zu den Methoden des Testens in der Produktion gehören A/B-Tests, Beta-Tests und Monitoring als Test. A/B-Tests helfen, zu entscheiden, ob ein Button oder ein Link als Handlungsaufforderung besser geeignet ist, während Beta-Tests eine breitere Nutzerbasis einbeziehen, um sicherzustellen, dass die Software auf verschiedenen Browsern und Plattformen funktioniert. Monitoring als Test konzentriert sich darauf, die Leistung der Software zu überwachen, insbesondere bei einer hohen Anzahl gleichzeitiger Nutzer. Für das Testen in der Produktion ist es entscheidend, dass die automatisierte Rückmeldung aus der Produktionsumgebung robust ist und alle relevanten Informationen zur Benutzer- und Systemverhalten liefert.

Ein wichtiger Aspekt des Testens in der Produktion ist das Feedback, das durch Monitoring, Analytics, Logs und Kundenrückmeldungen aus der echten Nutzung gewonnen wird. Diese Quellen sind nicht neu, aber der Wandel hin zu DevOps bietet die Möglichkeit, die Teststrategie bewusst auf diese Daten auszurichten. Die Entwicklungsteams müssen sich stärker mit den Informationen auseinandersetzen, die durch den Betrieb erzeugt werden, und sie zu einem integralen Bestandteil des Testprozesses machen. Monitoring und Alarming spielen hierbei eine Schlüsselrolle. Sie ermöglichen es, schnell auf Produktionsprobleme zu reagieren und so das Testen effektiver zu gestalten. Wenn zum Beispiel eine neue Version einer Anwendung veröffentlicht wird und sofort eine Leistungsverschlechterung festgestellt wird, kann das Team sofort darauf reagieren und das Problem beheben. In Organisationen, die auf schnelle Releases setzen, könnte dieser Prozess sogar schneller und effektiver sein als eine vorherige Stresstestphase.

Um Testen in der Produktion effektiv umzusetzen, müssen Entwickler und Operations-Teams eng zusammenarbeiten. Sie müssen gemeinsame Experimente entwerfen, relevante Messgrößen identifizieren, Ergebnisse sammeln und diese zur Bestimmung der nächsten Schritte nutzen. Eine koordinierte Zusammenarbeit ist der Schlüssel, um das volle Potenzial des Feedbacks aus der Produktion zu nutzen und die Software kontinuierlich zu verbessern.

Wie ein Teststrategie-Retrospektive das Verständnis im Team fördert und Risiken minimiert

Die Annahme, dass nur der spezialisierte Tester in einem funktionsübergreifenden Team in der Lage ist, eine Teststrategie zu definieren, mag auf den ersten Blick sinnvoll erscheinen. Schließlich ist das Testen sein Fachgebiet. Doch der Prozess, mit dem eine Strategie entwickelt und geteilt wird, spielt eine entscheidende Rolle. Ein Tester, der nicht transparent macht, wie er zu seinen strategischen Entscheidungen gelangt, setzt sich einem hohen Risiko aus, indem er Entscheidungen trifft, die möglicherweise nicht in seinem Verantwortungsbereich liegen. In der Testphase wird ein spezialisierter Tester ständig bewusste Entscheidungen treffen, die die Teststrategie des Teams beeinflussen. Er wird aktiv abwägen, welche Testpraktiken übernommen werden und welche Auswirkungen diese auf die Testabdeckung und die Gesamtqualität des Produkts haben. Doch oftmals denkt und entscheidet er als Einzelperson, ohne seine strategischen Änderungen mit dem Team zu teilen. In agilen Teams wird das Testen oft als eine Aufgabe für alle betrachtet, jedoch bleibt das strategische Nachdenken über Tests nicht selten außen vor. Dies führt dazu, dass Tester Praktiken anwenden, ohne den Hintergrund oder die Gründe dafür zu verstehen.

Eine Teststrategie-Retrospektive hilft dem Team, ein gemeinsames Verständnis darüber zu entwickeln, welche Teststrategien angewendet werden und welche Entscheidungen zu dieser Strategie führen. Ziel ist es, alle Teammitglieder in die Diskussion einzubeziehen, damit sie nicht nur verstehen, was getestet wird, sondern auch warum bestimmte Entscheidungen getroffen wurden.

Für die Durchführung einer Teststrategie-Retrospektive sind folgende Materialien nötig: eine Stunde Zeit, in der das gesamte Team zur Verfügung steht, Klebezettel in vier verschiedenen Farben und eine große Fläche, auf der diese Klebezettel angebracht werden können – ein großer Tisch oder eine leere Wand sind dafür ideal. Zu Beginn der Retrospektive sollte der Testleiter den Zweck der Sitzung klar formulieren und erklären, dass die Teststrategie visualisiert werden soll. Dies fördert ein gemeinsames Verständnis über die durchgeführten Testaktivitäten. Zwei Klebezettel, einer mit der Aufschrift „IDEA“ und der andere mit „PRODUCTION“, werden am oberen linken und oberen rechten Rand der Fläche angebracht, um eine Zeitleiste zu schaffen, die den Prozess der Softwareentwicklung von einer Idee bis hin zur Einsatzbereitschaft der Anwendung abbildet.

Die verschiedenen Farben der Klebezettel symbolisieren unterschiedliche Zustände: Lila steht für Aktivitäten, die Teil der aktuellen Teststrategie sind und durchgeführt werden; Pink für Aktivitäten, die Teil der Strategie sind, aber nicht umgesetzt werden; und Gelb für Aktivitäten, die nicht Teil der Strategie sind, aber idealerweise integriert werden sollten. Jeder Teilnehmer platziert seine Klebezettel an dem Punkt der Zeitleiste, der seiner Meinung nach den Zeitpunkt markiert, an dem die jeweilige Testaktivität durchgeführt wird. Nach fünf Minuten entsteht eine unsortierte Ansammlung von Klebezetteln. Nun soll das Team gemeinsam die Zettel gruppieren und die Position der Aktivitäten innerhalb der Zeitleiste festlegen. So wird gewährleistet, dass alle Perspektiven berücksichtigt werden.

Sobald das Team mit der Visualisierung zufrieden ist oder die Diskussion sich im Kreis dreht, kann die Sitzung beendet werden. Doch diese Visualisierung eröffnet nicht nur einen Überblick über die derzeit praktizierte Teststrategie, sondern auch eine Grundlage für eine tiefere Diskussion. Fragen wie: „Gibt es Gruppen, die Klebezettel in unterschiedlichen Farben enthalten?“ oder „Werden Begriffe verwendet, die dasselbe Testverfahren beschreiben?“ helfen dabei, Missverständnisse und Unklarheiten zu erkennen. Die Diskussionen zu diesen Fragen bieten wertvolle Einblicke in den aktuellen Stand des Testens und die Entscheidungen, die die bestehende Strategie geformt haben.

Ein interessantes Beispiel einer solchen Diskussion fand statt, als ein Team feststellte, dass der Begriff „End-to-End-Testing“ unterschiedlich interpretiert wurde. Einige Mitglieder dachten, dass diese Art des Tests Teil der Strategie sei und auch durchgeführt werde, während andere der Meinung waren, dass er zwar Teil der Strategie sei, jedoch nicht umgesetzt werde. Dies führte zu einer intensiven Auseinandersetzung darüber, was „End-to-End“ im Kontext ihres komplexen Architektursystems tatsächlich bedeutet und wie diese Testaktivität sinnvoll umgesetzt werden kann.

Ein weiteres Beispiel zeigte sich bei der Diskussion über die Begriffe „manuelles Testen“, „exploratives Testen“ und „Abnahmetests“. Das Team stellte fest, dass sie diese Begriffe häufig synonym verwendeten, was zu Verwirrung führte. Nach einer genaueren Untersuchung entschieden sie sich, den Begriff „exploratives Testen“ zu verwenden, um Missverständnisse zu vermeiden.

Wichtige Ergebnisse einer Teststrategie-Retrospektive können auch die Entdeckung von Lücken in der Teststrategie sein. Eine Diskussion über die Frage, welche Aktivitäten fehlen oder warum bestimmte Aktivitäten nicht umgesetzt werden, hilft dabei, strategische Schwächen zu identifizieren und Lösungen zu finden. So kam es in einem Team dazu, dass einige Entwickler, die davon ausgingen, dass „Unit Tests“ durchgeführt würden, nach der Retrospektive entdeckten, dass ein Teil des Systems, der eine spezielle Architektur hatte, nicht für Unit-Tests geeignet war – ein Umstand, der den Geschäftsvertretern und Testern zuvor nicht bewusst war.

Ein alternativer Ansatz wurde von Sean Cresswell entwickelt, der die Teststrategie-Retrospektive mit einer anderen Visualisierungsmethode anpasste. Hierbei schrieb jeder Teilnehmer auf einen Klebezettel eine Testaktivität und verwendete die Farben, um anzugeben, wer diese Aktivität durchführt (Tester, Entwickler oder andere Rollen). Diese Zettel wurden dann in einer Matrix platziert, die die Häufigkeit der Aktivität im Vergleich zur optimalen Häufigkeit anzeigte. Dieser Ansatz verschiebt den Fokus von der Diskussion über die Reihenfolge von Aktivitäten hin zu einer Diskussion über den aktuellen Stand der Testaktivitäten im Vergleich zu dem, was idealerweise passieren sollte.

Ein Nachteil dieser Methode könnte sein, dass sie weniger auf Lücken in der Teststrategie hinweist, dafür aber stärker aufzeigt, wer in welchem Maße zu den Testaktivitäten beiträgt. In einem Team, das über eine funktionsübergreifende Zusammenarbeit verfügt, kann dies ein wertvoller Schritt sein, um die Beiträge von Entwicklern und anderen Teammitgliedern anzuerkennen, die oft weniger Beachtung finden, obwohl sie wesentliche Tests durchführen.

Die Teststrategie-Retrospektive fördert somit ein gemeinsames Verständnis aller Teammitglieder über die Ziele und Methoden des Testens und verhindert das Risiko von Missverständnissen oder unklaren Verantwortlichkeiten. Durch eine transparente Diskussion und Visualisierung der Teststrategie können alle Teammitglieder sicherstellen, dass sie die richtige Testaktivität zur richtigen Zeit durchführen und im Einklang mit den übergeordneten Zielen des Projekts arbeiten.

Wie bereit ist Ihr Team für DevOps? Der Weg zur erfolgreichen Integration agiler Testpraktiken

In einer agilen Umgebung fühlt sich das Testen oft intuitiv an, da der gesamte Entwicklungsprozess auf Kollaboration und kontinuierlichem Feedback basiert. Dies ist ein entscheidender Aspekt, wenn es darum geht, den Übergang zu einer DevOps-Kultur zu meistern. Teams, die bereits agile Methoden wie Scrum oder Kanban praktizieren, sind in der Regel gut aufgestellt, um eine DevOps-Mentalität zu übernehmen. Ein gemeinsames Verständnis der Anforderungen und der notwendigen Tests sowie ein schneller Umgang mit auftretenden Problemen sind in solchen Teams selbstverständlich. Doch was passiert, wenn diese Prinzipien noch nicht voll etabliert sind? In diesem Fall könnte der Übergang zu DevOps mit Herausforderungen verbunden sein.

Die zentrale Frage lautet: Wie agil ist Ihr Testprozess? Ein Team, das mit agilen Testmethoden vertraut ist, sollte in der Lage sein, Antworten auf folgende Fragen zu finden: Wer ist für die Tests verantwortlich? Wie wird getestet? Und vor allem: Wie reagiert das Team auf auftretende Probleme? Wenn diese Fragen im Team noch nicht eindeutig beantwortet werden können, könnte dies ein Zeichen dafür sein, dass noch eine Übergangsphase erforderlich ist, bevor der vollständige Schritt zu DevOps gemacht wird.

Karen Greaves hat eine Liste von zehn Fragen zusammengestellt, die Teams dabei helfen können, ihre Testpraktiken zu bewerten und herauszufinden, ob sie für DevOps bereit sind. Diese Fragen umfassen grundlegende Aspekte wie das Verständnis der Testanforderungen für jede User Story, die Frage nach der Automatisierung und deren Integration in den CI/CD-Prozess sowie die Transparenz des Testprozesses für alle Teammitglieder. Teams, die weniger als fünf dieser Fragen positiv beantworten können, sollten sich weiter mit den Grundlagen agilen Testens auseinandersetzen.

Ein wichtiger Punkt hierbei ist, dass Testautomatisierung in einer DevOps-Umgebung nicht nur die Verantwortung einzelner Tester ist, sondern eine gemeinschaftliche Aufgabe aller Teammitglieder, vom Entwickler über den Business Analysten bis hin zum Betriebsteam. Automatisierte Tests sind ein integraler Bestandteil des Arbeitsprozesses und werden zusammen mit dem Quellcode versioniert und verwaltet. Dies stellt sicher, dass jeder Teil des Systems kontinuierlich getestet wird und Fehler schnell behoben werden können, ohne den Entwicklungsprozess zu verlangsamen.

Die Rolle der kontinuierlichen Integration (CI) ist dabei nicht zu unterschätzen. Wenn ein Fehler auftritt und der CI-Server in einem fehlerhaften Zustand bleibt, muss dieser innerhalb kürzester Zeit behoben werden, idealerweise innerhalb einer Stunde. Hier zeigt sich, wie gut das Team auf schnelle Reaktionen und enge Zusammenarbeit ausgelegt ist. Wer in einem agilen Team arbeitet, sollte nicht nur Tests durchführen, sondern auch aktiv zum Testen beitragen – sei es durch die Ausführung von Automatisierungen oder durch exploratives Testen.

Neben der Frage der Testpraktiken ist auch das Verständnis der organisatorischen Rahmenbedingungen entscheidend. DevOps wirkt sich nicht nur auf die Entwickler aus, sondern umfasst eine Vielzahl von Rollen, die über das Entwicklungsteam hinausgehen. Eine genaue Analyse, was DevOps in Ihrer spezifischen Organisation bedeutet und welche Ziele damit verfolgt werden, ist der erste Schritt. Entwickler und Manager können unterschiedliche Perspektiven auf DevOps haben, und diese sollten nicht als Gegensatz, sondern als Bereicherung verstanden werden. Manager könnten den Fokus auf schnellere Markteinführung oder höhere Produktqualität legen, während Entwickler sich auf die technischen Änderungen konzentrieren, die nötig sind, um diese Ziele zu erreichen.

Ein weiteres wichtiges Element bei der Einführung von DevOps ist die Zusammenarbeit über die Grenzen des Entwicklungsteams hinaus. In der Vergangenheit war es üblich, dass Entwicklungsteams relativ klein und fokussiert auf den eigenen Arbeitsbereich blieben. Doch DevOps erfordert eine intensivere Zusammenarbeit mit weiteren Rollen im Unternehmen, wie beispielsweise den Betriebsingenieuren oder den Agile Coaches. Dies bedeutet nicht nur, die Kommunikation mit neuen Stakeholdern zu etablieren, sondern auch, neue Wege der Zusammenarbeit zu finden.

Dies beginnt mit dem Aufbau von Verbindungen zu anderen Teams und der Etablierung von Kommunikationskanälen. Ein effektiver Ansatz ist es, Beziehungen Schritt für Schritt zu entwickeln, indem man zunächst kleinere, informelle Gespräche führt und danach die Zusammenarbeit durch gemeinsame Projekte oder Treffen vertieft. Es ist wichtig, dass diese Zusammenarbeit nicht nur einseitig ist; es geht darum, gegenseitigen Austausch zu fördern und voneinander zu lernen. So können auch bisherige Barrieren zwischen den Teams abgebaut und eine breitere Zusammenarbeit ermöglicht werden.

Um die Umsetzung von DevOps im Unternehmen weiter voranzutreiben, müssen Teams darüber hinaus ihre Bereitschaft zur Veränderung verstehen. Menschen in unterschiedlichen Rollen werden unterschiedlich auf die Herausforderungen einer neuen Arbeitsweise reagieren. Ein erfolgreiches DevOps-Programm erfordert, dass alle Beteiligten – von den Entwicklern bis hin zu den Managementebenen – bereit sind, die bestehenden Prozesse zu hinterfragen und kontinuierlich zu verbessern.

Die Bereitschaft zur Veränderung und zur kontinuierlichen Verbesserung ist ein wesentlicher Erfolgsfaktor. Ein Unternehmen, das DevOps effektiv umsetzen möchte, muss sich darauf konzentrieren, alle relevanten Rollen einzubinden und eine Kultur der Zusammenarbeit und des gemeinsamen Lernens zu fördern. Dabei spielt nicht nur die Technik eine Rolle, sondern auch die Schaffung eines geeigneten Umfelds, in dem offene Kommunikation und Teamarbeit gefördert werden.

Jaký je správný způsob реагování na общественные ожидания в свете личных стремлений?
Jak opravit chybu "Scratch Disks Full" v Adobe Photoshopu: Praktické rady pro zlepšení výkonu
Jaké výhody a nevýhody přináší používání WebSOM a dalších metod vizualizace?
Jak se orientovat v jídle a stravování při omezeném příjmu zpracovaných potravin?