Test Anomaly Report: Trace a Failure Back to Requirements

A thermal vacuum chamber door closes on an avionics enclosure at 2 a.m. Four hours later the data shows the baseplate temperature climbing past its limit. The test engineer logs a failure, attaches the plot, and goes home. By morning, three people have opinions and none of them have the same files open.

This is the moment a test anomaly report either earns its keep or becomes a document that describes the symptom and nothing else. The anomaly itself is rarely the hard part. The hard part is the disposition: is the design wrong, is the test setup wrong, or is the requirement wrong? Answering that means walking backward from a failed test through the requirement it verifies, the decisions that shaped the design, the CAD changes since, and the evidence that passed earlier.

This post follows one illustrative anomaly through six steps. The persona is the engineer who owns the disposition, usually a test or systems engineer working with a mechanical lead and a quality reviewer, on a design the team believed was ready. Tandem is the connected record in this workflow. It doesn't run your tests or replace your quality system.

The persona and the job: dispositioning a test anomaly on a design everyone believed was ready

Meet the owner of the disposition. Call her the systems engineer on a small satellite avionics unit, though the same seat exists on a medical device, a robot actuator or an automotive thermal module. She didn't write the test procedure. She didn't model the enclosure. She's the person the program lead asks, "What happened, and what do we do about it?"

The job-to-be-done is narrow and unforgiving. She has to decide whether the anomaly is a design defect, a test-setup problem or a requirement that was wrong from the start, and she has to write down why. That rationale has to survive the next design review, a customer audit and the engineer who inherits the unit in eighteen months.

Our illustrative scenario: during thermal vacuum verification, the enclosure baseplate exceeds its allowed temperature at the hot-soak plateau. The requirement says the baseplate must stay below a stated limit at a stated heat load. Everyone on the program thought this was a closed question. A thermal analysis passed. An earlier bench test passed. The unit sailed through the last design review.

That confidence is exactly what makes the anomaly expensive. When a design is believed ready, nobody has the context fresh. The decisions behind the thermal path were made months ago, the CAD has moved since, and the earlier passing evidence lives wherever the person who ran it saved it.

The disposition is a judgment call, and judgment needs the whole chain in front of the person making it. Without that chain she's guessing, and a guess dressed up as a disposition is how the same failure returns at the next build.

Before: an anomaly report that stops at the symptom and sends engineers digging through CAD history, Slack and old test files

Here is what the old way looks like for this exact failure.

The anomaly report has fields for date, unit serial number, test procedure, observed behavior and immediate action. It captures the symptom well. "Baseplate TC3 exceeded limit at hot soak, test aborted at step 14." It captures nothing upstream of the test.

So the digging starts. The systems engineer asks the mechanical lead which revision of the enclosure was in the chamber. The lead checks the CAD history and finds three revisions since the thermal analysis, one of which changed a boss feature near the mounting interface. Nobody remembers why. Someone searches Slack for "baseplate" and finds a thread from five months ago where a thermal pad thickness was discussed, with a screenshot and no conclusion. The earlier bench test result sits in a spreadsheet on someone's drive, named in a way that made sense to its author.

Three hours in, the team has a hypothesis, no evidence for it, and two people already arguing for opposite dispositions. The test engineer suspects a thermocouple was bonded badly. The mechanical lead suspects the requirement heat load was optimistic. Neither can prove it without the same missing context.

This is the real cost of a symptom-only report. The anomaly eats days of archaeology before anyone can make a decision, and the decision itself rests on whatever fragments surfaced. The rationale for the disposition often never gets written down at all, because everyone is tired and the schedule is slipping.

If your anomaly reports stop at the symptom, you've outsourced the root cause investigation to memory and search. That works until the person who remembers leaves.

Step 1 and 2: log the anomaly and trace the failed test to the requirement it verifies

