Geeignete Organisation von Testprozessen und professionelle Qualifikation der Tester

Fehlerhafte Software kann für Unternehmen große wirtschaftliche Schäden und hohe Unzufriedenheit bei Kunden zur Folge haben. Um das zu vermeiden, braucht Software bessere Tester.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 13 Min.
Von
  • Matthias Hamburg
  • Tilo Linz
Inhaltsverzeichnis

Fehlerhafte Software kann große wirtschaftliche Schäden und hohe Unzufriedenheit der Kunden zur Folge haben. Um das zu vermeiden, braucht Software bessere Tester.

In der Softwareentwicklung haben sich in den vergangenen Jahren viele konstruktive Techniken durchgesetzt, die dazu beitragen, die Programmierung zu erleichtern und fehlerärmer zu machen: beispielsweise der systematische Architekturentwurf in UML, die damit einhergehende Nutzung bewährter Entwurfsmuster (Design Pattern) und die anschließende Implementierung der Programme in moderne objektorientierte Programmiersprachen. Die Techniken erlauben die systematische Wiederverwendung von Teillösungen und verbessern die Modularisierung der Software. Das erhöht nicht nur deutlich die Produktivität der Entwickler, sondern auch die Qualität der Systeme. Allerdings ist es grundsätzlich unmöglich, allein durch solche Maßnahmen zuverlässig zu vermeiden, dass die Software Programmierfehler, Designfehler oder Fehler durch falsch erhobene, falsch verstandene oder vergessene Anforderungen enthält.

Das Ziel muss daher sein, Fehler effektiver aufzufinden, bevor sie (im produktiven System) Schaden anrichten können. Mit anderen Worten: Unternehmen, die Software erstellen oder in ihre Produkte integrieren, müssen zielgerichteter, wirksamer und produktiver testen als bisher. Die gute Nachricht ist: Es lässt sich mit organisatorischen und ausbildungsorientierten Maßnahmen viel erreichen.

Der Schlüssel für ein wirksames Testen liegt darin, die Programmierung und das Testen organisatorisch so gut und so früh wie möglich voneinander zu trennen. Fünf Organisationsmodelle sind in dem Zusammenhang denkbar:

  1. Die Softwaretests liegen weiter in der Verantwortlichkeit des Entwicklungsteams, die sich jedoch "gegenseitig" testen. Ein Entwickler testet also die Programme eines Kollegen, aber nicht die eigenen.
  2. Einzelne Mitglieder des Entwicklerteams werden ausschließlich für Testarbeiten abgestellt. Diese Tester erledigen alle Testarbeiten ihres Teams.
  3. Ein separates Testteam bekommt die Testaufgaben für die Dauer des Entwicklungsprojekts übertragen. Das Team wird von einem Testmanager geleitet. Auch Mitarbeiter aus Fach- und IT-Abteilung arbeiten als unabhängige Tester in diesem Team mit.
  4. Für spezielle Aufgaben wie das Testen von Performanz, Benutzbarkeit oder Sicherheit werden zeitweise unabhängige Tester beauftragt.
  5. Eine separate Organisationseinheit (interne Testabteilung/Test-Center oder ein externer Testdienstleister) übernimmt das Testen oder wesentliche Teile davon, etwa den Systemtest. Diese Organisationseinheit ist als Dienstleister für mehrere Projekte oder Produkte zuständig.

Die Maßnahmen ergänzen sich beziehungsweise bauen aufeinander auf. Es ist nicht notwendig, alle Maßnahmen von Beginn an gleichzeitig einzuführen. Man kann die Maßnahmen schrittweise umsetzen und miteinander kombinieren. Das Prinzip ist jedoch immer das Gleiche: Man trennt Test- und Entwicklungsaufgaben personell, um zu erreichen, dass Annahmen, Gedankenmodelle und versteckte Voraussetzungen, die die Programmierer getroffen oder verwendet haben, kritisch hinterfragt werden. Das alleine macht das Testen schon wesentlich wirksamer. Dass die auf das Testen spezialisierten Personen oder Teams Routine bekommen und die relevanten Testmethoden zunehmend besser kennen und beherrschen, erhöht zudem die Produktivität.

Die personelle Trennung erhöht jedoch den Bedarf an Dokumentation – von den Testfällen bis zu den Testergebnissen. Aber das ist kein Nachteil, im Gegenteil: Denn nur wer aufschreibt, was man testet, kann erkennen, welche Regionen der Software (noch) nicht ausreichend getestet wurden und welche Risiken für unentdeckte Fehler deshalb noch schlummern.