Seite 2: Organisatorische Trennung

Inhaltsverzeichnis

Trennung und Kooperation

Die Einführung einer organisatorischen Trennung zwischen Entwicklung und Test verläuft erfahrungsgemäß nicht ohne Reibungspunkte. Es lassen sich dabei fünf Phasen unterscheiden – von der Ablehnung bis zur konstruktiven Zusammenarbeit:

1. Ausgangsphase

Dass jede Codezeile zu testen ist, weiß jeder Entwickler. Im Projektplan ist vermutlich auch ein Zeitslot für das Testen vorgesehen. Im Zweifel gehen die Entwurfs- und Codierarbeiten aber vor. Die Programme müssen fertig werden, und der Projektplan ist häufig knapp bemessen. Zudem ist der Reiz, Neues zu programmieren, verlockender, als den (fast) fertigen Code systematisch zu testen. Daher wird die Botschaft, Test und Entwicklung zu trennen, grundsätzlich positiv aufgenommen. Eine gewisse Skepsis darüber, ob die Trennung in der Praxis funktioniert, ist aber nicht zu übersehen: Wird der (neue) Tester in der Lage sein, "meine" Programme gut genug zu verstehen? Welche Fehler kann der Tester finden, wenn er nicht derart tief in der Materie steckt wie der Entwickler? Erzeugt das nicht eine Menge unnötige Bürokratie und Overhead durch Testpläne, Fehlerprotokolle und Testberichte? Will die Projektleitung Fehlerstatistiken einführen? Etwa zur Leistungskontrolle?

Das Management sollte der verständlichen Skepsis und Unsicherheit mit früher und offener Information begegnen: Wie wird die Arbeitsteilung genau aussehen? Welche Informationen benötigen die Tester, um wirkungsvoll arbeiten zu können? Wie werden Fehler dokumentiert? Wer wertet das aus? Welche Ergebnisse liefern die Tester? Wie helfen die Tester den Entwicklern, entdeckte Fehler schneller als bisher zu beheben?

2. Ablehnungsphase

Viel schneller als erwartet werden die neuen Tester bisher übersehene Fehler aufdecken, und zwar nicht nur Kleinigkeiten, sondern viele ernsthafte Fehler und Lücken oder Ungereimtheiten im Softwaredesign und in den Spezifikationen. Das ist neu und unangenehm für die betroffenen Entwickler. Sie empfinden jede Fehlermeldung schnell als Kritik an der eigenen Leistung. Sie reagieren in der Phase häufig ablehnend und versuchen, sich gegen vermeintliche Angriffe durch die Tester zur Wehr zu setzen. Jeder Tester kennt die empörten Kommentare über Fehlermeldungen nur allzu gut: "Auf meiner Maschine funktioniert das", "echte Anwender machen das nie so", "it's not a bug, it's a feature", "das Problem kenne ich schon lange, ich hatte nur keine Zeit mich darum zu kümmern".

Tester müssen in dieser Phase Fingerspitzengefühl beweisen: Sie haben Fehler zu finden und schonungslos aufzudecken, müssen dabei allerdings "Kleinigkeiten" von "relevanten" Fehlern sicher unterscheiden können – sonst erhalten sie als Sparringpartner fachlich keine Akzeptanz. Aber Tester dürfen nie persönliche Kritik üben, sondern müssen sachlich und objektiv bleiben. Dann verstehen alle Beteiligten schnell, dass ein gemeinsames Ziel verfolgt wird: gemeinsam ein Produkt in hoher Qualität abzuliefern.

3. Etablierungsphase

Das Testen wird nun immer mehr zu einem abgegrenzten Teilprozess der Softwareentwicklung. Die Tester arbeiten methodisch und können jederzeit begründen, welche Situationen sie getestet haben und welche nicht. Für Management und Entwickler wird sichtbar, wie gut oder schlecht die erreichte Testabdeckung tatsächlich ist. Fehlermeldungen werden in einem Fehlermanagement-Tool zentral dokumentiert, bewertet und verwaltet. Die berichteten Fehler bearbeiten die Entwickler routinemäßig, und die Tester prüfen das Ergebnis nach. Letztere bereiten die Testläufe rechtzeitig vor, damit ihr Feedback möglichst schnell und zeitnah nach der Lieferung korrigierter Softwarestände erfolgen kann. Durch die Kanalisierung und Priorisierung der Fehlermeldungen über das Fehlermanagement-Tool wird aus chaotischem Ad-hoc-Bugfixing ein geordneter, ruhiger Routineprozess. Entwickler und Tester können ihre Arbeit besser planen.

Das Fehlermanagement-Tool darf jedoch nicht das einzige Kommunikationsmittel zwischen den Entwicklern und Testern sein. Direkte Abstimmungen und eine adäquate Moderation durch ein kompetentes Fehler-Bewertungsgremium sind ebenfalls notwendig. Sonst besteht die Gefahr, dass ein Fehler-Pingpong zwischen beiden Seiten einsetzt – mit dem Ergebnis, dass einige Fehlermeldungen endlos zwischen den Parteien hin und her wechseln.

