Quality Culture and Ownership Questions

Direct answer

With three months and four people (three developers, one QA), the right move is not to try to test everything. Sequence work by risk (which paths have caused the most past incidents and change the most often), bank a visible quick win in the first two weeks to earn trust, and spend the last stretch making the new habit durable rather than just adding more tests.

Structured elaboration

Weeks 1-2: baseline and a fast win. Inventory the service's critical paths and interview support/on-call about where incidents actually cluster. Pick the single riskiest path and add one smoke test (a fast check that the core flow still basically works, not a full regression pass) for it in continuous integration (CI), even if it is only a handful of assertions, so the team sees automated coverage exist for the first time.

Weeks 3-6: characterization tests on the riskiest, most-changed code. Rank modules by git change frequency crossed with incident history, and write characterization tests (tests that lock in current, observed behavior so a refactor cannot silently break it) for the top few before anyone refactors them. Prefer these integration-style tests over unit tests at this stage, since legacy code usually has no clean seams for unit testing yet; carve out small unit tests opportunistically wherever a change happens to create one. In parallel, QA builds an end-to-end smoke suite (a fast set of tests covering the handful of paths that would be catastrophic if broken) covering the top five user journeys.

Weeks 7-10: a coverage floor plus a CI gate. Add a definition-of-done line: no pull request merges without a test for the lines it touches. Write a regression test for every defect traced back to a past incident, so the same failure cannot recur silently. Make the smoke suite a blocking CI check; keep broader unit coverage advisory so velocity is not choked everywhere at once.

Weeks 11-12: consolidate and report. Write a short internal guide on how to write and run these tests, pair with each engineer once on adding a test for code they already own, and prepare the three-month report.

Tests to prioritize: characterization and integration tests on the highest-risk, most-changed paths first, a small smoke suite across the top user journeys, and unit tests only where a change naturally creates a testable seam. Not a blanket rewrite of the whole surface.

Maintaining the tests: make "add a test for touched lines" part of the pull request definition of done, keep the smoke suite blocking in CI, run a 15-minute weekly test-health triage (are any tests skipped or flaky), and forbid disabling a test without an attached ticket explaining why.

Worked example

Say the legacy service is a billing engine that had roughly 15 production incidents in the prior quarter, all resolved by hand with no test written afterward. Week 1: baseline shows zero automated tests. Week 2: one smoke test for the highest-risk billing calculation runs in CI. By week 6: about a dozen characterization tests now cover the three most-changed billing modules, identified from commit history. By week 10: the smoke suite blocks merges, and two of the historical incidents now have a regression test that would have caught them. By week 12: the report shows the smoke suite already caught one real regression before release, roughly a third of new pull requests now include a test, and the change-failure rate for this service is trending down against the pre-project baseline, described as an early trend rather than a solved problem.

Trade-offs and pitfalls

The most common wrong turn is trying to unit-test the whole legacy codebase before shipping anything visible, which produces no progress the team can point to in three months. Chasing a raw coverage percentage as the headline metric invites trivial, low-value tests written just to move the number. Characterization tests intentionally lock in current behavior, including known bugs, so document what you are deliberately not fixing yet rather than letting a test quietly certify a bug as "correct." With only one QA engineer, keep them focused on smoke and end-to-end coverage while developers write characterization tests as part of work they are already doing, rather than running testing as a separate initiative competing with feature deadlines.

Direct answer

As SDET (Software Development Engineer in Test) lead, treat the automation roadmap as an investment portfolio, not a single up-or-down bet: prioritize by expected reduction in the cost of the failures that actually hurt today (frequent flaky escapes, slow manual regression cycles) rather than by raw coverage percentage, fund it in small increments that ship alongside feature work instead of asking for a dedicated quarter, and report return on investment (ROI) in terms both engineering leadership and product understand, mainly time saved and incidents avoided, not "test count."

Structured elaboration

Prioritization. Rank candidate automation work by a rough cost-avoided-versus-effort ratio: what currently costs the most in engineer time or production risk (a manual regression pass that takes two days before every release, a class of defect that keeps escaping to production) goes first, ahead of comprehensive coverage of low-risk, rarely-changed code. This naturally produces a roadmap that pays for itself early, which is the strongest argument you can make for the next round of investment.

Building buy-in. Buy-in comes from evidence, not advocacy. Pick one painful, visible process (the slowest manual regression cycle, the flakiest recurring incident) and automate just that first, then show the before-and-after directly to both engineering leadership and product: how much manual time it used to cost, how much it costs now. A single credible before-and-after story does more for buy-in than a roadmap deck ever will.

Measuring ROI without inventing precision. Track a small number of things that are actually measurable: manual testing time avoided per release, count and severity of defects that would previously have escaped to production, and release cycle time before versus after. Present these as directional trends over successive releases, not as a single fabricated efficiency number, since a portfolio of automation work rarely reduces to one clean metric.

