Agile Needs a Whole-Team Approach to Testing

This is a guest post by Nishi Grover Garg.

As teams have adopted agile practices, they’ve realized that they no longer have time for fast and furious testing at the end of a release, like they used to do in traditional projects.

Testing has to adapt to the needs of the project. Here are some ways the entire team can keep up with the pace of agile to get test-related activities done in better ways.

Make quality a whole-team effort

Although testing activities may be assigned to a few individuals on the team, the quality mindset has to be adopted by the entire team. 

Whether it’s thinking about the performance impacts of a feature or the risk areas of making a design change or a UI redesign, everybody needs to have a quality-driven thought process. The whole team should analyze these areas together to produce better-quality software.

The whole-team approach involves constant collaboration. Testers on agile teams are automatically involved in all discussions without the need for special requests and are made a part of all communication, design discussions, and sharing of documentation.

This brings the testers closer to the intricacies of a feature during its design and development, automatically shifting their test efforts to the left.

Share specialized skills and knowledge

An agile team has to be self-sufficient. Ideally, the team must possess all the skills needed to produce quality code by the end of their iteration. 

And if the agile team is missing a tester with a specific skill or specialty that’s needed, well then — it is time for others to pitch in with their knowledge and contribute to the task at hand!

Let’s say we require performance tests to be done for a specific new feature, but the single tester on the team does not have knowledge about or prior experience with performance testing. But there’s a developer who worked with LoadRunner and JMeter in her last project, so she takes up the task and shares her knowledge with the rest of the team, so they can all work out the performance tests together.

Similarly, let’s say we have the exit criteria for at least 70% unit test coverage, but due to some design changes, developers are struggling with not having enough unit tests created for the current sprint. The tester can help out by having developers show him a simple white-box test procedure and then expanding it for more extensive unit tests. This is easily done on an agile team because they have shared design documents, hold in-depth conversations, and collaborate throughout the day.

On an agile team, anyone can ask for and receive help.

That means there is no task too big or small for someone with experience to run point on, and no person tied to a single task or area. Team members can help each other, rotate their assignments as per interest, share their knowledge, and leverage each other’s past experiences, all in the interest of a better, higher-quality result at the end.

Pitch in on tight deadlines

Agile teams are continually pushed for time in their short iterations, and testers are even more so because of their end-of-sprint activities. 

If the team is going to meet these tight deadlines, there are bound to be times when everyone needs to pitch in on tasks like regression tests, quick bug fixes and retests, reviewing and updating tests, running automated acceptance tests on the final build, emailing reports, or simply closing relevant Jira tasks to mark the end of the sprint.

Each of these tasks takes time and effort, and the entire team needs to share the responsibility in order to close the sprint in time. This can happen only if the team has the right mindset and everyone takes ownership of in-time delivery of the entire sprint, instead of just their own assigned tasks.

Agile is constant collaboration

The whole-team approach to testing is what works for successful agile teams. It is not about defect counts, test numbers, or failure reports — what matters is quality and constant collaboration.

As Lisa Crispin and Janet Gregory say in their book Agile Testing, “The fact is, it’s all about quality — and if it’s not, we question whether it’s really an ‘agile’ team.”

This transition from individual responsibility to collective ownership is often the hardest part of the cultural shift that teams face when adopting agile. Want to learn more ways to encourage healthy competition, more cooperation, and a sense of community among agile teammates? Check out this blog post on the common communication barriers for agile teams and how to overcome them.

Nishi is a corporate trainer, an agile enthusiast, and a tester at heart! With 13+ years of industry experience, she currently works with Trifacta as a Community Enablement Manager. She is passionate about training, organizing community events and meetups, and has been a speaker at numerous testing events and conferences. Check out her blog where she writes about the latest topics in Agile and Testing domains.

In This Article:

Sign up for our newsletter

Share this article

Other Blogs

Agile

Agile QA Process: Principles, Steps, and Best Practices

The agile QA (Quality Assurance) process is a set of practices and methodologies aimed at ensuring that software developed within an Agile framework meets the desired quality standards. It aligns with Agile development principles, emphasizing collaboration,...

Agile, Software Quality

QA Best Practices to Improve Software Testing

Software testing is crucial for ensuring high-quality software releases. However, one often overlooked aspect is the quality of the Quality Assurance (QA) process within your team. A well-streamlined QA process not only identifies more bugs but also aids in...

Agile

Regression Testing in Agile

In TestRail, you can triage risks faster by monitoring the progress of all your regression testing activities in one place