Your Test Suite Is a Diligence Asset, or a Liability an Acquirer Will Find

Mostafa Dhouib·8 min read

Your Test Suite Is a Diligence Asset, or a Liability an Acquirer Will Find

The short answer. A suite nobody has watched go red is unproven, and to a diligence engineer unproven is indistinguishable from absent. Seven specific absences reprice deals, and each one maps to a named public failure. The highest yield question an investor can ask is to make a check fail on camera.

Most of this pillar argues that verification rigor is worth doing because systems fail without it. This post makes the other argument, which lands with a different audience: rigor is an asset on your balance sheet, and its absence is something a competent buyer will find and price.

What technical diligence actually probes

Hardware and firmware diligence is not a document review. It is an engineer led, hands on assessment, typically a senior engineer over several days: schematic review, bill of materials obsolescence and risk scoring using tools like SiliconExpert, Z2Data and Octopart or Findchips, signal integrity and EMC exposure, and a judgement on whether the firmware will hold in production.

The recurring principle in that practice is worth quoting close to how practitioners state it: hardware red flags rarely surface in the pitch deck. Diligence has to go and find them, which means the reviewer arrives assuming the flattering account is incomplete.

On the software side, buy-side and sell-side checklists ask for concrete metrics: test coverage percentage, uptime, deployment frequency. They flag vague answers as red flags. And then, in the same breath, the better ones warn that coverage numbers alone are gameable.

That last point is this whole pillar arriving from the buy side. The number everyone reports is the number that does not predict quality. Once suite size is controlled for, coverage correlates only weakly with fault detection, and against real post release defects the correlation is statistically insignificant, at Spearman rho of about -0.059 with p of 0.559 across a hundred large Java projects. A reviewer who knows that will ask for your number, write it down, and then ask a different question.

Note the confidence level honestly: the diligence practice described here comes from practitioner sources rather than peer reviewed work. The empirical claims underneath it do not.

The seven red flags

Each of these has a public report behind it, which is what turns it from an engineering opinion into a question with a precedent attached.

No staged or canary rollout for updates. The CrowdStrike failure verbatim. A validator passed content the sensor could not parse, and it went broadly at once.

No written deployment procedure and no version consistency check. The Knight Capital failure verbatim. Seven of eight servers took the code, nothing compared them, and the firm was insolvent within days.

Single points of failure not identified or not fault injected. The MCAS pattern. A hazardous function on one sensor channel, with the assumption recorded and never driven.

Reused code not re-verified to the new envelope. The Ariane 5 pattern. A flawless record that was evidence about a different vehicle.

No negative tests on input parsing, protocol or sensor paths. The Heartbleed pattern. A suite that only ever sent well formed messages, and a fix that was one value check.

A penetration test or audit finding that was never remediated. The ignored alarm pattern, and the organisational sibling of Knight's 97 pre-open warning emails. A finding that was filed rather than fixed tells a reviewer something about the organisation, not about the finding.

Roadmap and backlog not tied to real risk. The only one without a single incident behind it, and the one that predicts the others. If verification effort is not aimed where failure would be most costly, its quantity is not the interesting number.

The acquirer's frame, and why it mirrors DO-178C

Two ideas run through how diligence engineers actually assess a system.

The first is that an architecture must survive the business plan. Not survive today's load: survive the thing the deck says will happen. That reframes every scaling question as a verification question about assumptions nobody has tested yet.

The second is more specific and more useful. Diligence explicitly checks whether somebody other than the author can walk the system and understand it. That is the author independent review principle, and it is not a soft preference. DO-178C mandates independence of verification at Levels A and B, the two highest assurance levels, for precisely the reason a diligence engineer applies it: the person who built a thing is the worst available judge of whether its checks work, because their tests and their code share a model.

Which produces the sentence that should govern how you think about your suite before a process starts. To a diligence engineer, a suite that has never been shown to fail is unproven, and unproven is indistinguishable from no suite at all until they watch it catch an injected defect.

The founder move: a verification data room

Four artifacts. All cheap to produce, all specifically asked for, and all impossible to assemble the week the term sheet arrives.

Surviving mutant reports on critical paths. Money, safety, access control. Each survivor names an assertion you do not have, and a short list of known, owned gaps reads far better than a coverage percentage. It also signals that you know what mutation testing is, which is itself information.

Fault injection results. Evidence that detection was observed rather than argued. This is the artifact that most directly answers the MCAS class of question, and almost nobody has it.

Deploy consistency evidence. Proof that an incomplete rollout goes red, ideally including the negative control on that check: you deliberately skipped a node in staging and the deploy failed.

A flaky test ledger. Quarantined tests with owners and deadlines. This one is counterintuitive, because founders assume admitting to flaky tests is a weakness. It is the opposite. Every organisation at any scale has them; having a ledger says red still carries information here.

Vague answers reprice deals. Specific answers, including specific admissions, do not.

The investor move: make a check fail on camera

If you get one question, ask this one.

Pick a guard on a critical path. Ask an engineer to break the thing it protects, live, and watch. It takes minutes. A suite nobody has watched go red is a claim; a suite you have watched go red is an observation, and the gap between those two is the entire subject of this pillar.

Then work down the specific absences, because each has a public precedent you can name: no staged rollout, no deploy verification, no negative tests on input and sensor paths, reused code not re-verified, single points of failure never corrupted deliberately. Those are the highest yield questions available, and their yield comes from being unanswerable with a metric.

If the answer to any of them is that the control exists but nobody has ever seen it fire, you have learned something precise. That is not a control yet. It is a belief with a filename.

The verification diligence scorecard scores all twelve controls with that distinction built in, weighted by what each absence has cost publicly. The printable checklist below is the same list, designed to be ticked only where somebody has actually watched the check go red, and the argument underneath all of it is in a test that has never failed is a decoration.

FAQ

What do acquirers check about testing in technical due diligence? Concrete things rather than documents. Hardware and firmware diligence is a senior engineer over several days doing schematic review, bill of materials obsolescence scoring, signal integrity assessment and a judgement on whether firmware holds in production. Software checklists ask for coverage, uptime and deployment frequency, flag vague answers, and warn that coverage numbers alone are gameable.

What testing red flags reprice a deal? Seven: no staged or canary rollout, no written deployment procedure or version consistency check, unidentified single points of failure, reused code not re-verified to the new envelope, no negative tests on input paths, an unremediated audit or penetration test finding, and a backlog not tied to real risk. Each of the first five maps to a named public failure.

What should founders prepare before a diligence process? A verification data room with four artifacts: surviving mutant reports on critical paths, fault injection results, deploy consistency evidence, and a flaky test ledger. All are cheap to build in advance and impossible to assemble under time pressure.

What is the single highest yield diligence question? Ask the target to make a check fail on camera. Pick a guard on a critical path, have an engineer break what it protects, and watch. It converts a claim into an observation in minutes.

Should we just report our coverage percentage? Report it and expect it to be discounted by anyone competent. Coverage is a floor that reliably flags an inadequate suite rather than evidence of a good one, and a reviewer who knows the research will ask what your suite catches rather than what it executes.