Nine Reasons Testing Becomes a Bottleneck

It’s a new year once again, and time to think about what improvements you and your team can make to increase the quality of your products! One complaint I often hear from testers is that they have become a bottleneck on their team. They feel constant pressure to get their testing done, and they feel that they don’t have time to do good exploratory testing or write quality automation.

In my experience, there are nine main reasons why testing becomes a bottleneck. Read on to see if any of them apply to your team!

Reason One: The team has too much tech debt
When a product has crushing tech debt, testing and fixing bugs both become more difficult. The software often requires careful configuration before running any tests, and any test automation will likely be flaky. When developers fix bugs, it’s likely that they’ll break something in the process, resulting in additional bugs that then need to be fixed and validated. The remedy for this is to prioritize fixing tech debt, which will pay off in faster development and testing processes.

Reason Two: The team is given work without adequate acceptance criteria
Have you ever been assigned to a project that doesn’t have clear user stories and acceptance criteria? It results in the whole team flying blind. No one knows when a last-minute request for a forgotten feature will come in. When you don’t know the scope of a project, you can’t correctly estimate how long the work will take. When the development work takes longer than expected, it’s often the testers who are expected to work miracles and test twice as many features as time allows. The best solution for this problem is for the team to refuse to take on any work that does not have clear user stories and acceptance criteria. If the Product Owner wants to add a last-minute feature, the project deadlines should be renegotiated to allow for extra time to do the development and testing.

Reason Three: The developers aren’t completely coding their stories
Developers can sometimes get so mired in solving coding problems that they forget to go back and check the acceptance criteria of a story to make sure they’ve met all the requirements. They pass the story off to the tester, who quickly discovers the missing requirements and sends the story back to the developer. This kind of story ping-pong can slow things down for everyone. The developer has probably started work on their next story, and now has to switch their context back to the first story. The tester will now have to find something else to work on while the story is completed, and will then have to switch contexts back to the story once it’s completely ready. If this is happening on your team, calling it out in a team retro meeting might be enough to get the team to understand the problem. They can then develop the habit of checking the acceptance criteria before handing off the story.

Reason Four: The developers aren’t scheduling a handoff meeting with the testers
In a handoff meeting, the developer who worked on a story meets with the tester who will be testing the story. They demonstrate the work they did, show how the work can be tested, and outline which adjoining areas should be regression tested. Then the tester can ask any questions they have about the feature and how to test it. When a team does not use handoff meetings, it’s more likely that the tester will discover that the feature hasn’t been deployed, or that they don’t understand how to test the feature. This results in more back-and-forth questions that slow down the testing process.

Reason Five: There are not enough unit tests
Unit tests, typically created by developers, are an awesome way to catch problems quickly. When the developer pushes their code to a branch, the branch is built and unit tests are run against it. Any functionality that the developer broke with their code is detected in a matter of seconds. They can then fix the problem before handing the feature off for testing. When there aren’t enough unit tests to catch problems, the problems will go directly to the tester, who will then have to report the bugs. The time spent reporting bugs is time that the tester could have been doing exploratory testing and finding more challenging bugs.

Reason Six: The team has not tied API automation to builds and deployments
Almost as useful as unit tests, API automated tests catch any changes in the code that may have introduced bugs into how the API behaves. For example, a code change might have inadvertently changed a response code from a 401 to a 403, which would then result in an error in the UI. If API automation is run with every build and every deployment, problems are detected before the feature goes to the tester, once again saving them time and energy.

Reason Seven: There is no good process for reusing regression test plans

Exploratory testing is a great way to find bugs, but when you have an existing product or feature, it’s important to have some record of what should be tested during a regression. Without a record, it’s easy to forget to test some less-used part of a feature. For example, when testing an e-commerce application, the tester could forget to test removing an item from a cart, and instead focus only on purchasing the cart items. Without a good system for creating and saving regression test plans, the plans will need to be recreated with every release. This takes up valuable time that could be used for testing. Having a set of regression test plans for reuse can save enough time that the tester can do exploratory testing before the release.

Reason Eight: Developers are not contributing to test automation
Yes, good software testers know how to write good test automation, but developers are great at writing code, and they are a valuable resource for writing clean code, creating reusable methods, and setting up mocks for testing. When a team has only one tester who is expected to do all the automation on their own, the process of automating the tests will be slow. It may be worth pointing out to your team that when there are good, reliable, automated tests, it saves time for everyone, not just the tester. Developers will get fast feedback, which prevents time-consuming context switching.

Reason Nine: The team is relying too much on UI automation
There is definitely a place for UI automation, because this is where the visibility and functionality of UI elements are tested. But most of the business logic of an application can be tested with unit and API tests. We all know that UI automation tends to be slow and flaky, even with well-written tests. With unit and API tests, teams can get accurate feedback more quickly. And these tests are easier to maintain because there is less flake.

Do any of these reasons apply to your team? Do most of them apply? In this New Year, I challenge you to pick one of these reasons and discuss it with your team. See whether you can come up with a plan to address it, and watch the testing bottleneck start to speed up!