Manual Testing (IT)Manual QA Engineer

How to determine the sufficiency of testing coverage in a manual approach and why it is important?

Pass interviews with Hintsage AI assistant

Answer.

Background of the question:

The issue of test sufficiency arose when projects became large and time became scarce. It became necessary to understand when to stop testing in order to use resources effectively. The tester must explain to the business that enough has been tested and the risks are minimal.

Problem:

Manual testing cannot be made absolutely complete — there are always constraints on time and resources. Insufficient coverage leads to missed defects, while excessive coverage causes budget overruns and delays.

Solution:

  • Use coverage metrics: percentage of passed requirements, code coverage (if accessible), ratio of unique scenarios/modules.
  • Implement traceability matrix practices to ensure test cases meet requirements.
  • Conduct joint reviews of test cases and defects with the team.

Key features:

  • Harmonization between requirements, test cases, and functional modules.
  • Risk assessment for prioritization.
  • The ability to clearly justify why testing is complete.

Tricky questions.

Can we rely solely on coverage by test cases without considering risks?

No. It is necessary to consider the priorities of functionality: which areas are most critical to the business.

Does the number of test cases always indicate the quality of coverage?

No. A lot of unfounded or duplicate test cases do not indicate high coverage.

Should exploratory testing be included in the coverage metric?

Yes, definitely. Exploratory testing uncovers unexpected defects that formal test cases miss, and it should be part of the overall coverage picture.

Common mistakes and anti-patterns

  • Focusing only on formal indicators, ignoring critical risk areas.
  • Hiding coverage deficiencies (unaccounted requirements, untested scenarios).
  • Missing deadlines due to the desire to "cover everything".

Real-life example

Negative case

The tester considers coverage solely based on the number of test cases without taking into account the impact area of bugs or user scenarios.

Pros:

  • Easy to present nice reports.

Cons:

  • Critical bugs may remain out of sight.

Positive case

The tester, together with the analyst, clarifies risks, adjusts coverage and focuses efforts on the most important components.

Pros:

  • Minimization of the likelihood of serious bugs in production.
  • Ability to justify to the team lead the time of test completion.

Cons:

  • Additional approvals are needed within the team.