Is There Any Start and Stop Boundary to the QA’s Role in Scrum?

Let’s understand the QA’s Role in Scrum in this article. What are the Scrum Activities for the Testers?

This article is not just a tutorial about some processes or methods or instructions about how to work as a QA. Instead, this is an article in which I want to share my own experience of working as a Senior QA in SCRUM.

My previous CTO always used to say that “With freedom comes responsibility’.

If you are given the freedom to do your work in your way then it is you and only you who is responsible for your work or tasks or activities.

This is what Scrum is all about!! Let me give you a basic idea about Scrum as we proceed further.

QA’s Role In Scrum

Overview of Scrum

Scrum is a subset of agile methodology and is a lightweight process framework that is used widely.

Scrum helps us to keep the customers happy by giving them the product in small modules, it also keeps the customer aware that their frequently changing requirements may slow down the activities.

The releases are short and work is taken as per the capacity of the team involved, hence the chances of failures or unhappy customers are reduced to a great extent.

However, the requirements (in this case User Stories) are finalized before Sprint starts in order to avoid rework and thus result in delayed or failed Sprint (exceptions are always there).

But the biggest challenge for QA is that the release span is short, Sprint is mostly a 15 day cycle.

Hence, delivering a product that is bug-free for a max of 4-5 days (taking out the development time) requires a lot of effort and smart thinking.

I am the QA of my team

Oh yes, I am the QA of my team and I am an important player. Why??

Because the customers, BAs, Scrum Master, and everyone else are fuzzy about the quality, the look & feel, and the performance of the application or product.

In Scrum, as the sprint duration is short, QA has to perform in a smart way, and hence the need from the QA to be involved right from the beginning . Planning becomes very important.

There are times when a QA can play the role of a Proxy Product owner when the PO is not available, thus helping the BA with creating the acceptance criteria test scenarios/cases.

The developers also approach the QA at times when they face trouble with the functionality or business rules.

At Scrum, the focus is only on having a smooth and successful Sprint release, and it’s not about “my work” or “your work” to give a helping hand when your team approaches you for help.

In Scrum team bonding, healthy relations between the team members play a very crucial role, and being a QA, you should be very careful while communicating your opinion about the user stories that you are testing.

Your communication should be about the user story or functionality and not about the person who worked on it.

In Scrum, QA is not judged or appreciated for the number of bugs he/she discovers but also about how he/she is interacting with the team, helping the team, and motivating the team even at difficult times.

Apart from testing the sprint tasks, writing test plans/test cases/release documents also try to involve more because the release duration of the Sprint is short and the goal is the same for everyone “to deliver a working bug-free product successfully by helping each other”.

QA is involved in almost all the activities carried out in Sprint and technically there is no boundary for the start or stop of QA activities.

Unlike the traditional Waterfall model where the QA is only limited to testing the release, here the QA has much more responsibilities. I would suggest trying and doing more of the following activities:

Activities to be Followed

Given below are a few activities that I would suggest you to follow as a QA in Scrum:

1) Dwell Deeper

When the user stories and their acceptance criteria are ready, study them thoroughly and think deeply about the dependencies and hidden outcomes and also if there is a better way to do it.

Communicate and collaborate with BA and the development team about this because it may happen that they also may not have thought about this. Share your ideas and findings with the team.

If you find that there are hidden hindrances or negative impacts, then raising them with the Scrum Master and the dev folks will give them time to think and act accordingly.

This activity in Scrum becomes very critical when the project is a large-scale one and when there are modules spread across the teams.

Now while studying the dependencies, an impact is very important for QA and it even makes the development team aware of the same.

To do this, discuss with the QAs of the other teams and take inputs from them.

2) Involve in Estimations

The usual practice is to involve a QA in the estimations but a lot of times due to the small sprint, the QA may not be asked for estimation for testing the tasks and leaving them with 3 / 4 /5 days for the testing work.

Never accept this. Raise your voice if you have to but make sure that you are providing your testing estimation which should include the time you need for every task.

It may include time for research, time for setups, time for collecting historical data, etc., but be strict and specific about the time required for carrying out the testing activities and have these time values added to the User story along with the development tasks time.

This is very important because if you try to do your work in the allotted time and if you are unable to complete it, only you will be responsible for the failure.

When the QA time is added, the Scrum Master, the PO will be aware of the QA activities involved and the amount of time required.

3) Dev QA Pairing

Ideally, in Scrum, Sprint User Stories are handed over for testing after the development is completed and once dev testing has been done, but the problem here is that by the time it’s handed over to QA for testing hardly 4-5 days to the Demo or review remains.

