Bewertung: 0 / 5

Stern inaktivStern inaktivStern inaktivStern inaktivStern inaktiv
 

 

2 Organisatorische Voraussetzungen für Testmanagement

2.1 Professionelle Testmanager einsetzen/aufbauen

Eines der Ergebnisse der CHAOS Studie war die Feststellung, dass professionelle und gute ausgebildete Projektmanger erheblich zum Projekterfolg beitragen. Ähnliches gilt „im Kleinen“ für die Durchführung von Tests und damit für die Qualitätssicherung des Projektprodukts (Software) und damit für die Erreichung der Abnahme.

Während sich inzwischen die Erkenntnis durchgesetzt hat, dass man für die Durchführung von Projekten spezielle Führungskräfte benötigt – eben Projektmanager - finden auf der anderen Seite die Maßnahmen zur Qualitätssicherung weniger Beachtung. Qualitätsmanagement ist eines der Kernwissensgebiete des Projektmanagement [PMI]. Dies bedeutet jedoch nicht unbedingt, dass der Projektmanager sich auch gut im Bereich der Testmethode auskennt. (Sicherstellung der Qualitätssicherung ist zwar Aufgabe des Projektmanagements, jedoch ist die konkrete Ausführung immer an den Produkterstellungsprozess gebunden, d.h. Testmethode für Softwareentwicklung.)

Daher kann es sinnvoll sein, die Testvorbereitung und Testdurchführung im Projekt professionell zu betreuen.

Man sollte sich immer vor Augen halten, was Test für das Projektergebnis bedeutet: Es ist die Vorbereitung der Abnahme durch den Kunden. Daher muss schon die Aufnahme der Abnahmekriterien (hier: Testfälle) sehr strukturiert und vollständig durchgeführt werden. Dies erfordert Methodenwissen im Bereich Test und ein gutes Durchsetzungsvermögen.

Ein weiterer Aspekt ist der Zielkonflikt zwischen Produkterstellung und Qualitätssicherung: Während der Projektmanager rein psychologisch irgendwann in den get-it-done!-Modus (Werdet endlich fertig!) umschwenkt, ist es dringend erforderlich, dass es ein Gegengewicht in Form eines professionellen Testmanagers gibt, der bis zuletzt im get-it-right!-Modus (Macht es richtig!) bleibt.
Dies bedeutet nicht: „Qualität um jeden Preis!“, aber wenn Termine eingehalten werden müssen, muss am Ende zumindest eine qualitativ vollständige und fundierte Bewertung der Software vorliegen und die Risiken einer evtl. „verfrühten“ Produktivschaltung müssen den Entscheidern bekannt sein. Dies kann ein professionelles Testmanagement leisten.

 

Bei Unternehmen, mit einem hohen Anteil von Softwareentwicklungsprojekten, lohnt sich daher der Aufbau einer professionellen Testmanagement Abteilung, sowie der damit verbundene Ausbildungsaufwand.

 

Vereinfacht gesagt sind Testmanager Menschen mit Projektmanagement und mit Test-Ausbildung. Eine Doppelzertifizierung macht Sinn.

 

2.2 Positionierung des Testmanagements

Die Positionierung des Testmanagement im Unternehmen und im Projektgeschehen kann sich auf den Erfolg des Testmanagements auswirken.

Bedingt durch die Tätigkeit selbst passiert es, dass die Tester und Testmanager genau dann Beachtung durch das Management erfahren, wenn ein Projekt schlecht läuft. Läuft ein Projekt gut, bekommt die Lieferantenseite (Entwickler & Projektmanager) die volle Aufmerksamkeit des Managements.

Eine schwache Vertretung des Test-Gedankens beim Management großer Unternehmen hat einige unangenehme Seiteneffekte:

Immer nur bei Problemen vom Management Beachtung zu finden ist nicht motivierend für die Testmannschaft. Gute Mitarbeiter wählen ggf. mit den Füßen – sie finden auch in Unternehmen einen Job, wo ihre Arbeit gewürdigt wird.

 

