By Dario Ochoa, QA Engineer at Distillery
I’ve been working as a QA for quite a few years, across projects of all kinds. Over time, I keep asking myself: Why do we need testing? Do we really need it? Am I providing value as a QA?
Then I see video games crashing on launch day with the most basic actions, airplanes losing a door mid-flight, cellphones exploding, or even mailmen getting arrested by mistake. These are reminders that when testing is missing, consequences can be serious.
The truth is, in software —as in life— what we really need is balance.
“Invincibility lies in the defense; the possibility of victory in the attack.” — Sun Tzu
As QAs, we play defense, we focus on the why. If it were up to us, products would launch with almost zero bugs… but only after years of testing. Developers, on the other hand, are the playmakers, the quarterbacks — focused on the how, building features and moving forward. Product Owners and Business Analysts focus on the what, and Management cares most about the when.
Each perspective is valid, but when one outweighs the others, an imbalance happens. If defense disappears, bugs slip through. If management overrules everything, deadlines beat quality. Each side must compromise through a well-balanced discussion. That is the only way projects succeed.
“Both optimists and pessimists contribute to society: the optimist invents the airplane, the pessimist the parachute.” — George Bernard Shaw
On the side of testing, I think I can argue its value and weigh in on that war for balance. I think we need testing because it’s boring, slow, and adds more tasks. Let me explain. Everyone else is playing attack, and when you add a task to test something, everyone else looks at you like, “Why are you delaying us”? “I already checked the code, it works, why add more testing?”, and sometimes they are correct. But if we, as QAs, don’t challenge that, if we don’t ask more questions, then we wouldn’t have defense, if our vision is not part of that balance, we will surely get into trouble soon enough.
Developers want to build, not save evidence or explore edge cases, and that is ok. Management wants things now, not after another testing round. Testing often feels like it’s slower, less exciting, and sometimes unpopular, but it’s because it’s an investment.
That makes QA a tough role: we constantly have to convince others that prevention is strategic, not just an obstacle. Without defense, the team is wide open.
“An ounce of prevention is worth a pound of cure.” — Benjamin Franklin
When projects are full of bugs, QA value is obvious. You find defects, report them, and the team sees immediate results. But as teams mature and processes improve, bugs become harder to find. Ironically, that’s when people start questioning whether QA is still necessary.
Testing then becomes like eating vegetables or exercising: boring, easy to skip, but essential for long-term health. When things are going well, it feels like we don’t need it — until problems appear again. Prevention is invisible. But invisibility doesn’t mean lack of value — it means the system is healthy.
“Slow is smooth, smooth is safe, safe is fast.” — Navy SEALs
One common imbalance comes from misinterpreting frameworks. Agile does not mean fast. Agile means “ability to change directions easily.” It is about adaptability: delivering in small increments, learning from feedback, and adjusting. That’s not the same as going fast (even less as rushing).
Similarly, lean methodology isn’t about eliminating all processes. It’s about improving them — cutting waste while keeping what adds value. When management confuses lean with “cutting corners,” testing is usually the first thing on the chopping block. That’s when preventable failures happen — sometimes with tragic results, like the OceanGate submersible disaster.
The velocity of a team lies more in processes and maturity — a racehorse might sprint if it’s forced, but it can only keep winning if it’s trained. Pressure gives speed for a moment; training gives speed for a career.
“Ubuntu: I am because we are.”
In the end, theory defines strategy and reality demands tactics. Knowledge and experience (and humility) are needed to put in place balanced workframes. For a project to run smoothly, all roles must respect and learn from each other:
- QA defends quality.
- Devs build the product.
- POs define direction.
- Management enables the team.
Only when these perspectives are balanced does software development work as it should. Testing may be less visible, but without it, the balance collapses.
