Answer.

Background:

Test coverage is one of the main metrics of testing quality. Coverage strategies emerged in the early days of automation when the number of tests began to grow rapidly, making it impossible to manually track uncovered scenarios. Since then, approaches have evolved from intuitive to strict analytical methods, including the use of requirements traceability, code coverage tools, and control over the testing pyramid technique.

Problem:

Achieving balanced and conscious test coverage is a complex task due to different types of tests (unit, integration, E2E), varying execution speeds, maintenance costs, as well as the need to balance ROI and risks of missed defects.
There is often a false sense of complete protection simply due to a high percentage of code coverage while ignoring "gaps" in business logic or user scenarios.

Solution:

A combination of different techniques should be used: code coverage, traceability matrix, risk-based testing.
It's important to align the strategy with the development team and the business to understand the real priorities.
A key practice is regular coverage audits (both manual and automated), adjusting priorities, and abandoning the idea of "100% code coverage" in favor of a more meaningful, scenario-based, and risk-oriented approach.

Key features:

Use of multiple types of coverage: statement, branch, condition, feature, requirements coverage.
Integration of traceability matrix and code coverage techniques for maximum completeness.
Regular review of the strategy and automatic report generation.

Tricky questions.

Can a high percentage of code coverage fully guarantee product quality?

No, it cannot. A high percentage of code coverage (e.g., 95%) often means that only specific areas of the code were "hit" by tests, but this does not guarantee the correctness of business logic or usage scenarios.

Should one always strive for 100% code coverage?

No. Striving for 100% coverage increases maintenance costs and sometimes requires writing tests for insignificant or unreachable areas. It's better to prioritize based on risk and benefit.

Is it sufficient to use only unit tests to ensure reliable coverage?

No. Unit tests do not cover integration scenarios or component interactions. Different types of tests need to be combined according to the testing pyramid.

Common mistakes and anti-patterns

Blindly striving for a high percentage of code coverage
Ignoring coverage of user scenarios and requirements
Lack of business team involvement in determining coverage priorities
All tests of one type: only unit or only E2E

Real-life example

Negative case

The team implemented a pipeline with a mandatory 90% coverage of tests for each pull request. As a result, "empty" tests started to appear, covering lines but not scenarios. Errors in business logic went unnoticed.

Pros:

Quickly achieving a formal criterion
Motivation to write more tests

Cons:

Tests don't catch real bugs
Technical debt grows, and the team loses trust in tests

Positive case

The team built a coverage strategy using a traceability matrix and risk-based testing: the most critical functionality is covered by E2E tests, less important by unit tests. A coverage audit by scenarios is conducted once a month.