Loading today’s stories
Build1 distinct publisher3 min readPublished
DeviQA reports a healthcare platform's regression pass falling from two and a half weeks to a single day while coverage went from 50% to 90%. The arithmetic says most of that came out of the suite's contents, not the test runner.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Two and a half weeks on a five-day week is 12.5 working days [1]. Getting to one day means taking roughly 92% of the elapsed time out, a 12.5x reduction [1]. Read the two and a half weeks as calendar time and the required cut rises to about 94% [1]. Either reading, ask where that time can come from. The lead-time sum in the write-up has seven terms: preparation, environment setup, queue time, execution, failure investigation, reruns and reporting [7]. Execution is one of them, and the author says it is often not the biggest [8]. Removing execution entirely saves only execution's share, so a 92% cut is arithmetically unavailable from a faster runner unless execution was already more than 92% of lead time [4]. I have not worked on a suite where it was.
The smoke figure is the sharper tell. Smoke alone took seven days [2], which was 56% of the old pass by itself [3]. The full pass now takes one day [3], so the whole suite completes in a seventh of the time the cheapest tier used to need [2]. Running the same checks faster does not produce that. Either those checks stopped running, or they moved.
Both are what the piece prescribes. UI end-to-end tests break when a selector shifts, need a running environment and real data, and retry slowly [11]; the author's position is that the UI is the wrong place to verify a business rule you could assert against an API or a service, and that most slow suites are shaped like an inverted pyramid [12]. Move a rule check from a browser to a service call and you delete the environment, the seeding and the retry, not just the milliseconds.
The environment list is where I would look first: manually configured environments, shared mutable accounts, hand-seeded databases, third-party services outside the team's control, and tests that depend on running in a specific order [13]. Order dependence quietly forbids the runner's main trick. A suite that must run in sequence cannot be sharded across workers, so parallelism buys nothing until the fixtures are isolated.
Then triage. A two-hour run can still block a release for two days while someone works out whether red means a product defect, a broken test, an environment hiccup, a bad data state or a flaky third-party call [14]. The author reports watching teams celebrate twenty minutes off runtime while two days of post-run analysis went untouched [15]. That is the term automation is worst at compressing.
Transfer conditions, because this is one consultancy's first-person account of an unnamed client [17]. To get the same order of win you need a suite that is genuinely inverted-pyramid shaped, a lead time dominated by the non-execution terms, and coverage measured the same way before and after. The passage gives 50% to 90% without saying what is being covered [18]. Against line coverage that means something different than against risk coverage, and a suite that shed duplicated and outdated specs can raise the first while the second drops. Worth checking, because nobody gets promoted for deleting 300 tests, which is most of why the ballast is there in the first place [9].
Ranked by verification strength, evidence, and original report placement.
The author states that automation was part of the result but nowhere near the whole story.
Pointing automation at a bloated, outdated, UI-heavy suite produces an oversized, expensive automated version of the same slow process, plus a maintenance bill that grows every sprint.
A faster test runner does not create a faster regression process; it runs the wrong tests more quickly.
The author defines regression lead time as preparation plus environment setup plus queue time plus execution plus failure investigation plus reruns plus reporting.
Execution is one term in the lead-time sum and often not the biggest; you can halve runtime and still ship on the same day if the other six terms are untouched.
Every team is good at adding tests and almost none are disciplined about removing them, so suites accrete scenarios that are duplicated, outdated, disconnected from real risk, already covered at a lower level, or written so vaguely that a pass or fail tells you nothing.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 31, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Three manual interventions in a month, and every guard was working as designed1 distinct publisher
build
Six MariaDB versions, one real difference: the only reason to leave 10.6 is the July 2026 clock1 distinct publisher
build
Force the tool call, then hand Lightsail a long-lived key1 distinct publisher
build
Separating moderation rejections moved one API gateway's success rate from 95.5% to 98.9%1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One teller, checkable only by arithmetic
Every number in this story — the 2.5 weeks, the seven-day smoke tier, the one-day result, the coverage jump — comes from the practitioner who did the work, about a client he does not name, in a post no editor verified. What keeps the score off the floor is that the piece supplies the formula that constrains its own claim, so the internal consistency can be tested without trusting anyone.
One anonymised engagement, nothing to count
A single unnamed client is not an adoption curve. Nobody else in this reporting has tried the four-tier split or the audit checklist and reported back, there is no tool, release or repository to track uptake against, and the practices described are ordinary enough that usage elsewhere would be invisible anyway. We would rather say nothing than convert one anecdote into a number.
Sober thesis, unaudited headline
The argument runs against the grain of its own genre — a QA firm telling you not to start by automating, and conceding that automation was 'nowhere near the whole story' — so the framing is not inflated. The overstatement sits entirely in the marquee figures: a 12.5x cut with a coverage jump attached, presented with the confidence of a measured outcome and the evidentiary standing of a recollection.
Capability demonstration wearing a methodology
Read the structure rather than the sentences: an unnamed client, a dramatic before/after, and a five-step method that happens to describe consulting work rather than a product you could buy instead. That is business development, and the anonymity conveniently removes the possibility of a reference check. The mitigating detail is that the pitch argues against selling the customer more tooling, which is a strange lie to tell.
Sure about the reasoning, not the receipts
We are fairly confident the piece says what we say it says, and confident that its own lead-time decomposition rules out the runner as the main source of a 92% cut. We have almost no basis for believing the specific durations, and no second account to fall back on if they are wrong. Hence a middling number: strong on the durable idea, weak on the story it is hung from.