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

What is QA’s Role in Scrum: 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. Rather, 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.

Overview of Scrum

Scrum is a subset of the 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 is reduced to a great extent.

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

But the biggest challenge for a QA is that the release span is short, a Sprint is mostly a 15 days cycle. Hence, delivering a bug ‘free’ product in max 4-5 days (taking out the development time) needs a lot of efforts 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 of my team. Why?? Because the customers, BAs, Scrum Master and everyone else is 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. In 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 same for everyone “to deliver a working bug-free product successfully by helping each other”.

A QA is involved in almost all the activities carried out in a 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. So, I would suggest trying and doing more of the following activities.

Activities to be Followed

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

#1) Dwell Deeper:

By this, I mean that when the user stories and their acceptance criteria are ready, study them thoroughly and think deeper about the dependencies, hidden outcomes and if there is a better way to do it.

Communicate and collaborate with the 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 about the dependencies, an impact is very important for a 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 work.

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, 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, the Sprint User Stories are handed over for testing after the development is completed and once the dev testing has been done, but the problem here is that by the time it’s handed over to the QA for testing hardly 4-5 days to the Demo or review remain.

Now, if as a QA you find out even 4 blocker or functional failures, you will have to work late 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, 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 to do 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, save everyone’s time as before the release to 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 till the ‘closed’ state.

#4) QA on the White Board:

I always have 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 of individual stories for a Sprint because I have to spend extra time to take out my status from the tools compile and show them or draft 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:

This is one of the drawbacks or cons of Scrum 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. The Scrum Master/BA may not and does not always update the documents about the 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 ‘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 less) for documentation so that you can review the documents and update or make the Scrum Master or the BA update them.

A 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 and if your Scrum Master is busy to update.

#6) Sprint Review/Sprint Demo:

Mostly it happens that the QA is the one who is chosen to give the demo to the PO and the Stakeholders. but if not persuade your Scrum Master to do so. A QA is a 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 the Scrum Master and BA.

#7) Act like a BA:

This is not a regular task and not even 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 give a boost to your role and will be a factor to contribute to your career growth.

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

Conclusion

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

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

This will help to understand the product or application as (as I said before) 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 initiatives on your own, help the team in every possible way, maintain a healthy relationship, keep a track of the ongoing things in the team and most importantly be clear about your tasks in a given sprint.

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

Feel free to express your thoughts/suggestions about this informative article in the comments section below.