Why does “no bugs” fail to prove quality?
Testing proves the software matches the specification. Testing does not prove the specification matches the work.
These are two different things, and the gap between them is where most projects fail. Three patterns repeat:
- Correct logic, worse workflow. A task that used to take three steps now takes eight. Staff quietly return to spreadsheets.
- Correct spec, real data breaks it. The spec was written against clean sample data. Production data has blank fields, duplicate codes and special characters — and the flow fails in the first week.
- Correct feature, wrong purpose. The request was an “export to Excel” button. The real goal was the Monday morning report to head office. The button works exactly as specified, and the report still takes half a day.
All three pass acceptance testing. All three are failed projects.
What does unused software actually cost?
The cost of unused software is larger than the build budget, because it keeps accruing every day the system stays live.
For internal systems, the cost shows up as time. Here is a calculation you can run on your own numbers:
| Variable | Example value | Result |
| Extra time per person per day | 30 minutes | — |
| People using the system | 100 | 50 person-hours per day |
| Working days per year | 250 | 12,500 person-hours per year |
This is an illustrative calculation, not survey data. Replace the values with your own — the result is usually larger than expected.
For customer-facing applications, the cost is revenue leaking across page transitions and load times. The difficulty is that this loss appears in no report, so no one owns it.
For agencies and systems integrators, the cost is credibility. Deliver something that runs but produces no result, and the end client does not come back — and does not explain why.
Which metrics measure software quality?
Software quality should be measured with four metrics used together. A single metric misses the most dangerous failure mode: software that matches the specification and no one uses.
| Metric | Definition | Measured by | Frequency |
| Defect density at acceptance | Defects found ÷ delivered scope | Vendor | End of phase |
| Defect escape rate | Defects found after go-live ÷ total defects | Vendor | Every sprint |
| Task completion rate | Completed ÷ started core business tasks | System logs | Weekly |
| 90-day retention | Active users after 90 days ÷ provisioned accounts | Both parties | Monthly |
The first two belong to the vendor. The last two can only be measured after the system is live — which is precisely why most contracts leave them out.
One practical note: the logging needed for measurement must be designed before release, not added afterwards. Adding it post go-live loses the baseline, and every later improvement becomes unprovable.
How does VAON control quality?
VAON uses three review layers. Each layer catches a class of defect the previous layer cannot see.
| Layer | Performed by | Catches |
| 1. Self-check against acceptance criteria | The implementing engineer | Deviation from agreed acceptance criteria |
| 2. Peer cross-review | An engineer not involved in that work | Logic errors, duplication, missing edge cases |
| 3. Business-perspective acceptance | BrSE (Bridge System Engineer) | Code is correct but the business task fails |
The third layer is the decisive one. Layers one and two check the software against documents; layer three checks it against the actual job. It requires someone fluent in both the business and the technology, which is why most outsourcing arrangements skip it.
Alongside these layers, VAON reports the four metrics above in regular reviews — including when the numbers are poor. A bad number found early is far cheaper than the same number found late.
How do warranty and post-release improvement differ?
Warranty and improvement are different scopes, and failing to separate them is the most common source of post-delivery disputes.
| Warranty | Post-release improvement | |
| Covers | Deviation from the signed specification | Specification was right, real usage shows change is needed |
| Who pays | The vendor | By prior agreement — must be written into the contract |
| Decided by | The specification document | Usage data and user feedback |
VAON includes one post-release improvement cycle in contract scope, with an explicit hour cap. That removes the need to argue about boundaries the first time an issue appears.
Five questions to ask a vendor before signing
These five work with any vendor, including VAON. A vague answer to any of them is itself a risk signal.
- What is your actual defect escape rate on recent projects?
- Who writes the acceptance criteria — you or us?
- Is post-release improvement inside contract scope, and capped at how many hours?
- When production breaks, who responds first and within how many minutes?
- Are test cases generated from acceptance criteria, or from the code you already wrote?
The fifth question matters most. Tests generated from code only confirm that the code does what it currently does; they cannot detect divergence from the requirement.
When is measurement not worth it?
Measurement is not always worth its cost. Three cases where you should skip it:
- Short proof-of-concept work. The goal is technical feasibility, not operational outcome.
- Internal systems with fewer than 20 users. Task completion rate plus monthly qualitative feedback is enough. More metrics only add paperwork.
- No access to logs or to end users. Without data, every metric is a guess. In this case, renegotiate the scope of responsibility upfront instead.
Stating limits is part of quality assurance. A vendor who promises to measure everything in every situation has probably not done the work.
Next step
If you are running a delivered system and cannot say what result it produces, the sensible step is to assess the current state before investing further.
VAON offers a current-state assessment: a review of the acceptance criteria in use, identification of the metrics measurable today with existing data, and the logging gaps to close before the next phase. The output is a short report, with no contractual obligation.
Contact: sales@ai.vaon.com.vn · Website: https://vaon.com.vn/en