Zweck
Spezifikationsbasiertes Testen bewertet die Anwendung anhand dokumentierten erwarteten Verhaltens durch einen Verifikationsagenten oder Kontext, der vom Implementierungskontext des Coding-Agenten getrennt ist. Es ergänzt die Prüfung von Implementierungsannahmen und macht Verifikationsergebnisse zu Spezifikationen rückverfolgbar.
Verantwortliche Teilnehmer: Unabhängiger Verifikationsagent oder -kontext, koordiniert durch den Product Engineer.
Eingaben: Eingecheckter relevanter Spezifikationsbestand, autorisierter Zugang zu Anwendung und Testumgebung, bekannte Beschränkungen, verfügbare repräsentative Daten.
Ergebnisse: Zuordnung von Anforderungen zu Prüfungen, beobachtete Ergebnisse, reproduzierbare Fehler, blockierte oder unklare Fälle und Bearbeitungsentscheidungen.
Vorgehen
1. Einen unabhängigen Kontext schaffen. Beginnen Sie die Verifikation mit eingecheckten Spezifikationen statt mit der Selbstdarstellung abgeschlossener Arbeit durch den Coding-Agenten. Der Verifikator darf vorhandenes Verhalten nicht als Definition von Korrektheit verwenden.
2. Relevante Anforderungen bestimmen. Lesen Sie die relevanten Funktionsspezifikationen und referenziertes gemeinsames Verhalten. Nehmen Sie bei Erweiterungen Anforderungen auf, die wahrscheinlich von der Änderung betroffen sind. Notieren Sie Anforderungen, die für einen vertretbaren Test zu unklar sind.
3. Prüfungen ableiten. Erstellen Sie Prüfungen für wichtiges Normalverhalten, Validierungs- und Ablehnungspfade, Grenzen, Berechtigungsunterschiede und gegebenenfalls Zustandsübergänge. Verknüpfen Sie Prüfungen mit stabilen Spezifikationskennungen oder klar identifizierbaren Bedingungen.
4. Das tatsächliche Verhalten erproben. Bedienen Sie die relevante Oberfläche oder API in der autorisierten Testumgebung und beobachten Sie das Ergebnis. Kann eine Anforderung nicht erprobt werden, dokumentieren Sie den Grund, statt ein Bestehen zu erfinden. Statische Untersuchung allein darf nicht als vollständige Verhaltensverifikation beschrieben werden.
5. Ergebnisse und Nachweise erfassen. Verwenden Sie vier klare Status: Bestanden, Fehlgeschlagen, Blockiert oder Klärungsbedarf. Ein nützlicher Fehlerbericht nennt verletzte Anforderung, Erwartung, tatsächliches Ergebnis und Reproduktionsschritte. Nachweise können die Form annehmen, die Projektwerkzeuge und Datenschutzbeschränkungen erlauben.
6. Mit dem Product Engineer einordnen. Bestimmen Sie, ob ein Problem ein Implementierungsfehler, eine fehlende Testmöglichkeit, eine unklare Spezifikation oder eine berechtigte Änderung akzeptierter Absicht ist. Verweisen Sie Geschäftsregelentscheidungen an ihre Verantwortlichen. Aktualisieren Sie Spezifikationen bei geänderter akzeptierter Absicht.
7. Korrigieren und wiederholen. Implementieren Sie freigegebene Korrekturen und wiederholen Sie betroffene Prüfungen sowie passende Regressionsprüfungen. Bewahren Sie die Unterscheidung zwischen bestandenen und noch nicht erprobten Anforderungen.
8. Verifikationszusammenfassung vorbereiten. Benennen Sie geprüften Umfang, offene Fehler oder Blockaden, Grenzen der Abdeckung und ungeklärte Punkte. Stellen Sie dies für die abschließende Architektenprüfung oder die entsprechende Erweiterungszyklusprüfung und die UAT-Vorbereitung bereit.
Beispiel eines Ergebnisnachweises
| Spezifikationsprüfung | Erwartetes Verhalten | Beobachtetes Ergebnis | Status | Nächste Maßnahme |
|---|---|---|---|---|
| SPEC-001 / AC-01 | Eine Anfrage kann ohne Pflichtfelder nicht abgesendet werden | Absenden wurde verhindert und die fehlende Kategorie angezeigt | Bestanden | Keine |
| SPEC-001 / AC-03 | Nur autorisierte Prüfer dürfen zugewiesene Anfragen entscheiden | Nicht autorisierter Entscheidungsversuch wurde abgewiesen | Bestanden | Keine |
| SPEC-001 / AC-05 | Ablehnung erfordert eine Begründung | Anfrage wechselte mit leerer Begründung zu Abgelehnt | Fehlgeschlagen | Verhalten korrigieren und erneut testen |
| SPEC-001 / AC-07 | Antragsteller sehen keine privaten Details anderer Antragsteller | Repräsentative Testidentitäten waren nicht verfügbar | Blockiert | Freigegebene Testmöglichkeit organisieren |
Diese Tabelle veranschaulicht die Statuszuordnung; ihre Beispielergebnisse sind fiktiv und keine Nachweise aus einer realen Implementierung.
Abschlusskriterien
Für wesentliche Anforderungen sind Status dokumentiert; Fehler und Unklarheiten wurden behandelt oder gemäß etablierter Abnahmerichtlinie ausdrücklich weitergeführt; Testeinschränkungen sind transparent; und Änderungen wurden angemessen erneut getestet. Der Bericht übertreibt den gebotenen Nachweis nicht.
Häufige Probleme vermeiden
Den Implementierungsagenten seine eigenen Ergebnisse ohne unabhängige Quelle der Absicht zertifizieren lassen; eine generierte Liste nie ausgeführter Tests akzeptieren; blockierte Prüfungen stillschweigend als bestanden behandeln; Spezifikationen an zufälliges Verhalten anpassen; und Testerfolg als Ersatz für UAT oder fachliche Risikonachweise darstellen.