But why do I create tests then? Let me start from the beginning...
In software development it is very important that all participants in a project have the same understanding of what should be built. By all participants I mean not only software development, but also QA, UX/UI, business analysts, customers...
If you're working in an agile environment it is very likely that you're already working with user stories. But how does everyone know what to do in the story? This is where acceptance criteria comes into play.
In your estimation and especially later in the planning you start to create a set of acceptance criterias which should specify what needs to exist to make our customer happy.
Let's create an example:
"As a User
I want to be able to find products in the shop
In order to order them"
Where is our acceptance criteria?
Scenarios are a great way to describe acceptance criteria. I'll give you some examples:
"Given I am on the Homepage
And I entered a search criteria into the search box
When I click the search Button
Then I should see a list of products matching my search"
"Given a list of products
When I click on a product in the list
Then I should go to the detail for this product"
Then I should go to the detail for this product"
(Of course there should be more Scenarios for the complete story)
I used the Given-When-Then (GWT) Pattern to write down the scenarios. These Scenarios will cause a lot of questions in the team, about how things should be done. This is exactly what we want. The examples should help the team to understand what the problem is and what it should look like in the end.
One possible question: Where do I enter my search on the Homepage and where should the search button be?
These are questions that could arise during the workshop and that should be answered during the workshop. All the information that you agree on in the workshop should be written down and committed amongst all team members.
But why stop here and just write everything down? You can and should create tests from that information! The tests specify what should be implemented. Just like a software developer you can use Test Driven Development as a whole Team!
The main advantages of ATDD are, you can
- immediately get Feedback on how far the story is
- have a look at what you committed in the planning
- communicate changes in the requirements by changing the tests
- establish a common understanding of the problem in the team
- have a human readable specification of your domain
Of course this should not stop you from talking to each other. This is and will always be the most important skill of a team. The Tests help to establish a common language.
P.S.: The main idea on this topic came from the book "Bridging the communication Gap" by Gojko Adzic which is really an excellent book.