# The Holy Grail – Getting Your Customers to Write Acceptance Tests
Doug Alcorn @dougalcorn

TL;DR – Nothing predicts the success of your project better than how well and often you communicate directly with your client.

Who are Clients – Client, Customer, Product Owner, Stakeholder, Co-workers, Boss, other Manager
The Client is the person/people who really cares about what you are building
“One of the most difficult roles in an agile process is the product owner or agile customer” – Jeff Patton
XP turns the engineering practices up to 11, but the product owner/business doesn’t really get any better, which makes it harder

Testing evolution – Shoulda – started to better document tests by using a better, standard syntax with room for readability
RSpec improved it further and facilitated Behavior Driven Development
Naming things is one of the hard problems of computer science – these tools allow us to name things better.
Capybara drives Selenium with readable code to do integration level testing. Provides an impressive experience by driving the browser, but doesn’t really tell anyone how the application really works.
“You only have to write integration tests for the code you want to work”
Writing the code and the tests at the same time is TOO LATE – you need to know what the user wants before you get into coding.
Cucumber is readable English that in theory can be written by the customer. Except that it really can’t. We’re still looking at the grass (the trees are still way above us and completely forget about the forest)

You Said, They Said – you have a deliverable due at the end of the interation. You often don’t deliver what the client expected. That is what acceptance testing is for.
Even with wireframes there is a disconnect between the way the client envisions the software and the developers understanding.
Gherkin is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implmented.
Given, When, Then
Cucumber uses Gherkin and it is readable, but it is still not at the appropriate level for clients

Work with the customer every day, show the test results, get feedback, improve.
Convince the customer of the value of having these acceptance tests – that the tests will enable them to know that the feature works.
Talk with the client and transcribe it into Gherkin while you talk. Use it as a tool to capture what the client wants, but don’t get overly hung up on their “correctness”. Accuracy of what the client wants is more important than Gherkin syntax.
Use Gherkin as a requirements capture tool, not necessarily as automatable tests. You can “translate” then later. The focus is on describing what the client wants without taking a lot of time.
Use “five whys” analysis to get down to a why that is – it makes me money, it saves me money, or it makes me happy. Epics require a why (As a P, I want to A, so that W).
“I don’t like the term epic – we’re not writing Beowulf here.”
Each scenario is a story under the epic.
The user accepts or rejects each story – if they reject, they need to tell you why, but you shouldn’t take offense to it.
Put your Gherkin right into your story in your agile management tool (Ruby has a tool called pickler that can pull it out and execute it).
If there is not a story for what you are doing, you are doing it wrong. The client needs to know about the project progress all of the time, so you need to have up-to-date stories in your tool.
If a story takes more than a couple days, it is too big to finish. Really, if a story takes longer than an afternoon, it is too big.
This gives the client a good sense of how things are moving and allows you to quickly see when something is going wrong.
You are not really doing anything unless you have a story in progress.
“The cost of predicting the future in software is so high we may as well treat it as unpredictable” – Fowler on estimates
Our projects don’t fail because of technical problems, they fail because of communication, expectations, etc.
They like to spend 10-15 hours per week with the client. BUT – people hate meetings. So, ask them what they want and don’t call it a meeting – hey, we have the wireframes done, do you want to go over them? The only meeting they have is the daily standup – everything else is more focused on a subject. (Sounds to me like they just have sane meeting with agendas and action items)

## Bottom line – “Make sure you talk to your client.”
Just use Gherkin as a form of shorthand to capture the conversations you have with the client about what they want/need.