Skip to main content
main-content

Über dieses Buch

Dieses Praxisbuch soll ein Handwerkszeug für Testmanager von Software-Implementierungsprojekten sein. Es richtet sich zudem an Projektleiter und alle, die sich mit dem Thema Testmanagement auseinandersetzen wollen oder müssen.

Die Autoren haben oft festgestellt, dass in Projekten viele Vorgaben zum Testmanagement existieren, die praxisfern sind und zudem nur mit viel bürokratischem Aufwand umgesetzt werden können. Die Energie wird so oftmals in die Umsetzung eines komplexen Rahmenwerks gesteckt, ohne einen quantifizierbaren Nutzen zu stiften.

Hier setzt dieses Buch an. Mit Fokussierung auf das Wesentliche, was für eine erfolgreiche Umsetzung eines Testvorhabens relevant ist, soll es auch als Sparringspartner dienen und dem Testmanager bei seiner Standortbestimmung Hilfe und Unterstützung geben sowie Denkanstöße auslösen.

Der Aufbau dieses Buches orientiert sich am Lebenszyklus eines klassischen Projektes (V-Modell / Wasserfall-Modell). Der Praxisbezug wird von den Autoren anhand eines fiktiven Projektes hergestellt, welches mit tatsächlichen Erfahrungen ergänzt wird.

Inhaltsverzeichnis

Frontmatter

Die Vorbereitung

Frontmatter

1. Das Testmanagement und die Rolle des Testmanagers

Zusammenfassung
Das Testen wird in der Praxis oft als ungeliebte Pflichtveranstaltung empfunden, die aufwendig ist und deshalb viel Geld kostet. Darüber hinaus ist für viele Projektteilnehmer der Nutzen wenig bis gar nicht transparent. In diesem Lichte wird auch die Rolle des Testmanagers gesehen – er wird benötigt, ist jedoch hauptsächlich unbequem. Er stellt häufig unangenehme und kritische Fragen zur Realität, weil er das Projekt möglichst vollumfänglich verstehen möchte. Dieses Vorgehen findet nicht in jeder Projektorganisation Zuspruch, und dadurch erhält der Testmanager oft wenig Wertschätzung. Dass ein gut durchgeführter Test direkten Einfluss auf die spätere Qualität im Produktionsbetrieb hat und im Gegenzug hohe Folgekosten drohen, falls der Qualitätsstand nicht hoch ist, wird oftmals unterschätzt oder ignoriert.
Oliver Droste, Christina Merz

2. Das Projekt verstehen

Zusammenfassung
Das Projekt, in dessen Rahmen ein Testmanager arbeitet, bildet die Grundlage für all seine Handlungen. Es führt also kein Weg daran vorbei, das Projekt kennen zu lernen, also alle Grundlagen des Projektmanagements, die für das Testen von Bedeutung sind. Dazu zählen:
  • der Projektsteckbrief
  • die Umfeldanalyse
  • die Projektziele
  • der Phasenplan
  • die Projektorganisation
  • das Stakeholdermanagement
  • der Projektstrukturplan
  • das Risikomanagement
Folgen wir der Theorie des Projektmanagements (Wir orientieren uns am Projektmanagement-Standard der GPM [Deutsche Gesellschaft für Projektmanagement e. V.]. Auf formale Definitionen der verwendeten Projektmanagement-Begriffe verzichten wir jedoch bewusst), so sollte für die oben genannten Punkte jeweils eine klare Dokumentation existieren. In der Realität ist das allerdings selten der Fall. Wir wollen an dieser Stelle trotzdem idealtypisch beschreiben, welche Dokumente und Artefakte (Unter einem Artefakt verstehen wir ein Produkt, das als Zwischen- oder Endergebnis entsteht) wir wie nutzen würden. Falls ein Artefakt nicht vorhanden ist, so wird es schwieriger, das Projekt zu verstehen. Um diese Wissenslücke zu schließen, ist es sinnvoll, sich selbst eine Übersicht mit dem passenden Abstraktionsgrad zu erarbeiten. Der Testmanager kann alternativ dazu versuchen, das fehlende Artefakt im Laufe des Projektes vom Projektmanagement nachgeliefert zu bekommen.
Das hört sich nach viel Arbeit an und das ist es auch. Doch nur wer das Projekt in seinem Aufsatz verstanden hat, kann das eingebettete Testprojekt gut managen. Der Einsatz an dieser Stelle zahlt sich außerdem in anderer Form aus. Durch die initiale Recherchearbeit werden wertvolle Kontakte zu wichtigen Personen im Projekt geknüpft. Die Chance dabei kooperative Beziehungen zu etablieren, sollte sich kein Testmanager entgehen lassen.
Oliver Droste, Christina Merz

3. Das Qualitätsmanagement