Now, if as a QA you find out even 4 blockers or functional failures, you will have to work late at night or on weekend to meet your release date since there will be functional testing, regressions, etc., to be done.

This seems like the traditional waterfall model which is not the best way to do it, in Scrum the smartest way is “Prevent Defects rather than finding defects”.

Hence the solution is to do dev QA pairing and perform a basic round of testing on the dev setup as soon as the developers are ready with the stories even before a formal release for testing.

The following criteria can be taken into consideration when doing a BVT on the dev setup for the user stories:

• Acceptance criteria for each user story: BVT of the user stories in accordance with the acceptance criteria.
• Lack of confidence in Developers: Sometimes the developers are not confident about some implementations and hence they discuss such implementations and do a BVT for those on the same dev setup.
• Dependencies/Impact Testing: BVT of the dependencies or impact on/of the other modules of the new implementations.
• Unit Testing: Do a BVT with the developer of the Unit tests that they have created, if needed help them by adding or updating the unit tests.

This will help in reducing the to and fro of bugs and save everyone’s time as before the release of QA a majority of the crashing or functional bugs are already fixed.

Remember to log those defects in your tools before the sprint review and have them moved to the ‘closed’ state.

4) QA on the White Board

I have always personally encouraged my team to include QA tasks on the White Scrum board including the bugs as well. This helps the Scrum Master to figure out the QA status of a User story by simply looking at the board.

The no. of bugs in the To-Do list, the bugs in the In Progress list, the QA activities in the To-Do, In Progress, and the Done list speak for themselves.

I find it really painful when someone comes asking about the status of testing individual stories for Sprint. I have to spend extra time to take out my status from the tools compile and show them or write an email.

I simply prefer to point the person to the Scrum Board and let them make it out for themselves. Prefer a bright outstanding color for the QA Sticky slips.

5) Documentation

One of the drawbacks or cons of Scrum is that due to the small size of Sprint there is not much time for documentation and I have never seen a Technical Writer in a Scrum team.

Scrum Master/BA may not and does not always update any documents related to product information.

The problem comes if new members join or in the worst case if the business rules, functionalities change and how to keep a track of these because searching in the ‘Done’ user stories for information will be like looking for a needle in a haystack.

The solution is to have a separate task created in a sprint whenever possible (mostly in slack times or when the workload is very low) for documentation so that you can review the documents and update or make the Scrum Master or the BA update them.

QA is the right person to help in updating the documents because you are the one who tests, verifies the user stories and knows the functionality in and out.

Do it yourself if there’s no BA or if your Scrum Master is busy updating.

6) Sprint Review/Sprint Demo

Mostly it happens that QA is the one who is chosen to give the demo to the PO and the Stakeholders. If not, persuade your Scrum Master to do so.

QA is the right person to give the demo as he/she has tested the user story in and out. A QA can demo from the business point of view because they know the functionalities, the flows, and, the business rules.

Prepare well for the demo and try to answer each and every question that the PO and the stakeholders have. This will help you to become the point of contact for them in the absence of Scrum Master and BA.

7) Act like a BA

This is not a regular task and not expected from a QA but try to get in this role when a chance is thrown because a QA is the best person to be a BA.

For instance, try to think and visualize if the flows, functionalities, or business rules can be modified in a way that will benefit the customer.

Think and search for the current trends in the UI, look & feel of the application, and how it can be beatified, made more user-friendly, etc.

If the team is stuck on some problem, get involved and try to give a simple and smart solution. This will boost your role and will be a factor in contributing to your career growth.

Chances come while on calls with the PO when some problems are being discussed or in review/demo where you can give suggestions.

Conclusion

Scrum is a very different methodology as compared to the normal Waterfall method, and a Scrum Master is a facilitator. Hence you should not expect him/her to define your activities for you.

In Scrum, there is no start and end to QA’s role. The QA has to be involved in every activity right from the very beginning till the end, from pre-planning till the sprint review/demo, and must participate in all the activities.

This will help us understand the product and application as there is no proper documentation available when working in Scrum.

You are expected to be responsible, motivated, and proactive. Hence do not wait for anyone to come and tell you what or how you are supposed to do.

You should take initiative on your own, help the team in every possible way, maintain a healthy relationship, keep track of the ongoing things in the team and most importantly be clear about your tasks in a given sprint.

There are no Managers here who will monitor you or keep track of your activities. Always be ready with a helping hand for your team and you will surely get the best of opportunities.

Feel free to express your thoughts and suggestions about this informative article in the comments section below. We would love to hear from you.