It’s not a Bug, it’s Culture

11.3.2022

von

Sebastian Gerlich, verification-engineer.de

Wie Bugs mehr zeigen als nur die Qualität des Produkts

Keine Software, kein Produkt und auch keine Organisation ist fehlerfrei, somit ist es ein wesentlicher Teil einer Organisation einen optimalen Umgang mit dem Auffinden der selbigen zu entwickeln. Dies fällt dabei den Einzelnen häufig schwer, wodurch dies auch nicht die Aufgabe der einzelnen Kompetenzen sein kann, sondern von der gesamten Organisation.  

Ein Bug ist nicht gleich ein Bug.

In der Regel werden Bugs als Abweichungen von der Spezifikation definiert. Jetzt ist insbesondere in der agilen Entwicklung die Spezifikationslage in den einzelnen Tickets oder in anderen Dokumenten eher dünn, was natürlich der kreativen Implementierung zugutekommt, jedoch eine Bewertung, ob es sich um einen Bug handelt, erschwert. Vielmehr lassen sie sich vor allem in der agilen Entwicklung oder bei der Abwesenheit von ausführlichen Anforderungen anhand der folgenden Kriterien klassifizieren:

  • Abweichung von spezifizierten Anforderungen (z.B. Acceptance Criteria)  
  • Abweichung von der eigenen Erwartung an die Funktion
  • Limitierung in der Performance einer Funktion
  • Fehler in der Anwendbarkeit einer Funktion

Vielfalt macht eine Entwicklungsorganisation leistungsstark

In einer Entwicklungsorganisation treffen unterschiedliche Arbeitskulturen aufeinander. Die Entwickler sind und sollen von ihrer Implementierung überzeugt sein und auch davon ausgehen, dass sie diese korrekt implementiert haben. Durch geeignete Mittel wie die Unittests weisen sie nach, dass ihre berücksichtigten, vorhersehbaren Fälle und Varianten korrekt umgesetzt wurden. Hierbei werden Logikfehler gefunden, jedoch nicht Fehler bei der Interpretation von Funktionen, Grenzfälle oder Fehler bei unvorhersehbaren Kombinationen der Anwendungsfälle. In diesem Zusammenhang werden auch die Bugs häufig eher bei der Testerstellung und in späteren Regressionstests gefunden.

Die Tester und Anwendungsexperten hingegen sind immer auf der Jagd nach dem nächsten Bug. Sie wollen nachweisen, dass das Produkt nicht fehlerfrei ist. Dafür werden jegliche Kombinationen, Grenzfälle aber auch die eigene Interpretation basierend auf der Erfahrung und Expertise in die Waagschale geworden. Hierbei wird dann häufig versäumt, die gefundenen Bugs im Gesamtkontext zu betrachten. Nicht jeder Bug ist gleich kritisch und muss nicht unmittelbar gelöst werden.

Gemeinsam haben die jeweiligen Bereiche immerhin, dass sie den Reifegrad als ausreichend für ein Release nachweisen wollen.

Trotzdem führen die gegensätzlichen Ansätze dazu, dass es immer wieder zu Reibereien kommt. Die Entwicklung hinterfragt die Art des Tests und zweifelt an der Richtigkeit der Ergebnisse, weil die Unittests bereits in Ordnung waren und der Test keinen relevanten Anwendungsfall abbildet. Dies führt häufig dazu, dass nur die Bugs anerkannt werden, die eindeutig gegen eine Anforderung oder die eigene Interpretation einer Funktion verstoßen. Hierdurch entsteht eine Zusammenarbeit, die nicht auf Augenhöhe stattfindet, wodurch Innovationskraft verloren geht und es auch gleichzeitig zu grundsätzlicher Hinterfragung der eigenen Arbeit und Leistung, zu Frust und Unzufriedenheit kommt und dies interessanterweise nicht nur bei den Testern.

Diese Konflikte lassen sich jedoch nicht allein durch statische Prozesse oder starre Regeln lösen.  

Der Umgang mit Bugs beschreibt viel mehr die Kultur einer Organisation. Denn nicht nur das Produkt beinhaltet auf den Weg zur Marktreife und selbst im Markt noch Bugs, sondern auch die Personen produzieren in ihrer täglichen Arbeit Bugs.  

Und hier muss ein offener Umgang bei der Klassifizierung und der Lösung gelebt werden.

Denn ein Bug ist kein Fehler, keine Schwäche, sondern die Chance besser zu werden, daraus zu lernen.

