Sechs Fehler bei der Einführung eines Qualitätsmanagements

Ich bin jetzt seit über sechs Jahren im Qualitätsmanagement und kann glaube ich mit stolz behaupten, dass ich mittlerweile fast jeden Fehler gemacht habe, den man bei dem Thema machen kann. Das ist zumindest dann gut, wenn man jeden Fehler nur einmal machen will.

Damit aber nicht jeder in die Situation des Fehlermachens kommen muss, will ich heute mal ein paar der großen und der häufigsten Fehler, die mir in meiner Laufbahn aufgefallen sind besprechen.

Zu spät ins Projekt kommen
Klingt trivial, aber als QM sollte man nicht zu spät ins Projekt kommen. Am besten von Anfang an dabei sein. Dabei ist es gar nicht unbedingt der Grund, dass man danach viel zu viel aufräumen muss, sondern dass es immer schwerer wird vom Projekt akzeptiert zu werden. Akzeptanz ist einer der wichtigsten Punkte, die man erreichen muss, um erfolgreich zu sein.
Wir versuchen bei Projekten so früh wie möglich dabei zu sein, um dort bereits mit den Gerüchten aufzuräumen, dass QM/QA nur Kosten produziert. Dem ist nämlich nicht so.
Das Team nicht involvieren
Klassischer Fehler ist es, in ein Projekt reinzukommen, es zu analysieren und danach dem Team zu sagen, was es machen muss. Das kann zwar sehr effizient sein, wird aber nicht funktionieren. Natürlich bin ich derjenige, der schon 100 Projekte begleitet hat, natürlich kenne ich die üblichen Fehler einer Programmierers, denn auch die habe ich alle schon gemacht. Aber natürlich zählt das nicht.
Gerade in Zeiten von Scrum und Co. ist es wichtig, dass das Team selbstbestimmt ist. Jemand von außen sollte da also keine Anweisungen geben. Das mag niemand von uns. Wenn ich verantwortlich bin, dann will ich auch meine eigenen Entscheidungen treffen. Total legitim.
Was wir dabei dann machen ist über die Risiken ranzugehen. Gemeinsam mit dem Team bestimmen wir, was denn eigentlich alles schief gehen könnte und was uns das kosten würde. Danach besprechen wir gemeinsam, wie man diese minimieren kann. Dabei bringen wir natürlich unseren Werkzeugkasten gefüllt mit Tools und Prozessen mit. Nach einem solchen Workshop mit dem Team gehen eigentlich alle mit einem guten Gefühl raus. Und was das beste ist: die Maßnahmen, die beschlossen wurden sind nachvollziehbar und vom Team akzeptiert.
Tools vorschreiben
Im zweiten Punkt haben wir beschrieben, dass wir gemeinsam mit dem Team die Risiken. Jetzt könnte man dem Team sagen, dass man für Risiko A doch bitte PHPUnit einsetzen soll. Für Problem B Smoke. Wieder unheimlich effizient, aber auch frustrierend. Wenn ein Team etwas neues ausprobieren will, dann ist das problemlos möglich. Natürlich können wir dann nicht im vollen Umfang unterstützen, aber manchmal sollte man die bekannten Wege auch verlassen. Wichtig ist nur, dass man das neue Tool, falls die Nutzung ein Erfolg war mit in den eigenen Werkzeugkasten aufzunehmen.
Die falschen Dinge testen
Wir machen Unit Tests. Testabdeckung ist 80%. Schlecht ist das sicher nicht. Aber wenn man versucht diese 80% über alles zu schütten, dann sind da sicherlich ganz viele Komponenten dabei, bei denen das gar nicht nötig ist. Wir verfolgen den Ansatz „no risk no test“ und fahren damit ganz gut. Was wäre denn, wen ein E-Mail-Formular kaputte E-Mail-Adressen annimmt. Dann hätten wir wahrscheinlich alle 1000 Adressen mal eine falsche dabei. Ja, und?
Sucht euch also genau aus, was ihr testen müsst. Welche Komponenten haben einen hohen Businesswert, womit verdient ihr euer Geld? Wenn ihr diese Fragen beantworten könnt, dann wisst ihr auch. wo ihr 80% Testabdeckung haben solltet.
Das Team komplett alleine lassen
Wenn man sehr früh im Projekt ist, dann man den Fehler machen am Anfang einmal alles zu spezifizieren und danach das Team laufen zu lassen. Früher, zu Zeiten des Wasserfalls ging das ohne Probleme. Heute im agilen Leben aber leider nicht mehr. Viel zu oft ändert sich der Fokus oder Features werden gar nicht mehr so umgesetzt, wie sie geplant waren. Also heißt auch hier wieder das Zauberwort „Flexibilität“. Als QM sollte man davon ausgehen, dass alle Pläne, die man am Anfang macht über den Haufen geworfen werden können und das darf meinem nicht wehtun.
Zu formal sein
Mein ganzes Team ist ISTQB (advanced) zertifiziert. Yeah. Wir wissen also genau, was ein Testplan alles enthalten muss, wie man formal sauber Tickets erfasst und und und. Das ist auch wichtig, denn jetzt wissen wir genau, wann wir das Zeug nichts brauchen. Ein zu formaler Prozess gibt den Entwicklern das Gefühl in ein zu enges Korsett eingesperrt zu werden. Nicht gut! Auch wenn wir uns nach innen an einige formale Prozesse halten, ist es wichtig dem Team das Gefühl zu geben das sie das machen, was sie wollen.

Das waren meine sechs Punkte, die mich die letzten Jahre beschäftigt haben. Ich hoffe, dass es dem ein oder anderen hilft in diese Fettnäpfchen nicht zu treten. Aber wie es so oft ist, manche Fehler muss man einfach selber machen.