Zusammenfassung
Wenn die gewünschte Funktionalität eines Lieferobjektes zu einem bestimmten Zeitpunkt gewährleistet werden kann, ist ein hoher Qualitätsstand erreicht. Doch wie erreicht man dies? Es empfiehlt sich eine enge Verzahnung der Bereiche Test- und Qualitätsmanagement, wie sie auch (langsam) in der Projektwelt anzutreffen ist, um eine Systemeinführung ohne große Reibungsverluste zu ermöglichen. Je nach Projektgröße ist es sinnvoll einen dedizierten Qualitätsmanager zu installieren, sollte der Testmanager diese Aufgabe nicht zusätzlich erbringen können. Eine kontinuierliche Abstimmung der Maßnahmen zur Qualitätssicherung und der Testaktivitäten führt darüber hinaus dazu, dass die Projektleitung besser mit Informationen versorgt wird. Gleichzeitig wird damit ein geordneter Projektverlauf gewährleistet und eine „qualitätsgesicherte“ Entscheidungsfindung unterstützt. Mögliche Risikosituationen werden somit frühzeitig transparent gemacht, rechtzeitig eskaliert und eliminiert. In vielen Projekten erfolgt dies jedoch nur schleppend.
Ein Qualitätsmanager ist für die Sicherstellung einheitlicher Definitionen, die Dokumentationen und die Einhaltung von definierten Qualitätsstandards und -kriterien verantwortlich. Ist beispielsweise die Qualität der Anforderungsdokumente mangelhaft, so kann über die Qualität der Testergebnisse nur sehr schwer eine seriöse Aussage getroffen werden. Möglicherweise wird aus diesem Grund am Ziel vorbei getestet, was sich in der Produktion rächen wird, etwa dadurch, dass die Produktion mit erheblichen Verzögerungen startet.
Generell muss in Qualität „investiert“ werden, um Qualität zu erreichen, zum Beispiel durch ausreichend Projektzeit. Hundertprozentige Qualität zu erreichen, ist unrealistisch und ein solcher Perfektionismus entspricht auch nicht dem Realismus und Pragmatismus im Projekt. Deshalb ist es ratsam, einen harten Cut bei gefühlten 90 bis 95 % des Qualitätserreichungsgrad zu machen. In der Praxis wird die Qualität gerne anderen Zielen geopfert. Zwar wird sie häufig gezielt erwähnt, um einen Qualitätsanspruch nach außen zu demonstrieren, der aber innen nicht gelebt wird. Testphasen werden beschnitten, um Verzögerungen im Projektverlauf auszugleichen. Oder es werden aus Budgetgründen Aufwände im Test reduziert. Auch an der Bereitstellung einer tragfähigen Testumgebung mit ausreichenden Testdaten wird gerne gespart. Einer der Gründe dafür ist, dass Qualität schwer greifbar zu sein scheint – zumindest schwerer als ein Meilenstein, der Funktionsumfang oder die Kosten.
In den folgenden Abschnitten erklären wir, was wir unter Qualität im Rahmen des Testmanagements verstehen. Und wie ein Testmanager Qualität in den Testprozess bekommt. Um dieses Ziel zu erreichen, ist ein Grundverständnis zum Thema Qualität innerhalb Organisation beziehungsweise der übergeordnete Einsatz eines Qualitätsmanagements für das Projekt unabdingbar. Damit kann erreicht werden, dass es generell den Anspruch gibt, Qualität zu liefern – und dies auch gelebt wird. Das Qualitätsmanagement umfasst noch weitere Aspekte zum Beispiel aus vorgelagerten Projektphasen, wie der Entwicklung, die hier jedoch nicht weiter betrachtet werden.
Oliver Droste, Christina Merz

4. Der Projektgegenstand und seine Umgebung

Zusammenfassung
In einem Software-Implementierungsprojekt hat der Testmanager das Ziel, fehlerfreie Software in Betrieb zu nehmen, die ihren Anforderungen entspricht. Es liegt auf der Hand, dass sich der Testmanager dazu mit der Software, die erstellt oder angepasst werden soll, intensiv beschäftigen muss. Doch das alleine genügt aus unserer Sicht nicht. Denn:
  • Software dient den Zielen eines übergeordneten Geschäftsmodells
  • Software ist eingebettet in eine bestehende technische Umgebung
  • Software ist selten alleiniger Projektgegenstand
  • Software soll Menschen helfen
Ein Testmanager muss sich daher auch Wissen über die Organisation und deren Geschäftsmodell aneignen, über deren technische Umgebung und über alle Lieferobjekte, die Gegenstand des Projektes sind. Außerdem muss er die Nutzer des Projektgegenstandes verstehen lernen. Denn schließlich soll Software ihnen helfen, ihre Aufgaben zu bewältigen – ansonsten würde sie ihren Zweck verfehlen. Aus unserer Erfahrung genügt es, wenn sich ein Testmanager dabei eine grundlegende Orientierung verschafft. Er muss den Gesamtkontext so weit durchdrungen haben, dass er in Gesprächen mit dem Projektmanagement, dem Business und der IT folgen kann. Wenn ein Testmanager in solchen Gesprächsrunden Fragen stellen kann, deren Klärung für die Beteiligten relevant ist, dann hat er den richtigen Kenntnisstand. Dann ist er in der Lage risiko- und wertorientiert zu handeln. Sich Detailwissen in den Domänen anderer anzueignen, ist dagegen nicht notwendig, vielleicht sogar hinderlich.
Im folgenden Kapitel wollen wir die oben genannten Punkte beleuchten. Wir schlagen vor, welches Wissen sich ein Testmanager in einem Software-Implementierungsprojekt erarbeiten sollte und mit welchen Visualisierungsmöglichkeiten er arbeiten kann. Dabei greifen wir zur Beschreibung des Geschäftsmodells auf das bekannte Business Model Canvas zurück. Um die technische Umgebung zu visualisieren, schlagen wir ein Systemkontextdiagramm vor. Zusätzlich nutzen wir zur Beschreibung des Projektgegenstandes eigene Kategorien, die auf unseren Erfahrungen basieren.
Oliver Droste, Christina Merz

