Teams often work on web applications that not only incorporate complex business requirements but also involve intricate communications with external systems and interactions among multiple internal services. In such cases, testing becomes crucial and quickly turns into a challenge to detect bugs early. Over the years, I’ve seen companies respond to this by hiring large numbers of testers or appointing test managers. While these approaches do help surface issues and provide valuable reporting, they often fail to significantly reduce the number of bugs discovered late in the development process. There are several reasons for that.
Your Test Manager is just a manager
There’s nothing wrong with being a test manager. However, I’ve seen projects expect bugs to simply disappear once a test manager joins the team.
In practice, the test manager’s role is often more about reporting than transforming testing. They track progress, communicate results to stakeholders, and ensure compliance with testing plans — but usually lack the technical capacity or the allocated time to improve how testing is done.
And this leads us to the next problem…
You didn’t allocate capacity to enhance Testing
Your project is thriving, user stories include time for developers to test the features they build, and they probably do. But testing a feature and improving the testing process are two entirely different things, especially in complex systems.
Test rules and acceptance criteria define how a story should be verified, but they rarely cover all edge cases. Developers often end up testing on shared integration environments, where multiple teams are deploying simultaneously, making the testing phase slow and results unreliable.
To meet deadlines, corners are cut — and the real issues show up later, in the customer’s hands.
“So how can I detect bugs earlier? What do I really need?”
What you need is a Test Designer, someone specialized in understanding the system as a whole, whose responsibility is to extend and create the environment necessary for developers to spot bugs as early as possible, whether manually or automatically.
Unit tests are great for checking whether an input produces the expected output. But most bugs arise from interactions between complex systems, where one component passes the wrong data to another, breaking the entire chain.
To detect these issues early, you need a technical strategy that tests your business logic in real-world conditions as early as possible. This can include:
Designing integration tests that run locally
Replicate complex systems (for instance, using Docker containers made of real components) and run automated end-to-end test scenarios locally.Developing and extending automated testing and staging environments
Set up dedicated environments linked to specialized automated tests.Identifying key business features and generating realistic datasets for testing
Researching ways to improve local testing speed
Creating innovative reporting for test coverage and test quality
By dedicating someone to enforce and develop these capabilities, your developers will work in an environment that closely mirrors production, allowing them to detect bugs before they reach integration.
A bit of story
I was once tasked with creating a JBoss application for an ETL pipeline composed of multiple processing steps. The available unit testing framework was extremely limited, and component injection barely worked. I had to test each step manually and deploy the entire pipeline on a JBoss server just to verify the process end-to-end.
Instead of continuing down that painful path, I designed my own testing framework. It loaded all process step classes, injected the right dependencies, and executed them sequentially, all within the existing unit test framework (JUnit in this case). I also built classes to generate dummy datasets and feed them into the pipeline.
In short, rather than writing countless class-specific unit tests, I focused on reproducing real-world end-to-end scenarios inside the test framework. The project reached 91% coverage, and only a few bugs (if none) usually appeared during integration testing.
I was fortunate to have the time and freedom to build that mini testing framework — but most projects don’t allocate such resources or plan for these technical surprises. As a result, developers get trapped in testing hell.
“Wait, what about my architect? Shouldn’t they have already designed such an environment?”
Architects typically design the overall multi-service architecture, but someone still needs to take the time to reproduce that architecture locally, gather test datasets, and implement it in a reusable way for all developers. This requires dedicated effort, but it ultimately saves developer time and significantly reduces the occurrence of bugs in the future. Of course, an architect is a amazing candidate for this task, as he/she understands all the interactions involved.
In Conclusion
If you want to catch bugs early in a complex multi-service project, allocate a dedicated position for a Test Designer, someone whose sole purpose is to enhance and evolve your testing ecosystem.
It’s not a single user story, it’s a continuous stream of improvements that will emerge throughout development.
Who should take on this role? It varies. It can be an experienced developer, an architect, or even a motivated junior developer. The only real requirement is that they understand the system from both a business and technical perspective and can recreate a simulated environment that’s as close to reality as possible.
People often say, “Fail fast, learn fast.”
Well, you’ll learn even faster if you fail earlier.
