10 Schritte zu einem guten Start ins nächste Testprojekt (Teil 5)

von Maud Schlich

Ein neues (Test-)Projekt für Sie? In zehn Schritten legen Sie die Basis für einen guten Start und damit auch ein erfolgreiches Ende - ganz egal, ob Sie in einem agilen Umfeld unterwegs sind oder das V-Modell als Leitlinie haben. Aus dem Risikomanagement von Schritt 4 heraus, geht es in diesem Beitrag nun um die Berücksichtigung von Risiken und Stakeholdern in der Teststrategie und um die Erstellung des zugehörigen Dokumentes.


Die Ergebnisse der ersten vier Schritte werden in diesem Schritt genutzt, um die Teststrategie zu erstellen.

  1. SMARTe Ziele bestimmen
  2. Erwartungen der Stakeholder kennen und erfüllen
  3. Eine gute Basis für die Teststrategie legen
  4. Risiken managen

Die Teststrategie

Die eigentliche Teststrategie verteilt sich bei den meisten Unternehmen typischerweise auf zwei Dokumente:

  • ein Testhandbuch und
  • ein Testkonzept/Testplan.

Was viele Unternehmen unter einem Testhandbuch verstehen, ist in der ISO/IEC/IEEE 29119-3:2013 eine Zusammenfassung aus Testpolitik, Teststrategie und einem Master-Testkonzept und beinhaltet alles, was über (fast) alle Projekte hinweg einer Organisationseinheit oder des gesamten Unternehmens gültig ist. Das widerspricht der Norm aber nicht, solange alle Inhalte der "vorgeschriebenen" Dokumente irgendwo schriftlich festgehalten sind.

Das Testkonzept ist dagegen ein projektspezifisches Dokument, hier werden alle Dinge notiert, die für genau dieses Projekt gelten und sehr konkret sind. Es ist das zentrale Planungsdokument und quasi der Projektplan für ein Testprojekt.  In vielen Unternehmen werden diese Testkonzepte immer noch nach der IEEE Std. 829-1998 Software Test Documentation gegliedert, obwohl es seit 2008 eine Überarbeitung gibt, der IEEE Std. 829-2008 Software and System Test Documentation, der ja wiederum durch die ISO/IEC/IEEE 29119-3:2013 abgelöst wurde. Meine Vermutung ist es, dass diese Gliederung zum Einen tatsächlich eine gute Grundlage für Testkonzepte darstellt UND das von den Anwendern auch so gesehen wird und zum Anderen, kaum ein Standard so häufig als herunterladbare Dokumentvorlage - teils mit Erklärungen - kostenfrei angeboten wird. Außerdem ist die Aufteilung in Master- und Stufentestkonzept der IEEE Std. 829-2008 deutlich komplexer mit wesentlich mehr Kapiteln – eine Mühe, die in vielen Fällen zu hoch und zu wenig nützlich erscheint.

Ein weiterer Grund ist sicher, dass die alten Dokumentvorlagen in Unternehmen eine lange Tradition haben, kaum jemand hat Interesse und Zeit für eine grundlegende Änderung von Vorlagen und der häufig aufwändigen Prozesse bis zur organisationsweiten Freigabe.

Also einfach sein lassen? Mein Tipp: Picken Sie die Rosinen aus der ISO/IEC/IEEE 29119-3:2013 heraus und fügen Sie dementsprechend einzelne Kapitel oder Inhalte in Ihr Testkonzept ein. Wenn es sich bewährt, dann investieren Sie in eine Änderung der Dokumentvorlage, damit alle davon profitieren können.


Rosinen Rosine der ISO/IEC/IEEE 29119-3:2013

Rosinenstapel


Der ISO/IEC/IEEE 29119-3:2013 beschreibt das Testkonzept (engl. test plan) mit den einzelnen Unterpunkten. Im folgenden diskutiere ich einzelne daraus - mit ihren jeweiligen Stärken und Schwächen.


Rosine Geltungsbereich (Scope)

Das Dokument Testkonzept (engl. testplan) enthält laut ISO/IEC/IEEE 29119-3:2013 sowohl einen Geltungsbereich (Scope) des Dokuments als auch den Testscope.

Dokumentieren Sie hier, was das Testkonzept

  • umfasst bzw. alles einschließt,
  • explizit nicht beinhaltet, sowie die
  • Annahmen, die Sie treffen und
  • Einschränkungen, unter denen Sie das Testkonzept erstellt haben.