5. Die vorbereitenden Planungsaufgaben des Testmanagers

Zusammenfassung
Die Testplanung bildet die Basis für alle anstehenden Testaktivitäten und ist die Grundlage für die zu liefernde Qualität. Die Herausforderung dabei ist, die wesentlichen Aspekte zu erkennen, anstatt in Details abzutauchen. Durch die Kenntnis aller Rahmenbedingungen und Vorgaben muss der Testmanager in der Lage sein, potenzielle Risiken zu identifizieren und diese zu verhindern. Ziel ist es, die Transformation von der Theorie in die Praxis möglichst praktikabel zu gestalten. Wichtig ist uns hier der Begriff „praktikabel“. Denn es kann schnell passieren, dass mit einer Testplanung zwar ein hohes Qualitätsniveau angestrebt wird, der Plan selbst aber nicht umsetzbar ist.
Auch in der Vorbereitungsphase ist der Testmanager auf die Offenheit und Kooperationsbereitschaft der handelnden Akteure (unter anderem Stakeholder, Projektleitung, Fachbereich, IT) angewiesen. Sind Kooperation und Kommunikation in der Testplanungsphase nicht ausreichend gegeben, führt das zu Qualitätsmängeln in der Umsetzung bis hin zu einer Verzögerung oder Verhinderung des Go-Lives.
Oliver Droste, Christina Merz

6. Das Testkonzept

Zusammenfassung
„In der Kürze liegt die Würze!“
Nach diesem Motto sollte der Testmanager bei der Anfertigung des Testkonzeptes streben. Wahrscheinlich wird er allerdings viel Zeit damit verbringen, bereits existierende Rahmenwerke zu sichten und auf seine (Test-) Bedürfnisse hin anzupassen. Hier kommt es darauf an, ob das Projektumfeld und die Vorgaben der Organisation es zulassen, vorgegebene Standards als Leitplanken zu sehen oder aber als eine strikte Vorgabe. Da das Testkonzept ein klassischer Prüfpunkt bei Projekt-Reviews ist, soll es verständlich geschrieben sein, sodass auch Außenstehende (unter anderem interne und externe Prüfer) in der Lage sind sich zu orientieren.
Oliver Droste, Christina Merz

7. Die Metriken

Zusammenfassung
Es gibt in der Theorie zahlreiche Metriken auf Basis einer quantitativen Auswertung. Doch welche davon sind für die Praxis relevant und wertvoll? Viele Metriken dienen ausschließlich dazu, potenzielle Risiken im Rahmen des Projektmanagements zu quantifizieren, die jedoch keine verlässliche Aussage zu möglichen Risiken eines Testprojektes liefern. Erfahrungsgemäß reicht eine Hand voll Metriken, um ein Testprojekt zum Erfolg zu führen. Die Größe eines Projektes, das heißt die Anzahl der involvierten Personen oder der Umfang von Teilprojekten, ist hiervon fast unabhängig, da die Basis der Erhebung gleich ist. Bei Großprojekten müssen die gegenseitigen Abhängigkeiten der jeweiligen Teilprojekte herausgearbeitet werden.
Metriken dienen nicht ausschließlich der Feststellung eines Status. Auch Prognosen und Trends lassen sich mit Metriken erheben. Der Testmanager muss in der Lage sein, für sein Testprojekt die geeigneten Metriken auszuwählen – und zu verteidigen! Das setzt voraus, dass der Testmanager die Metriken kennt und eine Einschätzung vornehmen kann, welche davon am geeignetsten sind. Generell müssen Metriken in der Anzahl überschaubar und vor allem begreifbar sein.
Oliver Droste, Christina Merz

Die Umsetzung

Frontmatter

8. Die Transformation des Testkonzeptes

Zusammenfassung
Der Testmanager muss in seiner Rolle von den übrigen Projektmitgliedern als ein Schlüssel zum Erfolg gesehen werden. Dies setzt voraus, dass er bereits zu Beginn in die Projektkommunikation eingebunden wird und dass er auch nach seiner Meinung oder seiner Einschätzung gefragt wird. Dies wiederum setzt voraus, dass in dem gesamten Projekt offen kommuniziert wird.
Eine transparente Kommunikation des geplanten Testvorgehens sowie die rechtzeitige Einbindung des Testmanagers sind wichtige Bausteine, damit alle Projektbeteiligte auf dem gleichen Stand bezüglich der Testaktivitäten sind. Der Testmanager sollte in der Lage sein, das Testvorhaben im Rahmen einer kurzen Präsentation mit einem groben Zeitplan vorzustellen. Offene Fragen sollten lieber im Vorfeld geklärt werden und nicht während der Testaktivitäten.
Es ist wichtig, viel Zeit und Energie in eine gute Vorbereitung zu investieren, Doch erst in der entscheidenden Phase, der Umsetzung, zeigt sich, ob alle Vorbereitungen, Planungen und Abstimmungen des Testmanagers mit den Projektbeteiligten auch dazu führen, dass tatsächlich mit dem Testen begonnen werden kann. Durch das Testkonzept verfügt der Testmanager über ein „Kochbuch“, mit dessen Hilfe er seine geplanten Aktivitäten in Verbindung mit dem Test- und Projektplan umsetzen kann. Auch in der Umsetzungsphase ist die Kommunikation zu allen Projektbeteiligten ein wichtiger Erfolgsfaktor. Darüber hinaus muss der Testmanager die Erwartungen aller Stakeholder ständig im Blick haben, um den Testprozess gut starten und im Verlauf möglichst reibungslos managen zu können.
Oliver Droste, Christina Merz

