Zertifizierungen

Blog
CELEBRATE BUGS!
Warum wir Fehler feiern müssen.
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 finanziellem oder 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 Charaktere
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 Systems 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.
Marcel Rütschi,
Principal Consultant