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

Comprehending QA’s Position in Scrum: Responsibilities of Testers in Scrum Procedures

This piece extends beyond a guide or a collection of instructions for how to be a QA professional. Rather, it is a recount of my journey as a Senior QA in SCRUM.

The former Chief Technology Officer I teamed with frequently highlighted the notion that ‘Responsibility accompanies freedom’. If you are bestowed the autonomy to control your work process, it is primarily your duty to manage your tasks and responsibilities.

That pretty much summarizes Scrum! Let us delve into the underpinning of Scrum now.

Scrum Overview

Scrum is a streamlining process structure that is extensively employed and functions as a subset of the agile methodology.

Scrum enables us to deliver the product to customers in smaller segments while maintaining their satisfaction. It ensures customers understand their changing demands may influence the development pace. Deliverables are brief and rely on the team’s abilities, leading to a reduced likelihood of failure or grievances from customers.

Nonetheless, a major challenge for QA in Scrum lies with the short release cycles, typically spanning 15 days. Therefore, the task of releasing a wholly bug-free product within a window of 4-5 days (excluding the time needed for development) necessitates considerable effort and strategic acumen.

I am an integral part of the QA team:

Indeed, I am a valuable member of the QA team, performing a pivotal function within it. This is because stakeholders such as customers, Business Analysts, the Scrum Master, and others express concern about the product’s quality, appearance, and performance.

In Scrum, where sprint durations are short, QA should be involved from the planning stage. Cases may arise where a QA can stand in for the Product Owner who is unavailable, aiding the Business Analyst in crafting acceptance criteria and test scenarios/cases.

Developers also approach QAs when they face challenges with functionality or business regulations. In Scrum, the focus lies in achieving a smooth and successful Sprint release. It is not confined to individual tasks. Be prepared to contribute when your team needs assistance, regardless of whether the task is specifically assigned to you.

In Scrum, establishing positive relationships and encouraging team cohesion is critical, particularly for QAs as they communicate their thoughts on the user stories being tested. Concentrate on discussing the user story or functionality itself, rather than criticizing the person responsible for it.

In Scrum, QAs are not solely evaluated on their ability to detect bugs, but also on their team interactions and support, especially during tough times.

Aside from testing sprint tasks, QAs should also assume an active role in writing test plans, test cases, and release documentation. Basically, QAs should be involved in every activity since the duration of a Sprint is short and the prevailing goal is to deliver a fully-operational product through teamwork.

In Scrum, a QA is engaged with virtually every activity during a Sprint, and there are technically no restrictions on when they can begin or end their activities. Unlike the traditional Waterfall model where QA’s role is restricted to testing releases, Scrum assigns them more responsibilities. Therefore, I suggest the following activities:

Practices to Adopt

I recommend adopting the following practices as a QA in Scrum.

#1) Explore Further:

This refers to the in-depth study and examination of user stories and their acceptance criteria. Take into account any dependencies, potential unanticipated consequences, or areas for enhancement.

Convey and collaborate with the Business Analyst and the development team as they may not have fully examined these factors. Share your insights and findings with the team.

If you identify concealed barriers or negative impacts, inform the Scrum Master and the development team so they can contemplate and address them. This activity becomes increasingly significant when dealing with significant projects with modules spread across several teams.

When reviewing dependencies, it is helpful for QAs to consult and exchange thoughts with QAs from other teams.

#2) Engage in Estimations:

Ordinarily, QAs are expected to partake in estimating the testing tasks. However, in certain instances, due to the brevity of the sprint, QAs may not be prompted to provide estimates for testing tasks. This leaves them with only 3, 4, or 5 days allotted for testing.

Do not accept these conditions. Express your concerns and ensure that you provide estimates for testing tasks that encompass all the time necessary.

Factor in time for research, setup, and gathering historical data, but be explicit about the time needed for testing activities. Ascertain these time values are incorporated into the user story along with the time for development tasks.

This is significant because if you endeavor to complete your tasks within the established time frame and fall short, you alone will bear the liability of failure. By including QA time, the Scrum Master and Product Owner will be aware of the QA activities involved and the necessary time.

#3) Form Partnerships with Developers:

The ideal scenario in Scrum is that Sprint User Stories are transferred to QAs for testing after development and subsequent developer testing. The issue arises when only 4-5 days remain until the Demo or review upon passing the stories to the QAs for testing.

If, as a QA, you identify four or more critical or functional shortcomings during testing, you may need to work late hours or on weekends to meet the release deadline. This echoes the conventional waterfall model, which is not the objective. In Scrum, the intelligent approach is to “dodge defects instead of identifying defects.”

