Ich komme einfach nicht an dem Thema vorbei. Es gab bis heute noch keinen Kunden, der in der agilen Software Entwicklung keine Abneigung gegenüber dem Berichten von Fehlern hatte. Meist liegt es an der Firmenkultur, die Fehler als etwas Schlechtes ansehen und darauf mit Fingern zeigen. Ich höre aber auch immer mehr die dogmatische Äusserung der agilen Jünger, dass das Vertrauen über der Kontrolle steht (was ja gut und recht ist) und darum keine Bugs erfasst werden sollen (was weder gut noch recht ist). Wir kontrollieren mit den gefunden Bugs keine Teams sondern erhalten über die Qualität des Produktes Auskunft. Erst dann wenn wir uns bewusst werden, was wir aus Fehlern alles lernen können, wird der Kontrollgedanke verdrängt. Und jetzt ist es endgültig an der Zeit, die kleinen Käfer unter die Lupe zu nehmen.
Fakt 1: Ein Bug ist ein Bug ist kein Bug
Was ist eigentlich ein Bug? Ist es ein Fehlerzustand, sprich: ein inkorrektes Teil eines Programmes oder Dokumentes? Oder ist es eine Abweichung vom erwarteten Soll- zum gelieferten Ist-Zustand? Handelt es sich bei einem Bug um die Fehlermeldung, die uns auf dem Bildschirm erscheint oder in Form eines Systemabsturzes auffällt? Der Bug ist ein sehr gängiger Überbegriff von all den erwähnten Situationen oder besser gesagt: Es ist ein Verhalten des Systems, welches der Anwender nicht erwartet und erst recht nicht goutiert. Bei einer mobilen App, welche von Millionen von Kunden zur Unterhaltung benutzt wird, ist der Kunde ein bisschen nachsichtiger betreffend einem möglichen Fehlverhalten. Ein Absturz einer Poker-App läuft nicht Gefahr, dass Sammelklagen über falsche Funktionalität eingehen könnten. Es kommt niemand zu finanziellemoder noch schlimmer, zu gesundheitlichem Schaden. Sobald aber diese Aspekte ins Spiel kommen, dann kann schnell einmal ein Bug einem Produkthersteller teuer zu stehen kommen wenn es um die Korrektur des Fehlerzustandes, oder um Zahlung von Schadenersatz geht.
Fakt 2: Bugs haben Charakteren
Wie und wann Fehler gefunden werden sagt einiges über den Charakter des betroffenen Bugs aus. Persönlich unterscheide ich zwischen den guten und den bösen Bugs. Das hat nichts damit zu tun, was sie dem System oder dessen Benutzer für Schaden zufügen, nein es geht eher darum, wer sie findet. Die "Bad Bugs" haben sich lange versteckt und werden von den Kunden und den Endanwendern eines System gefunden. Sie sind die miesen, kleinen Fehler, welche uns verärgern. Es sind genau die, welche ein schlechtes Bild auf die Qualität des Produktes liefern. Solche Bugs wollen wir nicht und können dem Problem auch mit Testen Abhilfe schaffen. Und genau das sind dann die "Good Bugs". Fehler, die sich vor der Auslieferung eines Produktes von einem Tester finden lassen. Und der Tester ist nicht eine Job-Description oder eine Rolle. Sobald ein Produkt von jemandem geprüft wird, trägt der Prüfer den Testerhut und ist persönlich verpflichtet, sich um den Bug zu kümmern. Am einfachsten ist das, wenn ein Entwickler ihn sofort beheben kann. Aber das bringt mich bereits zum nächsten Fakt.
Fakt 3: Bugs brauchen Aufmerksamkeit
Das hört sich jetzt vielleicht ein bisschen komisch an, aber Defects sind die grössten Diven in der Entwicklung. Sie wollen gefunden werden und dass sich jemand um sie kümmert. Am liebsten haben sie es, wie schon erwähnt, wenn sie vom Entwickler gefunden und umgehend behoben werden. Falls dies aber nicht möglich ist, dann lieben sie es, in einer Liste mit ihren Kollegen gepflegt zu werden. Ich habe schon oft erlebt, dass vergessene Fehler zu "Bad Bugs" mutiert sind und erst in der Produktion wieder gefunden wurden. Kommt noch dazu, dass Fehlerzustände richtig gesellige Kerlchen sind. Sie fühlen sich wohl, wenn sie unter sich sind. Solange sie man in einer zentralen Liste hält, sind sie glücklich und pflegeleichte "Good Bugs". Einzelgänger, die einsam in irgendwelchen Mails oder auf losen Zetteln dahinsiechen müssen, haben die Neigung zu "Bad Bugs" zu werden. Wenn auch nicht alle Fehlerzustände vor der Produktion behoben werden können, die gelisteten Bugs haben wir im Griff und Wissen das sie potentiell als böse gelten. Solange wir das aber den relevanten Stakeholdern kommunizieren können, hält sich das Böse aber in Grenzen.
Fakt 4: Bugs zeigen Qualitätslücken
Oh ja, Fehler haben einiges zu erzählen und wenn man ihnen richtig zuhört, kann man herausfinden, wo und warum sie überhaupt entstanden sind. Einige entstehen in der Anforderungsbeschreibung, andere während der Entwicklung und gar nicht so wenige entstehen während des Testens. Ich möchte nichts relativieren, aber Fehler, die Aufgrund von schlechten Testfällen oder Testdaten entstehen, weisen auf einen schwachen Testprozess hin. Diese Fehler sind so Quasi die "Ghost Bugs", also Fehler, die nach Definition gar keine Fehler sind. Genau so können sie auch über die Maturität der anderen Prozesse Auskunft geben oder auf gewisse Stellen in Systemen hinweisen, die noch Qualitätslücken aufweisen. Und falls wir etwas testen möchten, dann sollten wir immer wieder auf den Rat der Fehler in den genannten Listen hören, denn sie sagen uns, wo wir potentiell noch Kollegen von ihnen in unserem Produkt finden können.
Quintessenz: Good Bugs sind Freunde
Fehler werden geliebt und gehasst. Fehler brauchen Zuneigung und Pflege. Der Aufwand hält sich meist in Grenzen, wenn man ein gutes System einsetzt. Etwas weiss ich aus meiner langjährigen Erfahrung: Ich kümmere mich lieber um "Good Bugs" als um "Bad Bugs", weil sie geplant behoben werden können. Es gibt wahrscheinlich nichts lästigeres, als wenn man an der Weiterentwicklung eines Systems arbeitet und immer wieder Kraft, Zeit und Mühe mit der Behebung von Fehlern aus der Produktion aufwenden muss. Auf diese Fehler muss man mit den Fingern zeigen und sie sollen auch für eine negative Bewertung der gelieferten Qualität dienen. Aber jeder einzelne Fehler, der noch vor Auslieferung gefunden wird, ist unser Freund und darum sollten wir sie auch feiern können.