Das Produkt gegen sein beabsichtigtes Verhalten testen
Spezifikationsbasiertes Testen ist eine definierte Verifikationsphase im SHAPE Framework. Ein vom Implementierungskontext des Coding-Agenten getrennter Verifikationsagent oder Modellkontext liest den eingecheckten Spezifikationsbestand und leitet daraus Prüfungen für das vorgesehene Softwareverhalten ab. Anschließend führt er die Implementierung nach Möglichkeit aus und dokumentiert das Ergebnis bezogen auf Anforderungen.
Diese Trennung ist wichtig, weil ein Implementierungsagent seine eigenen Missverständnisse in Tests wiederholen kann, die er aus gerade erzeugtem Code schreibt. Die unabhängige Ableitung aus Spezifikationen bietet eine andere Referenz. Sie ist eine nützliche zusätzliche Prüfung, keine Behauptung, Modelle seien grundsätzlich objektiv oder fehlerfrei.
Was der Verifikator erhält
Der Verifikator benötigt relevante Spezifikationen, ausreichend legitimen Kontext zum Verständnis des beabsichtigten Verhaltens und autorisierte Möglichkeiten, die Anwendung zu untersuchen oder auszuführen. Er darf das aktuelle Implementierungsverhalten nicht als Beweis für die Bedeutung einer Spezifikation behandeln. Bei Mehrdeutigkeit sollte diese gemeldet und nicht stillschweigend als neue Anforderung aufgelöst werden.
Was der Verifikator tut
Leiten Sie für jede wesentliche Anforderung geeignete repräsentative positive, negative, Grenz- und Berechtigungsprüfungen ab. Prüfen Sie Benutzerinteraktionen, Anwendungsschnittstellen oder anderes extern beobachtbares Verhalten nach Möglichkeit praktisch. Benennen Sie getestete Anforderungen, beobachtete Nachweise und nicht abgeschlossene Prüfungen. Bestehende Unit-, Integrations- und Ende-zu-Ende-Tests bleiben wertvoll; unabhängige spezifikationsbasierte Verifikation ergänzt sie.
Ergebnisse berichten
Ein nützlicher Bericht unterscheidet Bestanden, Fehlgeschlagen, Blockiert und Klärungsbedarf. Bei Bestanden werden beobachtetes Verhalten und Bezug zur erwarteten Anforderung genannt. Bei Fehlgeschlagen werden Abweichung und Reproduktionsschritte erfasst. Blockiert bezeichnet eine Einschränkung von Umgebung, Daten oder Zugriff. Klärungsbedarf bezeichnet eine Spezifikation, die keine vertretbare Beurteilung ermöglicht.
Der Product Engineer schließt die Schleife
Befunde gehen an den Product Engineer zurück. Er entscheidet, ob Software geändert oder Spezifikation präzisiert werden muss oder eine Einschränkung eine weitere Fach- oder Stakeholder-Entscheidung benötigt. Korrekturen werden erneut getestet. Die Spezifikation bleibt die Referenz für beabsichtigtes Verhalten; akzeptierte Änderungen dieser Absicht müssen erfasst werden, statt Tests stillschweigend an eine zufällige Implementierung anzupassen.
Was dies nicht beweisen kann
Ein Verifikationsagent kann Probleme übersehen, Anforderungen falsch lesen oder unvollständige Testabdeckung erzeugen. Auch eine vollständig bestandene Spezifikation kann wichtigen Geschäftsbedarf auslassen. Nachweise zu Sicherheit, Leistung, Barrierefreiheit und Regulierung können Fachmethoden jenseits funktionsbezogener Verifikation erfordern. Spezifikationsbasiertes Testen ersetzt weder Architektenprüfung noch UX-Urteil oder UAT.
Wo das Verfahren erklärt wird
Der Praxisleitfaden Spezifikationsbasierte Tests durchführen bietet einen wiederholbaren Ablauf und einen beispielhaften Ergebnisnachweis. Das Referenzprojekt zeigt eine kleine Nachverfolgung von Spezifikation zu Test.