Quality Assurance is a necessity in today’s world of information technology. That argument is already well defined does not require additional justifications or clarifications. However QA (surprisingly) lacks internal quality some times. Not all tests that are done in the world are worth the effort. Many teams and even entire companies offer QA services while their testing processes, tools and methodologies are either outdated or simply irrelevant and can do only one thing: waste time and resources.
One of greatest tools in achieving quality of QA processes is usage of User Stories and confirmation of them. You already know that any User Story defines particular processes that people undertake while gaining from software solutions. These are literally small chunks of information about how particular goals may be achieved by people, and, more importantly User Stories describe why this or that functionality presents actual value. But how does one create an excellent User Story?
- Do you know what’s the most important part about any existing User Story? Users that will potentially be behind it. Stories we are talking about must be aimed to describe how people will actually use your app. Therefore appropriate stories should be designed from their perspective. User Stories should also capture precise and accurate pieces of information like why and how would a certain person log in the app. Not more, nor less.
- How to do so? Definitely via using personas. Creating personas will assist you with creation of valid User Stories. There are numerous Persona templates you can download, but you should rather determine your personal ones. This way you will understand what people might want from your software and it will be easier to get in their shoes.
- Don’t be a one man army. You will never think of everything users can do with your app on your own. Creation of personas should be a collaborative activity. This doesn’t have to be hard. Design them through conversations. Discuss possible stories with both your team and the product owner. This process hits two birds with one stone. Decent tests are created and collaboration between the team and owners increases mutual understanding of the app under tests and its primary business values and core functionality.
- Keep stories simple. The simpler – the better. However simple does not mean lacking in content. No story should be misleading and each has to cover at least one trip users will be making.
- Always begin with Epics. Despite all that simplicity talk before, it’s better to begin with large, through-product stories without too much specifications. And those stories should be broken down into consumable chunks.
- Add acceptance criteria, meaning question yourself what exact results are users trying to achieve by commencing particular actions and determine what software response may be qualified as such user’s success.
- Don’t hide created stories. Keep them constantly visible on a board or something. Make sure none were missed.