Documentation
The deliverable is the point.
Every application here writes documents rather than printing results to a screen. That is deliberate: the part of this job I spent a decade doing by hand was the paperwork, and it is the part a small shop least has time for. A report you can hand to a customer, a contract manufacturer or an auditor is the thing being sold - the analysis is how it gets written.
Or read one Everything below is a description of what comes out. One complete run is published on this site as it was generated — the test plan, the test specification, ninety test cases, the DFT report, an FMEA of fifty-one failure modes and the traceability matrix underneath them, for a real board. Open the worked example →
01
Test plans and test specifications
Test legs and flowcharts, proposed test cases and the method for each, with every case traced back to the requirement that demanded it. Generated from one trace model with the design documents and the test analysis results, so the plan and the specification agree with each other by construction rather than by somebody reconciling them.
02
Test instructions
One per set-up, written so the person running it does not have to interpret the standard: the standards it runs against, the levels and pass criterion, the equipment by id, and explicit entry and exit criteria. These are the pages that go in the folder beside the bench.
03
Coverage workbooks
An Excel workbook with one row per component, scored PCOLA/SOQ across ICT, flying probe, boundary scan, AOI and functional test, plus net access and suggested test points where no probe can currently land. It is the document a contract manufacturer asks for and the one that settles an argument about whether a board is testable.
04
Sample matrices and schedules
Which units go down which test leg, how many are needed for the legs to run in parallel, what the equipment costs, and a dated schedule with the resource loading behind it. Validation is where a programme quietly loses a quarter, and it is lost at planning time.
05
Findings, with the fix on the row
A failure that comes with no remedy is a bill, not a report. Each predicted failure carries its standard, kind and margin, and a first fix on the same row - with the numbers behind it, so the fix can be costed before it is attempted.
06
Results your sequencer can consume
Not every document is for a human. Results come back as CSV and JSON for a test sequencer, Touchstone for a field solve, and over SCPI for anything that already speaks VISA - so a report and a measurement are the same data in two shapes.
Formats
Whatever the next person along needs to open.
A document that only opens in the tool that made it is not a deliverable. Everything here is written in formats somebody else's toolchain already reads.
The manuals
Three hundred and fifty pages, written the same way.
The applications are documented to the same standard as their output. MBLT PLC has a 119-page manual and a separate 76-page C/C++ guide with seven worked tutorials; MBLT HMI has 102 pages and a widget reference generated from the registry; SignalScope has 53. Their screenshots are retaken from the running application by script, so the pictures cannot drift away from the software the way hand-pasted ones do.
Where it comes from
One model, many documents.
Test plans drift from specifications, and specifications drift from requirements. Generating all three from a single trace model is the only way they stay consistent once the design starts changing - which it will.