Es handelt sich um ein Entwicklungsprojekt für eine Verwaltungssoftware. Die Software soll nach der Fertigstellung von der Öffentlichen Verwaltung genutzt werden und ist noch nicht produktiv. An der Software arbeiten zwei Scrum Teams parallel, welche sich über regelmäßige übergreifende Termine synchronisieren und in gut abgrenzbaren Bereichen der Software wirken.
1. Diskussionspunkt: Die Detailtiefe der Testdokumentation
Der Softwaretester vertrat die Auffassung, dass eine detaillierte Dokumentation sinnvoll sei, um die Nachvollziehbarkeit und Wiederverwendbarkeit von Testfällen zu gewährleisten. Daher wurde ein neuer Testfall vor seiner Ausführung mitsamt Testschritten und dem SOLL-Ergebnis in der Testverwaltungssoftware angelegt und einer neuen oder bestehenden Kategorie von Testfällen zugeordnet. Nach Durchführung des Testfalls wurde das IST-Verhalten in der dem Testfall zugeordneten Dokumentation festgehalten. Bei einer festgestellten Abweichung vom SOLL-Verhalten wurde auch der Fehler entsprechend dokumentiert. Durch diesen Prozess wurden im Schnitt ca. 5 Testfälle pro User Story erstellt. Das ergab bei durchschnittlich 10 User Stories pro Sprint 50 dokumentierte Testfälle zzgl. der im Zuge ihrer Ausführung zu erstellenden Artefakte (z. B. die Dokumentation der Testausführung). Der Entwicklungsleiter vertrat den Standpunkt, dass die Dokumentation der Testfälle einen zu großen Aufwand im Verhältnis zum Nutzen darstellt. Insbesondere der Aufwand, die steigende Anzahl von Testfällen, die mit dem Funktionsaufwuchs je Sprint einhergehe, aktuell zu halten, sei problematisch. Er sprach sich dafür aus, dass die Anzahl der Testfälle pro User Story erhöht, die Dokumentation allerdings darauf beschränkt wird, die identifizierten Fehler als Kommentare in der zugehörigen User Story festzuhalten.
Im Buch „Testing in Scrum: A Guide for Software Quality Assurance in the Agile World“ finden sich Informationen zu manuellen Tests (S. 114 ff.) und zum Management der Systemtests (S. 137 ff.). Außerdem wird auf die Nachverfolgbarkeit des Zusammenhangs zwischen Anforderung und Test eingegangen (S. 152). Als manuelle Tests werden Akzeptanztests (auch Abnahmetests genannt) und Explorative Tests aufgeführt. Die Basis für Akzeptanztests bilden die Akzeptanzkriterien der User Story. Anhand der Akzeptanzkriterien wird überprüft, ob ein Feature seine Funktion erfüllt. Beim explorativen Testen ist die testende Person an keine vordefinierten Kriterien gebunden. Es werden sämtliche verfügbare Informationsquellen (z. B. User Stories) herangezogen. Um exploratives Testen überprüfbar und messbar zu machen, wurde das Sessionbasierte Testen entwickelt. Es erweitert das Explorative Testen um einen formellen Rahmen, welcher eine kurze Beschreibung des Vorgehens und der durchgeführten Testschritte beinhaltet. Beide Testtypen sind jedoch von geringer Dokumentationstiefe geprägt. Nach Scrum sollen Fehler unmittelbar nach ihrer Identifikation und einer kurzen Analyse behoben werden. Eine detaillierte Dokumentation des Fehlers ist nicht gefordert. Hinsichtlich der Nachvollziehbarkeit des Zusammenhanges von Anforderung und Test wird betont, dass diese im Kontext sicherheitsrelevanter Softwareprodukte wichtig sei und eine Herausforderung in agilen Projekten darstelle. Das Ausmaß der Nachvollziehbarkeit richte sich hierbei vor allem nach externen Anforderungen.
Letztendlich wurde sich darauf geeinigt, dass pro User Story ein Testfall dokumentiert wird. Dieser Testfall beinhaltet lediglich das SOLL-Verhalten. Das Ergebnis der Testausführung wird nicht dokumentiert. In regelmäßigen Abständen werden die dokumentierten Testfälle gesichtet, bei Bedarf aktualisiert und kategorisiert. Sie dienen langfristig als Dokumentation des SOLL-Verhaltens des Systems. Über diese Dokumentation hinaus werden keine Testfälle, sondern nur identifizierte Fehler schriftlich festgehalten. Maßgeblich zur Konsensfindung beigetragen hat die Zusicherung der Entwicklungsleitung, Softwaretestende nicht für übersehene Fehler verantwortlich zu machen und zu keinem Zeitpunkt eine Dokumentation der Testfälle als Nachweis ihrer Arbeit zu fordern. Durch die deutliche Reduktion der Dokumentationspflichten wurde den Testenden mehr Freiraum für Kreativität eingeräumt und es wurden mehr Fehler identifiziert.
2. Diskussionspunkt: Der Zeitpunkt der Testautomatisierung
Die Grundfunktionen der Software waren zu Beginn vielen Änderungen unterworfen. Erst mit der Zeit nahmen die Anpassungen ab und die Umsetzungsgeschwindigkeit neuer Features nahm zu. Es herrschte Einigkeit darüber, dass schon zu Beginn der Entwicklung, unabhängig von Anpassungen an der Software, technische Tests automatisiert werden sollten. Bei der Automatisierung der Oberflächentests gingen die Meinungen jedoch auseinander: Einige Teammitglieder befürworteten eine möglichst frühe Automatisierung, andere sprachen sich für eine spätere Automatisierung und die Fokussierung auf ausgewählte Testfälle aus.
Auch zu dem Zeitpunkt der Testautomatisierung liefert das Buch „Testing in Scrum: A Guide for Software Quality Assurance in the Agile World“ Anhaltspunkte (S. 117 ff.). Die Automatisierung von Oberflächentests bringe einige Herausforderungen mit sich. Zum einen verändert sich die Oberfläche häufig im Entwicklungsprozess, was kontinuierliche Anpassung erfordere. Zum anderen müssen die Ergebnisse der Oberflächentests häufiger manuell ausgewertet werden als die Ergebnisse von automatisierten technischen Tests. Darüber hinaus wird erklärt, dass es, anders als bei technischen Tests, nicht möglich sei, Oberflächentests vor der Erstellung des Codes zu entwickeln. Außerdem wird auf den Nutzen von Schlüsselwortgetriebenem Testvorgehen hingewiesen. D. h. dass Serien von Klicks (beispielsweise die Auswahl eines Menü-Items) in einem Schlüsselwort zusammengefasst werden und die Erstellung eines neuen Oberflächentests durch die Kombination dieser Schlüsselworte erfolgt. Dadurch muss bei der Änderung der Oberfläche (z. B. des Menüs) nur die Implementierung eines Schlüsselworts angepasst werden.
Letztendlich wurde sich darauf geeinigt, dass freie Kapazitäten der Softwaretestenden, die nicht für andere Aufgaben im Projekt gebunden sind, in die Erstellung von automatisierten Oberflächentests investiert werden kann. Ab einer gewissen Reife des Entwicklungsstands wurde der Automatisierung von Oberflächentests zusätzliche Kapazität eingeräumt und zudem verstärkt auf die Verwendung von Schlüsselworten geachtet.
3. Diskussionspunkt: Das Testkonzept
Die Entwicklungsleitung zielte darauf ab, ein möglichst kompaktes Testkonzept zu erarbeiten. Im Wesentlichen sollte es die verschiedenen Teststufen beinhalten, eine Beschreibung wie diese in der Testmanagement Software abgebildet werden und erklären, wie dadurch die Fehleranfälligkeit reduziert wird. Allerdings sprach sich der Softwaretester für ein deutlich umfangreicheres Testkonzept aus, in dem u.a. eine Beschreibung des Aufbaus von User Stories und dem Branching des Code-Verwaltungssystems enthalten sein sollte. Die höchste Priorität gelte der Vollständigkeit.
Das Buch „Testing in Scrum: A Guide for Software Quality Assurance in the Agile World“ behandelt das Thema der Dokumentation im Zuge des Qualitätsmanagements ebenfalls (S. 141 ff.): In vielen Organisationen existiere eine große Zahl von Qualitätsmanagement-Dokumenten, deren regelmäßige Anpassung viel Zeit koste. Das führe dazu, dass notwendige Änderungen der Dokumente, insbesondere aufgrund der Abstimmungsrunden in großen Projekten, häufig hinausgezögert werden. Die Schlussfolgerung des Buchs: Es ist besser wenigen Regeln zu folgen als ein komplexes System von Regeln zu ignorieren, welches nur auf dem Papier existiert. Daher wird empfohlen, komplexe Beschreibungen durch Diagramme zu ersetzen und etablierte Standards (z. B. die Definition of Done) lediglich zu referenzieren.
Schlussendlich war die Lösung ein Kompromiss: Das Testkonzept beschränkt sich auf die wesentlichen Inhalte, aber beinhaltet alle relevanten Aspekte und referenziert andere Dokumente, um den Anpassungsaufwand zu minimieren. Somit umfasst das Testkonzept lediglich vier Seiten und kann durchgehend auf dem aktuellen Stand gehalten werden.
