Anforderungsmanagement meets Softwaretest

... idealer geht’s kaum: Man sitzt mal da (Systemanalyse ¹) und mal dort (Softwaretest) – und jetzt gilt es einen Artikel zu verfassen, der beide Disziplinen gegenüberstellt. Der geneigte Leser erwartet sich selbstredend – wie es der Artikeltitel ankündigt – Erfolgsfaktoren.

¹ Systemanalyse, genau gesagt Systemanalyse 3.0 beinhaltet für mich Business Analyse (→ http://www.iiba.org/babok-guide.aspx), Requirements Engineering (→ https://www.ireb.org/de) und noch ein bisschen mehr

Vordergründig keine große Sache, das kann man ja im Schlaf! Okay, wie das tun? Also, einfach ausreichend Melatonin-Konzentration im Blut aufbauen (durch Licht aus). Damit geht die Herzfrequenz runter, Temperatur und Blutdruck sinken ebenfalls. Jetzt Augen zu und ab in die erste Tiefschlafphase.

Wir wissen, alle Sinne bleiben im Schlaf aktiv und somit sollten wir in diesem Zustand wiedergeben können was ohnedies jeder weiß:

1. Ausreichend richtige Dokumentation
2. Verständnis für ein „Miteinander“ i.S. von ungeteilter Verantwortung für den Erfolg und Prinzip des Helfens
3. Kontinuierliche Abstimmung im Rahmen der Entwicklung der
   Lösung

Nun, und wie machen wir das?

Richtige Dokumentation: Zumindest just enough, aber abgesichert; fragen Sie sich und andere im Team, was dokumentiert werden muss (i.S. von Menge, Art, ...) und vor allem: Für wen und welchen Zweck! Vermeiden Sie insbesondere Dokumentation, die „wir immer schon gemacht haben, aber nicht mehr wissen, wofür“. Ich selbst habe in meiner ersten Zeit als Datenbankadministrator im wahrsten Sinne des Wortes tonnenweise Papier bedrucken lassen – mit Listen und Reports, die keiner wirklich mehr gelesen hat. Bei Beschreibungen von Applikationen fokussieren Sie sich bitte eher darauf, was in der Applikation selbst nicht zu sehen ist (z.B. Feldfunktionen und Geschäftsregeln), weniger bzw. gar nicht, was ohnedies jeder sieht. Hier ist die Applikation selbst die beste „Dokumentation“. Verständnis für einander, Prinzip des Helfens: Versuchen Sie ernsthaft eine gemeinsame „Haftung“ für den Erfolg zu vereinbaren. Wenn Analysten,  Programmierer und Tester („The Three Amigos“²) gemeinsam für das Endergebnis gerade stehen müssen, müssen Sie verstehen, was der jeweils andere macht, wann er was wie braucht – und Sie selbst werden sich auch fragen, wie Sie die anderen am besten unterstützen können, insbesondere, wenn’s bei denen „zwickt“.

² The Three Amigos – „Business Analyst, Developer and QA“; nach: https://www.scrumalliance.org/community/articles/2013/2013-april/introducing-the-three-amigos

Eine Abgrenzungspolitik à la „ich bin fertig, jetzt sind die anderen dran“ hilft erfahrungsgemäß nicht. Kontinuierliche Abstimmung: Anforderungen sind am Start nicht zu 100% formulierbar und fixierbar. Eine User Story z.B. ist eine Einladung zum Gespräch, nicht mehr und nicht weniger.

Wir wissen zum „Gesprächsbeginn“ worum es geht – aber haben noch viel Klärungsarbeit vor uns (z.B. Definition der Akzeptanzkriterien), werden die jeweils andere Sicht nutzen um ein noch besseres, griffigeres und abgestimmteres Zielbild zu entwickeln. Am Ende der Abstimmung steht die analysierte, programmierte, getestete und abgenommene Funktion. D.h. planen Sie viele Treffpunkte zum Gespräch ein und nutzen Sie diese Termine für eine Präsentation des jeweils aktuellen Standes. Damit vermeiden Sie Überraschungen und kommen pünktlich und abgestimmt ins Ziel. Aber betrachten wir mal die Kontrahenten Software Tester und Systemanalysten in diesem Spiel jeweils für sich; was würde man der jeweiligen „Seite“ an Tipps in der Zusammenarbeit mit den anderen mitgeben? Ein paar Überlegungen dazu folgend.

Software Tester

Seit Jahren wird das jeweilige „Inseln der Seligen“-Konstrukt, d.h. der Schaffensbereich der Systemanalysten einerseits und Tester andererseits, aufgebrochen. Es gibt kaum noch Projekte, wo jeder für sich allein arbeitet. Selbst „unabhängige“ traditionelle Testteams können sich nicht mehr allein auf ihre ISTQB-Theorie und ihre Praxis im Softwaretest allein stützen.

Durch die stärkere Verzahnung mit den Three Amigos sind wechselseitige Hilfe und damit Verständnis für die jeweils „anderen“ Disziplinen gefordert. Ein Software Tester heute muss neben  ISTQB ³ und Softwaretest-Praxis viele weitere Kenntnisse mitbringen: Branchen-Know-how, Systemanalyse-Fähigkeiten und für z.B. Testautomation und Continuous Delivery (zumindest Einstiegs-) Programmierkenntnisse.

³ Bitte nageln Sie mich nicht auf ISTQB fest – es gibt auch viele andere gute Wege, Softwaretest Theorie aufzubauen und sich prüfen zu lassen; aber wie auch immer Sie dazu stehen, ISTQB ist auch ein Weg ...

Konkret sind für die Software Tester durch die Einführung von „User Story’s“ die Anforderungen an das System nicht mehr so umfangreich beschrieben, wie Vergleichsweise in Projekten mit Lasten- und Pflichtenheften. Dennoch waren und sind auch diese nicht wirklich ausreichend spezifizierend! Viele Aspekte müssen Software Tester im Kontext einfach schon wissen oder weiter erfragen. Dieses Wissen wird in Form von Testkonzepten, -plänen, -fällen und -durchführungsprotokollen dokumentiert. Leider sehr oft nicht mit dem Verständnis und Rückschluss, dass damit die zugrunde liegenden Pflichtenhefte erweitert bzw. detailliert werden müssen!
Würde ich einem Software Tester beschreiben müssen, was im Kontext mit Anforderungen auf Basis von User Story’s wichtig ist, so würde ich das – in Ergänzung zu den oben stehenden Empfehlungen – auf eine Handvoll Tipps zusammenfassen:

• Ein „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“ ist viel mehr als nur ein Satz. Der Kontext der User Story, wie die Verknüpfung zum Anwendungsfall, Informationen zur Schätzung, Priorität, ... bilden den Rahmen, der Life-Cycle-Status der User Story bestimmt den notwendigen Detaillierungsgrad. Blicke über den Tellerrand und kümmere dich einmal mehr darum, was nicht geschrieben steht!
• ... fundamental und wichtig: Akzeptanzkriterien! Am besten auch in Form von Templates, wie z.B. BDD ⁴. Daraus leitet man ab, was die User Story „done“ macht, was die „Nicht-Ziele“ sind und was zu testen ist. Halte an dieser Stelle unbedingt auch nach den nicht funktionalen Anforderungen Ausschau!

... richtig erkannt! Alle Tipps gelten auch für was-auch-immer-eine-Anforderungsbeschreibung: Einfach „User Story“ durch „Anforderung“ ersetzen! :-)