Wenn Sie etwas bewusst ausschließen, begründen Sie warum. Es könnte z.B. sein, dass der typische Leser des Testkonzeptes im Dokument etwas erwarten kann, dann sollten Sie mitteilen, wo die Information stattdessen zu finden ist.

Annahmen und Einschränkungen sind wichtig - sozusagen Ihre Versicherung gegen Unheil.

Tipp: Bereits zu Beginn des Risikomanagement lege ich das fest - um auch gleich zu entscheiden, welche Risiken ich außerhalb meines Verantwortungsbereiches z.B. auch nach "oben" zum Projektmanagement delegiere.


Rosine Stakeholder und Kommunikationsplanung (Stakeholders / Testing communication)

Warum Stakeholders ein Unterkapitel 6.2.4.5 von Textkontext (6.2.4 Context of the testing) ist und die Kommunikationsplaung (6.2.5 Testing communication) ein eigenes Kapitel erschließt sich mir nicht ganz. Tatsächlich wird für Stakeholder "nur" festgelegt:

Listen Sie die Stakeholder und deren Bedeutung im Testkontext. Beschreiben Sie, wie die Kommunikation zu jedem Stakeholder durchgeführt wird.

Für die Kommunikationsplanung wird festgelegt:

Beschreiben Sie die Kommunikationswege zwischen Testen, anderen Aktivitäten im Rahmen des Lebenszyklus und innerhalb der Organisation.

Beispiel Dies kann beinhalten, wer Vorgänge, die im Rahmen der Tests erstellt wurden, erledigen darf und wer Arbeitsergebnisse des Testens und Testprozesse freigeben darf.

Diese Information kann visuell dargestellt werden.

Hinweis Eine visuelle Darstellung kann ein Organigramm oder eine Grafik sein, die den Informations- und Datenfluss darstellt.

Das ist leider alles. Und der Testplan im Anhang F macht es sich da besonders leicht:

2.5 Stakeholder

  Siehe Stakeholder Analyse in [PP]

3 Kommunikationsplan Test

  Siehe [PP]

Wenn Sie die Stakeholder-Analyse aus Teil 2   durchgeführt haben, dann haben Sie bereits mehr getan, als die Norm fordert - aber genau das, was Ihnen wirklich hilft. Die Rosine hier liegt für mich darin, dass die Norm immerhin an dieses Thema "denkt", die Hilfestellung durch den ISO/IEC/IEEE 29119-3:2013 ist aber äußerst dürftig.


keine RosineDas Risikomanagement

Die Beschreibung des Managements von Produkt und Projektrisiken und die Beispiele im Anhang F betrachte ich als wenig gelungen und inkonsistent - dazu habe ich mich in meinem Newsletter bereits ausführlich geäußert. Hier daher nur kurz zusammenfassend: Risiken werden nicht sauber als Ursache-Wirkungs-Paar dargestellt, die Beispiele sind formal sehr unterschiedlich und die abgeleiteten Maßnahmen wenig riskovermeidend oder schadensreduzierend.


Rosine Teststrategie innerhalb des Testkonzepts

Was der ISO/IEC/IEEE 29119-3:2013 unter Teststrategie versteht, wird durch die einzelnen "Sub-clauses" deutlich. Im Vergleich zum IEEE Std 829 wird also besser deutlich, dass dies alles zur Teststrategie dazugehört und somit die Frage: "Was ist das eigentlich?" hoffentlich klarer beantwortet - daher eine klare Rosine.

  • Test-Subprozesse
  • Arbeitsergebnisse des Testens
  • Testverfahren
  • Testendekriterien
  • Zu erfassende Metriken
  • Anforderungen an die Testdaten
  • Anforderungen an die Testumgebung
  • Fehlernachtest und Regressionstest
  • Unterbrechungs- und Wiederaufnahmekriterien
  • Abweichungen von der Organisationsweiten Teststrategie

Sowohl die Test-Subprozesse als auch Arbeitsergebnisse des Testens gehören für mich in ein möglichst organisationsweites Dokument - selten ändern sich die Beschreibungen diese Teile und die bloße Auflistung wie im Annex beschrieben nützt wenig. Auch die Auflistung von Testverfahren ist wenig hilfreich: warum sollte man diese einschränken oder vorgeben? Gute Tester jeder Teststufe werden entsprechend der jeweiligen Testbedingung und dem Testobjekt die dann passende auswählen. Keinem Handwerker würde man vorab vorschreiben, welches Werkzeug er benutzen soll, sondern lehren, das jeweils Optimale auszuwählen.