4. (Aus)nutzen des Testens zum eigenen Vorteil

Je wirksamer und umfassender die Tester arbeiten, desto mehr Vertrauen entsteht bei den Entwicklern, dass die Tester gute Arbeit leisten. Umgekehrt sehen die Tester, dass die Entwicklung reife und stabile Software an den Test liefert. Das Zusammenspiel kann gegen Projektende unter starkem Zeitdruck jedoch empfindlich gestört werden. In dieser Phase kann es vorkommen, dass sich einige Entwickler unbewusst – in manchen Fällen auch durchaus bewusst – zu sehr auf die nachfolgende Teststufe verlassen. Nach dem Motto: "da schaut ja der Tester ohnehin noch mal drauf", liefern sie neue Funktionen oder Bugfixes halbgar ab. Der Test wird durch solche nicht testreife Softwarestände unter Umständen stark behindert und gebremst.

Spätestens jetzt ist es an der Zeit, den nächsten Schritt zu gehen und innerhalb des Tests Teststufen abzugrenzen: den entwicklungsnahen Unit-Test, den Integrationstest und den Systemtest. In jeder Teststufe sind gewisse Fehlerarten einfacher und schneller zu finden. Die Testziele und Testaufgaben der Stufen lassen sich aufeinander abstimmen, und in jeder Stufe arbeiten spezialisierte Tester mit spezialisierten Testwerkzeugen und der passenden Testumgebung. Das erfordert gewisse Zusatzinvestitionen. Als Nutzen ergibt sich mittelfristig eine nochmalige Steigerung der Test-Produktivität. Denn die Produktfunktionen und die Fehlerrisiken werden insgesamt zeit- und kostenoptimal abgedeckt.

5. Konstruktive Zusammenarbeit

Im Softwareentwicklungsprozess gibt es etliche Themen, die sowohl für Entwickler als auch für Tester von hoher Relevanz sind. Beispiele hierfür sind das Anforderungsmanagement, Schätz- und Planungsverfahren, Metriken und Statistiken sowie Release- und Änderungsmanagement. Bei diesen Themen sitzen Tester und Entwickler im selben Boot. Wenn Tester gegenüber der Unternehmensführung beispielsweise die Konsequenzen unklarer Anforderungen für die Produktqualität verdeutlichen können und eine Verbesserung der Anforderungsqualität durchsetzen, dann profitieren auch die Entwickler davon. Wenn Entwickler im Unternehmen für ein regelmäßiges Konfigurationsmanagement der Entwicklungsdokumente sorgen, dann vereinfacht das auch das Management der Testpläne und Testfälle erheblich. Charakteristisch für diese Phase ist, dass Entwickler und Tester gemeinsam an kontinuierlicher Prozessverbesserung interessiert sind und sich gegenseitig stärken.

Bessere Ausbildung der Tester

Die bessere Organisation des Testens ist nur ein Baustein, der notwendig ist. Die Aus- und Weiterbildung der Tester gehört ebenfalls dazu. Unabhängig davon, nach welchem Organisationsmodell man die Aufgaben trennt und wer als Software-Tester Verantwortung übernimmt, muss jeder Einzelne sein Handwerkszeug gut beherrschen. Je besser die einschlägigen Testmethoden und Techniken trainiert sind, desto schneller und effizienter kann ein Tester arbeiten. Die wichtigsten dieser Techniken sind die Testentwurfsverfahren, die eine systematische Abdeckung von Fehlerrisiken ermöglichen. Sie bilden die Kernkompetenz eines Testers. Heute sind mehr als ein Dutzend grundlegende Testentwurfsverfahren mit vielen Varianten im Einsatz, die ein professioneller Tester beherrschen muss.

Um es auf den Punkt zu bringen: Ausgebildete Tester sind bessere Tester. Die Ausbildung zum Certified-Tester stellt sich dieser Aufgabe. Das International Software Testing Qualifications Board (ISTQB) definiert die Lehrpläne und Qualifizierungsverfahren für die Certified-Tester-Ausbildung, nationale Organisationen wie das German Testing Board (GTB) setzen sie in ihrem Gebiet um, akkreditieren Trainingsanbieter und überwachen die Prüfungen. Die strikte Trennung von Trainings- und Prüfungswesen ist dadurch gewährleistet. Zwei unabhängige Zertifizierungsinstitute, die Dienstleistungsgesellschaft für Informatik mbh und die iSQI GmbH, wickeln derzeit die Prüfungen in Deutschland ab. Mittlerweile wurden hierzulande über 17.000 Studenten und Arbeitnehmer zum Certified-Tester ausgebildet, weltweit durchliefen schon mehr als 155.000 Personen diese Zusatzausbildung.

Der Certified-Tester hat gerade in Branchen mit Systemen, die viel Software enthalten und Softwarefehler potenziell hohen Schaden anrichten können, hohes Renommee. Dazu gehören die Automobilindustrie, die Medizintechnik, die Luftfahrt und die Finanzbranche. Auch in öffentlichen Ausschreibungen wird zunehmend nach der ISTQB-Certified-Tester-Qualifikation gefragt.