Wir kennen die Situation sicherlich von schlecht geführten Restaurants. Am Tisch bekommen alle ihr Essen zu unterschiedlichen Zeiten, das Schnitzel ist wie eine Schuhsohle oder wir bekommen gar etwas, was wir gar nicht bestellt haben. Der Koch/die Köchin in der Küche ist völlig überfordert und kommt mit der Flut der Bestellungen und ständigen Änderungen am Rezept nicht zurecht.
Auch beim Softwaretest gibt es ähnliche Situationen. Dabei betrachten wir den Koch/die Köchin hier mal als Tester/in, der ein neues Rezept testet. Das heißt, das neue Rezept ist unser Testobjekt, welches vom Koch/Köchin, durch kochen überprüft wird. Das Testteam kommt mit der Flut an Änderungen nicht hinterher. Tests werden unnötig doppelt ausgeführt, andere werden vergessen oder übersehen. Fehler werden nicht entdeckt und können so in die Produktion gelangen. Das Chaos ist perfekt und die Qualität stimmt nicht. Doch was tun wir in so einem Fall? Den Koch/die Köchin antreiben, das Chaos automatisieren oder einfach mehr Tester/innen einsetzen? Nein! Denn was würde dann passieren?
Personal antreiben?
Da der Koch/die Köchin so schon durch das Chaos am Kollabieren ist, wird das Antreiben höchsten zu einer kurzzeitigen Verbesserung mit anschließendem K.O. führen. Damit erhalten wir also keine langfristige Optimierung der Situation.
Chaos automatisieren (Testautomatisierung einführen)?
Da wir erstmal einen Mehraufwand für die Automatisierung benötigen und in dem Chaos gar nicht klar ist, wo wir hier anfangen sollen, würde dies nur zu noch mehr Chaos und Überlastung in der Küche führen. Das ergibt somit eine noch schlechtere Qualität.
Einfach mehr Personal einsetzen?
Jeder kennt den Spruch „viele Köche verderben den Brei“. Wenn wir also einfach dem Koch/der Köchin noch weitere Hilfsköche/innen zur Seite stellen, heißt das nicht zwangsläufig damit sei alles gelöst. Hier ist nicht zu unterschätzen, dass das neue Personal erstmal eingearbeitet werden muss. Was wiederum zu Verzögerungen in den Arbeitsabläufen führen kann. Dies muss auf jeden Fall sorgfältig geplant werden, sonst führt dies zu noch mehr Chaos in der Küche.
Also was können wir tun?
Erstmal müssen wir analysieren, wieso es Chaos in der Küche gibt und welche Ursachen zu Grunde liegen. Oft stellt sich dann heraus, dass es an Stellen klemmt, an die zuvor gar nicht gedacht wurde. Zum Beispiel, dass der Kellner/die Kellnerin die Bestellungen nur unleserlich auf einen Zettel schreibt und nicht ersichtlich ist, was für welchen Tisch bestellt wurde. Das heißt, der Koch/die Köchin (Tester/in) muss ständig nachfragen. In diesem Vergleich betrachten wir den Kellner/Kellnerin als Analyst/in und die Bestellung, die der Kellner/die Kellnerin aufnimmt, als Teil-Anforderung. So können auch im Test (in der Küche) die Probleme bereits bei den aufgenommenen Anforderungen liegen und der Tester/die Testerin muss ständig nachfragen, wie die Anforderung gemeint ist.
Genauso könnte es sein, dass der Koch/die Köchin immer erst die Zutaten zusammensucht und mit den Vorbereitungen beginnt, wenn die Bestellung bereits da ist, also der Testende die Testfälle erst dann erstellt, wenn er das fertige Produkt vorliegen hat.
Wichtig ist auch, dass die Kommunikation in der Küche stimmt. Aber nicht nur in der Küche auch mit dem Kellner/der Kellnerin, dem Gast und dem Erstellenden des Rezeptes muss die Kommunikation stimmen. Das heißt im Test, dass die Kommunikation nicht nur im Testteam stimmen muss, sondern eben auch mit dem Analyst/Analystin, dem Product-Owner und dem Entwickler/Entwicklerin.
Ein weiteres Problem könnte darin bestehen, dass der Abstand zwischen Herd und Spüle zu weit ist. Für unsere Tester/innen übersetzt heißt das, dass sein Testwerkzeug einfach zu langsam ist und zur Testfallerstellung oder Testdurchführung zu viel Zeit benötigt wird.
Als Fazit muss also der Arbeitsprozess genauer unter die Lupe genommen werden:
- Ausgangslage
- Kommunikation
- Arbeitsschritte
- Verwendete Werkzeuge
- Dokumentation
- etc.
Anhand der Analyse können Schwachstellen identifiziert und entsprechende Maßnahmen ergriffen werden. Kurz um, diese Analyse mit entsprechenden Maßnahmen muss ein regelmäßiger Prozess werden. Richtig: ich spreche von einer regelmäßigen Retrospektive. Wichtig ist auch, dass in solch einer Retrospektive nicht nur die Probleme identifiziert werden, sondern auch Actionitems definiert werden, die dann umgesetzt und in der nächsten Retrospektive überprüft werden. Wenn nur analysiert wird, wo die Probleme liegen und keine Maßnahmen ergriffen werden, dann ändert sich auch nichts.
Auch in Hinsicht der Testautomatisierung ist es wichtig, dass die Arbeitsprozesse optimiert sind, sonst bringt auch diese keinen Erfolg. Also ohne Öl wird das Schnitzel schwarz – ob automatisiert oder nicht.
Es gibt leider kein Patentrezept, welches in jedem Projekt funktioniert. Es gibt jedoch einige Best Practices aus denen sich jeder für sein Projekt entsprechende Anregungen zur Verbesserung holen kann. Für den ersten Einstieg in den regelmäßigen Verbesserungsprozess können Sie sich gern von uns beraten lassen und die ersten Retrospektiven mit einem/einer erfahrenen Berater/Beraterin aus unserem Hause gemeinsam durchführen.
Lesen Sie auch meine anderen Artikel zum Thema Testautomatisierung:
Kochrezepte für Testautomatisierung (Teil 1) – Suppe
KochrezepKochrezepte für Testautomatisierung (Teil 2) – Datensalat
Kochrezepte für Testautomatisierung (Teil 3) – Wie muss ein richtiges (Test-)Rezept aussehen?
Dieser Beitrag wurde verfasst von:
