Soweit ich weiß, wird das Gegeben/Wann/Dann -Format der Akzeptanzkriterien verwendet, wenn das Projekt BDD (Behavior Driven Development) folgen soll. So werden die Akzeptanzkriterien für die automatisierten Tests verwendet , während Checklisten für manuelle Tests vorgesehen sind . Die Frage lautet: "Wann sollten wir das Checklistenformat zur Beschreibung der Akzeptanzkriterien für User Storys verwenden und wann sollten wir das Gherkin-Format verwenden ?"
Es hängt davon ab, hilft es dem Team, sie besser als Anforderungen zu nutzen, und verbessert es die Kommunikation mit Stakeholdern? Dann ja. Besprechen Sie einfach mit dem Team, was ihrer Meinung nach den größten Wert für das Projekt bietet.
GTW fügt ein wenig zusätzliche Arbeit hinzu. Außerdem könnte es schwieriger sein, anstelle von Akzeptanzkriterien mit einem Liner auf hoher Ebene zu lesen und zu verstehen , da Sie jetzt drei oder mehr Sätze lesen müssen.
Wenn Sie BDD verwenden oder sie sowieso nachträglich automatisieren, scheint es besser, mit GWT von Beginn einer Aufgabe an zu beginnen. Ich persönlich denke, dass es bei GWT um die Kommunikation zwischen Entwicklern und nicht-technischen Interessengruppen geht. Wenn Sie es nicht auf diese Weise verwenden, wird es Overhead sein, verwenden Sie stattdessen vielleicht TDD.
Ich würde INVEST verwenden und überprüfen, ob die Anforderungen und Akzeptanzkriterien für das Team während der Schätzung der Arbeitseinheiten klar genug sind.
Das Hauptziel des manuellen Testens (auch bekannt als exploratives Testen (auch nur Testen genannt, da keine Maschine wirklich testet )) besteht darin, neue Informationen über das Produkt zu erheben – neben Fehlern wirft diese Technik Fragen zu nicht funktionalen Anforderungen, Möglichkeiten zur Verbesserung der Benutzererfahrung usw. auf .
Diese neuen Informationen schaffen neue Akzeptanzkriterien, die in die Gegeben/Wann/Dann-Szenarien aufgenommen werden sollten, sogar a posteriori (in Erinnerung an den agilen Wert „Reagieren auf Veränderungen statt Befolgen eines Plans“).
Hinzu kommt, dass die gegebenen/wann/dann-Szenarien nichts mit Testen zu tun haben. Sie sind die Anforderungen des Features. Alle Informationen über das Funktionsverhalten sollten als Gegeben/Wann/Dann-Szenario (direkt oder indirekt, durch Links zu Websites/Dateien (was sehr selten sein sollte)) enthalten sein, damit alle Teammitglieder verstehen können, wie das System funktionieren sollte sich verhalten.
Wenn ein Szenario automatisch überprüft werden kann, großartig; aber selbst wenn es nicht von einem Computer überprüft werden kann, sollte es in der .feature-Datei enthalten sein.
João Farias