Step 1 is logging the anomaly with enough structure that it can be connected to something. Record the unit, the build configuration, the test, the step, the observed result, and the evidence attached (plots, raw data, photos of the setup). Do this in your test or quality system, which remains the system of record for the test itself. Tandem isn't a test case manager and doesn't execute tests. It stores and connects validation evidence alongside the rest of the engineering record.

Step 2 is the one most teams skip, and it's the one that changes the investigation. Take the failed test and trace it to the requirement it verifies. Not "the thermal requirements" in general. The specific requirement: baseplate temperature below the limit at the stated heat load, in vacuum, at hot soak.

In Tandem, requirements live in structured tables with hierarchy, ownership and approvals, and they connect to the architecture node they apply to, the CAD that implements them and the verification evidence attached to them. When the anomaly is linked to the requirement, the engineer lands on one page that shows what the requirement says, who owns it, what parent requirement it flows from, and every piece of evidence tied to it so far.

Two things happen immediately. First, the team confirms they're even arguing about the same requirement. In our scenario, the test procedure cited a version of the requirement with a slightly different heat load than the current approved one. That's a finding before any root cause work begins. Second, the engineer can see the verification method assigned to the requirement. If you need a refresher on why that assignment matters, our guide to verification methods covers test, analysis, inspection and demonstration.

Tracing to the requirement turns a vague failure into a bounded question. The anomaly is now a claim that a specific requirement isn't met, and every later step is a way of testing that claim.

Step 3: pull the design decisions, CAD changes and earlier passing evidence behind that requirement

With the requirement in hand, the investigation fans out in three directions, and this is where a connected record pays for itself.

Design decisions. Why is the thermal path built the way it is? The record behind the requirement shows the reasoning captured at the time: the choice of a thermal pad over a gap filler, the assumption about contact pressure at the mounting interface, the trade that favored mass over conductivity. Our scenario's record shows the heat load assumption came from an early power budget that was later revised upward. That kind of detail otherwise lives in one engineer's head. For more on keeping that reasoning defensible, see our engineering trade study guide.

CAD changes. Tandem links CAD changes to requirements, design intent and validation evidence, and it works alongside the CAD tools a team already uses (SolidWorks, Onshape, Fusion and NX are the off-the-shelf integrations). The question is simple: what changed in the geometry that touches this requirement since the last passing evidence? In the scenario, the boss feature revision near the mounting interface shows up as a change linked to the thermal requirement, with a note on why it was made: a fastener clearance fix. Nobody flagged the thermal effect. If you want the mechanics of this, our post on thermal requirements traceability when mechanical design changes walks through it.

Earlier passing evidence. The bench test that passed is attached to the same requirement, along with the thermal analysis. The engineer can now compare configurations: which revision did the bench test cover, and which revision was in the chamber? They differ by exactly the boss change.

Now there's a hypothesis with evidence behind it, produced in an afternoon instead of a week. Nothing has been decided yet. But the team is arguing about facts instead of recollections.

Step 4: decide whether the cause is the design, the test setup or the requirement, and record the disposition and rationale

Step 4 is the decision, and no tool should make it for you. Tandem holds the context. The engineer holds the judgment.

Use the evidence you just pulled to test three candidate causes against each other.

Design. Did the design change since the passing evidence degrade the thermal path? In the scenario, the boss revision reduced the contact area at the mounting interface by a measurable amount. If the analysis rerun on the current CAD shows the limit exceeded at the stated heat load, the design is at fault. The fix is a design change, and the passing bench test no longer covers the current configuration.

Test setup. Was the measurement valid? A thermocouple bonded poorly reads high. A chamber shroud that wasn't at the specified temperature skews the boundary condition. Check the setup records and the sensor placement against the procedure. If the setup deviated, the anomaly may be an artifact, and the right disposition is a re-test with a corrected setup, not a design change.

Requirement. Is the requirement itself wrong? In our scenario, the procedure cited a stale heat load, and the current approved requirement is higher. If the analysis shows the design can't meet the current heat load and the heat load is itself justified, the requirement and design are in conflict, and the answer may be a deviation or a renegotiated allocation. Our guide to deviation and waiver requests covers that path.