9. Aus Anforderungen Testfälle erstellen

Zusammenfassung
Die Anforderungen bilden die Basis für den Großteil aller Testaktivitäten. Sie sind somit das Öl im Getriebe des Testens. Um jedoch am Ende das Lieferobjekt in guter Qualität abliefern zu können, müssen die Anforderungen in guter Qualität vorliegen. Das setzt qualitätssichernde Maßnahmen voraus, die idealerweise von einem Anforderungsmanager durchgeführt worden sind. Je nach Projektgröße kann auch der Testmanager das Anforderungsmanagement übernehmen. In diesem Fall könnte er selbst Einfluss auf die Qualität der Anforderungen nehmen. Der Testmanager hat dafür zu sorgen, dass dem Tester alle für die Testfallerstellung notwendigen Informationen vorliegen. Ist dies nicht der Fall, muss der Testmanager gemeinsam mit dem Tester klären, was fehlt und wo und wie die Informationen beschafft werden können. Eine Qualitätssicherung der Testfälle sollte vom Tester gemeinsam mit Vertreten des Fachbereichs auf Basis der Kommunikationsmatrix (siehe auch die Erfahrungsbox in Abschn. 1.2) durchgeführt werden.
Oliver Droste, Christina Merz

10. Der Teststart

Zusammenfassung
Der Teststart ist kein Termin, sondern ein schleichender Prozess, der sich aus der Kommunikation mit der Entwicklungsabteilung ergibt. Maßgeblich hierbei ist der Fertigstellungsgrad der Entwicklung jedes Testobjekts. Wie wird der Fertigstellungsgrad bewertet? Wir können uns natürlich auf die Aussagen der Entwicklung verlassen. Andererseits haben wir genau dazu Testeingangskriterien festgelegt.
Beim Teststart kann man vieles falsch machen. Zum ersten Mal ist der Testmanager kein „Papiertiger“ mehr, der Konzepte erstellt und das Testvorhaben dokumentiert, sondern tritt wirklich in Aktion. Eine gute Performance beim Teststart ist nur möglich, wenn im Vorfeld sorgfältig geplant und viel Wert auf das Stakeholdermanagement gelegt wurde. Davon müssen wir nun beim Teststart zehren.
Oliver Droste, Christina Merz

11. Das Defect-Management

Zusammenfassung
Welche Rolle spielt eigentlich der Testmanager im Defect-Management? In erster Linie fungiert er als Dienstleister für die Teams unserer „drei Amigos“ aus Entwicklung, Fachbereich und Test. Er analysiert die Gesamtfehlersituation und leitet daraus den Status der Testaktivitäten ab.
Ein gut aufgesetztes Defect-Management, auch Abweichungsmanagement genannt, ist ein zentraler Baustein der Testaktivitäten. Es ist auch wichtig für das Qualitätsmanagement, das für eine kontinuierliche Verbesserung des Lieferobjektes sorgt. Zugleich liefert das Defect-Management Ergebnisse und damit Aussagen über die Qualität der Entwicklung. Sind zu viele kritische Defects vorhanden, die einen Go-Live verhindern, muss das Management die Entscheidung treffen, ob das Risiko trotzdem eingegangen wird oder ob Bestandteile des Lieferobjektes reduziert werden müssen (Descoping), um das Gesamtprojekt nicht zu gefährden. Die Grundlage für diese kritischen Entscheidungen liefert der Testmanager unter Berücksichtigung der Defect-Situation. Das setzt voraus, dass das Defect-Management dem Testmanager verlässliche Informationen liefert.
Oliver Droste, Christina Merz

12. Das Informations- und Berichtswesen

Zusammenfassung
Es gibt bei Kunden häufig sehr strikte Vorgaben zum Informations- und Berichtswesen, die möglichst eingehalten werden sollten. Der Testmanager sollte in der Lage sein, die Berichtsvorschläge, die er im Testkonzept formuliert hat, auch in der Praxis umzusetzen. Er sollte seiner Linie treu bleiben und keine wesentlichen Anpassungen des bereits abgenommenen Berichtswesens zulassen. Nur so ist er in der Lage, im Projektverlauf im Spannungsfeld zwischen Testverlauf, Fehlersituation und näher rückendem Zieltermin gegenüber dem Management souverän zu agieren. Er sollte genügend Freiräume haben, seine praxiserprobten Berichte mit dem Projektmanagement abzustimmen und diese auch einsetzen zu dürfen.
Der Testmanager muss dafür sorgen, dass alle Testaktivitäten offen kommuniziert werden, dass keine Testergebnisse kaschiert werden oder es andere „alternative“ Darstellungsformen gibt. Es ist davon abzuraten, auf Wunsch des Managements spezielle Reports zu erstellen. Dies ist meist sehr zeitaufwendig und liefert oft keinen Mehrwert an Informationen. Außerdem reichen die Datenmengen für ein neu aufgesetztes Reporting oft nicht aus, um dem Management umgehend verlässliche Informationen liefern zu können. Der Testmanager muss ein gutes Erwartungsmanagement betreiben, damit die Projektmitglieder wissen, wann sie die Reports zur Verfügung gestellt bekommen. Anhand der aufgelaufenen Datenmengen sollte abgewogen werden, ob es sinnvoll ist zu berichten oder nicht, denn manche ausgewählte Metriken funktionieren nur mit einem ausreichenden Datenbestand. Grundsätzlich sind festgelegte Berichtszyklen einzuhalten, damit eine kontinuierliche Berichterstattung etabliert wird, die im Projektverlauf ein wichtiger Vertrauensfaktor ist. Auch interne und externe Prüfungen verlaufen reibungsloser, wenn ein stabiles und aussagekräftiges Berichtswesen vom Testmanager vorgewiesen werden kann.
Oliver Droste, Christina Merz

