Should I specify user story acceptance criteria in Given/When/Then format or checklists?

Question

As far as I understand Given/When/Then format of acceptance criteria is used when the project is going to follow BDD (Behavior Driven Development). Thus, the acceptance criteria will be used for the automated tests, while checklists are aimed for manual testing. The question is: "When should we use the checklist format of describing User Story acceptance criteria and when should we use Gherkin format?"

Answer 1

It depends, does it help the team in better using them as requirements and does it improve communication with stakeholders? Then yes. Just discuss with the team which they think gives the most value for the project.

GTW adds a bit of extra work. Also it might make it harder to read and understand instead of one liner high level acceptance criteria, since now you need to read three or more sentences.

If you use BDD or automate them afterwards anyways, then it seems better to start with GWT from the beginning of a task. Personally I think GWT is about communication between developers and non-technical stakeholders. If you do not use it in this way it will be overhead, maybe use TDD instead.

I would use INVEST and verify the requirements and acceptance criteria are clear enough for the team during estimation of units-of-work.

Answer 2

The main goal of manual testing (aka exploratory testing (also called only testing, since no machine really tests)) is to raise new information about the product - beside bugs, this technique raise questions about non-functional requirements, UX improvement opportunities, etc.

This new information creates new acceptance criteria, which should be included in the Given/When/Then scenarios, even a posteriori (remembering the agile value 'Responding to change over following a plan').

Adding, the Given/When/Then scenarios has nothing to do with testing. They are the requirements of the feature. All information about the feature behavior should be included as a Given/When/Then scenario (directly or indirectly, by links to sites/files (which should be very rare)), in order to allow all team members to understand how the system should behave.

If a scenario can be automatically checked, great; but even if it cannot be checked by a machine, it should be included in the .feature file.