Software — tspec

Test Spec Ecosystem

One traceability model across every document the product has.

Early release 0.1.1 tspec — command line and desktop app

What it does

Links the design documents, the test analysis results and your requirements files into a single trace model, then generates the test plan, the test specification, the DFT report and the risk analysis from it — so they agree with each other by construction.

  • Traceability from requirement to test case to result
  • Test plan with test legs and flowcharts
  • Test specification with proposed test cases and methods
  • A DFT report built from PCB Test Analysis's own coverage and access numbers
  • An FMEA with severity, occurrence and detection, RPN, action priority, the tests that mitigate each line, and the residual RPN once they are done
  • Production test legs in order - AOI, then in-circuit or flying probe, boundary scan, programming, functional and final quality - and a separate design verification flow
  • Test cases proposed per requirement, including boundary-value and negative cases
  • AI instruction sets for Claude, Gemini and Copilot, plus an engine-neutral AGENTS.md
  • Exports to DOORS/DNG ReqIF, StrictDoc, OpenFastTrace and Kiwi TCMS
The traceability tab on the Z-Stack controller carrier: every design-review finding with its category, status, severity and the number of links in and out. The detail below one of them shows what traceability is actually for - a barrel jack whose 24 V / 5 A rating equalled the top of the input range, the part that replaced it, and the five links that tie it to the action that closed it, the test case that confirms the fix and the risk it came from.
The traceability tab on the Z-Stack controller carrier: every design-review finding with its category, status, severity and the number of links in and out. The detail below one of them shows what traceability is actually for - a barrel jack whose 24 V / 5 A rating equalled the top of the input range, the part that replaced it, and the five links that tie it to the action that closed it, the test case that confirms the fix and the risk it came from.
Not the application - the hub page it writes. One run against the Z-Stack carrier: 37 requirements with 37 of them covered, 92 test cases in 10 legs, 4 open high-priority risks with none left unmitigated, 11 design-for-test findings, and the board's 90.2 % coverage carried through from PCB Test Analysis rather than retyped. The release gate at the top either passes or it does not; here it passes on requirement coverage at exactly its minimum.
Not the application - the hub page it writes. One run against the Z-Stack carrier: 37 requirements with 37 of them covered, 92 test cases in 10 legs, 4 open high-priority risks with none left unmitigated, 11 design-for-test findings, and the board's 90.2 % coverage carried through from PCB Test Analysis rather than retyped. The release gate at the top either passes or it does not; here it passes on requirement coverage at exactly its minimum.
The generated test plan, and the part worth reading is Assumptions. It says the coverage figures are pre-fixture estimates and that measured coverage comes from fixture debug and fault injection; it says test cases marked Proposed were generated from the documents and each one needs an engineer's review before it is baselined. Underneath, the production flow drawn as a flowchart - AOI, in-circuit, programming, functional, final - with the repair and retest loop and the rule that two failed retests send a board to the material review board.
The generated test plan, and the part worth reading is Assumptions. It says the coverage figures are pre-fixture estimates and that measured coverage comes from fixture debug and fault injection; it says test cases marked Proposed were generated from the documents and each one needs an engineer's review before it is baselined. Underneath, the production flow drawn as a flowchart - AOI, in-circuit, programming, functional, final - with the repair and retest loop and the rule that two failed retests send a board to the material review board.
The design-for-test report, which is willing to fail. Eleven rule checks with their results: component and joint coverage pass, AOI and functional test pass - and 'every net that needs it has ICT access' fails, naming the three that do not have it. Three more come back Warn, including one noting that no device on the board is marked JTAG-capable. The findings below carry a severity, a recommendation and a link to the test case that would mitigate each one.
The design-for-test report, which is willing to fail. Eleven rule checks with their results: component and joint coverage pass, AOI and functional test pass - and 'every net that needs it has ICT access' fails, naming the three that do not have it. Three more come back Warn, including one noting that no device on the board is marked JTAG-capable. The findings below carry a severity, a recommendation and a link to the test case that would mitigate each one.
The FMEA, proposed from the gaps the other documents found. Each failure mode has severity, occurrence and detection on 1 to 10, an RPN that is their product, an action priority, the controls that exist today, a recommended action and the test case that would mitigate it - with a residual RPN assuming that test case runs. The top row is a real one: no top travel limit, because only the bottom switch exists and the move command accepts any height, so a mistyped number drives the carriage into the end stop.
The FMEA, proposed from the gaps the other documents found. Each failure mode has severity, occurrence and detection on 1 to 10, an RPN that is their product, an action priority, the controls that exist today, a recommended action and the test case that would mitigate it - with a residual RPN assuming that test case runs. The top row is a real one: no top travel limit, because only the bottom switch exists and the move command accepts any height, so a mistyped number drives the carriage into the end stop.

On video

One recording of it actually running.

A screenshot of a program that moves is only half of it, so here it is moving. Recorded off the screen while it ran on this bench - its own window, its own example project, nothing staged. The verdicts are whatever the application returned. Nothing plays until you press it.

30 s Four source documents read into one trace model: 37 requirements, every one of them with a test case, 92 test cases, 49 risks and 553 links between them. Then the traceability matrix underneath it, the test plan with its production and design-verification flows, the test cases themselves, the FMEA, and the eleven DFT findings.

What one run produced

It runs last, after the testability, EMC and validation analyses have written what they found. This is the whole run that is published on this site, all four applications of it:

59files from one run
4applications, one command
91tasks / 500.5 hours merged
841links in the trace model
-57.2 dBworst EMC margin (ESD-CE USB)
14 sstart to finished

Read it - nothing was edited →

Get in touch

Test Spec Ecosystem is not a download. It is one of the tools the work is done with, installed and licensed when an engagement starts. Tell me what you are working on and I will tell you what it would do for it.

Or email mblab.technology@gmail.com. Your details are used to answer you and to follow up — nothing else.

Requirements

  • Windows 10 or 11, 64-bit
  • About 200 MB of disk
  • No .NET install needed — the runtime is bundled
  • No Excel needed — workbooks are written directly

Also in the set