What You'll Learn:
- Requirement defects often cost more than coding defects because they affect architecture, development, testing, automation, and business validation.
-
Many production incidents originate from questions that were never asked during requirement discussions.
-
Accessibility, edge cases, exception handling, and system integrations are common sources of overlooked requirements.
-
AI can help analyze documented requirements but cannot uncover knowledge that exists only in stakeholders' minds.
How many defects did we find?
This is the most common question I used to ask my team. My managers used to ask me in most of my projects.
That was a measure of success.
After 22 years in software testing, I have stopped measuring the success of testing by one simple metric:
Today, I ask a different question.
How many defects should never have reached testing in the first place?
That means to say, how many defects did you prevent?
That question has changed how I think about testing and user experience.
Early in my career, I believed thorough testing could compensate for weak requirements. If we wrote enough test cases, explored enough scenarios, and executed comprehensive regression suites, we could catch almost anything before release.
But, my experience taught me something different
Some of the most expensive production issues I have analysed were not caused by poor coding or inadequate testing. Developers built what the requirements described. Testers validated exactly what was documented. Automation suites passed successfully. Green everywhere.
Yet customers experienced critical issues.
The real defect had been introduced much earlier.
It was written into the requirement.
Over the last couple of decades, our industry has transformed the way we build software. We started with the waterfall model. Moved to incremental. Then adopted Agile, embraced continuous delivery, invested heavily in automation, and are now integrating AI into every phase of SDLC.
These advances have made us faster. The speed!! Yes, all of us are in the race.
But speed cannot compensate for building the wrong solution or solution which might introduce new user problems.
In my experience, requirement quality/completeness remains one of the most overlooked factors impacting software quality.
Requirement defects have the largest blast radius
A coding defect usually impacts a feature.
A requirement defect affects an entire delivery pipeline.
Once an incorrect assumption enters a requirement, it propagates through every stage of development. Architects design it, developers implement it, and testers create test cases from it. Then automation validates it, and product owners approve demonstrations based on it.
Everyone can perform their work correctly. All internal stakeholders are happy.
But the outcome can still be wrong.
And, I have often heard teams say, "The testing team missed the defect."
Whenever I hear that, I ask a different question.
Was the correct behaviour ever defined in the first place?
Testing cannot validate a business rule that was neither discussed, nor documented.
Automation cannot verify an exception scenario that nobody identified.
AI cannot discover business knowledge that exists only in someone's head.
AI can analyse what has been written. It cannot analyse what was never said. That distinction is more important today than ever.
The patterns I have seen repeat throughout my career
Every project is different.
But the underlying causes of requirement defects are remarkably similar.
The most common one is assumptions.
Teams often leave requirement discussions believing everyone shares the same understanding. In reality, each stakeholder takes away a slightly different interpretation.
Here is one incident from my career. It fundamentally changed how I view requirement reviews.
We were working on a feature. It had progressed through requirement discussions, development, testing, and user acceptance testing without major concerns. Every planned test case passed. The feature was ready for release.
Just before production deployment, a business stakeholder casually asked how the feature would behave for one specific category of users who can not use a mouse.
You know what, there was a dead silence. Everyone was looking at one another. We had big question marks on our faces.
That scenario had never been discussed. It wasn't in the requirement document. Developers had implemented exactly what was specified, and testers had validated exactly what was documented. No one had made a mistake during execution.
The mistake had occurred much earlier.
No one thought about accessibility. No one thought about users who cannot use a mouse due to disabilities.
An important business and user rule had never been captured.
Accommodating that single missing requirement required design changes, code changes, additional test cases, regression testing, updated documentation, and ultimately a delayed release.
That experience taught me something I have never forgotten.
And the new lesson is : Many expensive defects don't originate from poor implementation. They originate from unanswered questions during requirement discussions.
I wonder. In some projects, requirements review/discussion never happens !!
Another recurring pattern is incomplete business rules.
Most requirements describe the happy path perfectly. But say nothing or very little about exceptions.
- What happens when external systems are unavailable?
- How should the application behave when permissions change?
- What if customer data is incomplete?
- What if regulations require additional validation?
- What if users make mistakes and do wrong operations on the application?
Developers may consider them as edge cases in enterprise software. But they are everyday realities.
I have also learned that enterprise failures rarely occur within a single application. The probability is low.
But, they most probably occur where multiple systems interact across an end-to-end business process.
Enterprise products exchange data with legacy platforms, third-party services, reporting tools, authentication systems, and external APIs. A feature may pass every functional test yet fail in production because a single integration assumption was never discussed during requirement analysis.
In complex enterprise environments, that missing assumption doesn’t stay local. It propagates across systems, amplifying business risk and impacting entire workflows.
Working in regulated environments reinforced another important lesson to me.
That is documentation.
Many people see documentation as bureaucracy. Or as an overhead.
I see it differently.
Documentation is not created because organisations enjoy paperwork. Or just for audit purposes.
It exists because software outlives projects, team members move on, audits happen. Business decisions made today may need to be understood years later.
In regulated industries, proving that quality activities were performed correctly is often as important as performing them.
Documentation is a mechanism for preserving knowledge and reducing future risk. And not simply about compliance.
Prevention creates more value than detection
Ask questions.
One practice that has consistently improved quality throughout my career is asking better questions before development begins.
Some of the highest-value work I have done as a tester happened before a single line of code was written. Before a mockup was created. Before test cases were designed.
- Requirement reviews.
- Risk discussions.
- Design walkthroughs.
- Assumptions made.
- Conversations with product managers and business stakeholders.
These activities have prevented more defects than weeks of execution testing.
Today, whenever I review requirements, I deliberately ask five questions:
- What assumptions are we making?
- Who is the exception to this workflow?
- Which external systems or business processes depend on this behaviour?
- What happens when things don't go as planned?
- If this feature fails in production, where is the greatest business risk?
These questions are simple.
Yet they consistently expose gaps that eventually become production incidents if left unanswered.
This is also where I believe AI genuinely helps experienced testers.
AI can summarize lengthy requirements, compare versions, identify inconsistencies, generate review questions, and suggest edge cases.
I have found these capabilities extremely useful.
But AI has limits.
- Output depends on the quality of input (prompt).
- It cannot interview a domain expert.
- It cannot challenge an unwritten organizational assumption.
- It cannot ask a product owner why a business rule changed after years of stability.
Those conversations still require curiosity, business understanding, and judgement.
We often celebrate automation coverage. 100% automation coverage claim.
After two decades in testing, I celebrate something different.
Assumption coverage.
Because assumptions, not code have caused some of the biggest problems I have seen.
A different definition of a great tester
When I started my career, I admired testers who found hundreds of defects.
In one of the projects, we even awarded a tester who reported maximum defects !
Today, I admire testers who prevent those defects.
That requires a different mindset.
- It requires curiosity instead of compliance.
- Business understanding instead of only technical expertise.
- Confidence to challenge requirements respectfully before development begins.
You may need smarter automation or better AI. You certainly need both.
But your product quality & user experience still come from better conversations, clearer requirements, and a willingness to question assumptions before they become code.
Ask bad , uncomfortable questions. Early in the SDLC. You will build good products. Your users will have a great user experience.