Der Abschluss

Frontmatter

13. Das Testende

Zusammenfassung
Endlich haben wir es geschafft! Die Testaktivitäten gehen dem Ende zu. Eine Auswahl von Nutzern, die künftig mit dem System arbeiten, müssen im Rahmen des User-Acceptance-Test (UAT) ihre finale Freigabe erteilen und damit das System abnehmen. Das Testende ist eine der heißesten Phasen im Projektverlauf. Jetzt zeigt sich, ob durch das Testen unter anderem die entsprechende Qualität in das Lieferobjekt gebracht werden konnte, um nun auch tatsächlich Live gehen zu können. Ist das nicht der Fall, muss über Workarounds gesprochen werden oder über ein Descoping, also einer Reduzierung des Lieferumfangs. Dies gilt aber nur, wenn der Zeitpunkt für den Go-Live gesetzt ist und nicht verschoben werden kann.
Bevor jedoch tatsächlich Live gegangen werden kann, müssen noch zahlreiche Freigabeprozeduren durchlaufen werden, die sehr zeitraubend sein können. Es ist deshalb nicht möglich, bis zum letzten Tag vor dem Live-Gang zu testen. Für die Freigaben und Abstimmungen mit dem Deployment- und Release-Management ist immer ein entsprechender zeitlicher Puffer einzuplanen.
Parallel sind auch Regressionstests und mögliche Testautomatisationen zu identifizieren und zu etablieren. Wird die Testinfrastruktur bis auf Weiteres nicht mehr benötigt, ist ihr Rückbau zu organisieren. Im Anschluss sollte eine Lessons Learned durchgeführt werden, um den Testablauf zu verbessern und aus den Fehlern, die diesmal gemacht wurden, lernen zu können. Ebenso ist der Know-how-Transfer sicherzustellen, damit das operative Business-Team in der Lage ist, den Geschäftsbetrieb nach dem Go-Live aufrechtzuerhalten. Hierzu dient eine Stabilisierungsphase direkt nach dem Go-Live.
Nicht zu vergessen ist die Party mit dem gesamten Projektteam und den Stakeholdern, wenn die größten Herausforderungen nach einem erfolgreichen Go-Live gemeistert worden sind. Ein kleiner Umtrunk im Testteam ist vorab natürlich auch denkbar.
Oliver Droste, Christina Merz

14. Post Go-Live Testaktivitäten

Zusammenfassung
Auch wenn der Go-Live gut vorbereitet war und gut durchgeführt worden ist, wird es im Anschluss noch weitere Testaktivitäten geben. Das kann daran liegen, dass während der Stabilisierungsphase oder dem Auflösen von Workarounds Fehler in Produktion gefunden wurden. Diese Testaktivitäten sollten rechtzeitig, also bereits vor dem Go-Live, geplant und mit geeigneten Testressourcen ausgestattet werden.
Oliver Droste, Christina Merz

Was haben wir gelernt

Frontmatter

15. Die Kommunikation

Zusammenfassung
Unsere Erfahrung zeigt, dass nach Projektende im Rahmen vom Lessons Learnd am meisten die mangelnde Kommunikation kritisiert wird. Es ist schon erstaunlich, schließlich ist Kommunikation ja allgegenwärtig – aber leider oft in der Form von Nicht-Kommunikation. Die Dinge, die viele Projektteilnehmer aus Erfahrung immer als sehr wichtig erachten, werden in der Praxis nicht oder nur sehr eingeschränkt gelebt. Der Vorsatz kann noch so gut sein, die alten Verhaltensmuster sind stärker. Doch woran liegt das?
In Teil I haben wir viel über Werte und das damit einhergehende Vertrauen gesprochen, das vorhanden sein muss, damit eine Gruppe erfolgreich arbeiten kann. Ist dieses Grundvertrauen nicht oder nur sehr eingeschränkt vorhanden, so kann keine offene und ehrliche Kommunikation stattfinden. Der Vertrauensverlust führt zu Abwehrhaltungen und Reduktion der Kommunikation auf ein notwendiges Minimum.
Auch eine schlecht ausgeprägte Konfliktkultur kann zum Verlust des Grundvertrauens führen und damit zu erheblichen Einschränkungen in der Kommunikation. Anstatt einen Konflikt offen und ehrlich auszutragen, wird lieber geschwiegen. Oft werden politische Aspekte ins Feld geführt, die von Macht, Karrierestreben, Profilierung und autoritärem Verhalten geprägt sind.
Doch wie etabliert man eine adäquate Kommunikation? Wir haben gelernt, dass gemeinsam mit allen Projektbeteiligten zu Projektbeginn ein einheitliches Verständnis von den Projektzielen und den dazugehörigen Werten erarbeitet werden muss. Im Anschluss müssen allen Projektmitgliedern die Ergebnisse transparent gemacht werden. Insbesondere müssen die Ergebnisse auch von den Stakeholdern akzeptiert, getragen und vor allem auch gelebt werden. So wird ein Grundgerüst an vertrauensbildenden Maßnahmen etabliert, was dabei hilft, Konflikte lösungsorientiert anzugehen und konstruktiv zu kommunizieren. Ist dies aufgrund der Projektstruktur oder der Akteure nicht möglich, ist zu prüfen, welche kommunikationsfördernden Maßnahmen ergriffen werden können. Diese können ein Einzel- oder Gruppen-Coaching sein, die Vermittlung von Kommunikationsmethoden- und Arten oder auch Konfliktmanagement-Schulungen.
Oliver Droste, Christina Merz

