Stellen Sie sich vor, Sie kaufen ein neues Auto - würden Sie den Vertrag unterzeichnen, bevor Sie eine Probefahrt gemacht haben? Und nun stellen Sie sich vor, ein guter Freund von Ihnen ist KFZ Mechaniker oder Mechatroniker - Sie würden höchstwahrscheinlich versuchen, ihn mal unter die Haube gucken zu lassen und seine Meinung wissen wollen?
Die Probefahrt oder der Check durch einen vertrauenswürdigen Experten beim Autokauf stellt letztendlich einen Test dar - Ihre Anstrengungen, zu aussagekräftigen Testergebnissen zu kommen, kann man als Testmanagement bezeichnen. Nun macht die Probefahrt im Neuwagen auf der leeren A3 ab 200 Km/h wesentlich mehr Spaß als das Testmanagement in Projekten, aber letztendlich verfolgt beides denselben Zweck - und sollten wir scheitern, fahren wir in beiden Fällen etwas sehr wertvolles gegen die Wand oder die Leitplanke.
Wenn zu Projektbeginn bei klassisch geleiteten IT- Projekten sauber und realistisch geplant wird, die Experten befragt werden, wie lange einzelne Tasks benötigen, der Zeitbedarf gegen den Urlaubsplan gespiegelt wird und ein Puffer von nehmen wir mal 10% eingeplant wird, dann sollte es nur in Ausnahmefällen möglich sein, die erforderlichen Arbeiten völlig außerhalb des geplanten Zeitraums fertigstellen zu können.
Soo, und dann kommen wir in die Testphase - und hier habe ich leider in einem Großteil der Projekte bemerken müssen, dass die Testphase, diejenige Phase welche die letzte Phase vor dem Go Live darstellt, in der man eigentlich nur noch mal kurz alles überprüfen möchte bevor man endlich die langherbeigesehnte Projektabschlussparty feiern kann, für eklatante Verzögerungen sorgt. Und jetzt werden Sie sich denken: Dann plan die Testphase doch einfach länger. Habe ich getan. Ich habe schon für 3 Monate Projektarbeitszeit anschließend 2 Monate Testphase geplant, einfach als Experiment - und raten Sie mal: Hat auch nicht gereicht. Und ich finde, dass die Testphase weniger Zeit in Anspruch nehmen soll als die vorangehenden Arbeitsphasen - je nach Komplexität des Endproduktes, Erfahrung des Teams etc. mehr oder weniger, aber es ist schwer zu rechtfertigen, wenn eine Testphase beispielsweise die doppelte Zeit der Entwicklungsphase einnimmt.
Verdeutlichen wir uns das am Beispiel des Autokaufs: Wenn Sie ein neues Auto kaufen möchten, dann checken Sie im Internet erstmal mögliche Alternativen, prüfen diese auf Eignung, fragen Kollegen und Freunde. Dann gehen Sie in ein paar Autohäuser und reden mit den Verkäufern. Sie schlafen ein paar Nächte darüber und entscheiden sich dann für Ihre 1 bis 2 Topmodelle für eine Probefahrt, üblicherweise von maximal 2 Std pro Modell. Der Testzeitraum stellt auch hier nur einen geringen Bruchteil des Entscheidungs- und Recherchezeitraumes dar, bevor Sie eine Entscheidung treffen.
Warum ist der Testzeitraum in Projekten so schwierig?
Ich vermute, dass die menschliche Komponente eine große Rolle spielt: Man will fertig werden, und gedanklich ist man am Ende der Entwicklung fertig. Wurde ja alles geplant und alles wie geplant erstellt. Tests bedeuten Kontrolle - und wer lässt sich schon gerne kontrollieren? Das passt schon, wir machen sowas ja schon lange und sind Profis... Das reicht, wenn der Kollege Klaus mal kurz drüber guckt, der hat ja auch halbwegs Ahnung davon...
Tja, in dem meisten Fällen reicht das dann leider nicht, und das ist nicht zwingend die Schwäche derjenigen, welche das Produkt erstellt haben, sondern die Schwäche der Planung und der Anforderungsdefinition. Wenn Anforderungen anfangs widersprüchlich oder nicht realisierbar waren, ohne dass es jemandem aufgefallen ist oder wenn Komponenten nicht zusammen passen, dann fällt dieses Problem im schlimmsten Fall erst in der finalen Testphase auf - und das gilt dann auch beim agilen Projektmanagement...
Apropos, im agilen Projektmanagement entstehen solche Probleme natürlich nicht, zumindest nicht nach Lehrbuch. Das agile Projektmanagement verfolgt den Gedanken, in kürzeren Zeiträumen zu entwickeln, legen wir einmal 2 bis 4 Wochen zugrunde, innerhalb dieses Zeitraumes zu testen und am Ende dann ein lauffähiges Produktinkrement erzeugt zu haben - nicht das Endprodukt wohlgemerkt, sondern nur eine verbesserte Version. Wann das Endprodukt erzeugt ist, ist dem agilen Projektmanagement herzlich egal, es wird so lange iteriert, bis das Produkt dann halt fertig ist. Der agile Autokauf sähe so aus, dass sie nicht so lange vorab planen und recherchieren, sondern sich möglichst schnell Probefahrten organisieren um sich durch trial and error zum Traumauto hin iterieren. Fangen wir mal mit einem Smart an, der ist schön preiswert...Hmm, fährt nicht spritzig genug? Dann testen wir mal einen Ferrari... Schon cool, aber ups, zu teuer... Dann fahren wir mal den Golf... Bingo, der fährt ganz gut und ist erschwinglich. Ob dieses Vorgehen letztendlich schneller und besser funktioniert als im klassischen Projektmanagement sei dahingestellt.
Der sinnvolle Grundgedanke des agilen Projektmanagements ist, möglichst schnell zu testen, bevor eine lange Entwicklung völlig für die Tonne war. Diesen Grundgedanken sollten eigentlich alle Projektmanager verfolgen, unabhängig davon, ob sie sich nun klassisch oder agil nennen. Es stellt sich die Frage, inwiefern dies möglich ist - sowohl im klassischen als auch im agilen Projektmanagement. Unit- Tests oder Komponententests, also die Tests einzelner Systemkomponenten, können und sollten in beiden Arten des Projektmanagements möglichst schnell durchgeführt werden. Integrationstests, die das Zusammenspiel des geänderten Systems mit anderen Systemen testen und der Systemtest, also der Test des gesamten Systems können ggf. erst am Ende der Entwicklung sinnvoll getestet werden. Je nach Situation entsteht hier beim agilen Projektmanagement sogar noch ein Mehraufwand gegenüber der klassischen Variante, wenn wirklich alle 14 Tage eine Änderung ausgebracht werden soll, welche im Verbund mit mehreren weiteren Systemen getestet werden muss.
So, Traumauto gefunden, ob nun klassisch mit viel Vorbereitungszeit oder agil iterativ- Wie testen wir also?
Die Straßen, auf denen wir unser Auto Probefahren sind wichtig. Ein bisschen Autobahn, ein bisschen Landstraße und vielleicht sogar ein bisschen Feldweg - ganz nach gewünschtem Einsatzgebiet (Spoilerwarnung: Fahren Sie den Ferrari am besten nicht auf einem Feldweg Probe). Den Testaufbau und die Ergebnisse halten wir am besten in einer Testmatrix fest, dann ist das halbwegs revisionssicher und Ihr Ferrarihändler weiß hinterher auch wenigstens, woher die ganzen Kratzer auf dem schönen roten Lack kommen.
Die Testmatrix beginnt mit der Definition der Testfälle. Ich fasse das als "Testvorbereitung" zusammen. Die Testfälle werden idealerweise ganz am Anfang des Projektes oder der Iteration definiert und ggf. fortlaufend ergänzt. Das ist extrem wichtig, weil: Testfälle hängen extrem eng mit Anforderungen zusammen. Letztendlich soll ja getestet werden, ob die zu Beginn festgelegten Anforderungen erfüllt werden (Traceability). Die Definition der Testfälle könnte für unser Beispiel so aussehen:
Das Testschema offenbart, dass zu beginn die Anforderungen "Fahrverhalten", "Sound" und "Preis" festgelegt wurden. Diese Anforderungen wurden in der Testvorbereitung auf verschiedene Testsituationen (Landstraße, Autobahn, Feldweg) umgelegt. In unserem Beispiel sind somit bereits aus 3 Anforderungen 7 Testfälle geworden. Weitere Anforderungen & Testsituationen würden zu einer weiteren Vervielfältigung der Testfälle führen, beispielsweise wenn wir verschiedene Motorensetups hätten und oder verschiedene Reifengrößen.
Wenn wir die Tests nach bestem Wissen und Gewissen sauber definiert haben, können wir zur Testumsetzung, also zur Testdurchführung kommen. Diese muss natürlich dokumentiert werden. In unserem Beispiel könnte das so aussehen:
Welche Erfahrungen haben Sie mit Projektverzögerungen ab der Testphase gemacht? Testen Sie systematisch oder nach Augenmaß? Haben Sie das Gefühl, dass Tests in agilen Projekten besser laufen als in klassischen Projekten? Schlägt ihr teurer Sportwagen auf Feldwegen auch immer auf dem Boden auf? Ich freue mich auf Ihre Kommentare.
