Wie viel Testen muss sein? Aus Expertensicht so viel wie möglich – aber richtig.
In Softwareeinführungsprojekten wird das Thema Testen häufig unterschätzt und zeitlich möglichst weit nach hinten geschoben. Die Gefahr, dass der Einführungstermin dann nicht zu halten ist, ist sehr groß.
Ein Fall aus der Praxis
Das neue TMS sollte Ende Juli produktiv gehen. In der Projektplanung waren noch einmal 2 Wochen für die Abschlusstests vorgesehen. Eigentlich war es das erste Mal, dass alle Beteiligten – Fachseite und IT – richtig intensiv getestet haben. Leider mit der Erkenntnis, dass die Einführung verschoben werden muss. Schlimmer noch: Das komplette Migrationskonzept (schrittweise Einführung) hat sich als nicht tragfähig erwiesen. Man wird nunmehr mehre Softwarekomponenten zur gleichen Zeit einführen müssen. Dadurch steigt die Komplexität – die Termine verschieben sich deutlich. D.h. die Anwender können erst viel später von dem System profitieren.
Kommentar des Projektmanagers: Gut, dass wir getestet haben, sonst hätten wir nicht gemerkt, dass das Migrationsszenario gar nicht möglich ist…. Leider eine sehr späte Erkenntnis.
Tipps für das Testen
Um so etwas zu verhindern, nachfolgend ein paar Tipps rund um das Thema Testen:
So früh wie möglich beginnen
Konkret heißt das: Sobald die ersten Anforderungen der Anwender feststehen (z.B. als Lastenheft, Anforderungsliste, Requirement Dokument o.ä.), sollten diese Anforderungen in Testfälle (neudeutsch: Use Cases) umgemünzt werden. Diese können dann z.B. auch schon im Rahmen der Softwareauswahl verwendet werden. Mit diesen Use Cases lässt sich die Machbarkeit eruieren, sie bilden für den Proof of Concept eine gute Basis.
Dem Anbieter gegenüber kommunizieren
Testfälle sind auch für den Lösungsanbieter nützlich: So kann er die Erwartungshaltung des Kunden frühzeitig besser abschätzen und wird später nicht von Anforderungen überrascht, die eigentlich schon klar waren. Und selbstverständlich kann der Entwickler damit die erstellten Softwarefunktionen und –module optimal testen.
Qualitätsmanagement und Testen zum Auswahlkriterium machen
Gerade durch die zunehmende Entwicklung in Richtung „Agile Softwareentwicklung“ werden die Themen QM und Testen immer wichtiger. Durch sehr kurze Entwicklungszyklen in Sprints und entsprechend höherer Frequenz der Auslieferungen steigt die Gefahr schlecht getesteter Software. So kommt es immer wieder vor, dass im neuen Release Fehler, die schon längst als behoben galten, wieder auftreten.
Agile Entwicklung ist deshalb ohne ein intensiviertes Qualitätsmanagement auf Seiten des Lösungsanbieters und dem Einsatz von Testtools und –automatisierung auf Dauer nicht sinnvoll. In sehr vielen „agilen Projekten“ wird nach unserer Erfahrung das Testen einseitig auf den Kunden verlagert. Das führt zu Konflikten und Frust.
Genügend eigene Personalressourcen einplanen
Testen ist aufwändig und muss systematisch und nachhaltig erfolgen. Hiermit sind viele Kunden überfordert. Denn professionelles Testen erfordert ein spezifisches Know-how:
• Wie wird getestet?
• Wie erstellt man einen Testplan? Wie Testfälle und Testdaten?
• Welche Tests sind zu unterscheiden? Zu welchem Zeitpunkt sind sie sinnvoll?
• Wie sind Fehler sinnvoll zu dokumentieren?
Zeiten einhalten
Wenn es am Ende eines Projektes zeitlich eng wird, werden sehr häufig Testzeiträume zusammengestrichen. Das ist nicht zu empfehlen, weil dies unmittelbar die Einführungsrisiken erhöht. Eine nicht durchgetestete und noch nicht abgenommene Software einzuführen, ist grob fahrlässig und kann – wie viele Beispiele zeigen – zu massiven Problemen im Geschäftsablauf und Akzeptanzverlust bei den Anwendern führen.
Gut geführte Projekte erkennt man u.a. daran, dass für die Tests (insbesondere Integration und Lasttests) mind. 3 Monate nach Fertigstellung der eigentlichen Software zur Verfügung stehen. Zudem werden die Tests von einem Testteam, in dem nicht irgendwelche, sondern die besten Mitarbeiter tätig sind, strukturiert durchgeführt und dokumentiert.
Abnahmeprocedere verbindlich vereinbaren
Fehler beeinflussen auch die Abnahme, ohne die ein IT-System nicht produktiv gestaltet werden sollte. Das konkrete Abnahmeprocedere (Vorgehen, Fristen, Abnahmegremium, Abnahmekriterien (z.B. in Form von Fehlerklassen und zulässiger Anzahl) sind deshalb schon im Vertrag mit dem Lösungsanbieter konkret zu fixieren. Sonst wird ein Projekt schnell zur „Never ending Story“, was weder für den Kunden noch für den Anbieter sinnvoll ist, da Personalressourcen unnötig lange gebunden werden.
Testen ist also komplex, wird oft als lästig empfunden, ist aber für die erfolgreiche Einführung einer Softwarelösung besonders wichtig. Hierbei hilft eine neutrale Sicht und entsprechende Expertise, die Sie unbedingt nutzen sollten, um ansonsten unüberschaubare Risiken und Folgekosten zu vermeiden.
Schreibe einen Kommentar