In this blog post about acceptance criteria the author explains that good acceptance criteria should:
State an intent not a solution (e.g. “The user can choose an account” rather than “The user can select the account from a drop-down”)
Are independent of implementation (ideally the phrasing would be the same regardless whether this feature/story would be implemented on e.g. web, mobile or a voice activated system)
Are relatively high level (not every detail needs to be in writing)
And further details such as:
- The column heading is “Balance”
- The rolling balance format is 99,999,999,999.9 D/CR
- We should use a dropdown rather than checkboxes
should be moved to either a Team internal documentation or Automated acceptance tests
However, I often hear people frowning about using Cucumber or similar frameworks for doing GUI tests. Moreover, using an internal documentation could generate lots of problems due to failure to update the documentation regularly.
I'm still struggling to find an effective way to capture such details during the conversation with the customer.