In the Shadow of Development: Is QA really your bottleneck or just a convenient excuse?

As the head of a quality assurance department, people often say that the testing team is the bottleneck in the development process, causing delays in deliveries. The feeling of failure at the end of a sprint or release is challenging. Consistently attributing responsibility to the testing team creates an atmosphere of pressure, frustration, and demotivation. Sometimes, we even have to skip some of our usual steps to make sure we deliver on time.

I wanted to figure out if it's really the testing team causing the problems, so I looked more closely at it. Let's check out some important reasons why the testing team might seem to be not doing well or working slowly.

Things that can indeed be the directly attributed to the QA team:

1. Insufficient Automation:

Automation speeds up the repetitive execution of tasks. If every new development requires a manual retest of a test suite, it not only becomes time-consuming but also highly susceptible to errors. This is due to the mechanical nature of repeating the same scenario endlessly, leading to the oversight of certain details. In this context, having insufficient or weak automation results not only in a loss of time but also in compromised consistency and quality, given the increased likelihood of human errors.

2. Lack of Regression Testing Processes:

There are many ways to test, and exploratory testing is a great way to find issues. But, when you're working on an existing product, it's important to make sure that the main features of the app still work after changes. Figuring out what these main features are is a big part of regression testing. You need a clear picture of what customers use the most to create effective tests. Once you have a good list of scenarios, running these tests is fast and easy. Strong regression processes and tests have benefits like quickly finding problems, being consistent, and saving time and resources.

Those are two potential issues that we can directly and unmistakably address to QA , however, let's analyze the remaining causes that can be causing QA delays:

1. Lack of Documentation:

Without proper documentation, it becomes harder to find and fix problems because there's no clear record of design, architecture, and implementation decisions. Over time, people might forget how things work, and as teams change, it becomes more time-consuming for new developers or testers to understand and resolve issues.

2. Vague Specification of Acceptance Criteria:

Ever faced confusing user stories with no clear acceptance criteria? Having clear user stories and specific acceptance criteria makes it clear for both the developers and testers about what the expected functionality should do. This significantly reduces misunderstandings or doubts because vague instructions are hard to test and implement. Also, it boosts product quality, improves communication, and makes prioritizing tasks easier.

3. Technical Debt:

When working with code carrying a lot of technical debt, each new change or bug fix can lead to more problems. It's even trickier when dealing with less experienced developers who might not fully understand the business logic. This cycle of creating new problems with every development or bug fix often leads to tasks going around in the development process repeatedly, causing big delays in delivering the final product.

4. Limited Involvement of the Development Team in Testing:

When the development team doesn't thoroughly check the acceptance criteria, a user story gets sent for review and testing too quickly. But, when the tester starts, issues with meeting the criteria can pop up, sending the story back to development. Going back and forth in this workflow isn't helpful. To tackle this, processes like shoulder checks can be put in place, promoting collaboration between developers and testers before the user story goes for testing.

5. Absence of Unit/Integration Testing:

Tests created by the development team, such as unit or integration tests, are great for quickly finding issues. When these tests are linked to the code repository, a test suite runs right after the code is committed, giving fast feedback on the code's condition. While opinions may differ, especially about unit tests, they can catch problems early on. But if these tests are missing or not well-made, the issues end up with the tester. Finding and reporting these problems at a later stage will take more time.

6. Weak Test/Staging Environments:

Many software development organizations put up with faulty environments. You've probably heard phrases like "it's always been like this" or "we can't test in dev." Having weak test or staging environments with poor quality, unreliability, and not replicating production setups well, introduces problems in the development process. Issues with test environments often don't get marked as urgent, lack proper prioritization, and end up sticking around. Yet, these subpar environments pose serious risks of causing problems in production and bring hidden costs to the development process. Testing in a faulty environment takes attention away from finding critical issues in new developments. Plus, bugs in the staging environment are already costing your company money.

7. Poor Communication:

Communication is vital not just in development but in all areas of life. Without a strong and clear communication process among the different people involved in development, we might end up wasting a lot of time on misunderstandings about requirements, having to talk about the same things over and over again, lacking coordination—especially when different teams depend on each other—and struggling to solve problems. When you're working with big teams or multiple teams all aiming for the same goal, it's really important to create straightforward and inclusive communication processes. This way, everyone can easily understand what the project is trying to achieve and how it's progressing.

Some of these nine points reflect, in my opinion, a weak culture regarding quality. I recently read that "Anti-quality culture is team-wide acceptance of low-quality ways of working," and I couldn't agree more. Blaming the testing team exclusively as the bottleneck seems unfair, considering that flawed processes may mean 80% of effort is spent seeking solutions to problems, not in test execution. It's time to reconsider whether the testing team is truly the primary bottleneck.