Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv
 

 

Die Projektplanung ist der Kern und die Voraussetzung für eine effektive und effiziente Projektsteuerung. Da für Test ein gewisses Maß an Spezialwissen notwendig ist (vgl. Organisatorische Voraussetzungen), bietet es sich an für den Bereich Test eine Testplanung zu erstellen.

Rein inhaltlich hat man hier mit Schwierigkeiten zu kämpfen, da Test eigentlich nur ein Qualitätssicherungsmaßnahme ist. Als Reaktion auf den Test sind aber Nachbesserungen notwendig, welche den gesamten Rest des Projekts steuern. Damit übernimmt die Testplanung neben ihrer eigentlichen Aufgabe (nämlich den Test zu steuern) in der Endphase des Projekts quasi die Gesamtsteuerung des Projekts. Im Bereich Test Planung ist eine große Menge von Aktivitäten anzusiedeln.

Aufgabenklärung

Im allgemeinen sorgt Test dafür, dass die Software den Anforderungen des Kunden entspricht. Dazu gehört, dass das Programm

  • bei korrekten Eingaben die korrekten Ausgaben erzeugt (funktionale Anforderungen)
  • bei falschen Eingaben, diese zurückweist
  • den nicht-funktionalen-Anforderungen (Bedienbarkeit, Wartbarkeit, Performance, ...) entspricht

Im Allgemeinen ist es nicht mögliche Kombinaten von Eingabewerten zu prüfen, so dass sie der Bedarf nach einer Priorisierung der Anforderungen ergibt.

Des Weiteren gibt es andere QS-Methoden (Code_Walkthroughs, Reviews, ..), welche zum Einsatz kommen.

All diese Parameter erzeugen die Notwendigkeit, dass der Test Manager wirklich versteht, was er tun muss und warum er es tun muss.

Dazu muss der Test Manager

  • Das System verstehen. Dies geht über die Anforderungslisten hinaus, da meist noch Prozesswissen benötigt wird. Kontextprodukte müssen bekannt und verstanden sein, um den Zweck des System und die Schnittstellen endgültig beschreiben zu können.
  • Schon zur Projektinitialisierung eingebunden sein, um die Historie, die Priorität und die Risikosituation der einzelnen Anforderungen zu verstehen.
  • Die Projektkultur des Zielunternehmens kennen. Gerade wenn der Test Manager nicht aus dem Haus des Kunden oder des Umsetzers kommt, muss er sich über die Prozesse und Rollenverteilung bei Entwicklung, Test und Abnahme im Klaren sein.
  • Die Erwartungen an den Softwaretest kennen. (zB müssen nicht-funktionale Anforderungen getestet werden oder reicht es bei Bedarf später das System zu optimieren)
  • Lessons Learned aus der Zielorganisation über frühere Testphasen kennen.
  • Aufwand und Aufwandsverteilung (und die Erwartungshaltungen dazu kennen). Eine oft verwendetet Faustregel ist, dass 33% des Projektaufwands im Bereich QS + Test verbraucht werden. Je nach Projektart kann es dazu signifikante Abweichungen geben. Wie ist das im Zielunternehmen.
  • Das Vorgehensmodell des Projekts / der Entwicklung kennen. Agile Entwickler benötigen ein völlig anderes Testvorgehen, als Entwickler in Wasserfall-Projekten.

Risiken und Teststrategie

Teil der Testplanung sollte immer eine Risikobetrachtung sein. An der Risikosituation muss sich letztendlich auch die Testplanung orientieren.

Zur Betrachtung der Risiken gehört auch eine Bewertung der Annahmen und Voraussetzungen. Eine Annahme, dass eine Testumgebung bis zum Zeitpunkt X bereitgestellt wurde hilft nichts, wenn der Test Manager nicht sicherstellt, dass dies auch geschieht.

Und alle cya-Annahmen und Voraussetzungen helfen dem Projekt und dem Test Manager am Ende nichts, wenn das Projekt nicht rechtzeitig und in guter Qualität auf die Straße kommt. Daher müssen Annahmen und Voraussetzungen – genauso wie die Risiken – ständig beobachtet werden.

Die Teststrategie sollte aus der Risikobetrachtung abgeleitet werden. Die Teststrategie einer der wichtigsten „kreativen“ Teile des Testmanagements. Eine intelligente Teststrategie findet Fehler früh, reduziert den Gesamttestaufwand und zielt darauf ab, die Risken, Annahmen und Voraussetzungen möglichst früh zu attackieren und prüfen.

Folgende Faktoren spielen bei der Teststrategie eine Rolle:

  • Systemarchitektur: Die Systemarchitektur sollte bei der Erstellung der Teststrategie bekannt sein. Handelt es sich um eine Software mit Schichtenmodell? Handelt es sich um eine Web-Applikation? Welche Teile können unabhängig getestet werden?
  • Testschnittstelle: Wird über das Frontend (GUI) getestet? Kann das Backend evtl. maschinell getestet werden? Wird nur das Backend getestet? Werden Standardkomponenten verwendet, welche schon als „Fehlerfrei“ angesehen werden können und sind daher nur bedingt Testobjekt? Welche Funktionalitäten sind nicht von der Benutzerschnittstelle aus sichtbar?
  • Entwicklertests: Wie ist die Qualität und die Kultur des Testens direkt bei den Entwicklern? Setzt das Testteam direkt auf dem Code auf oder setzt es auf fertigen Applikationsteilen auf?
  • Auswahl von Testtechniken.
  • Auswahl von Testtools
  • Auswahl des Testteams: Basierend auf der Teststrategie werden die benötigten Skills für das Testteam abgeleitet.
  • Testabdeckung: Welche Testabdeckung ist vom Kunden gewünscht (und wird bezahlt)? Hier wird oft ein risikobasierter Ansatz gewählt. Funktionen mit hohem Durchsatz oder ohne manuelle Workarounds werden intensiver getestet als Funktionen mit geringem Durchsatz.
  • Abnahmekriterien: Vor Beginn des Tests müssen die Abnahmekriterien mit dem Kunden geklärt sein.
  • Zeitplanung: Die einzelnen Teststufen müssen auf die Zeitachse allokiert werden, um eine Zeitplanung des Projekts zu ermöglichen. Unterschiedliche Testziele erfordern unterschiedliche Teststufen. Nur wenn die Teststufen in eine sinnvolle Reihenfolge gebracht werden, kann ressourcenoptimal getestet werden.

Je nach Unternehmen und Umfeld spielen vermutlich in jedem Projekt andere Faktoren eine Rolle, welche in die Teststrategie einfließen müssen.

Aus der Teststrategie leiten sich auch eine Vielzahl der Projektrisiken im Test ab. Auf der anderen Seite spielen die Projektrisiken eine Rolle bei der Testplanung und Teststrategie.