Für den Projekterfolg ist es oft notwendig, wenn der Testmanager das nötige Standing hat um Liefertermine durchzusetzen oder zumindest die Priorisierung des Kunden bei der Entwicklung durchzusetzen. Gleiches gilt für andere konstruktive und analytische QS Maßnahmen, die der Testmanager durchsetzen muss, wenn er insgesamt gute Ergebnisse von der Entwicklungsseite bekommen möchte.
Ist dies nicht der Fall, gefährdet dies den Projekterfolg.

 

Wird professionelles Testmanagement zur Chefsache erklärt und auch so im Unternehmen kommuniziert, dann ist der Testerfolg leichter zu erreichen. Daher sollte es immer einen Machtsponsor für Testmanagement im Unternehmen, bzw. für das spezielle Projekt geben. Während der einzelne Testmanager in seinem die Nähe zum Machtsponsor suchen kann, würde eine strukturelle Positionierung des Testmanagements auf Augenhöhe mit dem allgemeinen Projektmanagement die Arbeit für alle Projekte im Unternehmen erleichtern.

 

2.3 Testmanagement Methode festlegen

Bezüglich der Methode gilt für Testmanagement das selbe, wie für Projektmanagement: Es ist gut eine zu haben!

Es gibt verschiedene Aspekte, die für den Einsatz einer unternehmensweiten Testmethode sprechen:

  • Wiederverwendbarkeit von Vorlagen
  • Einheitliches Reporting über mehrere Projekte, bzw. projektübergreifendes Reporting
  • Vermeidung von Missverständnissen durch Schaffung eines gemeinsamen Wortschatzes
  • Ermöglichen einer Lernkurve für neue Mitarbeiter im Bereich Test (sonst wird alles ständig neu erfunden)
  • Verbesserung der Gesamtergebnisse in der Softwareentwicklung durch Implementierung einer Testkultur
  • usw.

 

Beim Festlegen der Methode gilt es zwischen einer Vereinheitlichung der bisher verwendeten Methoden und einem Industriestandard abzuwägen.

 

Es gibt bereits Prozessmodelle und Verfahren zum Thema Test und Testmanagement. Es macht Sinn, einen bestehenden Standard zu verwenden und an das jeweilige Unternehmen anzupassen. Der IEEE 829 Standard (incl. seiner deutschen Übersetzung) ist beispielsweise eine gute Stelle um damit anzufangen, die Ergebnisdokumente und den Wortschatz für Test im Unternehmen zu vereinheitlichen.

Die Prozessvorschläge weiter unten orientieren sich an diesem Standard.

 

Viele Unternehmen haben bereits eine Projektmanagementmethode in ihrem Unternehmen etabliert. Docken sie die Testmanagement-Methode möglichst nahtlos daran an, um Reibungseffekte und Kompetenzstreitigkeiten mit dem Projektmanagement zu vermeiden.

 

Es hilft wenig, den IEEE Teststandard mit dem Firmenlogo zu versehen. Eine Testmanagement-Methode muss auch strukturiert eingeführt werden. Es macht Sinn, dies beispielsweise auf Basis von Pilotprojekten zu machen.

 

Auf der anderen Seite kann hier die Standardisierungsfalle zuschnappen, wenn das Pilotprojekt einen verbindlichen Prozess für die Folgeprojekte vorschreibt:

Projekte werden genau deshalb in einer Projektorganisation durchgeführt werden, weil die Durchführung im Rahmen einer Linienorganisation nicht möglich ist. Trotzdem ist in den letzten Jahren ein Trend zu beobachten, dass Projektmanagement – und damit letztlich auch Testmanagement – in ein enges Korsett von Prozessen gequetscht wird, welche den Projekten „die Luft zum atmen“ nimmt. Das bedeutet, dass es zu einer Überreglementierung (Bürokratisierung) kommt, welche oft aus Controllingaspekten oder einer falsch verstanden Übertragung von IT-Betriebsprinzipien auf das Projektgeschäft entsteht.