Pick one. Say which, and say why, in plain sentences. Then record the disposition and the rationale against the requirement itself, with the evidence that supported it. A disposition that reads "Design: boss revision R4 reduced interface contact area; analysis rerun on R5 shows 4 degrees of margin lost" is auditable. A disposition that reads "Corrective action taken" is not.

The rationale is the deliverable. The test will be rerun either way, but the reasoning is what the next reviewer needs.

Step 5 and 6: link the design change to the requirement and re-test evidence, then review the closure in context at the next design review

Suppose the disposition is a design fix: the team restores contact area at the interface and adjusts the fastener clearance a different way. Step 5 is closing the loop so the change doesn't become another orphan.

Link the CAD change to the requirement it addresses and to the anomaly that triggered it. Tandem identifies what a change affects and runs requirement checks against linked CAD, so the engineer sees other requirements touched by the new geometry, such as the fastener clearance requirement that caused the original boss change. That's the trap in this scenario: fixing the thermal path by undoing the boss revision would have reopened a mechanical clearance requirement. Seeing both requirements on one change is what prevents the ping-pong.

Then attach the re-test evidence. When the unit goes back into the chamber and the baseplate stays inside its limit, that result links to the same requirement, next to the original failure, the anomaly disposition and the earlier passing evidence. The record now tells the whole story in order: pass, change, fail, analysis, disposition, fix, pass.

Step 6 is the review. At the next design review, the team examines the closure in context rather than from a slide. Tandem supports reviews held against the requirement, architecture node, CAD change and verification evidence they relate to. The reviewer sees the anomaly, the disposition rationale and the re-test evidence without anyone reconstructing them from email. If the program is heading toward a gate, this record feeds directly into a test readiness review or a later production readiness review, where closed anomalies are a standard question.

The closure is only as good as the link. An anomaly marked "closed" with no connection to the changed CAD and the re-test result is a claim, not a record.

Outcome: what changes for the team, what Tandem does and does not do, and a checklist for your next anomaly report

What changes is where the time goes. In the old flow, most of the effort went to finding out what the requirement said, what changed and what had passed before. In the connected flow, that context is one trace away, and the effort goes to the judgment call: design, test setup or requirement. The anomaly in our scenario took an afternoon to disposition with evidence, where the symptom-only version would have taken days and ended with a thinner rationale. This is an illustrative scenario, not a measured result, so time your own next anomaly before and after.

Be clear about the boundaries. Tandem is the connected record. It isn't your test management or execution system, not your quality management system, not a CAD tool and not a PLM or PDM replacement. It doesn't run your tests. It connects requirements, CAD changes, design intent, reviews and validation evidence so the reasoning survives.

Use this checklist on your next test anomaly report:

• Log the unit, build configuration, test, step, observation and attached evidence.

• Trace the failed test to the exact requirement and confirm the procedure cites the current version.

• Pull the design decisions and assumptions behind that requirement.

• List CAD changes since the last passing evidence.

• Attach the earlier passing evidence and compare configurations.

• Test design, test setup and requirement as three separate hypotheses.

• Record the disposition and the rationale against the requirement.

• Link the design change and the re-test evidence to the same requirement.

• Check what else the change touches before you close.

• Review the closure in context at the next design review.

Conclusion

Your next test anomaly report should end with a disposition someone can defend two years from now, not a symptom and a promise to investigate. Pick one live anomaly on your program and trace it end to end: failed test, requirement, design decisions, CAD changes since the last pass, and the evidence on either side. Write the disposition and the reason against the requirement, then link the fix and the re-test to it.

If you want that trace to be one click instead of a week of searching Slack and CAD history, book a Tandem demo and bring a real anomaly. We'll walk it from the failed test back to the requirement and the design change behind it, in the tools your team already uses.