'Fix One Software Bug, Create Three More' Syndrome — Part 4: Why is this syndrome still unresolved at many software teams?
Mostly human factors.
In this article series:
Part 1: Symptoms and Consequences
Part 2: Why is it happening? *
Part 3: Solution: Automated End-to-End (UI) Regression Testing
Readers who have followed the previous three parts will likely agree with the following points:
The "Fix One Bug, Create Three More" syndrome is real and does happen often.
It’s costly, not just in time and money, but also in ways like frustrating customers and lowering team morale.
Automated end-to-end (UI) regression testing is an effective antidote.
Yet, most software teams still do nothing about it.
In this article, I’ll explain the reasons why this syndrome remains unresolved, based on my observations across numerous IT companies over the past two decades.
1. Neglect of Software Testing Overall
One of the most deep-rooted problems in the software industry is the widespread neglect of software testing. This isn’t just a team or company issue—it starts from the very beginning: university education. The fact: test automation courses are rarely offered.
This educational gap creates a culture where testing is seen as secondary or even optional.
2. No Immediate Pain After Fixing a Bug
Because the feedback loop is so long, teams don’t feel the impact right away.
When a developer fixes a bug, it’s often considered "job done," and the app "seems to work now." The newly introduced issues surface later, sometimes weeks or months down the line. But by then, the original change is old news and likely disconnected from the symptoms being observed.
3. Lack of E2E Test Automation Skills, but principal software engineers and architects often think they do.
Let’s see some quotes:
“In my experience, great developers do not always make great testers, but great testers (who also have strong design skills) can make great developers. It’s a mindset and a passion. … They are gold”.
- Patrick Copeland, Google Senior Engineering Director, in an interview (2010)“95% of the time, 95% of test engineers will write bad GUI automation just because it’s a very difficult thing to do correctly”.
- this interview from Microsoft Test Guru Alan Page (2015), author of “How we test software at Microsoft”“Automated testing through the GUI is intuitive, seductive, and almost always wrong!” - Robert C. Martin, co-author of the Agile Manifesto, on his blog (in 2009)
“Testing is harder than developing. If you want to have good testing you need to put your best people in testing.”
- Gerald Weinberg, software legend, in a podcast (2018)
A real test automation engineer is referred to as ‘Gold’ at Google. So, chances are that no one in your company—and possibly no one in any software company in your city (unless you're in Silicon Valley)—truly understands end-to-end (E2E) test automation.
Yet, nearly every principal software engineer and solution architect I met or witnessed could talk about E2E test automation, wrongly, of course.
I did once meet one test lead in a meeting who said, “All past E2E test automation attempts have failed in this company. I admit I don’t have the knowledge.” That kind of honesty made it easy for me to help him implement real E2E test automation. Unfortunately, very few have the courage and wisdom.
4. Confusing Continuous Testing with Continuous Integration
From a testing perspective, Continuous Integration (CI) focuses on running automated unit and integration tests. Continuous Testing (CT), on the other hand, involves executing automated end-to-end (UI) tests. The tools, skills, and practices required for each are very different—CT is significantly more challenging than CI.
By the way, real Continuous Delivery (CD) is only possible with solid Continuous Testing in place.
In reality, because so few software professionals have seen real success with end-to-end (E2E) test automation and Continuous Testing (CT), they often confuse it with Continuous Integration (CI). Most principal software engineers and architects are in the dark—blindly attempting to run E2E test suites using traditional CI tools like GitHub Actions or Jenkins. These efforts frequently lead to failure and, ultimately, embarrassment.
5. Don’t seek external help
When a clearly defined task keeps failing, the logical response is to seek professional help—even a child knows that. Yet in practice, software companies rarely reach out for support when it comes to end-to-end (E2E) test automation.
As mentioned earlier, many senior engineers see testing as secondary—something that shouldn’t be difficult. Admitting they need help feels like a loss of face, so they avoid it entirely.
So, how do these principal engineers typically respond when the CEO demands test automation? Rather than acknowledging the skill gap, they place their bets on a hyped new test automation framework or tool, hoping it will magically solve the problem. So, we witnessed this.
In fact, the raw Selenium WebDriver (released in 2011) is just fine and web testing has barely changed since then.
“Facebook is released twice a day, and keeping up this pace is at the heart of our culture. With this release pace, automated testing with Selenium is crucial to making sure everything works before being released.” — DAMIEN SERENI, Engineering Director at Facebook, at Selenium 2013 conference.
I have implemented successful web test automation for various software projects, with the same tech stack since 2011.
