How To Create Test Cases From User Stories

A Perfect Guide to User Story Acceptance Criteria with real-life scenarios:

In the Software Development industry, the word 'Requirement' defines what our goal is, what the customers exactly need and what will make our company to increase its business.

Be it a product company which makes software products or a service company which offers services in various software fields, the prime base for all of them is the requirement and the success is defined by how well the requirements are met.

The term 'requirement' has different names in different project methodologies.

In Waterfall, it is referred to as 'Requirement/Specification Document', in Agile or SCRUM it is referred to as 'Epic', 'User Story'.

User Story and Acceptance Criteria

Under Waterfall model, the Requirement documents are huge docs of 200 or more pages as the whole product is implemented in one phase. But this is not the case with Agile/SCRUM because in these methodologies the requirements are given for small functionalities or features as the product is prepared in a step by step manner.

In this article, I have tried my best to share all my 4 years of experience on working with User stories and their related Acceptance Criteria along with easy and simple real-life scenarios for your better understanding.

Let us re-visit the fundamentals first.

What You Will Learn:

What is a User Story?
What is an Acceptance Criteria?
Digging deep into User stories
- Case #1:
- Case #2
In-Depth look at Acceptance Criteria
Importance of finding Discrepancies in User Story/Acceptance Criteria
- #1) Wastage of Time:
- #2) Wastage of Efforts:
Conclusion
Recommended Reading

What is a User Story?

A user story is a requirement for any functionality or feature which is written down in one or two lines and max up to 5 lines. A user story is usually the simplest possible requirement and is about one and only one functionality (or one feature).

The most commonly used standard format for a User Story creation is stated below:

As a <user role/customer, I want to < goal to be accomplished> so that I can <reason of the goal>.

Example:

As a WhatsApp user, I want a camera icon in the chat write box to capture and send pictures so that I can click and share my pictures simultaneously with all my friends.

User Story and Acceptance Criterion

What is an Acceptance Criteria?

An acceptance criterion is a set of accepted conditions or business rules which the functionality or feature should satisfy and meet, in order to be accepted by the Product Owner/Stakeholders.

This is a very important part of user story completion and it should be studied by the Product Owner and Business Analyst very meticulously because missing a single criterion can cost a lot. This is a simple numbered or bulleted list.

Its format is as follows:

"Given some precondition when I do some action then I expect the result".

Example (w.r.t to above user story):

Let's consider that I'm chatting with a friend and I should be able to capture a picture.
When I click on a picture, I should be able to add a caption to the image before sending it.
If there is some problem with starting my phone camera, an error message like 'Camera could not be started'. etc., should be shown accordingly.

Hence, the User story defines the requirement for any functionality or feature while the Acceptance Criteria defines the 'Definition of done' for the user story or the requirement.

As a QA it is very important to understand the user story and its acceptance criteria profoundly with not even a single doubt remaining at the 'start of testing'. Moving forward let's understand why it is extremely important to dig 'deep' in user stories and acceptance criteria.

Digging deep into User stories

To start with, let us first understand the importance of an 'in-depth' study of a basic and fundamental thing i.e. User Stories.

The following cases are my own real experiences.

Case #1:

Before 3 years, I was working on a Mobile Application Project and the product was an application that was designed for the delivery people.

You would have seen a delivery person coming to your place for delivery. And they have a mobile phone on which they ask you to give your signature after delivery. This signature reflects on the portal of the courier service providers like DTDC, FedEx etc.

Let's imagine that the mobile app is just launched and their portals are already existing and up.

Problem: For a Sprint your Product owner has a user story for this mobile app that "As a Portal Admin, I should be able to view the signature taken by the delivery person at the time of delivery" . Here the portal (web app) is changed and updated accordingly to reflect the signature.

As a QA you have to verify if the signature captured in the mobile app is reflecting as expected in the portal.

If you look at this user story, it looks simple but there is a hidden requirement here that "For historical deliveries, there was no signature reflection functionality, so what should happen if the portal guys view historical deliveries?" Should historical data be wiped out? Should we allow crashes or errors for such data?

Of course not at all, this should be handled graciously.

Solution: When the respective DB tables are updated to add a new column for the Signature location, the old data should have a NULL or 0 value which should be checked and a message stating 'No signature exists' should be shown.

This can be called as a miss from the Product Owner or Business Analyst, but this has to be done. Implementing one feature successfully but breaking something along with it is not desirable by the customers. This needs to be done along with the same user story and in the same sprint.

Case #2