The resolution is to perform an elementary round of testing on the developer’s setup once the developers have completed the stories before the initiation of formal testing. This is known as dev QA pairing.

The following parameters can be adopted to conduct a Basic Verification Test (BVT) on the developer setup:

• Acceptance criteria for each user story: Carry out a BVT based on the acceptance criteria for each user story.
• Uncertainties among developers: Developers may occasionally lack confidence in certain implementations. Discuss and administer a BVT for those particular implementations on the developer setup.
• Dependencies/Impact Testing: Conduct a BVT to verify the dependencies oreffects on other modules due to new implementations.
• Unit Testing: Collaborate with developers to conduct a BVT to inspect the unit tests they have created. Affordable assistance in adding or modifying the unit tests if necessary.

This strategy helps curtail the number of switchovers for bug amendments, saving time as many critical or functional bugs are already rectified before the formal QA process commences. Remember to document those defects in your tools before the sprint review and ensure they are marked as “closed”.

#4) Display QA on the White Board:

Personally, I motivate my team to incorporate QA tasks, along with bugs, on the White Scrum board. This enables the Scrum Master to easily ascertain the QA status of a user story through a simple glance at the board.

Whether bugs are on the To Do list, in progress, and QA activities in To Do, In Progress, and Done lists, they speak for themselves. Whenever I am queried about the testing status of individual stories within a Sprint, I find it tedious to take extra time to retrieve my status from tools, compile and display them, or create an email.

I favor directing them to the Scrum Board and letting them interpret the information themselves. Use a vibrant, striking color for QA sticky notes.

#5) Prepare Documentation:

One of the drawbacks or negative aspects of Scrum is the scarce time available for documentation owing to the brief sprints. Technical writers are infrequently seen in Scrum teams. The Scrum Master or Business Analyst may not always keep the documentation up to date with the latest product details.

This poses a problem when new team members join or when business rules or functionalities undergo changes. Tracking down information within the “Done” user stories can be like hunting for a needle in a haystack.

The solution is to create a separate task for documentation whenever feasible (typically during slack periods or when the workload is manageable), ensuring you can review the documents and make updates yourself or prompt the Scrum Master or Business Analyst to make them.

QAs are well-positioned to assist with updating documents because they are the ones who rigorously test and verify user stories and possess a deep comprehension of the functionality. If the Business Analyst is unavailable and the Scrum Master is too occupied to update the documents, assume the initiative to do it yourself.

#6) Sprint Critique/Sprint Showcase:

More often than not, QAs are picked to present demos to the Product Owner and stakeholders. If this isn’t the case, convince your Scrum Master to give you the opportunity. As a QA, you are ideally placed to deliver the demo because you have tested the user story extensively.

QAs can deliver a demo from a business perspective because they comprehend the functionalities, flows, and business regulations. Prepare well for the demo and strive to answer each question that the Product Owner and stakeholders may pose. This places you as their go-to contact person in the absence of the Scrum Master and Business Analyst.

#7) Assume the Role of a Business Analyst:

This is not a regular obligation, nor is it anticipated from a QA. However, if an opportunity presents itself, attempt to assume this role because QAs are well-suited to undertake the task. For instance, contemplate and visualize if flows, functionalities, or business rules can be adjusted in a manner that benefits the customer.

Keep abreast of current trends in UI, look, feel, and ease of use of the application. If the team is facing a problem, get involved and strive to offer a simple and innovative solution. This exhibits your value and advances your career growth.

Opportunities to act in this role may arise during calls with the Product Owner when discussing issues or during reviews/demos where you can provide suggestions.

Final Thoughts

Scrum is a unique methodology in comparison to the traditional Waterfall approach, with the Scrum Master serving as a facilitator. As such, do not anticipate the Scrum Master to delineate your activities for you.

In Scrum, there aren’t any rigid boundaries defining the onset and termination of a QA role. QAs must and are expected to play an active part in every activity from preliminary planning to sprint review/demo. They should partake in all activities actively, as documentation may not always be complete in a Scrum environment. QAs are expected to assume responsibility, demonstrate enthusiasm, and take the initiative. Do not wait to be assigned tasks or told how to perform them.

Embrace the initiative, aid your team in any way you can, foster robust relationships, stay cognizant of the team’s ongoing activities, and be clear about your tasks within the given sprint.

In Scrum, no managers are overseeing or tracking your tasks. Always be prepared to extend a helping hand to your team, and plentiful opportunities for personal and professional growth will come your way.

We welcome your reflections and input on this educational piece. Feel free to share them in the comments section below.