Die Folgen sind höhere Kosten, niedrigere Mitarbeitermotivation und damit schlechtere Projekte.

Zweifellos erfordert Test in seiner Aufgabe als analytische Qualitätsmaßnahme ein definiertes und sorgfältiges Vorgehen – dieses mag sich jedoch von Projekt zu Projekt unterscheiden.

„Heutzutage kann ein Prozessmodell nur noch die Werkzeuge aber nicht das vollständige, obligatorische Vorgehen vorschreiben." (Reinhard Wagner,  Präsident der GPM Deutschland am 05.04.2011 in Frankfurt/Main)

2.4 Tooleinsatz

In aller Regel lohnt sich der Einsatz eines professionellen Testtools (organisatorisches Testtool). Der Mehrwert ergibt sich aus einer geordneten Sammlung der Aktivitäten und Artefakte der Testvorbereitung und Testdurchführung. Außerdem lassen sich die Test-relevanten Tätigkeiten mit einem Prozess hinterlegen.

 

Hinweis: Daneben gibt es noch die technischen Testtool (Testautomatisierung, Lasttestmessung, etc.); deren Einführung lohnt sich abhängig von der Art der Projekte und des Unternehmens.

 

Dem Nutzen der Testtools steht natürlich immer die Kosten entgegen. Beispielsweise das markt-führende Tool „HP Quality Center“ kann (wg. der Kosten) oft nur von entsprechend großen Firmen verwendet werden. Es gibt noch eine Reihe freier Tools, welche dann aber oft einen eingeschränkten Funktionsumfang haben.

Verbreitete Tools haben natürlich auch den Vorteil, dass sie wesentlich leichter an Know How kommen, wenn sie es für ihr Projekt zukaufen müssen. (Das gilt sowohl für Tool-bewanderte Testmanager, als auch für Tooltrainer oder Tool-Administratoren. )

Die Tooleinführung für ein einzelnes Projekt ist oft schwer zu argumentieren, da der Hauptnutzen aus der Wiederverwendung von Testvorbereitung und Abweichungsinformation über die Projektgrenzen hinweg besteht. Daher ist eine unternehmensweite (oder bereichsweite) Einführung meist sinnvoller.

 

Ein wichtiger Aspekt beim organisatorischen Testmanagement-Tool ist die Einführung und die unvermeidliche Softwareanpassung.

Die meisten Tools bieten die Möglichkeit, die Prozesse und Datenfelder umfänglich anzupassen. Hier besteht die Gefahr, dass die Projekte im Unternehmen „eigene Wege“ gehen, welches bei späteren gemeinsamen Projekten schwer macht wieder „zusammen zu finden“. (Beispielsweise wenn eine Reihe von Applikationen in einem Technologie- oder Migrationsprojekt gemeinsam getestet werden muss.)

Daher sollten die Anpassungen – genauso wie alle anderen Softwareentwicklungen im Unternehmen – von einem guten Softwarearchitekten geprüft werden. Einer sollte den „Griff“ auf das Datenmodell behalten und Wildwuchs radikal eindämmen.

In der Regel reicht ein Prozessmodell für alle – wenn es die notwendige Flexibilität in der Benutzung zulässt..

 

Eine zentrales Applikationsmanagement für das Testmanagement Tool, welches über reine Lizenzverwaltung hinausgeht, lohnt sich auch um beispielsweise zentral Schulungsunterlagen zu erstellen, Einweisungen durchzuführen oder die Hoheit über den Testprozess allgemein zu halten.

 

Im Downloadbereich finden Sie ein Template für eine Testtoolauswahl-Befragung der Herstellern. Diese können Sie als Grundlage für ihre eigene Toolauswahl verwenden.

 

Ein konkreter Vorschlag für die Konfiguration (Rollen, Daten, Prozess) finden sie an späterer Stelle.