16. Die Qualität

Zusammenfassung
Was bedeutet eigentliche Qualität? Und wie kann ich Qualität liefern? Um Qualität liefern zu können, ist ein Qualitätsbewusstsein erforderlich. Daran scheitert es oft schon bei sehr vielen Projektvorhaben. Doch wie entsteht eigentlich Qualität? Qualität kommt vom lateinischen Begriff „Qualitas“, der mit „Beschaffenheit“ oder „Eigenschaft“ übersetzt wird. Für die effiziente Nutzung von Software sind grundsätzlich eine gute Beschaffenheit, die durch Stabilität gewährleistet wird, sowie eine gute Funktionalität als wichtige Eigenschaften erforderlich. Wir haben gelernt, dass wir uns bereits lange vor den ersten Testaktivitäten damit beschäftigen müssen, dass Qualität in den Testprozess und am Ende in das Lieferobjekt gelangt.
Neben der Existenz von Qualitätskriterien und Lieferobjekten, die in Quality Gates münden, ist eine qualitativ hochwertige Beschreibung der zugrunde liegenden Anforderungen dabei ein wesentlicher Erfolgsfaktor. Um dies zu gewährleisten, ist eine Orientierung entlang der Kriterien nach IREB (International Requirements Engineering Board) zu empfehlen. Diese umfassen Inhalt (unter anderem Vollständig, Verfolgbar, Korrekt, Überprüfbar), Dokumentation (unter anderem Formate, Verständlichkeit, Eindeutigkeit) und Abgestimmtheit (unter anderem durch Experten und Stakeholder, Auflösung von Konflikten, finale Klärung von Annahmen und Optionen).
So kann Qualität in den Testprozess und am Ende in das gesamte Projektvorhaben gebracht werden. Jeder Qualitätsmangel, egal welche der oben aufgeführten Kriterien er betrifft, führt mit hoher Wahrscheinlichkeit zu einer Reduktion an Funktionalität und/oder Fehlern. Einen Qualitätsmangel zu beheben, erfordert einen erheblichen Mehraufwand an Kapazität, von der Entwicklung über den Test bis hin zum Fachbereich, je nachdem wann der Qualitätsmangel festgestellt worden ist. Ein zu niedriges Qualitätsniveau rächt sich am Ende also, indem man mehr Aufwand betreiben muss. Deshalb ist es sehr wichtig, ein hohes Qualitätsbewusstsein bereits zu Projektbeginn durch geeignete Maßnahmen zu etablieren. Hierzu zählen eine gemeinsame Verabschiedung von Qualitätsstandards ebenso wie die mögliche und notwendige Schulung von Personal, das mit der Dokumentation von Anforderungen betraut ist.
Oliver Droste, Christina Merz

17. Die Umgebung

Zusammenfassung
Mit der Umgebung sind die Rahmenbedingungen gemeint, in der die Testaktivitäten vorbereitet und durchgeführt werden. Diese können sehr vielfältig sein. Hierzu zählt beispielsweise, ob Richtlinien, komplexe Rahmenwerke und organisatorische Vorgaben eine produktive Arbeit überhaupt zulassen oder eher behindern. Ebenso sind die Projektteilnehmer, also Auftraggeber, Projektleiter, Mitarbeitern aus dem Fachbereich und der Entwicklung sowie weitere Stakeholder gefordert, gemeinsam eine Umgebung zu schaffen, in der konstruktiv gearbeitet werden kann.
Wir haben gelernt, dass sich zu viel Bürokratie negativ auf die Performance im Projekt auswirkt. Es ist die Verantwortung des Testmanagers, dafür zu sorgen, dass sein Testteam eine Umgebung vorfindet, in der es auch tatsächlich arbeiten kann. Störungen sind dementsprechend zu melden und gemeinsam mit der Projektleitung möglichst zu beseitigen. Dies ist allerdings nur möglich, wenn die Projektkultur von Vertrauen, Wertschätzung, Offenheit/Transparenz und vor allem einer Lösungsorientierung geprägt ist.
Steht eine lösungsorientierte Umgebung nur eingeschränkt oder gar nicht zur Verfügung, führt das unweigerlich zu Konflikten. Können Konflikte nicht konstruktiv gelöst werden, kann dies zum Stillstand eines jeden Projektes führen. Das gilt auch für die Testaktivitäten. Der Testmanager muss sein Testteam vor negativen Einflüssen aus der Projektumgebung schützen, denn das kann sich sehr negativ auf die Motivation und Leistungsfähigkeit des gesamten Teams auswirken.
Oliver Droste, Christina Merz

18. Das Teaming-Up

