How to implement an efficient QA Strategy from scratch?
A simple and comprehensive step-by-step guide (1/3).
During my past experiences as a QA Consultant, I faced the challenge to create and implement an efficient QA strategy on softwares that grewout of quality processes. These apps are already in production environments and used by real users but unfortunately, they were never submitted to quality standards. In this post, I will do my best to help QAs who find themselves in similar situations and give them answers to the question ‘How can I start setting an efficient QA Strategy?’.
Even if the context may differ from one application to another, I will detail a general approach that could be applied and tailored to on any software development project.
After reading this post, you will be able to effectively start implementing a QA Strategy on a wide range of applications.
QA Strategy step 1 : Identify your application’s components
Every application could be organised by components. Let’s take Facebook as an example : Wall, Gallery, Navigation Menu and Search Box are some of FB’s components.
Ok that’s clear! But why do I need to identify these components in setting a QA strategy?
As a QA engineer, one of your main tasks is to identify and document critical scenarios for all application’s features. In some cases, you have to deal with hundreds of scenarios. Organising your test cases by components is an efficient way to do this task. You can imagine that you are organising a library. If you start by identifying the themes, your task will be easier to organise the books. Moreover, You will be more comfortable to follow and communicate your progress to management and teams.
You will find useful information about project component in JIRA documentation.
Schedule PO-to-QA meetings, you will need three to four dedicated slots.
This is your starting point! Consider that the Product Owner is your ally to succeed in this step. You will need to organise meetings with him with clear objectives. I recommend that you split these interviews into three 1-hour sessions spread out over three weeks. I will call these meetings PO-to-QA meetings as the Product Owner will give inputs to QA.
QA Strategy / PO-to-QA meeting n°1 : clearly state your goals and why PO’s help is needed
- Explain your role and the QA strategy
Start by explaining your high level objective as a Software Quality Analyst : Enhance application’s stability by creating a Test Plan that contains critical scenarios. To achieve this objective you will need to identify and understand the application’s components.
- Ask for a quick demo
You can ask for a quick demo that will help you spot basic application’s features. I said quick because if you ask for a detailed demo you will not be able to understand a large flow of information when you first discover the app.
- Request documentation and access to discussion channels
You will also ask for functional documentation (slite, confluence or any useful materials…) and access to main discussions channels in Slack or Teams. Reading the channel’s content will help you familiarise yourself with the vocabulary used by the project teams.
- Request access to project boards
You will request access to project boards in JIRA or Notion or any other project management tools. So you might find stories, development backlog and reported bugs. It’s also a way to know the project’s members and organisation.
- Identify project key people and teams organisation
Do not hesitate to ask the Product Owner about the team’s organisation and key people in this project by asking these questions : How many POs and developers are working in this project? Who are tech leads? Is there a support team? Which person should I contact from the devops team?
QA Strategy / PO-to-QA meeting n°2 : Prepare your questions and validate application’s components list
Before your second PO-to-QA meeting, you need to do some preparation tasks :
- Reading as much documentation as possible following priority given by PO
- Do exploratory tests in test or QA environment
- Take notes of your questions and organise them by blocs
- Daft application’s components list
A reasonable delay to do this task is around 10 working days but it may vary depending on the application’s complexity in addition to the availability of documentation and dedicated test environment.
Your ideas should be more clear now, you can schedule your second PO-to-QA meeting. You will look for answers to your questions and validation of organising the components list.
NB : I highly recommend that you schedule your PO-2-QA meetings in advance, maybe one week before, to avoid unavailability disagreements.
By the end of this first step, you will have a clear application’s components list which will help organise your work and efficiently progress in your QA strategy implementation and you are ready to move to the next step in implementing the QA Strategy.
QA strategy step 2 : Identify critical scenarios per component
Critical scenarios are high priority test cases that must pass on every new release. To get ideas more clear, let’s take and example from the facebook application :
“As a facebook user, I can post text messages” is a critical scenario and must pass on every upgrade made by Meta’s tech teams. Here is some other critical scenarios per component :
Wall’s some critical scenarios
- As a user, I can post a picture on my wall
- As a user, I can delete any post from my wall
Gallery’s some critical scenarios
- As a user, I can add a photo to my gallery
- As a user, I can remove a photo from my gallery
Navigation menu’s some critical scenarios
- As a user, I can access my profile settings from navigation menu
As you can see, I used Gherkin to describe my test cases. It’s the best way to document scenarios readable by everyone. I recommend this link if you want to go further on Gherkin topics.
At this point, I assume that you have a good understanding of high priority scenarios and you can go forward by drafting high priority test cases per component. I used to use a google sheet where I create a tab for every component which is a good way to keep your work organised :
Productive trick : You don’t need to write detailed scenarios using steps or Gherkin format at this step. You only need a comprehensive title that you can share with POs. For example :
“Login using valid credential” or “As a facebook user, I can login with my valid credential”. The steps to execute the test case will be documented after validating your draft list. Otherwise, you will waste your time to detail a test case that you will remove after review.
When you progress within this step, don’t forget to keep a good balance between the number of scenarios per component. For example, if you have these statistics :
- Wall : 20 critical scenarios
- Gallery : 35 critical scenarios
- Navigation Menu : 17 critical scenarios
- Search Box : 3 critical scenarios
You can ask yourself if the “Search Box” component needs more covering as the feature is only covered by 3 critical scenarios compared to other features which are covered by many more scenarios.
QA Strategy / PO-to-QA meeting n°3 : Present critical test cases by components and gather PO’s comments and suggestions
During the third PO-to-QA meeting, you will present your work and ask for Product Owner’s inputs on these scenarios. It could be adding, removing or updating some test cases.
At the end of this step, you have an organised high priority test cases per component which is a great milestone on implementing an efficient QA Strategy. Now you can go forward and start detailing these scenarios on your test management tool such TestRail or XRay.
QA Strategy step 3 : Document critical scenarios
When I started my first QA experience, I used to use excel sheets that we called “cahier de recette” in writing scenarios. Even if this task could be done using this tool, I will not use it again for this purpose (Unless my customer or my manager requires it ;)). It’s a hard way to maintain and share test cases. I would rather use a dedicated test management tool such Xray or TestRail. The first one is a well-known plugin available in the JIRA market and the second one is a SaaS application.
I will detail this step using TestRail as a free time-limited account is available for anyone to reproduce my work.
Create a Project in TestRail named “Facebook”
Create application’s component as sections in TestRail. Following my previous example, we will have 4 sections called “Wall”, “Gallery”, “Navigation Menu” and “Search Box”
Create a select list custom filled in TestRail named “Category”. Set “critical” as the first option.
Create test cases by filling mandatory fields (name, steps…) and setting the right section. Select “critical” in the category field.
Create your first test run by selecting test cases having “critical” as category and execute it. This step will help you in reviewing your whole work.
Hurra! You finished a big milestone in implementing the QA strategy in an efficient way. All application’s components are covered at least by one critical scenario, that’s really great. Don’t forget that test cases should be reviewed in the future to remove deprecated ones and add needed updates.
Useful trick : Ask some of your QAs coallegue to do the test run. These iterations will improve your deliverables.
You can leave your comments or contact me if I missed some information. I will answer for sure!