Software-Test / Testmanagement

Das Testhandbuch – Testmanagement trifft Vertragsrecht

Oft stehe ich am Anfang meiner Testprojekte vor der Aufgabe, Erwartungen des Auftraggebers an die Qualität in konkrete Testziele und somit auch in Abnahmekriterien zu überführen. Leider kommen zu diesem Zeitpunkt die Abnahmekriterien oft  zu spät, da mit der Entwicklerfirma im Vorfeld bereits Abmachungen getroffen und vertraglich fixiert wurden. Die dadurch entstehenden rechtlichen Konflikte mit der Entwicklerfirma lassen sich verhindern, wenn bereits bei Vertragsabschluss ein geeignetes Testhandbuch vorliegt – und im Auftrag darauf verwiesen wird.

Testhandbuch_Keyvisual

Aber welche Probleme bergen schlecht formulierte Abnahmekriterien? Einerseits hat der Auftraggeber natürlich ein Interesse, eine fehlerfreie Software zu bekommen. Dass aber ein Schönheitsfehler die Abnahme verhindern kann und somit einen Produktivsetzungstermin gefährdet, ist meistens auch nicht im Interesse des Auftraggebers. Die Entwicklungsfirma auf der anderen Seite möchte gerne, dass eine Abnahme auch mit relativ vielen Fehlern noch erfolgen kann – auch wenn es sich um schwerwiegende Fehler handelt. Schließlich sind hier Zahlungsziele im Spiel. Formulierungen wie „eine fehlerfreie Software“ helfen hier keiner Partei wirklich weiter.

Doch nicht nur die Abnahmekriterien können zu Konflikten führen. Welche Festlegungen das Testhandbuch treffen sollte, hängt vom konkreten Umfeld ab. Einige der Wichtigsten sind nach meiner Erfahrung:

 

1. Abnahmekriterien für das Endprodukt

  • Wie viele Fehler, welcher Fehlerschwere dürfen bei der Abnahme noch enthalten sein?
    Z.B. keine schweren oder kritischen Fehler, maximal 10% der gefundenen leichten und 30% aller gefundenen Schönheitsfehler.
  • Wie viele Testfälle sind durchzuführen und mit welchem Ergebnis?
    Z.B. mindestens 1 Testfall für jede hoch oder mittel priorisierte Anforderung, Test von min. 50% der niedrig priorisierten Anforderungen. Dabei besteht wiederum eine Abhängigkeit zum vorangegangenen Punkt, denn wenn leichte und Schönheitsfehler offen sein können, werden nicht alle Testfälle auf „passed“ stehen.

 

2. Eine präzise Beschreibung der Fehlerschwereklassen

Sie verhindert Diskussionen bei der Bewertung von Fehlern.

Beispielhafte Fehlerschwereklassen

 

3. Inhalt und Akzeptanzkriterien für (Zwischen-) Lieferungen

Das sind zum Beispiel:

  • Installationsdateien
  • Installationsanweisungen (oder installierte Anwendung auf dem Testserver)
  • Releasenotes

 

Weitere sinnvolle Festlegungen betreffen:

  • Verantwortlichkeiten / Unterstützungsleistungen während der Testphase
  • (Mindest-)Dauer der Abnahmephasen
  • Fehlerbehebungsfristen – bis wann müssen Fehler nach der Abnahme behoben werden
  • Zu verwendende Fehlermanagementtools und –workflows
  • Nachweispflichten (z.B. Dokumentation des Systemtests)

Aber steht das alles nicht im Testkonzept des Projekts?

Idealerweise ist es so: Das Testkonzept wird zu Beginn des Testprojekts durch den Testmanager erstellt und ist „Ein Dokument, das u.a. den Gültigkeitsbereich, die Vorgehensweise, die Ressourcen und die Zeitplanung der beabsichtigten Tests mit allen Aktivitäten beschreibt.“ [Glossar des ISTQB]. Festlegungen im Testkonzept wirken sich direkt auf den Aufwand des Herstellers bei der Vertragserfüllung aus. Während mehr Klarheit beim Vorgehen im Abnahmetest von allen Beteiligten begrüßt wird, wird bei einer Konkretisierung der Abnahmekriterien hart verhandelt. Warum sollte die Entwicklerfirma potentiell erschwerten Bedingungen zustimmen? Das von Testexperten empfohlene Vorgehen, das Testprojekt gleichzeitig mit dem Entwicklungsprojekt zu beginnen, ist in der Praxis jedoch oft nicht umsetzbar. Verträge sind schon geschlossen, wenn das Testkonzept erstellt wird, Nachverhandlungen schwierig.

Verhindern lässt sich ein Streit, wenn Abnahmekriterien und Vorgehen im Abnahmetest bereits vor Vertragsabschluss bekannt sind. Eine mögliche Lösung hierfür ist die Festlegung im Testhandbuch und die Verankerung desselben als Vertragsbestandteil.

Ein zusätzlicher Vorteil besteht in der Standardisierung aller Testprojekte: Das Testhandbuch kann durch einen erfahrenen Testmanager auf Basis der Erkenntnisse aus vergangenen Projekte erstellt werden oder es wird für das Unternehmen aufgrund vereinbarter Qualitätsziele erstellt. Der Umfang des Testhandbuchs hängt dabei vom konkreten Umfeld ab. Es gilt: Soll eine Vereinbarung aus einem Projekt auch in künftigen Projekten eingehalten werden, sollte sie in das Testhandbuch aufgenommen werden. Das Testhandbuch wächst so zu einem Leitfaden für gute Testpraxis heran. Trotzdem sollte man bei jeder Festlegung bedenken: Qualität kostet. Werden unnötig strenge Vorgaben gemacht, so wird das die Entwicklung teurer machen und eventuell eine planmäßige Produktivsetzung verhindern.

Die Verwendung eines Testhandbuchs als Vertragsbasis schafft letztlich Sicherheit bei Auftraggeber und Auftragnehmer. Gerade bei Kleinprojekten hat mir ein Testhandbuch manchmal gänzlich die Erstellung eines Testkonzepts erspart: Festlegungen wie Zeitplan, Testbasis-Dokumente und erwartete Ergebnisse wurden im Rahmen der Auftragsklärung besprochen und dokumentiert. Alles andere war bereits durch das Testhandbuch vordefiniert. So ist es auch bei Status- und Zwischenberichten leichter das gemeinsame Ziel im Auge zu behalten: die Abnahme.

Passende Artikel

Kommentare gesperrt.