A board fails a test. It is investigated, tested again and eventually passes. Later, someone needs to know what happened: which test failed, what the measurement was, and whether the same failure is appearing on other units.
The evidence may already exist. Finding it is the problem.
Results can be spread across tester PCs, network folders and different log formats. A production report might show a final pass count, while the original failures and repeat tests remain buried in individual files. Answering a straightforward question becomes a job for the engineer who knows where everything is stored.
You do not necessarily need to replace your testers to improve this. A separate collection and analysis system can turn the logs your existing Flying Probe, ICT and FCT equipment produces into searchable records and useful reports.
Start with the questions your team needs answered
Before choosing dashboards or discussing integration, write down the questions that currently take too long to answer.
For a test or quality team, these might be:
- What is the recorded test history for this serial number?
- Which units passed first time, and which needed further testing?
- Which components or test steps fail most often?
- Has a product’s test performance changed over time?
- Which measurements were recorded for a failed test, and what were the limits?
- Are recorded test times changing for a particular product, program or machine?
These questions define the information you need to collect. They also expose the limits of a simple PASS/FAIL spreadsheet: a final result alone cannot explain the sequence of events that produced it.
What can you collect from a tester log?
The answer depends on what the tester records and what its configured parser can extract.
A source log may contain:
- Unit serial number and product identification.
- Test program and tester identification.
- Test date, time and overall PASS/FAIL result.
- Failing components or test steps.
- Individual measurements and pass/fail limits.
- Recorded test duration.
Not every tester produces every field. Different formats can also describe similar information differently.
That is why compatibility should start with a representative log—not a promise that every machine from a particular brand will work identically. The tester model, software version and output format help establish whether an existing parser fits or additional parsing is required.
Collection cannot recover a measurement that was never written to the source log. Establishing those boundaries early avoids disappointment later.
From log files to a shared reporting system
A practical collection workflow has four parts:
- The tester produces a log. Testing continues in the existing test environment.
- A configured parser reads the available data. Collection arrangements depend on where the tester writes its files and how those files can be accessed.
- The extracted results are stored as structured records. This makes them available for searches and reporting without repeatedly opening the original files.
- Production, test and quality teams use the results. Dashboards provide an overview; searches and unit history provide the detail behind it.
The tester still performs the test. The collection system makes the recorded results easier to use across the operation.
Keep first-pass results separate from retests
A final pass count and first-pass performance answer different questions.
If a unit fails and later passes, the final result matters—but so does the earlier failure. Looking only at the latest outcome can hide repeated testing and the problems that prompted it.
Useful analysis retains the recorded test history so engineers can examine first-pass results and subsequent tests separately.
A retest is not automatically evidence of a repair. It may follow investigation, a connection check or another intervention. The test records show what was recorded; understanding why a unit was tested again may require information from the wider process.
That distinction matters when turning test data into improvement decisions.
Move from an overview to the evidence
A yield chart can tell you where to look. It should not be the end of the investigation.
For example, an engineer reviewing a change in a product’s yield may need to examine recurring failing steps, find affected serial numbers, and inspect the available measurements and limits. A quality team investigating a unit may start with its serial number and work back through the recorded history.
Both need access to the detail behind the summary—not another manually compiled report.
Where NS-HPDCA fits
NS-HPDCA collects and analyses test logs from supported Flying Probe, ICT and FCT systems.
Its collector parses available log data into a MySQL database. Its analyser provides dashboards, searches and reports through web or Windows interfaces.
The collection and analysis workflow includes:
- Production yields and historical trends.
- First-pass and retest analysis.
- Top defects by component or test step.
- Searches and recorded unit history.
- Available measurements and failure detail.
- Recorded cycle-time and utilisation reporting.
Supported sources include Takaya Flying Probe logs, HP3070/Agilent and IFR4220 ICT logs, and configured FCT formats. Custom parsers can extend collection to additional formats, with scope established from representative files.
HPDCA also provides Last Test Result: scan a serial number to retrieve its latest recorded test result and display PASS or FAIL. That supports an operator’s result check; it does not, by itself, enforce a shipping interlock or replace the site’s release procedure.
Start with one source and a useful question
You do not need to begin with every tester or a full MES integration.
A sensible evaluation starts with a representative log format and a question the team needs answered. Confirm the available fields, review how collection would work, and demonstrate the relevant searches and reports before expanding the scope.
If the results also need to feed BI, MES or ERP systems, define the required information and data exchange as part of that evaluation. Do not assume that collecting a log automatically creates a complete integration.
Can your existing test logs answer more of your questions?
Email customDB@nicks-software.com with:
- Your tester model and software version.
- A representative anonymised test log, with customer and confidential information removed.
- What you need to report, search or investigate.
Nick’s Software can assess the parser fit and discuss a collection and analysis workflow around your existing test equipment.