Zusammenfassung
Ein Team zusammenzustellen, zu entwickeln und zu motivieren, ist ein sehr wichtiger Baustein für ein Erfolg versprechendes Projekt. Nicht anders verhält es sich beim Testmanager und seinem Testteam. Als erstes muss das Team auf das oberste Ziel eingeschworen werden – dem Finden von Fehlern. Für den Zusammenhalt des Testteams ist es sehr wichtig, dass es sicher sein kann, dass der Testmanager es immer unterstützt und es, wenn es nötig ist, auch verteidigt. Die Geschlossenheit des Teams setzt voraus, dass neben den Zielen auch ein klares Rollenverständnis kommuniziert wurde, um potenziellen Konflikten vorzubeugen.
Nachdem der Testmanager in Abstimmung mit der Projektleitung das Testteam zusammengestellt hat und die Aufgaben und Rollen verteilt wurden, kann man sich auch teambildenden Maßnahmen widmen, zum Beispiel gemeinsamen Aktivitäten außerhalb der normalen Projektumgebung im Rahmen von „Off-Sites“. Es bietet sich an, die grobe Testplanung gemeinsam mit dem Testteam zu verfeinern. So sind nicht nur allen Testteammitgliedern die geplanten Testaktivitäten bekannt, sondern der Fokus wird automatisch auf die zu erreichenden Meilensteine gelegt. Darüber hinaus können in einem Off-Site auch Gruppenübungen durchgeführt werden, die es ermöglichen, dass sich die Teammitglieder besser kennenlernen. Der Testmanager tritt hier idealerweise als Moderator auf, um einen gewissen „Team-Spirit“ zu erzeugen und für die richtige Motivation zu sorgen. Dieser Team-Spirit kann vom Testteam auch in andere Bereiche wie den Fachbereich und die Entwicklungsabteilung/IT getragen werden, um zu erreichen, dass diese im Projekt miteinander und nicht gegeneinander arbeiten – und dies vielleicht sogar über die Projektzeit hinaus.
Das gegenseitige Kennenlernen der Testteam-Mitglieder im Rahmen von teambildenden Aktivitäten kann für ein hohes Maß an Vertrauen sorgen. Vor allem das Vertrauen, welches das Testteam dem Testmanager entgegenbringt, ist für anstehende herausfordernde Testphasen immens wichtig. Dadurch kann gewährleistet werden, dass das Testteam oder einzelne Teammitglieder in brenzligen Situationen nicht alleine gelassen werden. Der Testmanager ist aber auch davon abhängig, von seinem Team gut unterstützt zu werden, das heißt zum Beispiel mit aussagekräftigen Informationen zum Testverlauf und der Fehlersituation versorgt zu werden.
Nur ein geschlossenes Team ist in der Lage, auch unter extremem Druck noch ein adäquates Ergebnis abzuliefern. Umso wichtiger ist das Teaming-Up!
Oliver Droste, Christina Merz

19. Die Vorbereitung

Zusammenfassung
Um Testaktivitäten erfolgreich umsetzen zu können, bedarf es einer guten Vorbereitung. Nur wie und durch wen kann die Vorbereitung denn überhaupt erfolgen? Natürlich durch den Testmanager. Das setzt allerdings voraus, dass der Testmanager rechtzeitig in das Projekt integriert wird. Mit „rechtzeitig“ meinen wir im Rahmen der Initialisierungsphase, also wenn der Projektauftrag formuliert worden ist und die Spezifikationsreife erlangt wurde. Sollte der Testmanager beispielsweise erst nach der Konzeptphase, also wenn das Projekt durch die Entwicklungsabteilung in die Realisierung geht, integriert werden, kann es oftmals schon zu spät sein.
Dem Testmanager muss genug Zeit zur Verfügung stehen, sich und sein Team auf die anstehenden Testaktivitäten vorzubereiten. Das bedeutet, er muss mit seinem Testteam ein klares Verständnis von der Zielsetzung des Gesamtprojektes und insbesondere des Funktionsumfangs des zu testenden Lieferobjektes erlangen. Darüber hinaus muss er die Möglichkeit bekommen, die Sichtweisen, Wünsche und Zielvorstellungen der jeweiligen Stakeholder in Erfahrung zu bringen, um das in seine geplanten Testaktivitäten einfließen lassen zu können.
Gerade zum Start einer Testphase wird der Testmanager von den Stakeholdern sehr genau beobachtet. Kennt der Testmanager die Erwartungen der Stakeholder nicht, so kann er je nach Testergebnis auch nicht oder nur in eingeschränktem Umfang auf deren Belange eingehen beiziehungsweise sie managen. Es kommt dann unweigerlich zu Konflikten, die vermeidbar gewesen wären. Hat der Testmanager genügend Zeit für die Vorbereitung, ist er in der Lage, die Erwartungen der Stakeholder adäquat zu managen.
Neben dem Stakeholdermanagement ist natürlich auch genug Zeit für die Qualitätssicherung der Anforderungen einzuplanen. Dazu gehört die Erstellung von Testfällen. Auch die gesamte Testinfrastruktur, angefangen von Testebenen über Testdaten bis hin zu verschiedenen geplanten Testarten, wie beispielsweise Last- und Performancetests, sowie die Verfügbarkeit der Testressourcen sind gut vorzubereiten, bevor man mit dem Testen beginnt.
Zusammengefasst bedeutet das: Eine gute Vorbereitung aller Testaktivitäten, unter der Berücksichtigung eines guten Qualitätsniveaus, ist ein Garant für ein gutes Gelingen im Projekt. Wird für die Testvorbereitung zu wenig Zeit verwendet, kann das zu verfälschten oder keinen Testergebnissen führen, die der Funktionalität im Live-Betrieb nur ansatzweise oder sogar gar nicht entsprechen können. Die Folge ist Mehraufwand – zeitlich und finanziell.
Oliver Droste, Christina Merz