Ein Bug muss auch mal zu einem Schmunzeln führen. Und ja, man darf sich auch mal über einen Bug so richtig ärgern. Aber niemals darf man dabei persönlich werden oder die Arbeit allgemein schlechter machen als sie ist.  

Was hat ein Bug jetzt mit Culture zu tun?

Ein Bug hat gleichzeitig nichts und alles mit der Kultur eines Unternehmens zu tun. Auf der einen Seite soll ein Bug eine klare, technische Abweichung von einer der oben genannten Aspekte dokumentieren.

Auf der anderen Seite beschreibt der Umgang mit Bugs innerhalb des Unternehmens so simpel wie eindeutig die Zusammenarbeit innerhalb des Teams in Bezug auf die gegenseitige Wertschätzung, Kommunikation und Transparenz.

Beschränkt sich ein Team lediglich auf die Bugs, die gegen eindeutige Anforderung verstoßen, zeigt das deutlich, dass keine tiefgreifende Zusammenarbeit zwischen den implementierenden und den testenden Bereichen besteht. Hier wird der nachweisende Bereich lediglich als notwendiger Prozessschritt angesehen und dies im schlimmsten Fall auch noch ohne eine Wertschätzung der Tätigkeit. Gleichzeitig ist dies häufig in Kombination mit einem fehlenden Vertrauen in die durchgeführten Tests des implementierenden Bereichs zu beobachten. Hierdurch wird klar die Chance vertan, gemeinsam das Produkt über die vorhersehbaren Anforderungen hinaus zu verbessern.

Im krassen Gegensatz dazu stehen Organisationen, die es geschafft haben, das Suchen, Finden, Klassifizieren und Lösen von Bugs in ihrer DNA zu verankern und die Grenzen zwischen Bereichen verschwimmen zu lassen, in der die Bereiche nicht gegeneinander arbeiten, sondern voneinander profitieren. In einer solchen Organisation wird jeder gefundene Bug als wertvoll für die Weiterentwicklung und Verbesserung des Produkts, aber auch der eigenen Organisation betrachtet.

Dieses Level wird dadurch erreicht, indem man eine offene Kommunikation zwischen den Bereichen etabliert, eine wertschätzende Meinungsäußerung fördert und gemeinsam über „lustige“ Implementierungsfehler aber auch „schräge“ Interpretationen oder Tests lacht.  

 

Wie kann eine solche Kultur gefördert werden?

Die Entwicklung hin zu einer solchen Organisation sollte auf diversen Ebenen gefördert werden:

  • Die Führung sollte sicherstellen, dass es keinen falschen Zeitpunkt gibt, zu dem ein Bug gefunden wird.
  • Der implementierende Bereich sollte offen sein für andere Perspektiven bei der Implementierung. Dafür können andere Bereiche bei Bedarf bereits bei der Implementierung unterstützen, kurze Feedbackschleifen verringern umfangreiche Anpassungen.
  • Der testende Bereich sollte frühzeitig die Erwartungshaltung an die Implementierung definieren und kommunizieren. Gefundene Bugs sollte sie mit Blick auf den tatsächlichen Impact auf das Produkt bewerten und diese Bewertung transparent kommunizieren.
  • Durch moderne Tools kann eine Organisation transparent gemacht werden und unentdeckte Fähigkeiten und Ressourcen sichtbar gemacht werden. Gleichzeitig können moderne Tools auch notwendige Kommunikationsschnittstellen sichtbar machen.

Insgesamt zeigt sich, dass eine Organisation, die es schafft, die einzelnen Bereiche zu einer integrativen Einheit zu vereinen, deutlich davon profitiert. Dies zeigt sich durch kürzere Feedbackschleifen, schnellere und innovativere Lösungen von Problemen, höhere Qualität des Produkts und vor allem in einer hohen Motivation und Zufriedenheit der Teammitglieder. Diese führt darüber hinaus auch dazu, dass neue Fähigkeiten von Teammitgliedern entdeckt werden und gefördert werden können.  

Es zeigt sich also, dass ein Bug viel mehr aussagt als nur etwas über die Qualität in einem Produkt. Ein Bug und der Umgang damit ist das Spiegelbild einer Organisation. Und zeigt deutlich, ob eine Organisation gemeinsam in eine Richtung strebt oder sich in einem Kompetenzgerangel blockieren.

Not the bug is a feature but the handling becomes the feature and the new culture

Folgt Sebastian Gerlich auf LinkedIn für noch mehr interessante Themen.

Auf dem neusten Stand bleiben

Wir informieren dich von Zeit zu Zeit über unsere Fortschritte.
Kein Spam, versprochen!

© 2021 Con Cubo GmbH