Owning the test estate: platform thinking

A test estate is every test a company has, spread across unit, integration, end to end, manual regression, and whatever half-abandoned Postman collection someone wrote three years ago. Most testers write tests inside that estate. Senior QA people own the estate itself, and that shift in responsibility is what actually separates a mid-level tester from a staff-level one, more than years of experience or tool knowledge ever does.

Writing tests versus owning the estate

Writing a good test requires knowing the feature and the tool. Owning the estate requires knowing which of the 6,000 existing tests are worth keeping, which ones nobody trusts anymore, which ones run and pass without checking anything real, and which parts of the product have almost no coverage at all. This is inventory work as much as engineering work, and it rarely gets assigned. Someone has to decide to do it.

At a logistics company I worked with, the end to end suite had grown to 1,800 tests over six years with no owner. A third of them were skipped in CI with no comment explaining why. Nobody wanted to delete them in case something important broke, and nobody wanted to fix them because nobody knew what they tested anymore. This is what an unowned test estate looks like, and it is far more common than teams admit.

The audit nobody wants to do

Taking ownership starts with an unglamorous audit: which tests have failed and been ignored in the last quarter, which ones take the longest to run relative to the risk they cover, and which parts of the codebase ship changes with zero test coverage touching them. This connects directly to why assertions break, because a huge fraction of an unhealthy estate is tests that assert the wrong thing entirely.

The logistics team's audit took two weeks and found that 40 percent of the "failing" tests in their dashboard had been red for over a year. Nobody was reading the results anymore. Deleting those tests and writing five new ones that actually covered the risky checkout path did more for real quality than the entire previous year of ad hoc test writing.

Making the estate someone's actual job

Ownership means having the authority to delete a test, not just add one. It means tracking coverage gaps the way a product manager tracks a roadmap, with a visible list and a review cadence. It also means being the person a director calls when they ask "can we trust our test suite" and getting a real answer instead of a shrug. This overlaps heavily with coaching developers to write decent tests themselves, since a healthy estate depends on that rather than a QA person cleaning up after every commit.

Estate ownership also means saying no. A team eager to add tests for every new feature will happily grow the estate to a size nobody can maintain. Part of the job is pushing back: does this test cover a real risk, or does it just make the coverage percentage look better on a dashboard.

• Inventory what exists: coverage, flakiness, run time, and whether anyone actually reads the results.
• Delete or fix anything that has been ignored for months. A red test nobody reads is worse than no test.
• Track gaps like a roadmap, with a visible owner and a review cadence, not an occasional cleanup sprint.
• Push back on low-value additions that inflate coverage numbers without reducing real risk.

Consider a checkout team that added a new end to end test for every feature flag they shipped over two years. By the time someone audited it, 60 tests covered the same three checkout paths with slightly different flag combinations, while a newer refund flow had no coverage at all. The fix was not more tests. It was deleting 45 redundant ones and adding four that covered the actual gap.

This is also one of the clearest ways to build proof of work toward a senior title. A resume line claiming "senior QA engineer" means little. A concrete story about cutting a flaky 90-minute suite down to 20 reliable minutes, with numbers, is something an interviewer remembers.

FAQ