image

Leitfaden & Einblicke

Wenn niemand “Schwarzer Peter” spielt: Das Geheimnis guter Zusammenarbeit von Entwicklern und Testern

Sie hatten penibel geplant und konnten es doch nicht verhindern: Beim Software-Release tauchten erhebliche Fehler auf. Nun war Schadensbegrenzung angesagt – und Sie hatten plötzlich den „Schwarzen Peter“ in den Händen. Was ist schiefgelaufen ist die Frage. Oft zeigen jetzt Entwickler und Tester mit dem Finger aufeinander.

Also, was ist passiert? Wessen Schuld war es? Und was können Sie beim nächsten Mal besser machen? Fakt ist: Wir leben in einer Zeit, in der der Druck auf die Softwareentwicklung höher ist als je zuvor, Tendenz weiter steigend. Mit Schuldzuweisungen hat außerdem niemand ein Problem gelöst. Und in einer echten DevOps-Umgebung, sollte das Fingerzeigen sowieso erst gar nicht passieren.

Wie wir hier gelandet sind: Die Wurzeln des Problems

Bevor wir uns mit der Lösung zu diesem „Schwarzen Peter“-Spiel befassen können, müssen wir erst verstehen, wo die Wurzeln des Problems eigentlich liegen.

Vor nicht allzu langer Zeit arbeiteten die meisten Teams in einer Wasserfall-Umgebung. Hier waren Entwickler und Tester getrennt. Jede Gruppe arbeitete für sich in unterschiedlichen Silos. Es gab klare Grenzen. Jeder wusste, wer für was verantwortlich war. Und hier nimmt das „Übel“ seinen Ursprung.

Wo wir hinsteuern: Auf in eine gut abgestimmte Zukunft!

Heute ist die Wasserfall-Methode für die meisten Unternehmen nicht mehr die erste Wahl.

Diese Ehre fällt nun DevOps zu, einem Ansatz, der sich auf die enge Verzahnung und Abstimmung von Softwareentwicklung und Softwarebereitstellung konzentriert, um ein Continuous-Delivery-Modell zu schaffen. Laut der RightScale-Umfrage „State of the Cloud 2017“ hatten damals mehr als drei Viertel aller befragten Unternehmen DevOps eingeführt, 30 Prozent sogar unternehmensweit.

Zwei wesentliche Grundsätze von DevOps sind die enge Zusammenarbeit zwischen Entwicklern, Testern und Betriebsteams sowie der Fokus auf Qualität als Verantwortung eines jeden Einzelnen.

Anders als in der isolierten Wasserfall-Umgebung, in der Teams funktional organisiert sind, fordert DevOps also die Abstimmung aller Disziplinen, um neue Releases effizienter zu veröffentlichen. Eine ideale DevOps-Welt besteht demnach aus End-to-End- und funktionsübergreifenden Teams, deren Mitglieder alle bestimmte Verantwortlichkeiten rund um das Testen teilen.

Wo stehen wir heute: Vergessen wir den „Schwarzen Peter“!

Natürlich leben wir nicht in einer idealen Welt, und DevOps ist immer noch eine relativ neue Methode zur Softwareentwicklung. Die Einführung erfolgt nicht über Nacht. Die meisten Organisationen, die DevOps implementiert haben, sind mit einer Mischung aus modernen und älteren Systemen und Prozessen noch weit von der vollständigen Reife entfernt.

Unabhängig davon, ob sich Ihr Unternehmen DevOps verschrieben hat oder nicht, gibt es bestimmte Schlüsselprinzipien, die Sie von Anfang an beherzigen sollten, damit diese Methode auch reibungslos funktioniert. An erster Stelle dieser Liste steht – wie schon erwähnt – die enge Abstimmung zwischen Entwicklern und Testern. Im Mittelpunkt des Handelns: Qualität.

Solange alles passt, erwähnen wir gerne, dass wir in einer DevOps-Umgebung arbeiten. Aber wenn es mit den Schuldzuweisungen losgeht, ist das ein klares Zeichen, dass Ihr Team möglicherweise doch nicht so perfekt aufeinander abgestimmt ist, wie Sie dachten. Das liegt vor allem daran, dass DevOps Qualität zur Verantwortung eines jeden Einzelnen macht. Stimmt die nicht, ist das gesamte Team in der Auslage. Und der „Schwarze Peter“ kann einfach nicht einer einzelnen, isolierten Gruppe zugeschoben werden.

Umgekehrt sollte jeder in einer DevOps-Umgebung das Gefühl entwickeln, Mitschuld zu tragen, wenn Software von minderwertiger Qualität veröffentlicht wird. Tatsächlich besteht der ganze Sinn von DevOps darin, das gesamte Team auf ein gemeinsames Ziel auszurichten – und zwar das qualitativ hochwertigste Produkt so schnell wie möglich auf den Markt zu bringen, ohne die Verantwortung auf Silos zu verteilen. Infolgedessen gewinnen und verlieren Sie in einer echten DevOps-Umgebung als Team. Und Fingerzeigen entfällt.

Machen wir es besser: 5 Tipps zur besseren Abstimmung von Entwicklern und Testern

Wenn Sie feststellen, dass Ihr Team nicht so auf gemeinsame Ziele und Verantwortlichkeiten ausgerichtet ist, wie Sie dachten, probieren Sie es einfach einmal mit folgenden fünf Tipps:

1. Fokus auf die Zusammenarbeit richten!

Stimmt die Chemie nicht, muss die Abstimmung zwischen Entwickler und Tester sofort verbessert werden. Denn je länger Sie warten, desto schwieriger wird es, die sich auftuende Lücke zu schließen. Dies gelingt am besten, indem Sie projektspezifische Teams bilden, die sowohl Entwickler als auch Tester umfassen. So können sich diese leichter an eine engere Zusammenarbeit gewöhnen.

