Eight weeks before start of production of a vehicle facelift, three things change: a new supplier variant of the brake-pedal sensor, a software bump on the brake ECU, and one CAN signal that now arrives on a faster cycle. Small changes, the kind every facelift carries by the dozen. In the release meeting, the question lands where it always lands: we have roughly four thousand test cases that could plausibly claim a slot, four hundred HiL hours before the gate, and a test manager who has to say which tests run, in which order. And therefore, which tests to leave out.
Risk-based testing is the practice of spending a limited test budget where the risk is highest: you assess how likely each item is to fail and how much damage that failure would do, then test in that order. It has been ISTQB doctrine for two decades; every certified tester can recite it. The method is fine. The inputs are the scandal. Likelihood and impact are produced in workshops, with experts around a table, scoring gut feelings into a matrix, because there was never anywhere to compute them from. ISO 26262 grades criticality as input for the computation, but only for the safety slice of the vehicle. ASPICE insists the trace links exist, then computes nothing with them. Since there is no practical computation in the field, people built a rigorous decision procedure and have been feeding it estimates ever since.
In practice, the answer is always a person, not a process: usually the most experienced test manager in the room, holding a spreadsheet that was out of date before it was finished. When that person is good, the answer is good. When they retire, the answer retires with them. And even then, nobody can show why: ask "why is this test in and that one out?" and the honest reply is twenty years of experience in one person.
The data problem stopped being unsolvable when the product data became available, for example in a graph.
Take the facelift. In a product knowledge graph, requirements, functions, components, signals, hazards, and test cases are all linked, all versioned. Those three changes we mentioned above aren't broad, subjective meeting topics; they are three marked nodes in the graph. From there, impact is a directed walk: the retimed signal reaches the two ECUs that consume it, the arbitration function they realize, the five requirements that constrain it, and the sixty-one test cases that verify any of the above. Direction plays a big role here, so that impact "flows" from producer to consumer, not backwards, and a traversal that ignores direction lights up the whole vehicle and tells you nothing.
Sixty-one suspect tests out of four thousand. But the more valuable output is the other side of the cut: the graph can show, edge by edge, why the change cannot reach the parking-brake logic or the ABS regression suite. The signal contracts on those paths are untouched. That is the sentence a test manager has never been able to say with evidence: we are not re-running these, and here is the trail. Permission to skip, in writing. Under a fixed budget, that page is worth more than the run list.
Which of the sixty-one run first? This is where the workshop used to happen. On the graph, its questions become lookups on data the organization has owned all along: criticality is the ASIL rating safety engineering already assigned, read through the hazard trace; likelihood is the change delta plus where the linked defect tracker says faults have historically clustered; and in addition, a signal half the network routes through carries more consequence than a leaf sensor, and the graph knows the difference structurally.
In the pedal example, this reshuffles the deck in a way gut feeling reliably misses: the single riskiest thing isn't any changed component, it's the interface between the brake ECU and the stability control, an unchanged neighbor. New software on one side, a historical defect cluster on that boundary, high network centrality, ASIL D above it. That intersection is where launches go wrong, and no per-component review ever surfaces it, because it doesn't belong to any one component owner. A query surfaces it in seconds.
The experts don't leave the room. They stop authoring numbers and start reviewing weights, which is what expert time was for all along.
One more thing falls out, and on carry-over platforms it's usually the largest single recovery of budget. When a vehicle inherits a baseline, requirements are copied forward wholesale, including, in our example, the interlock requirements of a park-brake actuator this vehicle no longer carries. Those requirements still exist, still trace to test cases, still occupy slots, and every audit passes them because audits check that links exist, not that they mean anything. On the graph, an orphan is a one-line query: a requirement whose target isn't in this vehicle's structure anymore. Retire them (deprecate, never delete; the auditors are right about that) and the freed hours of test infrastructure go to the top of the ranked list. It's the cheapest test capacity you will ever buy, and today nobody buys it, because finding orphans by hand across six tools that don't talk costs more than the slots they waste.
Order the selected tests by risk retired per rig-hour and something quietly changes about the calendar: when it slips (and it will slip) you no longer re-plan, you cut from the bottom of a ranked list, and you can say precisely what each cut costs in residual risk. The headline metric stops being pass rate, which measures the tests you happened to run, and becomes risk burn-down, which measures the launch.
So is the test manager automated away? No, and I want to be precise about which halves go. The compilation goes: the Friday spent gluing tool exports into a maturity spreadsheet becomes a query the graph answers continuously. The arithmetic goes: scope, scores, ordering, evidence packs. What stays is everything the spreadsheet was crowding out. Someone still decides what residual risk is acceptable to sign. Someone still approves retiring a test that traces to a safety function. Someone still calibrates the weights, and someone still smells the hazard no model of the vehicle contains; the graph ranks known unknowns, it cannot conjure unknown ones, which is why a slice of budget should stay reserved for experienced intuition, on purpose, forever.
Three failure modes, named, because trust dies the first time a tool bluffs. The traversal is only as complete as the trace links: where they're thin, the tool must say "unmodeled here" rather than radiate confidence. A brand-new supplier has no defect history, so history-based scoring flatters exactly the riskiest parts: novelty has to outrank the empty record. And timing, bus load, and resource contention live below the graph's resolution; those get flagged for simulation, never "computed" from topology. A prioritization that admits where its map ends is usable. One that doesn't is a liability with a dashboard.
The test manager role was named for a judgment: deciding, under a budget that never suffices, what evidence a launch needs. For twenty years the tooling forced that person to spend most of the week being a human integration layer between systems that wouldn't talk. The graph doesn't replace the judgment. It hands back the week.
This is the discipline behind SPREAD's approach to test management: one connected, directional engineering graph that turns risk-based testing from a workshop guess into a ranked, defensible plan, including the list of tests you can safely skip. See how it works in Product Explorer, or get started with SPREAD.
Risk-based testing is the practice of spending a limited test budget where the risk is highest: you score each item by how likely it is to fail and how much damage that failure would cause, then test in that order. It has been ISTQB doctrine for two decades. The method is sound; the hard part has always been the inputs, because how risky an item is and what a change actually touches were never computable and had to be estimated in a workshop.
Likelihood and impact were scored by experts around a table, because there was nowhere to compute them from. ISO 26262 grades criticality, but only for the safety slice of the vehicle, and ASPICE insists the trace links exist without computing anything from them. Once the product data lives in one connected, versioned graph, both inputs become queries: criticality reads from the ASIL rating through the hazard trace, and likelihood comes from the change delta plus where the linked defect history clusters.
On a connected engineering graph, a change is a set of marked nodes and impact is a directed walk from producer to consumer, so the graph shows both the tests a change can reach and, edge by edge, the ones it cannot. The tests it cannot reach are safe to skip, with the trace to defend each omission. Under a fixed budget, that documented list of tests you did not run is often worth more than the run list itself.
You need the product already connected as one queryable graph: requirements, functions, components, signals, hazards, and test cases linked and versioned, with ASIL ratings, defect history, change records, and trace links attached. No new data is required. An OEM already owns every input, it is just spread across six tools that do not talk, which is why the criticality lookup, the blast radius, and the orphan-requirement query only become possible once the data sits in one model.
WHITEPAPERKnowledge Graphs and LLMs in Systems EngineeringHow connected product data and language models improve traceability and cut engineering effort in complex systems.Get the whitepaper →