Balancing delivery pressure against reliability investment. Frame automation work explicitly as reducing a cost the team is already paying, manual regression time and production incident response, rather than as new overhead competing with features. Time-box the automation work as a fixed, small percentage of each sprint or cycle rather than asking for a dedicated block up front; a steady, visible trickle survives budget pressure better than a large ask that's an easy target to cut when a deadline looms.

Staying at the right altitude. This is a prioritization and buy-in problem, not a framework-design problem: the tool choice and test-suite architecture matter far less to leadership and product than the fact that a genuinely painful process got measurably faster and safer.

Worked example

A team's release process includes a two-day manual regression pass before every release, and roughly a quarter of releases in the past few months have needed a hotfix within a week because the manual pass missed something under time pressure. Instead of proposing a broad "increase automated coverage to eighty percent" initiative, which is hard for leadership to evaluate and easy to deprioritize, the roadmap targets that specific regression pass first. Automating the highest-traffic regression paths takes a few sprints, folded in alongside normal feature work rather than as a dedicated block. The next release cycle, the manual pass shrinks from two days to a few hours of spot-checking, and the hotfix rate in the following few releases drops noticeably. That specific, concrete win, not an abstract coverage target, is what gets the next investment approved without a fight, because both engineering leadership and product can see exactly what it bought them.

Trade-offs and pitfalls

Chasing coverage percentage as the primary metric is the most common trap: it's easy to report but doesn't track with actual risk reduction, and a team can hit a high percentage while leaving the riskiest, most complex paths untested because they were hardest to automate. Asking for a large upfront investment before showing any win is a hard sell under delivery pressure and an easy target when priorities shift. And framing automation purely as "quality work" rather than tying it to a concrete cost the business already feels (release delays, hotfixes, manual toil) makes it compete directly with features for the same attention, a fight it usually loses.

Direct answer

I would shift from "QA tests everything before release" to "engineers own testing their own changes, with QA as a coach and a safety net for the riskiest work," and back that shift with concrete role changes, automation targets so coverage doesn't silently drop as the manual gate shrinks, and a risk-based process so low-risk changes stop waiting in a queue at all. I would phase this over the three months rather than remove the gate on day one, since pulling the gate out before its replacement is ready just moves the bottleneck into production as a defect spike.

Structured elaboration

Roles:

• Engineers own writing and maintaining tests for their own changes as part of what "done" means, rather than handing untested work to QA.
• QA shifts to two things: coaching and reviewing test design on the riskiest changes, and owning the shared test infrastructure and the remaining end-to-end (e2e) suite that spans multiple teams' work, which no single engineer can own alone.
• A rotating "release captain" role, held by an engineer, not QA, is accountable for a given release going out cleanly, so accountability for a clean release doesn't default back to QA out of habit.

Automation targets: set a concrete target for how much of the current manual QA testing gets automated within the three months, starting with the highest-frequency, most repetitive manual checks, since those return the most time for the least effort. Track the percentage automated as a leading indicator alongside defect escape rate (bugs caught in production instead of before release), so the team can tell automation is actually replacing manual effort rather than just adding to it.

Process changes: pull QA into design and planning for risky changes instead of only at test time, and favor smaller, more frequent releases over large batched ones, since a bottleneck is often as much about batch size as about who does the testing, a smaller release has a smaller test surface and clears faster even before any automation lands. Define a risk-based release path: low-risk changes ship with the engineer's own automated tests and no QA gate at all; medium-risk changes get an asynchronous QA review that doesn't require QA to be available in real time; high-risk changes keep a synchronous QA review, at least while the transition is still in progress.

Three-month horizon:

• Month 1: baseline the current release cadence and find out where the time is actually lost, QA's real test execution time, or queueing while waiting for a QA person to be available, since the fix differs depending on which it is. Introduce the risk-based release path and the release captain role, and automate the handful of highest-frequency manual checks first.
• Month 2: automate the next tier of manual checks, have QA start pairing with engineers during planning for medium and high risk work, and measure release cadence and defect escape rate against the month-1 baseline.
• Month 3: check whether the low-risk, no-gate path is holding up (no unusual increase in escaped defects) and, if so, expand which categories of change qualify as low-risk. Formalize the new roles and process as the team's normal way of working, with a checkpoint review at quarter's end.

Worked example

Say the team currently ships 10 releases per quarter, and each release spends an average of 3 business days sitting in a QA queue before going out, because QA capacity, not test execution time itself, is the constraint. After automating the manual checks that made up the largest share of QA's execution time and introducing the risk-based path, the target by month 3 is for low-risk changes to skip the queue entirely (near-zero QA wait time) and for medium and high risk changes to see queue time drop meaningfully because the asynchronous review no longer requires waiting for a QA person's real-time availability. I would present this as the plan's target, checked against the month-1 baseline and the month-2 and month-3 measurements, not as an outcome already achieved.

