Es ist in der einschlägigen Fachliteratur nachzulesen, auf welche Art und Weise, mit welchen Methoden Softwaretests gemanaged werden können. Nun weiß man aber auch, dass die Realität oftmals eine andere ist. Tatsächlich kann man sich nicht darauf verlassen, dass
- man zum festgelegten Zeitpunkt alle Dokumente vorliegen hat
- die Spezifikationsdokumente konsistent und vollständig sind
- alle Resourcen (Hardware, Software, Mitarbeiter usw.) immer zu 100% zur Verfügung stehen
- es während des Testzeitraums keine signifikanten Änderungen der Software gibt
- Probleme, Fragen und Zusammenhänge sofort und kompetent geklärt werden
- es klare Zuständigkeiten für die Aspekte der Softwareentwicklung gibt
- in vorherigen Phasen fach- und sachgerecht gearbeitet wurde (Einhaltung von Vorgehensmodellen, Anwendung von Standards usw.)
und vieles mehr.
Dies alles ist weder schrecklich oder katastrophal, sondern einfach alltägliche Realität. Die Erfahrung lehrt, dass den Schwierigkeiten nur durch ein agiles Testmanagement beizukommen ist. Und wie das aussehen kann, soll hier kurz skizziert werden.
Menschen sind wichtig
Es ist absolut sinnlos sich auf bestehende Prozesse zu berufen, wenn etwas schwierig wird oder schief geht. Wichtig ist es mit den beteiligten Menschen (und das heißt i.d.R. Mitarbeitern) zu sprechen.
Setzen Sie Ihre kommunikativen Fahigkeiten ein!
- Warum gibt es die Probleme? Was ist ihr Ursprung und wie kann man sie klären?
- Bauen Sie ein vertrauensvolles Verhältnis auf. Machen Sie deutlich, dass es immer um ein Miteinander für die Sache und nie um ein Gegeneinander geht.
- Gleichen Sie Ihre Maßnahmen zur Lösung der Schwierigkeiten mit allen Beteiligten ab.
- Wenn sinnvolle Gegenmaßnahmen gefunden wurden: kommunizieren Sie diese offen und achten Sie darauf, dass sie von allen verstanden und angenommen wurden. Fragen Sie nach.
Der Kunde ist wichtig
Software wird nicht im Elfenbeinturm entwickelt, sondern hat immer einen Sinn und ein Ziel für den Kunden. Dabei ist es unerheblich, ob es sich um einen internen oder externen Kunden handelt.
- Kommunizieren Sie offen mit dem Kunden über bestehende Schwierigkeiten und binden Sie ihn in die Lösung mit ein.
- Kommunizieren Sie verlässlich und regelmäßig den aktuellen Stand der Arbeit (Entwicklung, Test usw.)
- Weisen Sie auf Risiken hin und machen Sie Vorschläge zur Minimierung.
- Binden Sie den Kunden in den Test mit ein. Am besten wird ein Mitarbeiter des Kunden Teil des Testteams. So kann Ihr Test noch stärkere Praxisrlevanz erlangen.
- Machen Sie ein Kick-Off- und ein Abschluss-Meeting. Feiern Sie Erfolge, verbreiten Sie gute Stimmung.
- Binden Sie den Kunden in den „Lessons learned“ Prozess mit ein.
Das Produkt ist wichtig
Sie haben alles richtig gemacht: Eine vollständige Spezifikation, mit dem Kunden abgestimmt, qualtitativ hochwertiges Softwareprodukt, nach allen Regeln des Handwerks erstellt. Leider am Einsatzzweck vorbei entwickelt … Ja, das gibt es, und noch vieles mehr …!
Hinterfragen Sie Ihre Arbeit immer bezüglicher folgender Fragestellungen:
- Warum werden die aktuellen Maßnahmen durchgeführt? Was ist das Ziel?
- Hat das Produkt im aktuellen Zustand einen Nutzen? Was muss getan werden, um das klar mit „Ja!“ beantworten zu können?
- Führt die aktuelle Arbeit zu dem Ziel, das Produkt zum Einsatz zu bringen, oder ist das Ziel „es schön zu machen?“
- Was steht nicht in der (Test-) Spezifikation, ist aber wichtig, um das Produkt in einen akzeptablen Zustand zu bringen bzw. zu halten?
Viele dieser Fragestellungen und deren Antwort werden während der laufenden Arbeit bearbeitet. Oftmals in einem kurzen Telefonat oder durch zwei Emails. Viele wichtige Dinge gehen dabei für die weitere Arbeit verloren. Versuchen Sie deshalb das „On the Fly“ gewonnen Wissen zu verschriftlichen. Meiner Meinung geht das am besten in Form eines Wikis, in dem schnell, einfach und für jeden zugängig die Informationen festgehalten und ergänzt werden können.
Sie befürchten Wildwuchs und haben schon (schlechte) Erfahrung mit Wikis gemacht? Dann sollte ich mich vielleicht noch mal an einen kurzen Artikel zu Information Mining und Knowledge Management machen …
Ergänzung: Dieser Artikel ist entstanden zu einer Zeit, in der ich noch im klassischen Umfeld als Testmanager gearbeitet habe. Die Rückschau zeigt, dass mir, bevor ich mich intensiv mit Agilität beschäftigt habe, die wesentlichen Prinzipien bereits klar und offensichtlich waren.
