Die besonders in der Agilen Community umstrittene ISO/IEC/IEEE 29119-3:2013 erhebt den Anspruch auch für Unternehmen mit agiler Softwareentwicklung und agilem Testen anwendbar zu sein. Dies gilt auch für eine schriftlich festgelegte Teststrategie. Der Anhang E gibt dazu ein Beispiel, das ich Ihnen in diesem Artikel kritisch vorstelle.

Dass die Teststrategie überhaupt schriftlich fixiert wird, mag vielen und vielleicht auch Ihnen schon als ein Widerspruch in sich vorkommen. Tatsächlich habe ich aber bereits in mehreren Unternehmen Spruchbänder an Whiteboards – gerne in Form witziger Grafiken – schon öfter gesehen und im Grunde handelt es sich ja um eine Leitlinie, die von den Mitgliedern agiler Teams selbst erstellt wurde und zu deren Beachtung sie sich optimalerweise selbst verpflichten.

Dennoch ist das Beispiel einer Teststrategie im agilen Kontext aus der ISO/IEC/IEEE 29119-3:2013 Anhang E kritikwürdig.

Zur Verdeutlichung habe ich das Beispiel aus Anhang E frei übersetzt und kursiv gestellt.

Die Teststrategie muss gemäß der Norm Kapitel 5.3.2 (wie alle Dokumente) verwaltende Informationen enthalten, um sie z.B. eindeutig zu bezeichnen. Dazu gehören

1. Identifikation des Dokumentes mit Namen/Inhalt und eindeutigem Bezeichner/Version, z.B. Organisationsweite Teststrategie der Agile Corporation, V1.1 (23.03.2009)
2. Herausgebende Organisationseinheit und ggfs. Autoren, z.B. Ursula Meyers, Leitung der Entwicklung
3. Freigabe durch, z.B. Stephan Blacksmith, Leitung QS
4. Änderungshistorie
5. Geltungsbereich, im Beispiel aus Anhang E erstaunlich ausführlich: 

   Die Organisationsweite Teststrategie beinhaltet die übergeordnete Vorgehensweise des Unternehmens zum Testen. Wir haben verschiedene Richtlinien entwickelt und implementiert, die über alle Projekte hinweg anwendbar sind. Wir streben danach, das Testen an jedem Punkt im System- und Softwarelebenszyklus anzubieten. Dies erreichen wir, indem unsere Testgruppe als Teil der Entwicklerteams frühzeitig im Entwicklungsprozess beteiligt wird und bereits mit User Stories arbeiten, wenn diese noch im Entwurf sind.

   Diese hilfreichen Arbeitsergebnisse bilden die Basis zur Entwicklung von Testplänen und der Abschätzung des Testaufwands. Neben der Erarbeitung der Testpläne wird die Organisation agile Testaktivitäten wie
   
   - die Einbeziehung der Stakeholder im Testdesign,
   - Vorbereitung der Testautomatisierung,
   - Peer Reviews,
   - verschiedene Testdesignaktivitäten (projektabhängig),
   - leichtgewichtiges Fehlermanagment und
   - leichtgewichtige Berichte.
   

   Für mich klingt diese Auflistung künstlich. Fast so, als hätte hier ein "Traditioneller" sein Verständnis von Agil aufgelistet. Mein Tipp: Fassen Sie hier kurz zusammen, welche Prinzipien Sie verfolgen und nennen Sie hier das, was für Sie besonders wichtig ist. Benennen Sie es mit Ihren eigenen Worten und so genau wie möglich. "leichtgewichtig" klingt vielleicht toll aber hilft den Lesern des Dokumentes wenig. Ok, wer mich kennt, weiß, dass ich weder schwer- noch leichtgewichtig für besonders treffende Begriffe halte). Dagegen ist es eine hilfreiche Spielregel zu sagen: „Alle Fehler müssen in <xyz-Tool> erfasst werden, wenn Sie
    
   - nicht sofort behoben werden ODER
   - vonmehr als einer bearbeitet werden.
   
   

6. Referenzen, die berücksichtigt werden sollen, hier nennt die Norm das Agile Manifest als Beispiel. Die Nennung des Agilen Manifests unter "Referenzen", damit der Norm genüge getan wird, empfinde ich als gekünstelt / zwanghaft. Aber immerhin kann es ja sinnvoll sein, die Leser der Teststrategie nochmals daran zu erinnern. Wie sehen Sie das?

7. Allgemeines Risikomanagment
   Das gesamte Risikomanagement unterliegt dem unternehmensweiten Risiko Management Prozess gemäß Corporate Policy-RM56, in der das zentrale Risikoregister aufgelistet ist. Jegliche Abweichungen und Ausnahmeregelungen müssen durch das Senior Management genehmigt werden.
   
   Das klingt nicht nach typisch agilen Unternehmen, oder? Festgeschriebene Prozesse? Zentrales Risikoregister? Das habe ich bisher nur in Firmen gesehen, bei denen vereinzelt Projekte „agil“ entwickeln durften, die aber im Allgemeinen nach einem Wasserfall- oder V-Modell arbeiten.

