6 Steps to Creating User Stories to Improve QA in Agile and DevOps
-
Feb 25, 20215 min read
In the days when waterfall reigned, developers would create reams of system requirements to guide software development efforts. These “spec docs” would often top 200+ pages but, without a clear vision of what the software was trying to accomplish, following “specs” took precedence over creating a compelling user experience. An app would pass through quality assurance for checking all the right boxes even though it ultimately failed to delight the users.
As enterprises adopt the concept of Agile and DevOps, lengthy spec docs are being replaced by user stories, allowing requirements and solutions to emerge and evolve through a collaborative team effort.
This simple form of documentation describes requirements in a specific software feature or functionality written from the perspective of the end-user. A user story ideally has a simple structure and is user-friendly: you are looking to demonstrate the needs of the customer and determine the value you want to deliver.
The following steps can assist you in creating user stories that are effective and useful:
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>.
But, a word of caution: while at some points of time, user stories are best written using a customary template or set pattern, at other times, user stories that are written following a template are the worst examples. Therefore, your main motif, more than just blindly following the template, should be to put the message across in a comprehensible way.
While creating a user story, it is important to have detailed knowledge of your users and their ultimate purpose behind using your product or application. How the customers interact with your site, app or product gives a key insight while you create a user story. The functions of the program are essential but what is more important is that you can see the UX from the perspective of the users and then formulate the story.
The aspect of independence among user stories is quite essential. You should make sure that two different user stories are not dependent on each other. If user stories are interdependent, they will not let your program run independently with minimal effort and instead make it more complicated for the end-users to use. Additionally, dependencies between two user stories can decrease the level of flexibility in the user interface, and a decreased flexibility would hamper your overall user-experience.
The reason why you should focus more on creating a flexible user story is, you should allow engineers to change and rewrite the whole program if they feel that the product has something better to offer the users than what is currently existing in the user story. Until they finally implement the code, there must be enough flexibility to offer change. However, once they implement the process, the developers need to create a new user story to exercise further change, if necessary.
You should test a user story appropriately for the user criteria. You can do this with the help of acceptance testing. The reason why you must test every user story thoroughly is, to ensure clarity in the information shared with both the systems designers and engineers.
Quality assurance is also vital to monitor whether the end-product is meeting all the acceptance criteria in the user story without any malfunction, as the end-user would expect. Ensure, all teams that are a part of creating and implementing the user story are working together. They should collaborate to figure out an acceptable criterion for the user story that the quality engineers will not only develop but also conduct a beta test on. The acceptance criteria are also useful to the developers as they get an overall idea of what the code that they have developed will be beta-tested against. It also provides a decently accurate timeline regarding when a user story will be completed and finally up and running.
Creating acceptance test cases for Acceptance Test Driven Development (ATDD) in Agile is a challenging task. ATDD services by skilled test engineers at Qualitest ensure acceptance tests act in sync with the detailed requirements and test cases. This enables you to create an ultimate set of acceptance criteria right from the early stages of software development.
According to Sree Renganathan, Quality Engineering Manager at Qualitest, “User stories should be granular and clearly articulate the functionality from the end-user perspective. They should address the What, When and Why aspects of a specific feature.”
Ensure that your acceptance testing specialists are adept enough to provide improved quality through a clear insight into your system and post working on the action points. A user story can be more comprehensive through acceptance testing services that provide increased test coverage, implementing new standards for quality enhancement.
Determine who your users are, what are their roles and responsibilities, what motivates them, what are their challenges, what are they worried about and what are they looking for. Create a completely fictional character for each one, even using a fake image and name, so your developers can really understand the person who will be using what they are developing for them. These personas will help you in creating a near-perfect user story for them.
So, whether you are a software developer or a QA professional, you cannot ignore the importance of a user story. An effective user story will also make sure that your team stays focused on the work that they are entrusted to do, with minimal doubts and questions. It also gives you a proper perspective when you would want to improve the product that is upon offer or when you feel the need to create a new UX with better features that can be beta tested on existing users.