Trade-offs and pitfalls

• Removing the QA gate before automation and engineer-owned testing habits are genuinely in place just relocates the bottleneck into production as a defect spike; the phased sequence exists specifically to avoid shipping the risk-based path ahead of its safety net.
• Treating this purely as a QA headcount or tooling problem misses that part of the delay is batch size and queueing, not test execution time itself; fixing only the automation side without also fixing release batching leaves real velocity on the table.
• Distributing testing responsibility to engineers increases velocity but risks inconsistent test quality early on, especially among engineers newer to testing; QA's coaching role exists specifically to manage that risk during the transition rather than disappearing on day one.
• Tracking release speed without tracking defect escape rate in parallel risks trading a slow-but-safe process for a fast-but-leaky one, which is the exact failure this plan is meant to avoid, not a different one.

Direct answer

I would write a short memo that agrees with the goal behind the ask (confidence that we are not shipping bugs) while explaining why 100% coverage does not reliably deliver that goal, propose a small set of alternative metrics and enforcement policies that correlate with it more directly, and lay out a negotiation path built on a short pilot with real data rather than a flat "no." The memo contests the metric, not the goal, which is what keeps leadership on the same side.

Structured elaboration

Why coverage alone is the wrong KPI (key performance indicator): coverage measures whether a line of code executed during a test, not whether the test actually verified correct behavior. A test with no real assertions can hit 100% of a file's lines and catch nothing. Pushing toward the last 10 to 20% of coverage, usually defensive error handling for scenarios that almost never occur, tends to cost far more engineering effort than the risk it removes. And once 100% becomes the target itself, it invites writing shallow tests purely to hit the number, a version of the well-known problem that a measure stops being a good measure the moment it becomes the target (often called Goodhart's law).

Alternative metrics I would propose, from lightest to heaviest to implement:

• Defect escape rate: the share of bugs found in production versus caught before release. This is a more direct proxy for "no bugs" than coverage ever was.
• Change failure rate: the share of releases that need a hotfix or rollback.
• Churn-weighted coverage: instead of a flat target everywhere, require higher coverage on files that change frequently, since a file edited constantly carries more real risk per line than one untouched for years.
• Historical-failures-weighted coverage: set stricter coverage bars specifically on the parts of the codebase with an actual track record of defects, rather than treating every file as equally risky.
• A defect-risk prediction model, using signals like change size, file history, and past defect density to flag high-risk changes for extra review, is a credible longer-term option for a mature organization, but I would flag it as a future-state investment, not something to promise as a month-one deliverable.

Enforcement policies: gate coverage on new and changed code specifically (a change must not lower coverage on the files it touches) rather than requiring the entire legacy codebase to hit a uniform number, since retrofitting old, stable, low-risk code is usually the most expensive and least valuable part of a 100% mandate. Pair that with periodic, targeted verification (spot-checking that tests on the highest-risk files actually catch a deliberately introduced defect, not just execute the line) on a sample of high-risk files rather than everywhere, since that kind of check is too expensive to run universally.

Negotiation plan: first, acknowledge the goal explicitly in the memo, leadership wants assurance there are not bugs, and that is a goal engineering shares. Second, pull two quarters of this codebase's own coverage and defect data and show the actual correlation (or lack of one) between high coverage and escaped defects, so the case is made with this organization's own evidence, not an abstract argument. Third, propose piloting the alternative metric set on one product line for a defined period, with an explicit "what would tell us this worked" criterion agreed in advance. Fourth, frame the ask in terms leadership already cares about: redirecting effort from the last, most expensive slice of coverage toward the metrics that more directly reduce escaped defects is a better use of the same engineering budget, not a request to lower the bar.

Worked example

Suppose a two-quarter pull of this codebase's own data shows that files already above 90% coverage still accounted for roughly 40% of the quarter's escaped, customer-visible defects. That single data point does more to move a skeptical executive than any general argument about coverage's limitations, because it shows the specific mandate is not achieving its own stated purpose in this specific codebase. The memo would present that number alongside the proposed pilot, not as proof the alternative metrics work yet, but as the reason the current single KPI deserves a second look.

Trade-offs and pitfalls

• Pushing back on the 100% ask without offering a credible substitute reads as engineering resisting quality itself, which damages trust with leadership; the memo has to lead with an alternative, not a refusal.
• The alternative metrics, especially churn-weighted and historical-failures-weighted coverage, depend on the organization's incident and change-tracking data being reasonably clean; if that data is itself unreliable, the alternatives inherit that unreliability and the memo should say so upfront rather than overselling them.
• Leading with technical nuance before restating the shared goal loses the room fast; the memo's structure (goal, then evidence, then proposal) is deliberate, not just a formatting choice.
• A single-product-line pilot risks leadership generalizing a good or bad result too broadly in either direction; being explicit about what the pilot can and cannot tell you protects against both overreacting to a lucky result and dismissing a real one.