The Case for QA in Agile

Written by: Sahil Gera

What role does QA play while working in Agile teams? Is it even possible to build a successful product without dedicating significant effort towards QA? If not, how can teams strive to reduce their development time and effort while simultaneously achieving the highest possible level of quality? These are all important questions that plague large agile teams and startups today.

The simple answer is that one needs to ensure that the product, once deployed in production, offers a consistent user experience, is fast enough, secure and accessible, which means it is important to think about your QA process and incorporate fundamentals related to quality to be able to deliver a robust product.

For the past 5 years, I’ve been leading the QA initiative at Myplanet and witnessed not only the hiccups and hurdles of bringing mature QA solutions to our teams, but also the impact and importance of having this process.

There is a perception in parts of our industry that software testing can be left until the final stages of a project, once all the development has been completed. And it is often assumed that developers and product managers can take charge of the process, thus making dedicated QA resources unnecessary. However, this line of thinking can often be misleading, if not downright unproductive.

Product managers are exceptional in that they have a holistic understanding of how the product is supposed to work. Combining this with their business expertise and domain specific knowledge gives them a unique ability to test product features and provide feedback to the team. Unfortunately, testing software can fill only a very small portion of their otherwise busy schedule. As managers, a significant portion of their time is devoted to managing their team, prioritizing feature backlogs, and budgeting, all while attending dozens of meetings and reporting to stakeholders, leaving little to no time for quality checks.

In the agile world, there is also a perception that QA can be a bottleneck and that developers should be responsible for testing. While this can be true on some smaller teams, it becomes problematic when product complexity increases. Business logic becomes intricate and requires thorough regression testing, which in turn further slows down development.

Developers have intimate knowledge of the code and the features being developed, but they’re often not actively hunting for bugs in their code. They’re the creators, the artists, but you always need a separate set of eyes and someone with a critique-oriented mindset to explore your product and find issues. Developers are more practised at following the happy path and testing for what a feature is supposed to do. But there are always negative tests, edge cases, and various kinds of validation that needs to be done. That really is best served by a specialist.

Having a dedicated test lead on an agile team helps you critically explore the product. Because of their experience in analyzing and exploring products, they bring in a unique perspective to the table. And by having them as an integrated part of the team, you have a user’s voice while building the product. They explore each and every feature and bring up issues and edge cases that may not be easy to find.

A tester’s role in an agile team starts at the beginning of the product discovery stage when they start understanding the application architecture and product requirements. At this stage, they would evaluate the product to determine what kind of testing it could benefit from. This usually includes, but doesn’t have to be limited to, functional testing, automated testing, performance testing, accessibility testing, security scan, location testing, and visual quality control. It is a tester’s job to determine which of these subsets are required and to what extent. I call this stage QA Discovery as you are discovering and evaluating the need for testing and tools.

Once development begins, the tester would play an active role in planning for features and highlighting any risks and edge cases associated with them. They do this in collaboration with the product owner/strategist/manager and developer to bring in different perspectives. These risks and edge cases then form test cases and are documented so they can be useful once regression testing is being performed. They can also be used to onboard new members to the team later on.

Testers at this stage play an active role in the team as they are part of daily standups, planning meetings, bug triaging and retrospectives. They help the team evaluate features as they get integrated into the existing codebase on a daily basis. This helps with raising and resolving bugs early on and saves time and money. Once the features are stable and deployed to the staging environment, manual test cases are automated to conduct regular regression tests and avoid repetitive testing. The tester helps in automating and maintaining the tests.

There is also a perception that 100% automation can make product development faster and achieve the highest standards of quality. While there is some truth in this statement, there are some drawbacks to consider. Having automated tests early on may not be useful as the application is constantly changing. The cost of maintaining automated tests at this point will probably be higher than just testing them manually, and it is likely more cost effective to manually test all user flows of the applications and wait to adopt automated testing until there are stable areas of the application where requirements do not change frequently and where regression testing has the greatest likelihood to uncover major system defects. This helps the team avoid repetitive testing, and lets them focus on areas which are new and that have a maximum chance of uncovering edge cases. Automated testing, in short, should be applied strategically and revisited regularly.

Usually startups and small companies start looking for a QA Lead when they find issues appearing in the production environment or hear customers complaining about their product. But if you’ve reached that point, then you’re already late. Processes are set up already and developers have adopted a working style. It becomes hard for someone to come in, change the mindset, and identify inefficiencies in the process while there is a huge backlog of features that needs to be tested alongside testing the ongoing work. The cost of development increases dramatically when issues are found in production.

And that’s what it really boils down to: QA isn’t about catching bugs in production. It’s about being proactive, and ensuring that bugs never make it to production in the first place. By having a defined QA strategy upfront, companies can actually save themselves time and money with a team that understands the complexity of the testing and a battle plan in place to conduct efficient and effective testing.

How do you feel about having a dedicated QA process and team? We want to hear your thoughts. Be sure to comment below and if you like the article, 👏 and share it.