Bzgl. der zu erfassenden Metriken sind sowohl der normative Teil als auch die Beispiele im Anhang "dünn", was wir in zwei vollen Tagen gründlich erarbeiten, wird hier in wenigen Zeilen abgehandelt.

Insgesamt kann das gesamte Teststrategie hier als eine Checkliste dienen, ob Sie an alles gedacht haben. Wie das im Detail in der Praxis aussehen kann, wird leider nicht deutlich.


keine RosineTestaktivitäten und -schätzungen

Egal, ob es um das Testen in einem klassischen oder einem agilen Kontext geht, eine gewisse Vorplanung und -abschätzung gibt es immer. Mal (vermeintlich) genau und detailliert, mal als Auflistung der Tasks auf einem "Agilen Board", wie es der ISO/IEC/IEEE 29119-3:2013 als Möglichkeit vorschlägt. Und auch der Hinweis darauf, dass Budget und Ressourcen auch im Projektplan dokumentiert werden können, fehlt nicht.

Diesen Unterkapitel ist dasjenige, was am häufigsten im Testkonzept geändert werden sollte. Tatsächlich wird zu Beginn eine Schätzung dokumentiert (meist auf vager Schätzbasis), die unverändert bis zum Ende so stehen bleibt. Und das, obwohl es bereits im Verlauf der ersten Wochen möglich ist, genauere Vorhersagen zu treffen.

Mein Tipp: Dieses Kapitel bewusst mit "Schätzungen Stand dd.mm.yyyy" überschreiben und für Aktualisierungen auf ein separates Dokument verweisen, dies kann z.B. auch der regelmäßige Teststatusbericht sein.


keine RosinePersonal

Dieses Kapitel enthält keine nennenswerten Rosinen. Rollen, Aktivitäten und Verantwortlichkeiten sind wichtig. Sie können es so machen, dass Sie nur kurz Projektrollen und zugehörige Personen benennen oder Sie betonen den Vertragscharakter zwischen den verschiedenen Stakeholdern (insbesondere zwischen Entwicklung und Test) und listen auf, was wer (bis wann) macht bzw. wofür wer verantwortlich ist. Diese detailliertere Festlegung hat schon mehrmals Coachees von mir bei in der Diskusson geholfen.

Hierzu liefert der Annex H der ISO/IEC/IEEE 29119-3:2013 die klassische RACI-Matrix.

Beispiel:

  Aktivität
Rolle Testumgebung einrichten Testdaten bereitstellen Analyse Testbasis
Testmanagement R A A
IT-Testkoordinator R R -
Tester I C R

Die Personalplanung im Test, bzw. die Planung der Weiterbildung wiederum ist bei meinen Coachees nur selten Teil des Testkonzeptes geworden - allzu häufig gab es einfach "diese x Tester" zugewiesen und Aus- und Weiterbildung lag außerhalb des Verantwortunsbereichs des Testmanagers. Hier empfehle ich, Defizite gesondert aufzuzeigen und direkt an die zuständigen Vorgesetzten zu adressieren.

Eine Analyse des Teams bezüglich der unterschiedlichen Wissenstände, Fertigkeiten und Fähigkeiten ist für mich eine wichtige Aufgabe des Testmanagers - leider wird das aus Zeitmangel viel zu selten ausreichend gründlich durchgeführt. Der ISO/IEC/IEEE 29119-3:2013 liefert hierzu im Anhang keine Hilfen.


Und im agilen Kontext?

Das Testkonzept, wie es oben beschrieben wurde, ist trotz aller "agilen Hinweise" eher für die Entwicklung im klassischen Kontext ausgerichtet. Der Annex F.1 der ISO/IEC/IEEE 29119-3:2013 liefert ein Beispiel, dass mir gut gefällt und dass ich deswegen in meinem Artikel Agile Teststrategie nach ISO/IEC/IEEE 29119-3 vollständig übersetzt vorstelle.



Mit unserem Testkonzept Intensivcoaching unterstützen wir Sie bei Ihrem ganz speziellen Testkonzept. Starten Sie heute noch.


Sobald es mit einer Strategie nicht mehr läuft, ist es an der Zeit neue Wege zu beschreiten.

Jonathan Schramke


Metriken sind ein umfassendes Thema, dem wir uns im nächsten Artikel der Reihe ausführlicher widmen.

Ich lade Sie ein, dieses Thema mit mir zu diskutieren, vereinbaren Sie einfach einen kostenfreien Termin in meinem Kalender mit mir.


Whitepaper-Banner flach

Zurück