Dass wir bei Leankoala viel und gerne über Qualität reden, ist ja nun fast allgemein bekannt. Unsere Expertise und Eloquenz zum Thema verdanken wir allen voran Nils und den Erfahrungen des Leankoala Teams aus ihren früheren Berufsleben. Und da Leankoala nicht nur die schlankeste, sondern auch die freundlichste Software as a Service für Lean Testing ist, teilen wir sehr gern unser Wissen mit Euch bzw. wollen gemeinsam mit Eurem Feedback besser werden.

Eine Software macht nun mal noch keine Qualität und beim Aufsetzen eines digitalen Qualitätsmanagements kann so einiges schief gehen. Hier die sechs gängigsten Fehler bei dessen Einführung, die wir alle schon gemacht haben.

1. Zu spät ins Projekt kommen

 

Gerade in Zeiten agiler Entwicklung und interdisziplinärer Kollaboration besonders wichtig, wenngleich auf den ersten Blick trivial. Das QM sollte idealerweise von Anfang an in das Projekt involviert sein. So entsteht nicht nur eine größere Akzeptanz für das Thema (und Ihr könnt den Gerüchten entgegen wirken, dass QM/QA nur Kosten produziert) innerhalb des Projektteams, sondern bereits eine frühzeitige Idee davon, was überhaupt QM/QA leisten muss und wie das Setup aussehen kann.

2. Das Team nicht involvieren

Neben Integration ist Selbstbestimmung wichtigste Eigenschaft von agilen Teams und Zwischenrufe von der Seite oder Holzhammer von oben sind auch nicht gerade als Produktivitätssteigerer bekannt. Anstatt also Ansagen zu machen lieber in einen Workshop mit dem Team zum Thema Risiken gehen. Gemeinsam im Team bestimmen wir dann, was denn eigentlich alles schief gehen könnte und was uns das kosten würde. Danach besprechen wir gemeinsam, wie man diese Risiken minimieren kann. Dabei bringen wir natürlich unseren Werkzeugkasten gefüllt mit Tools und Prozessen mit. Nach einem solchen Workshop 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.

3. Tools vorschreiben

Im zweiten Punkt haben wir beschrieben, dass wir gemeinsam mit dem Team die Risiken analysieren und das Team selbstbestimmt nach Lösungen sucht. Jetzt könnte man dem Team sagen, dass man für Risiko A doch bitte PHPUnit einsetzen soll. Für Problem B Smoke. Das kann unheimlich effektiv sein, aber auch frustrierend. Wenn ein Team etwas neues ausprobieren will, dann sollte das problemlos möglich sein. Denn das Verlassen bekannter Wege ist ja trotz Unwägbarkeiten der einzige Weg zu Innovationen. Wichtig ist nur das neue Tool, falls die Nutzung ein Erfolg war, mit in den eigenen Werkzeugkasten aufzunehmen und Erfahrungen mit allen zu teilen.

4. Die falschen Dinge richtig testen

Die meisten von Euch machen wahrscheinlich Unit Tests. Testabdeckung ist 80%. Schlecht ist das sicher nicht. Aber wenn man versucht diese Tests auf alle Szenarien und Fälle anzuwenden, dann sind da sicherlich ganz viele Komponenten dabei, bei denen das gar nicht nötig ist. Mit unserem Lean Testing Ansatz kommt man einem schlankeren Setup ziemlich schnell näher. Was passiert denn eigentlich, wenn ein Formular für Email-Adressen auch mal einen Fehler annimmt? Nichts?

Sucht euch also genau aus, was Ihr testen müsst (wichtig hierfür, Punkt 2 nicht zu überspringen). 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.

5. Das Team komplett alleine lassen

Wenn man sehr früh im Projekt ist, dann kann 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 gemacht hat, über den Haufen geworfen werden können und das darf einem nicht wehtun.

6. Zu formal sein

Viele QM-Teams sind komplett ISTQB (advanced) zertifiziert. Yeah. Ihr wisst also genau, was ein Testplan alles enthalten muss, wie man formal sauber Tickets erfasst und so weiter und sofort. Das ist auch wichtig, denn jetzt wissen wir genau, wann wir das Zeug nicht 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 den Freiraum zu selbstbestimmtem Arbeiten zu geben.

Wir hoffen, dass Euch unsere Erfahrungen vor dem ein oder anderen Misserfolg bewahren werden (auch wenn man einige Fehler auch am liebsten selbst machen sollte 🙂 ). Welche Erfahrungen habt Ihr im Bereich QM/QA gemacht? Teilt sie mit uns in den Kommentaren!

Dieser Artikel erschien zuerst auf thewebhatesme, einem früheren Projekt von Nils.

Foto von Lukas von Pexels