Possibly. A full test schedule does not mean useful testing is happening.
Imagine a checkout service with 200 tests. One hundred and eighty cover field validation, page layout and minor combinations. Twenty touch payment. Then the system double-charges Visa customers.
The dashboard will still tell you coverage was excellent. The customers may have a different opinion.
This is the kind of problem we like looking at because the fix is often not ‘more tests’ but moving effort towards the few things that can actually hurt you.
Coverage should follow consequence
Look at where failure hurts most: money, data, access, legal obligations, critical operations, high-volume journeys, irreversible changes and fragile integrations. Those areas should attract more thought and more varied testing.
Easy-to-test features naturally accumulate tests because they are convenient. Hard areas often get hand-waved because the environment is awkward or the data is difficult. That is exactly backwards. That helps explain why automated tests can pass while software is broken: scripts check the easy things while serious failures remain untouched.
Risk-based testing is not a phrase to put on slide three. It means consciously moving effort away from low-consequence repetition and towards the parts of the system where being wrong matters.
Use production to challenge the plan
Take the last ten serious incidents and ask whether the current test approach would find them today. If several would still escape, your coverage model is telling you something.
Follow the money, data and trust
If you need a quick way to prioritise, trace where the product touches money, valuable data, access rights and customer trust. Those paths often expose the risks that feature-by-feature testing misses. A harmless display bug and an account-isolation bug are both ‘functional defects’. Only one should keep senior people awake.
Also ask where the team is avoiding testing because it is difficult. Hard-to-create data, awkward integrations, batch processes and failure recovery frequently receive less coverage precisely because they require more effort. Difficulty is not evidence of low risk.
A good test approach is willing to spend ten times longer on one dangerous workflow than on ten trivial ones. Equality of test effort sounds fair and is usually nonsense.
A useful sanity check is to look at where the test team’s time actually went on the last release. If most of it was spent repeating easy page-level checks while the difficult integration or permission work was squeezed into the final day, the problem is visible without inventing a new methodology. Move the effort before you buy more of it.
If you want an independent view, we can do that review for you. We can map your test effort against business risk, recent incidents and system architecture and tell you where the team is over-testing, under-testing or simply testing the wrong thing very thoroughly.