⁴ BDD – Behavior Driven Development; Akzeptanzkriterien werden dabei in Form von Sätzen wie „Angenommen <Vorbedingungen>, wenn <Aktion>, dann <Ergebnis>“ formuliert

Systemanalysten

Der Zusammenhang zwischen den Arbeitsergebnissen von Systemanalysten und Software Testern erschließt sich meiner Meinung nach im Kontext der Qualitätssicherung von Anforderungen und bei der Verwendung von Anforderungen für den Soll-Ist-Vergleich, also der Ableitung von Testfällen aus den Anforderungen. Anforderungen, Ziele und Aufgabenstellungen kommen in der Wertschöpfungskette „vorne“ rein, werden Schritt-für-Schritt realisiert und dabei konkretisiert, ggf. auch verändert und müssen am Schluss eine Aussage zu Soll und Ist ermöglichen. Richtig und vollkommen klar ist somit die Feststellung, dass eine Anforderung eigentlich frühestens dann „done“ ist, wenn die Software live gegangen ist. Ob agil oder nicht – die Nachverfolgbarkeit von Anforderungen ist aus Qualitätssicherungssicht fundamental. Und natürlich brauchen wir auch testbare Anforderungen. Okay, also was bedeutet das im Detail?

Nachverfolgbarkeit von Anforderungen