8. Grad der Unabhängigkeit
   Die Testorganisation wird durch den Testmanager geführt, der keine direkte Verbindung zur Entwicklungsleitung hat. Das Testteam ist technisch, hierarchisch und finanziell unabhängig von der Entwicklungsabteilung der Agile Corp. Die Tester sind bei Zuweisung zu einem Projekt möglicherweise direkt in selbstorganisierten Teams inklusive Entwicklung tätig.
   

9. Testorganisation

   Agile Corp hat einen Pool von unabhängigen Testexperten, aus denen heraus Tester zu Agilen Teams, z.B. zu einem Scrum Team, zugewiesen werden. Dort sind die Tester Mitglieder eines übergeordneten Teams.
   
   Sowohl bei dem Punkt Grad der Unabhängigkeit als auch Testorganisation empfehle ich Ihnen, dies entsprechend Ihrer tatsächlichen Vorgehensweise zu beschreiben. Wenn es keinerlei Unabhängigkeit in Ihrem Agilen Team gibt, dann sollten Sie dies auch nicht einer Norm zuliebe irgendwie so „deichseln“. Und bedenken Sie:
   Menschen und Interaktionen stehen über Prozessen und Werkzeugen – also machen Sie sich genau dazu Gedanken und formulieren Sie Ihre Interpretation dazu hier. Ein Beispiel könnte sein, dass Sie genau hier jedem einzelnen Teammitglied (ja auch den Entwicklern, falls Sie das überhaupt von den Testern trennen), Rechte zusprechen. Schreiben Sie, was jeder darf (und soll und muss natürlich auch).
   

10. Testdokumentationsstrategie
    Darauf haben Sie gewartet, oder? Funktionierende Software steht über einer umfassenden Dokumentation und nun? Das Beispiel im Anhang E sagt:
    
    Die Testorganisation wird den Vorgaben der ISO/IEC/IEEE 29119-3 genügen und den Prinzipien der agilen Entwicklung. Jegliche Abweichungen benötigen eine Zustimmung des Testmanagements.
    
    Schade, war mein erster Gedanke. Schade, dass die Autoren die Einhaltung der Norm so wichtig nehmen und gleichzeitig so pauschal sind. Nein, einfach „Compliance“ zu fordern, ist sicher wenig hilfreich.
    Wie viel oder wie wenig dokumentiert werden muss, sollten Sie schon möglichst genau beschreiben. Auch, wer diese Dokumente wann und in welcher Form mit welchem Tool erstellt, wer ggfs. eine Qualitätssicherung durchführt (und wie) und auch was dann damit passiert (Wer bekommt was wann geliefert?). Fragen Sie sich bei jedem Dokument, wem es nützt. Fragen Sie Ihre Stakeholder. Nutzen Sie ruhig die ISO/IEC/IEEE 29119-3 um Ihre Stakeholder zu befragen, was Sie benötigen – sozusagen als Maximalliste. Und dann können Sie mit der entstandenen reduzierten Liste von Dokumenten die ISO/IEC/IEEE 29119-3 nochmals zu Rate ziehen, um Unterstützung bezüglich der Inhalte zu bekommen. Compliance sollte jedenfalls nicht ihr vorrangiges Ziel sein, sondern Nützlichkeit.
    

11. Dokumentation von Testprozessen in Projekttestplänen
    Das Unternehmen verlässt sich auf unseren hoch-kompetenten Testmanager um sicherzustellen, dass die effektivste Art des Testens durchgeführt wird. Dies wird durch ein Mentoren-Programm der Tester in den Scrum-Teams erreicht und schließt funktionale und nicht-funktionale Methoden, Testentwurfstechniken und Testtools ein, die entsprechend der ISO/IEC/IEEE 29119-1, -2 und -4 angepasst wurden. Zusätzlich definiert jedes Projekt die Testauswahl, Prioritäten und das Management. Außerdem muss jedes Projekt seine eigene Testumgebung, Retest/Regressionstestpraktiken und Abweichungsmanagementpraktiken definieren.
    Diese Inhalte werden über kontinuierliche direkte Interaktion mit den Stakeholdern während der Laufzeit des Projektes vereinbart. Dies gilt auch für die Vereinbarung der verschiedenen Dokumenten (Größe und Format).
    
    Aha, hier kommen Sie also doch noch ein wenig durch die Hintertür rein, die Prinzipien des Agilen Manifests. Und wieder klingt es für mich so, als wäre die Konformität zur Norm wichtiger. Was meinen Sie?
    Meine Empfehlung: reden Sie (wie im vorigen Punkt und sogar im Beispiel des Anhang E angedeutet) intensiv mit den Stakeholdern und nutzen Sie die Norm eher wie eine Checklisten des maximal Möglichen.

Nun wünsche Ich Ihnen viel Erfolg in der Anwendung und freue mich auf Ihr Feedback und Ihre Rückfragen. Gerne unterstütze ich Sie echt agil bei der Definition – Sie werden sehen, dass Dokumentation einer Teststrategie hilfreich sein kann. Nur das Beispiel aus Anhang E ist es meiner Meinung nach leider nicht.