Der optimale Testprozess

Wie sieht der optimale Testprozess aus? Genau so, wie es die Organisation gerade bzw. in naher Zukunft benötigt. Eine unbefriedigende Antwort, wenn man auf der Suche nach der einen Wahrheit bzw. dem Schema F zur Lösung aller Probleme ist.

Das Ausmaß und die Ausprägung des Testprozesses müssen sich immer an den Gegebenheiten in der Testorganisation und den Vorgaben der korrespondierenden Organisationen orientieren. Wie groß ist der Zeitrahmen eines Testprojektes? Wie etabliert ist das Testdepartment (so es denn existiert), um Forderungen nach Testbarkeit, frühe Einbindung in den Entwicklungsprozess, Ressourcen oder Prozessänderungen artikulieren und einfordern zu können? Sind die Rahmenbedingungen für die Einführung von Testautomatisierungen durch eine entsprechende Reife der zuliefernden Departments gegeben?

In Organisationen, deren Produkte einen Komplexitätssprung erleben, die gerade erst eine Testmentalität entwickeln oder sich im Umbruch befinden, ist die Zielstellung für den Test oft unscharf. Das Budget für den Test ist häufig implizit in einem Topf für Entwicklung versteckt, die Notwendigkeit der Entwicklung von Testprozessen ist außerhalb jedes Planungshorizontes.

Sollte nicht auf wundersame Weise ein Beschluss der Geschäftsführung massive Investitionen in die Qualitätssicherung auslösen, muss ein iterativer Prozess in Gang gesetzt werden. Die zentrale Frage dabei ist: Was sind die Anforderungen an den Test?

Die Anforderungen an den Testprozess leiten sich von den Anforderungen der Organisation ab und werden dabei in implizite und explizite unterschieden. Die Umsetzung von expliziten Anforderungen ist gut planbar. Sehr schwierig gestaltet sich jedoch das Erfüllen der impliziten, also unbekannten, Anforderungen. Um diese in explizite Anforderungen umzuwandeln, bedarf es zuerst einer Stakeholderanalyse.

Nur durch eine Analyse der Stakeholder, also der direkt oder indirekt vom Testprozess betroffenen Personen oder Organisationen, ihrer Identifikation und Klassifizierung, können deren Erwartungen an den Testprozess und seine Ergebnisse abgefragt werden. Auch hier handelt es sich um einen stetigen iterativen Prozess, da Stakeholder in verschiedenen Phasen eines Projektes unterschiedlich viel Einfluss haben bzw. beeinflusst werden.

Der verantwortliche Projekt- oder Testmanager muss nun die verschiedenen Anforderungen gewichten und seinen Prozess entsprechend ausrichten. Dadurch können auch dem Testfortschritt gegenläufige Aktionspunkte erwachsen. Es ist bspw. denkbar, dass der Projektsponsor mit dem gerade laufenden Projekt unter besonderer Beobachtung des Managements steht und deswegen ein tägliches Reporting einfordert. Daraus würde sich ein zusätzlicher Aufwand für die Erstellung tagesaktueller, aussagekräftiger Reports ableiten, der über das eigentlich zur Überwachung und Steuerung nötige Ausmaß weit hinausgehen kann. Ein anderes Beispiel sind unzureichende Kapazitäten des Produktmanagements bei der Erstellung der Requirements. Hier wäre es sinnvoll, verstärkt Ressourcen in das Verfeinern und in die Reviews der Requirements zu investieren.

Um den Testprozess den aktuellen Erfordernissen und Rahmenbedingungen bestmöglich anzupassen, bedarf es also einer zyklischen Betrachtung. Diese Neubewertung sollte nicht erst im Rahmen eines „lessons learned“-Meetings am Ende eines Projektes stattfinden. Vielmehr muss eine ständige Bereitschaft existieren, Vorgehensweisen und Machbarkeiten zu hinterfragen um die Testing Productivity andauernd zu optimieren.

Nur so kommt man zu einem optimalen Testprozess. Es ist ein Prozess, der einem ständigen Wandel unterliegt, um für aktuelle Erfordernisse das Optimum aus den verfügbaren Ressourcen herauszuholen.

Nie wieder einen Blogartikel verpassen >>> Zum Blog-Newsletter anmelden

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

neun + 17 =