... nochmals zu den User Story’s, die eigentlich nur einen sehr groben Rahmen und allgemein gesprochen einen Platzhalter für Anforderungen bieten: Sie erheben keinen Anspruch auf Vollständigkeit. Erst durch die Akzeptanzkriterien werden die User Storys konkretisiert bzw. das Verhalten der User Story aus Sicht des zugrundliegenden Geschäftsmodells klar („Confirmation“, siehe nachstehende Grundregeln zur Erstellung einer User Story).

Grundregel zur Erstellung einer User Story – die 3 c’s (Ron Jeffries):
Card: Eine User Story sollte so kurz und prägnant sein, so das sie auf einer Karteikarte Platz hat

Conversation: Es sollte mehrfacher persönlicher Austausch über eine User Story zwischen Kunde/Product Owner und Entwicklerteam stattfinden. Die Kommentare werden meist auf der Rückseite der Karte erfasst

Confirmation: Durch die Festlegung von Akzeptanzkriterien kann die erfolgreiche Umsetzung einer User Story vom Kunden abgenommen werden (inkl. der anderen DoD Kriterien)
Quelle: frei nach http://ronjeffries.com/xprog/articles/expcardconversationconfirmation

Akzeptanzkriterien unterstützen bei der Abgrenzung (In/Out of Scope?), bei der Konkretisierung bzw. Präzisierung (Fachbereich bzw. Projektmanager/PO machen ihre/seine Erwartungshaltungen klar bzw. helfen sie dem Entwicklungsteam genau zu verstehen, was Inhalt der User Story ist) und sind Bindeglied zwischen User Story und Testfällen. Akzeptanzkriterien sind so lange zu erheben bis alle Fragezeichen zu einer spezifischen User Story aufgelöst sind. Werden Fragezeichen nicht aufgelöst, exponiert man sich durch mangelhafte Qualität -> Risiko Kundenzufriedenheit (Termintreue und Qualität). By-the-way: Akzeptanzkriterien können sich auch auf andere Elemente der Wertschöpfung beziehen: Epics und andere Iterationsfeatures werden oft mit Akzeptanzkriterien versehen.In der Literatur und gängigen Praxis bedeutet „Nachverfolgbarkeit“ (oder „Traceability“) von Anforderungen:

Die Darstellungen der Beziehungen

• von Anforderungen zu anderen Anforderungen (welche Anforderung trägt zur Erfüllung welcher anderen Anforderung bei),
• zu den Quellen der Anforderungen (also wo kommen sie her: Aus Dokumenten, Workshops, Gesprächen...) und
• zu den Entwicklungs-Artefakten (also Testfälle, Programmcode)

Demzufolge spricht man von „Pre-Requirement Specification Traceability“, „Traceability zwischen Anforderungen“ sowie „Post-Requirement Specification Traceability“. Die Nachverfolgbarkeit kann man mit verschiedenen Mitteln sicherstellen.

Denk daran, dass eine entsprechende Toolchain dabei unterstützt! Voraussetzungen für die Nachverfolgbarkeit sind auch,

• dass bei jeder Anforderung die Quelle festgehalten wird,
• dass die Anforderungen zueinander in Beziehung gesetzt werden
• und dass auch die Testfälle und Programming-Tickets in Beziehung
  zu den Anforderungen gesetzt werden.

Egal ob das Projekt traditionell oder iterativ entwickelt wird: Anforderungen sind generell aktiv zu managen! Anforderungen ändern sich über die Projektlaufzeit, Anforderungen kommen hinzu oder werden ausgeschieden – in Wirklichkeit immer und zu jeder Zeit. ⁵

⁵ Dies trifft auch auf klassisch geführte Projekte zu, die auf Lasten und Pflichtenheften aufgebaut sind – nach deren Implementierung sind die Systeme im Regelfall durch Changerequests zu aktualisieren

 
Im Laufe des Projekts wächst im Regelfall der Zeitdruck und „Abkürzungen“ in den vorgegebenen Prozessen verlocken „ein Detail mal schnell abzuklären“. Vor diesem Hintergrund empfehle ich die Nominierung eines Prozessverantwortlichen: Er/sie kann projektphasenbezogen die Standardprozesse hinterfragen (Mehrwert gegeben?) und ggf. anpassen (verschlanken?). Dennoch ist von grundlegender Bedeutung, dass Disziplin und ganzheitliches Denken eingehalten werden.

Ohne strukturierte Erfassung und Verwaltung von Anforderungen entsteht zwangsläufig Chaos! In iterativen Projekten verschärft sich diese Problematik noch weiter. Allgemein geht man davon aus, dass Anforderungen nicht wie in traditionellen Modellen, wie z.B. beim V-Modell XP, zu Beginn des Projekts umfassend erhoben und festgelegt werden.

