Zu diesem Text inspirierte mich Jan Overbeck mit seinem Artikel „Widerstand gegen das Testen … und wie Tester ihm begegnen“ in der Juli-Ausgabe des ATB-Insider-Newsletters des Austrian Testingboards.
Wie kommen eigentlich die Bugs in die Software?
Statistisch gesehen machen selbst erfahrene Entwickler in etwa drei Fehler pro tausend Zeilen Code. Zieht man nun in Betracht, dass größere Anwendungen mehrere Hunderttausend, Betriebssysteme gar etliche Millionen Zeilen Code umfassen können, erscheint es naheliegend, dass sich darin (mindestens) Dutzende, wenn nicht Hunderte von gravierenden Fehlern befinden müssen.
Daher ist es so wichtig, Software ausführlich und methodisch zu testen. Das umfasst auch wieder- und weiterverwendeten Code sowie alle Bibliotheken, aus denen etwas übernommen wurde.
An einem Softwareentwicklungsprojekt sind zahlreiche Menschen beteiligt und dies i.d.R. in verschiedenen Rollen mit ganz unterschiedlicher Handlungsmotivation. Neben Entwicklern auch IT-Architekten, Projektleiter, Führungskräfte in Lenkungskreisen, Controller oder Fachanwender.
Das Testen von Software kann ihnen aus ganz unterschiedlichen Gründen quer kommen. Und so ist es mit Aufgabe des Testmanagers, diese Widerstände im Projekt aufzudecken und abzubauen, um so am Ende mit dazu beizutragen, dass durch das Projekt ein gutes und qualitätsgesichertes Ergebnis abgeliefert wird.
Entwickler sehen sich oftmals durch Tester bloßgestellt, wenn sie gefundene Fehler als eigene Fehlleistungen auffassen. Und das, obwohl Fehler oftmals auf unzureichend spezifizierte Anforderungen, Analysefehler, in der Softwarearchitektur übersehene Details oder Defekte in übernommenen Codeteilen zurückführbar sind. Außerdem macht das Streben nach innovativem und effektivem Arbeiten auch Freiräume zum Fehlermachen und Lernen erforderlich. Man muss nur sicherstellen, dass „zum Schluss auch aufgeräumt wird“ bevor das Produkt dem Kunden übergeben wird. Eine Aufgabe für Tester und Qualitätssicherer als festen Bestandteil im Team.
Anwender betrachten das Testen von Zwischenständen der Software oftmals als zusätzliche Belastung. Insbesondere, wenn sie sich diese Aufgabe zusätzlich und ohne geregeltes Zeitbudget neben ihren eigentlichen Aufgaben „eingefangen“ haben. Andererseits kommt man in Softwareentwicklungsprojekten nicht umhin, die fachlichen Wissensträger in die Testphase zu integrieren. Agile Vorgehensmodelle wie Scrum setzen eine (arbeits)intensive Beteiligung des Kunden am Projekt geradezu voraus. Das macht es erforderlich, die Testaufwände für die Fachtester zu kalkulieren und mit den Fachabteilungen zum Zwecke der vorausschauenden Kapazitätsplanung abzustimmen. Andererseits kann diese Aufgabe für die Fachtester auch eine Herausforderung sein. Sie werden dadurch zu ausgewählten Key-Usern, erhalten die Möglichkeit Aspekte ihres zukünftigen Arbeitsumfeldes mitzugestalten und können später u.U. ihren Wissensvorsprung als Referent im Rahmen innerbetrieblicher Schulungsprogramme weitergeben und sich so für höherwertige Aufgaben positionieren.
Projektleiter sind häufig mit den Unwägbarkeiten des Projektgeschäfts konfrontiert. Da werden zugesagte Mittel gekürzt oder gestrichen, Anforderungen geändert oder ohnehin zu knapp gesetzte Meilensteintermine noch weiter verengt. Gerne wird da auf „projektinterne Sparschweinchen“ zurückgegriffen, um mit der veränderten Lage klarzukommen. Darunter fallen alle im Prinzip disponiblen Positionen in der Projektplanung. Und dazu zählen meist auch Aufwände für Qualitätssicherungsmaßnahmen. Zumal der dafür zuständige Testmanager im Projekt ohnehin oft die A-Karte ziehen muss, wenn im Projekt-Jourfix alle Teilprojekte „grün“ melden, während die Tester als Ergebnis ihres Schaffens mit langen Bugreports aufzuwarten haben, die zu Meilensteinverzögerungen und „roten“ Teilprojektstatusmeldungen führen und so wirken, als hätten andere Projektbeteiligte Mist gebaut.
Dabei können Defizite in der Projektplanung bzgl. des Testens bereits sehr früh erkannt werden, wenn sich darin z.B. sinnfreie Aussagen wie „Wir testen bis zum Quartalsende“ oder „Wir testen bis das dafür vorgesehene Budget aufgebraucht ist“ finden. Eine OP wird auch nicht beendet, wenn ein bestimmter Zeitpunkt erreicht wurde, sondern wenn alles Notwendige getan, das Instrumentarium noch vollständig vorhanden und der Patient wieder zugenäht ist.
Testen ist eben keine disponierbare Größe im Kampf gegen projektierte Budget- und Terminprobleme. Zahlreiche langwierige juristische Konflikte im Nachgang gescheiterter oder zumindest nicht plangemäß gelaufener Projekte ihren Ursprung meist im Verstoß gegen diese Regel haben. Die Historie staatlicher IT-Großprojekte wie dem Autobahn-Mautsystem Toll-Collect, der elektronischen Krankenkassenkarte oder dem digitalen Polizeifunk zeigt das ganz deutlich.
Führungskräfte in Lenkungskreisen sehen Testen oftmals nicht als integralen Bestandteil des Softwareentwicklungsprozesses sondern als eine Art überflüssigen Extraaufwand, den man am besten vermeidet, indem man einfach keine Fehler macht. Kein Witz – diese Art der Inkompetenz ist einer der Gründe dafür, dass man in der produzierenden Industrie im Laufe der Zeit dazu übergegangen ist, Aufgaben, die fundierte Kenntnisse in der Methodik des Qualitätsmanagements erfordern, mit Personen zu besetzen die etwas Einschlägiges gelernt oder studiert haben. Dieser Teil der Industrialisierung der Softwareentwicklung wurde allerdings im Bereich der IT noch nicht vollständig nachvollzogen, da er mit Kosten verbunden ist, die zunächst nur indirekt und eher schwer messbar darzustellen sind und keinen ihnen direkt zurechenbaren return-on-invest bringen.
Auch wenn der Druck hinsichtlich Qualitätsfragen über Normungs-, Zertifizierungs- und Compliance-Anforderungen gerade aus hochregulierten Branchen wie der Finanzwirtschaft, dem Gesundheitswesen, der Luft- und Raumfahrt oder der Energieversorgung immer mehr zunimmt. Also aus den Bereichen, die für einen Großteil der Aufträge an IT-Systemhäuser verantwortlich sind.
Fehlertoleranz und organisationale Lernprozesse sind für alle Beteiligte eines Softwareentwicklungsprojekts wichtig. Ermöglichen sie es doch, die Kommunikation an der oft heikelsten Stelle im Projekt zu verbessern: Am Austausch zwischen den fachlichen technischen Experten sowie mit den Stakeholdern des Projekts.
Auf Dauer wird dies einen Beitrag zu besserer und sicherer Software leisten, so wie auch andere Produkte des täglichen Bedarfs auf diese Weise verbessert wurden.
