A few weeks ago I gave a presentation about acceptance criteria and agile testing to a team of developers I’m working with.
Some of the developers were familiar with agile processes & test driven development, but some were not. I introduced the idea of behavior driven development, with both rspec “it should” and gherkin “given/when/then” style syntax. I stressed that the exact syntax is not important, but consistency helps with understanding and can also help avoid “testers block”.
It’s a Java shop, but I didn’t get into the details of JBehave, Cucumber or any other frameworks. I pointed out that you can write tests this way without implementing the automation steps and still get value — with the option of completing the automation later. This is particularly valuable in a system that is difficult to test, or has external dependencies that aren’t easily mocked.
Here are the slides:
Acceptance Criteria Presentation [PDF] or [PPTX]
And a rough approximation below:
Acceptance Criteria
how to make it easier to know if what you’re doing is what they want you to do
What are Acceptance Criteria?
By any other name…
● Requirements
● Use Cases
● Features
● Specifications
● User Stories
● Acceptance Tests
● Expected Results
● Tasks, Issues, Bugs, Defects,Tickets…
What are Acceptance Criteria?
…would smell as sweet
● A way for business to say what they want
● A way for customers to describe what they need
● A way for developers to know when a feature is done
● A way for testers to know if something is working right
The “Agile” definition
User Stories
As a … [who]
I want to … [action]
So that I can … [result]
Acceptance Criteria
Given … [some precondition]
When … [action is performed]
Then … [expected outcome]
(Gherkin style)
Acceptance Criteria
Describe [the system] … [some context]
It (the system) should … [expected result]
(“should” syntax)
Shh…don’t tell the business guys
it’s programming
but can be compiled by humans…and computers!
Inputs and Outputs
if I enter X + Y
then the result should be Z
f(x,y) = z
Not a proof
or a function
or a test
or a requirement
or …
It’s just a way to help everyone understand
It should
- Describe “it”
(feature/story/task/requirement/issue/defect/whatever) - Give steps to perform
- List expected results
Show your work
● Provide examples
● List preconditions
● Specify exceptions
A conversation not a specification
Do…
● use plain English
● be precise
● be specific
Don’t…
● worry about covering everything
● include implementation details
● use jargon
● assume system knowledge
Thanks!
If you’re interested in learning how to turn your manual testing process into an agile automated test suite, I can help.
Aaron Evans
aarone@one-shore.com
425-242-4304