20. Die Umsetzung

Zusammenfassung
Aus der Summe und Güte der in den vorherigen Kapiteln erwähnten Erfolgsfaktoren „Kommunikation“, „Qualität“, „Umgebung“, „Teaming-Up“ und „Vorbereitung“ kann eine gute oder weniger gute Umsetzung resultieren. Doch auch bei der Umsetzung selbst bedarf es eines hohen Maßes an Disziplin. Hier zeigt sich, ob die gewählte Methodik von allen an der Testumsetzung Beteiligten verstanden worden ist, Trainingsmaßnahmen gegriffen haben und die geplanten Testaktivitäten überhaupt umgesetzt werden können. Natürlich ist die Verfügbarkeit der Testressourcen zum geplanten Teststart ebenfalls ein wesentlicher Punkt, um überhaupt in die Umsetzung gehen zu können.
Der Testmanager nimmt in der Umsetzung mit seinen eingesetzten Metriken zur Messung des Testfortschritts sowie des Fehlermanagements eine zentrale Rolle ein. Die Auswahl der richtigen Metriken für das jeweilige Testobjekt und deren Aussagekraft ist entscheidend für eine erfolgreiche Umsetzung der Testaktivitäten. Darüber hinaus ist der Testmanager gefordert, den im Testprozess entstandenen „Flow“ aufrechtzuerhalten. Nichts ist schlimmer als ins Stocken geratene Testaktivitäten. Eingeplante und bereitgestellte Ressourcen können dann nicht aktiviert werden. Das verursacht extrem hohe Fehlzeiten und damit verbundene Kosten. Dadurch entsteht viel Frust beim Aufraggeber, den Stakeholdern sowie den eingeplanten Testressourcen, der nicht unterschätzt werden darf. Wenn die Moral sinkt oder auch das Momentum verloren geht, ist es fast unmöglich, die Aktivitäten wieder hochzufahren und das Testteam innerhalb kurzer Zeit dazu zu bringen, sich weiterhin so motiviert einzubringen wie vorher.
Das Testmanagement hat den Flow aufrechtzuerhalten und abzuwägen, ob die Schwere von Fehlern tatsächlich die Testaktivitäten zum Stillstand bringen könnten. Das Testmanagement muss dafür sorgen, dass stabilisierende Maßnahmen ergriffen werden, zum Beispiel der Einsatz von Workarounds, die Verlagerung der Testaktivitäten zu anderen Testobjekten oder die Beschleunigung der Fehlerbehebung, bevor es zu einem kompletten Stillstand kommt. Auch ist die Kritik von den Stakeholdern zu managen, die möglicherweise einen Stopp der Testaktivitäten fordern.
Oliver Droste, Christina Merz

21. Die kontinuierliche Verbesserung

Zusammenfassung
Was bedeutet eigentlich eine kontinuierliche Verbesserung in Bezug auf das Testmanagement? Es müssen gewisse Voraussetzungen geschaffen werden, um zum einen überhaupt eine Verbesserung möglich zu machen und zum anderen eine Kontinuität dieses Prozesses zu ermöglichen. Beginnen wir mit den Voraussetzungen, die eine Verbesserung überhaupt möglich machen. Hierzu zählt unter anderem, dass eine Lessons Learned durchgeführt worden ist, die sich offen und selbstkritisch mit den Problemen und Herausforderungen beschäftigt hat, denen das Projekt ausgesetzt war. Neben der Offenheit zählen auch die Werte „Vertrauen“ und „Transparenz“ zu wichtigen Elementen, die eine kontinuierliche Verbesserung überhaupt erst ermöglichen. Fehlt die Bereitschaft, eine Lesssons Learned durchzuführen, so ist das ein Indiz für fehlendes Vertrauen. Ist kein Vertrauen vorhanden, kann nicht offen und konstruktiv über Probleme gesprochen werden, die sich rund um Projekt- und Testablauf ergeben haben. Konflikte sind in diesen Fällen oftmals vorprogrammiert, da dann eher nach Schuldigen als nach Lösungen gesucht wird.
Neben den aufgeführten Werten ist auch die grundsätzliche Bereitschaft der Beteiligten zu einer kontinuierlichen Verbesserung wesentlich. Es gibt Projekte, bei denen bereits die Lessons Learned abgelehnt werden. Die Begründung: Es wird sich am Ende ja doch nichts ändern. Wie immer. Dies ist ein klassisches Beispiel für fehlende Motivation. Sie führt dazu, dass Verbesserungen überhaupt nicht mehr angestoßen werden. In einem solchen Umfeld wird man dieselben Fehler immer wieder begehen und nichts daraus lernen. Es fehlt die Bereitschaft, sich mit den Problemen auseinanderzusetzen – oft aufgrund fehlenden Vertrauens.
Kontinuität in einen Verbesserungsprozess zu bringen, setzt demnach neben den notwendigen Werten und der grundsätzlichen Bereitschaft ein hohes Maß an Disziplin voraus. Denn die Bereitschaft aus Fehlern zu lernen, ist gerade im Testmanagement die Basis dafür, in jedem neuen Projekt noch besser zu werden.
Oliver Droste, Christina Merz

Backmatter

Weitere Informationen

Premium Partner

    Bildnachweise