Agilen Methoden folgend werden Anforderungen zu Beginn nur grob erhoben -> ein Merker für ein ausstehendes Gespräch (= User Story) als ein Dokument, das alle Details enthält. Anforderungen werden erst dann detailliert, wenn sie kurz vor der Implementierung stehen („just in time“). Damit wird versucht, „waste“ im Sinne von noch nicht notwendiger Anforderungen zu vermeiden, die durch Änderungen wieder zu aktualisieren wären (-> agile Manifesto „respond zu change“).

User Stories erfordern ein Umdenken. Details werden nicht mehr weit im Vorfeld der Story ausgearbeitet und aufgeschrieben, sondern erst, wenn die User Story konkret wird.

Weitere Aspekte, die bei agilen Realisierungen berücksichtigt werden
müssen:

• Kürzere Analysezyklen -> höherer subjektiver Zeitdruck
• Kleinere Stücke, task-orientiert -> mehr Artefakte
• Weniger Dokumentation -> Notwendige Klärung der Stakeholder
  Anforderungen, damit keine Dokumente später nachträglich erstellt werden müssen
• Mehr Kommunikation -> Knowhow, wie Gespräche in Anforderungen gewandelt werden
• Auflösung der klassischen Rollenbilder (Analytiker – Entwickler – Tester ) -> alle „dürfen“ Anforderungen erheben

Zusammengefasst ist von vielen kleinen jederzeit änderbaren Realisierungseinheiten auszugehen, die zusammenzuhalten sind.

Testbare Anforderungen

Wir haben jetzt kurz über Nachverfolgbarkeit von Anforderungen gesprochen – aber wie schaut’s mit der Testbarkeit von Anforderungen aus? Allgemein gesprochen sind Anforderungen nur dann sinnvoll testbar, wenn sie folgenden Kriterien entsprechen:

• Konsistent
• Vollständig
• Eindeutig (nur eine Interpretation der Anforderung möglich)
• Quantitativ formuliert (vgl.: „schnelle Antwortzeit“ kann nicht verifiziert werden)
• Praktisch verifizierbar (d.h. mit begrenzten Aufwand durchführbar)

Wie kann somit die Testbarkeit der Anforderung bei der Erhebung und Dokumentation gewährleistet werden? Konzepte, Konzeptmodelle, Geschäftsanwendungsfälle, funktionale und nicht funktionale Anforderungen werden das Ergebnis der Analysetätigkeit sein. Die Systembeschreibung wird aus allgemeinen Einleitungen, Use Cases und Features sowie Subfeatures (und Sub-Subfeatures) bestehen.

Werden die oben stehenden Kriterien (Konsistenz, Vollständigkeit, ...) eingehalten, ist Testbarkeit der Anforderung gegeben -> diese Kriterien müssen bei der Erhebung und Dokumentation berücksichtigt werden. Für die User Storys, die ja nur einen groben Rahmen bieten, sind Akzeptanzkriterien zur Konkretisierung festzulegen. Diese werden im Rahmen von Gesprächen mit den Stakeholdern definiert. Üblicherweise haben Projektleiter/POs bzw. die Featureteams viele Fragen, die zu einer ausreichenden Abgrenzung anhand von Akzeptanzkriterien führen.

Methodisch kann man auch die Ableitung von Fragen anhand der Analyse der Schlüsselwörter mit Fragenstellungen („W“-Fragen) absichern. Wie in obiger Abbildung exemplarisch ausgeführt, basiert die Methode darauf Schlüsselwörter aus den User Storys abzuleiten und mit einem vorbereiteten Fragenkatalog ⁶ zu hinterfragen.

⁶ Anwendung des Fragenkatalogs solange Fragestellungen im Kontext sinnvoll sind, bzw. wenn diese die User Story sinnvoll ergänzen bzw. konkretisieren

Abhängig von den Antworten werden Akzeptanzkriterien erstellt, wobei mehrere Antworten zu einem Akzeptanzkriterium zusammengefasst werden können. Abschließend sind nur noch korrespondierende Testfälle zu formulieren.

Empfehlung: Da die User Story‘s mit ihrer Erfüllung („Done“) am Ende ihres Lifecycles sind, ist zu bewerten: In welchem Umfang sollten diese künftig im Rahmen des Regressionssets weiterverwendet werden, wobei davon auszugehen ist, dass die Testfälle bei diesem Schritt auch nochmals verändert werden. Durch diesen Re-Use werden explizit die systembeschreibenden Artefakte (Use Case und Features ) zyklisch getestet.