6 years ago, I was working on a Retirement Planning Finance Application (with no BA) which was a global application where Finance folks like CA, Finance Advisors could use it for different currencies to project the investment plans, savings, etc., over a large period to their customers.

Problem: The Product Owner gives you a User Story that "As an Advisor, I want to view the report of my customer based on the financial details provided".

Here there were 2 hidden requirements and I would call it as an incomplete story because:

a] The reports should consider the daily currency conversion rate and not the historical one as in the last viewed report and

b] If the currency is changed after providing the customer's financial details, the reports should show in the changed currency.

Solution: I raised this concern directly with our Product Owner and made him aware that both of these had to be done as soon as possible. He agreed with me and created 2 different stories for the upcoming sprints with priority.

Take Away: These were caught because we all were very well aware of the products, their design, structure etc. Such knowledge can only be achieved by understanding the product completely, by understanding the inter-operability of modules and by studying the user story thoroughly even if it's a 2 liner.

Make notes to make things easier and discuss with the BA's and the developers about their thinking.

In-Depth look at Acceptance Criteria

Understanding the acceptance criteria and all the other conditions& rules exhaustively is even more important than understating a user story. Because if a requirement is incomplete or vague, it can be taken up in the next sprint but if an acceptance criterion is missed, then the user story itself can't be released.

I guess we all would have used net banking at some point and most of us use it every day and I download my historical statements a lot. If you observe it carefully, there are certain specific options available for downloading them.

There is an option to select the type of file for downloading your statement. There is an option to choose if you want to download only the Credits/Debit /both.

Now imagine that the Product Owner gives you this User story "As a customer, I want to download my account statement so that I can view all my transactions done for a specific period".

With the following Acceptance Criteria:

Considering that I am on the Download Historical Statement Page, I should select the period for which I want to download the statement.
Considering that I am on the Download Historical Statement Page, I should select the account for which I want to download the statement.
Considering that I am on the Download Historical Statement Page, I should not be allowed to download the statement for future 'To' date.
Considering that I am on the Download Historical Statement Page, I should not be allowed to select 'From' date 10 years beyond in the past.
Considering that I download my statement, I should be able to view the downloaded file.
Considering that I am on the Download Historical Statement Page, I should be able to download my statement in doc, excel and pdf formats.

If you go through this acceptance, there are 3 things missing here:

Name and format of the file name that will be downloaded.
What information (Column names) is to be displayed in the file.
The options list to select what kind of a transaction the customer wants i.e. only debits or only credits or both.

Such cases may happen once in a while, however still study well about each acceptance criteria and try to visualize it with reference to the user story. The more you study deeply about the conditions and business rules the more will be your knowledge about the feature.

Bugs found in the initial stage cost nothing compared to what it may cost in the 'testing' stage.

Acceptance Criteria

Importance of finding Discrepancies in User Story/Acceptance Criteria

It is always important to do a deep dive in the user stories and acceptance criteria at an early stage even before the development or testing commences.

Because it involves:

#1) Wastage of Time:

If the discrepancies or mistakes in the user story/acceptance criteria are found when development is going on or testing is going on, then a lot of rework may need to be done in the remaining sprint time.

It doesn't happen that even if the Product Owner missed few things, they will move the user story to the coming sprint. 95% chances are that they ask the team to do the necessary implementation and release it in the same sprint.

Hence it becomes a nightmare for the team as they have to spend extra time, come on weekends or work late night. This can be avoided by studying and discussing the user story/acceptance criteria at the earliest possible stage.

#2) Wastage of Efforts:

The developers and QA have to revisit the implemented code and test cases again. Updating, adding and removing as the per requirement is not an easy task. It becomes too painful as there is already a pressure to deliver on time.

In such a situation, there are chances of mistakes in the development or testing stage. If you come across such situation go for 'DevQA Pairing'. As an icing on the cake, you may not get a compensation for the extra work.

User Story and Acceptance Criteria discrepancies

Conclusion

Deep understanding of User Story and acceptance criteria can only be achieved by spending immense time on studying it.

There is no specific tool or course available in the market to do this for you as this is all about logical thinking, experience, and knowledge about the product.

Participating in Pre-plan meeting actively, talking to the BA, studying on your own can only help you to achieve this. The more efforts you put, the more you learn and grow.

Be it the QA's or developers, everybody has to be on the same page about the user stories and their acceptance criteria, only then the expectations of the customer can be achieved successfully.

Do you have something new to share with us about your experiences on working with User Stories? Please express your thoughts below!!