Diese projektspezifischen Teams sollten bereits vor Beginn eines Softwareentwicklungsprozesses gebildet werden, um eine reibungslose Zusammenarbeit von Anfang bis Ende zu gewährleisten. Funktionsübergreifende Teams wiederum, die gemeinsam die Verantwortung für die erfolgreiche Bereitstellung von Software an die Enduser tragen, helfen jedem Einzelnen zu verstehen, wie er zum Erfolg des Projekts sowie des Unternehmens insgesamt beiträgt.

2. Maßnahmen zur Qualitätssicherung setzen!

Sorgen Sie dafür, dass Qualitätssicherung so früh wie möglich in Ihren Prozessen stattfindet.

Diese Maßnahmen sollten zusätzliche Methoden wie beispielsweise explorative Tests bzw. Session Based Testing in der gesamten Pipeline umfassen, um den Fortschritt zu validieren und Feedback zu geben, bevor eine Software in Richtung Enduser ausgerollt wird.

Einfach gesagt: Je früher Qualitätssicherungsmaßnahmen im Projekt stattfinden, desto früher werden Probleme erkannt (und desto mehr Zeit für die Lösung dieser Probleme gibt es). Außerdem trägt dies auch dazu bei, eine natürlichere Abstimmung zwischen Entwicklern und Testern zu schaffen. Erfolgt Qualitätssicherung hingegen nicht bei jedem Schritt, werden Ihre Tester wahrscheinlich nicht so früh im Prozess eingebunden, wie sie es sein könnten und sollten. Die Wahrscheinlichkeit, dass bereits an dieser Stelle auftretende Fehler erkannt und behoben werden können, sinkt dadurch immens.

3. Kommunikation und Transparenz hochhalten!

Kommunikation ist King! Nur wer miteinander redet – in unserem Falle Entwickler mit Testern und umgekehrt –, kann Transparenz über alles, was so passiert, aufrechterhalten. Auch hier sollten diese Kommunikation und Transparenz aus einer engen Abstimmung zwischen diesen beiden Gruppen resultieren.

So offensichtlich es auch erscheinen mag: Bitten Sie Ihre Entwickler und Tester immer wieder, miteinander zu kommunizieren und so transparent zu sein wie möglich. Keine Aufgabe oder Erkenntnis – egal wie trivial sie auch erscheinen mag – darf unerwähnt bleiben. Unterschiedliche Perspektiven auf die gleiche Sache kann Dinge (und womöglich Qualitätsprobleme) ans Tageslicht fördern, die sonst unbemerkt geblieben wären.

4. Dokumentation priorisieren!

Schritte zur Verbesserung der Kommunikation und Transparenz münden unweigerlich in notwendiger Dokumentation. Denn eine ordnungsgemäße Dokumentation kann maßgeblich zu eben dieser Transparenz beitragen. Und sie kann zudem dabei unterstützen, das gesamte Team an die gemeinsame Verantwortung zu erinnern und den Entwicklungsfortschritt speziell bei kurzen Releasezyklen für alle einfach nachvollziehbar zu machen.

5. Sich in das Gegenüber hineinversetzen!

Last but not least, und vielleicht sogar am wichtigsten ist es, dass Entwickler und Tester versuchen, die Sprache des jeweils anderen zu sprechen.

Bei einer nahtlosen Abstimmung verschwimmen die Grenzen zwischen Entwicklung und Testing. So können bzw. könnten Entwickler einige Aufgaben übernehmen, die traditionell von Testern durchgeführt werden – und umgekehrt. In einer solchen Umgebung müssen beide Seiten zumindest wissen, wie man die Sprache des anderen spricht. Noch besser wäre es, wenn sie sich nicht nur gegenseitig verstehen, sondern auch noch entsprechend handeln (können). Erwarten Sie aber nicht zu viel: Dass Ihre Entwickler einige, einfache Testfähigkeiten erlernen und Ihre Tester einige, einfache Entwicklungskompetenzen aufbauen, sollten Sie eher als „willkommener Bonus“ statt als „unbedingt erforderlich“ auffassen.

Nie mehr “Schwarzer Peter” spielen!

Grämen Sie sich nicht, wenn einmal etwas schief geht. Selbst die angesehensten Entwicklungsteams veröffentlichen auch einmal einen schlechten Release. In solchen Fällen ist es am wichtigsten, wie Sie damit umgehen. Dies wird naturgemäß schwerer, wenn Ihre Entwickler und Tester damit beschäftigt sind, mit Fingern aufeinander zu zeigen.

Wenn Ihr Team also immer noch „Schwarzer Peter“ spielt und Schuldzuweisungen hin und her schiebt, ist es an der Zeit, einen Schritt zurückzutreten und eine schonungslose Analyse Ihres Status-Quos in Sachen DevOps vorzunehmen. Es wird sich wahrscheinlich zeigen, dass Ihre Umgebung doch nicht so ausgereift ist, wie Sie dachten. Aber selbst, wenn dies der Fall ist, ist es nicht zu spät, das Schiff wieder in die richtige Richtung zu steuern. Die oben beschriebenen Best Practices können Ihnen dabei helfen.

Wenn Ihnen am Ende gelingt, die Abstimmung zwischen Entwicklern und Testern maßgeblich zu verbessern, sind Sie auf dem besten Weg zu einer ausgereiften DevOps-Umgebung – eine, in der Fehler nicht nur schneller erkannt und behoben werden können, sondern auch deutlich seltener auftreten.

Jetzt anschauen

Bitte registrieren Sie sich hier