As a software tester you need enough information to be able to design your tests and to verify whether the outcome is correct. One of the sources to use for this are, of course, user stories.
There are many rules, best practices and principles on how a user story should be defined. Gherkin is one way to write user stories. I recommend you have a look at this Cucumber page for more information on Gherkin.
More often than not however I find myself opening a user story on a task board only to find a user story similar to:
‘Create a new page where users can sign-up for the newsletter.’
Simple enough, right? No, not really…
It always amazes me that these user stories make it into a sprint, ready to be developed. Some questions that come up right away are:
- What kind of newsletter is it? What is the goal?
- What information do you need from a user?
- Is there a process in place regarding newsletters?
Ready or not, here I come
So here you are, reading this less-than-perfect user story because it is actually already developed and ready for test! If only we had reviewed this user story (from a testing perspective) sooner!
Do you get started on testing the user story and let it pass or fail based on the assumptions you made? No, let’s not do it that way. Let’s get some information regarding the user story and improve the user story first.
Why tell me why tell me why
Talk to the developer who built the newsletter page. Don’t go in with a:
How could you develop this, it is not ready to be built!!1112.
That is what sometimes happens and it really does not help in any way…
You want to start with ‘why’. This reminds me of a talk by Simon Sinek, check out his TED talk on leadership.
Why is there a need for a newsletter sign-up page? Why did you build it like this?
You want to really understand the user story and the development of it, so listen carefully and ask more questions to further clarify the user story. For example: Why is there not a better defined user story? Why does the business need a newsletter sign-up page?
After some good listening and asking questions you want to talk to others: a product owner, end-users, team leads, other testers, whoever you have in your organization that can tell you more.
It really comes down to first understanding the user story and the people behind it. Stephen Covey said to ‘first seek to understand, then be understood’ . Why not put that wisdom into practice?
Talk to me, tell me your name
All that information you gathered from listening and asking questions can go into the user story now. Maybe the user story needs more development work before it is ready for test again.
Clearly define the ‘why’ of the user story and make sure the user story is testable based on the description. Again, have a look at Gherkin as a way to write the user story specification, see if Gherkin resonates with you and your project.
Before you know it, your user story walks like she talks and she talks like she walks!