Upload BOM & Gerber
-
Mobile: +86 13312967631
-
Email: sales@suga-pcba.com
PCB Testing Services for PCBA Verification
Plan the Right Test Scope for PCBA Verification
When an Original Equipment Manufacturer (OEM) project needs printed circuit board assembly (PCBA) testing-scope verification, SUGA PCB testing services help define the right test path by connecting method selection, setup readiness, fault evidence, and report evidence. To support a PCB testing service request, provide the bill of materials (BOM), Gerber data, setup files, and approved limits.
- Method Selection
- Setup Readiness
- Fault Evidence Review
- Report Evidence
What PCB Testing Checks After Assembly
PCB Testing as Assembly-Level Review
SUGA PCB testing supports verification of the assembled board after placement and soldering. For PCBA verification, testing can include electrical access checks, powered functional checks, programming confirmation, and recorded results tied to approved test protocols. For each board tested, SUGA needs to know whether the board passed or failed, what checks were performed, and what test setups were used, based on approved limits.
Bare PCB Checks and Assembled PCBA Checks
Bare board electrical checks test the bare PCB before components are mounted and are usually used to find continuity or isolation issues within the fabricated board. Testing for a PCBA occurs after the board has been assembled and can verify component value, polarity, soldering result, firmware state, connector access, and powered performance. A bare board can pass all electrical checks and still require PCBA-level verification after assembly.
Testing, Inspection, and First Article Records Serve Different Decisions
First Article Inspection (FAI) is different from testing, as testing records the electrical or functional performance of the assembled board using the approved test configuration. FAI evaluates the assembled board against approved requirements. Inspection reviews visual or image-based evidence for correctness, while testing records electrical or functional behavior associated with the test setup. Keeping these separate allows SUGA to determine the appropriate review before repair, rework, shipment, or further clarification.
Related Testing Services
The related testing services below support more specific needs for test access, production screening, powered function, defect analysis, or electrical checks.
Flying Probe TestingFlying Probe Testing has many applications for prototyping and low-volume production when fixtureless electrical access is preferred.
In-Circuit TestingIn-Circuit Testing is best suited to assembly-based production where the PCB has contact stability, defined test points, and defined program scope.
Functional TestingFunctional Testing is typically the preferred method of testing when the main concern is powered behavior under approved protocols and limit requirements.
MDA TestingMDA Testing supports component-level manufacturing defect checks when the project focuses on assembly-related defects.
Electrical TestingElectrical Testing supports continuity, isolation, open or short checks, and current-related test checks. Once the check requires the electrical state of the PCB to be documented, the required state should be defined.Match the Test Method to the Board Stage
A test method name is only the starting point for defining the test scope. The full scope still depends on board access, netlist quality, BOM, fixture or probe access, powered test conditions, and an approved test protocol.
PCB Testing Methods for PCBA Fault Coverage
| Test Type | PCBA Stage | Fault Signals | Setup Basis | Coverage Limit |
|---|---|---|---|---|
| Flying Probe Testing | Prototype, Low Volume, No Test Fixture Available | Open, Short, Net Mismatch, or Fault on Accessible Pads | Netlist + Gerber + Accessible Pads | Actual fault coverage defined by access to test points, netlist, and other process information; slower for repeated production |
| In-Circuit Test (ICT) | Production PCBA Testing | Open Circuit, Short Circuit, Wrong Value, Missing Components, or Polarity Problems | PCB Test Points + Bed-of-Nails Fixture + Test Programs | Actual Fault Coverage defined by the Test Point Map, Fixture File Setup, and Test Programs; Limited Access Based on Test Fixture Design |
| Manufacturing Defect Analyzer (MDA) | Component-Level Production Screening of PCBA | Wrong Value, Missing Components, or Analog Components Mismatched to BOM Value | BOM + Component Locations + Fixture Access to Test Points | Actual Component-Level Screening; Will Not Confirm That the Tested Components Have a Powered Function in any Specific Configuration |
| Functional Testing (FCT) | Production or PCBA Functional Verification | Functional Failure, Load Failure, Firmware Mismatch, Intermittent Function Failure, or Unstable Load Response | Firmware + Test Fixture + Test Protocols + Test Limit Tables | Expected Function Coverage Defined by the Approved Test Protocols and Test Limit Tables; Not All Hidden Nets/Faults Will Be Covered |
| Basic Electrical Testing of PCBs | Board-Level Continuity or Isolation Review | Open Circuit, Short Circuit, Abnormal Current, or Continuity Faults | Netlist + Power Source Used for Measuring Current + Measurement Limits | Limited Fault Isolation Without the Assistance of a Test Fixture or Test Program |
| Program Verification Testing | Programmed PCBAs or Controller PCBAs | Firmware Mismatch, Checksum Error, Boot Error, or Firmware Validation Error | Firmware File + Programming Methodology + Version Rules | Will Verify the Programmed Firmware File and Checksum; Will Not Confirm All Operational Functions |
| Boundary Scan Testing | Dense PCBAs with JTAG Interconnect Access | Interconnect Faults, Inaccessible Node Risk, or Digital Net Problems | JTAG Scan Chain + Boundary Scan File + Device Capabilities | Limited to Approved Device Types and Approved Scan Chain |
| Burn-in or Aging Test | Power Stress Testing of PCBAs Based on Defined Performance Profiles | Intermittent Function Failures, Thermal Drift Failures, or Load Failures | Load Profile + Temperature Profile + Acceptance Limits | Will Provide Coverage According to the Approved Test Procedure; This Is Not Default for All Types of PCB Testing |
Note: Coverage should not be considered a universal percentage. Flying Probe Testing and ICT depend on test point access, netlist quality, probe or fixture contact, and the scope of the approved test program.
Fixtureless, Fixture-Based, and Powered Test Options
After the method list is reviewed, the next decision is whether the board is still in an engineering stage, already moving into repeat production, or ready for powered functional verification. A prototype may start with fixtureless access, but a stable production build usually needs clearer test points, repeatable contact, and a defined program or fixture plan.
As a rule of thumb, early engineering samples generally require the fastest response to possible open and short circuits or problems with easily accessible components. On the other hand, the more mature an assembly is, the more likely it will require a repeatable test setup for production units built from the same PCB design. Some assemblies have firmware, connectors, sensors, or load behavior that requires a specific powered state to produce a meaningful test result.
Method Names Do Not Define Full Coverage
A method like Flying Probe Testing, ICT, MDA, or FCT gives a limited view of the coverage supported by the selected testing method. The same test method can support different levels of coverage depending on the arrangement of available pads, blocked nets, fixture designs, programming setup, and criteria for evaluating the tested item.
SUGA views test method selection as a scope decision, not simply a method label. A test supports review only when the accessible points, program, and result limits correspond with the revision and approved requirements of the board. If there are no checks for certain nets, functions, or operating conditions, this should be acknowledged before a final acceptance or rework result is recorded. For example, ICT may confirm accessible component and net conditions, but it cannot replace FCT when the concern is firmware response or powered behavior. A basic electrical pass also should not be used to close an intermittent load failure unless the load condition was actually tested.
Checks Beyond Basic Screening
In addition to performing basic electrical screening of a PCBA, additional test methods may be needed to meet product design requirements, operating-risk controls, or quality standards. Additional tests may include boundary scan, burn-in, aging, automated test equipment (ATE), or load-based functional testing. Although these test options can be considered for many PCBAs, they are not necessarily part of every PCBA order.
In selecting the methodology for testing, the method selected should correspond with the specific questions that need to be answered, as well as the evidence required to support the question. If the concern is limited to verification of a short circuit, then the setup should focus on electrical access. If the concern is limited to firmware response, powered function, or intermittent operation under load, then the setup will need to be based on the required condition. Careful method selection will reduce the chance of the limited test type being misunderstood as complete verification of all elements.
Confirm Setup Readiness Before Testing
Test results are reliable only when the setup is mapped to the correct PCB revision, access condition, reference file, and approved limits. SUGA checks to see if the test setup is capable of producing a repeatable enough result that can support engineering review, repair activity, or shipment decisions.
Test Points, Fixtures, and Setup Files
| Setup Factor | Used In | Engineering Check | Weak Condition |
|---|---|---|---|
| PCB Test Points | ICT, Flying Probe Testing, boundary scan support | Pad access, spacing, net association | Uncovered nets need engineering review |
| Test Point Maps | ICT, Flying Probe Testing, basic electrical testing | Net name, location, side access | Test access cannot be mapped clearly |
| IPC-356 or Netlist | Flying Probe Testing, ICT, electrical testing | Net connectivity, open and short reference | Net mismatch between CAD and assembled board |
| PCB Test Fixtures | ICT, FCT, MDA testing | Board fit, contact stability, support area | False fail risk from unstable contact |
| Bed-of-Nails Testing | Volume ICT testing | Probe access, pin contact, board-side clearance | Not suitable when test points are limited or blocked |
| Test Pins and Probes | ICT, Flying Probe Testing, fixture access review | Contact area, probe pressure, wear condition | Contact variation during repeated testing |
| Firmware File | Programming verification, FCT | Version match, checksum, programming interface | Powered test cannot confirm intended function |
| Test Protocol and Limits | FCT, burn-in or aging test | Pass or fail rule, load condition, measured signal | Result judgment may vary between test runs |
| Golden Sample Reference | FCT setup comparison after engineering-approved golden sample | Known-good response, connector setup, firmware version | Setup mismatch may create false failure |
Note: Not all setup factors apply to every order.
Access: Test Points, Probe Contact, and Uncovered Nets
Electrical access determines whether the proper test can reach the desired nets or component locations to be tested. If a pad is blocked, the probe point is missing, or the fixture contact is not stable, then it is possible that a portion of the PCB will be left untested even though a test may be completed on the assembly.
For prototypes and low-volume assemblies, the accessible pads will directly affect the amount of the circuitry which is tested without needing to create a dedicated fixture to perform the test. For fixture-based test methods, stability and alignment of fixture contacts are important because the test method will be performed multiple times on different assemblies. When there are areas which cannot be accessed, it should be indicated which parts of the assembly remain untested instead of being grouped with the general test result.
Reference: Netlist, IPC-356, Firmware, and Test Program
The connection of electrical checks to the intended circuit requires proper reference data in addition to the test setup. A netlist file or an IPC-356 file will provide this connection to the electrical circuit for testing purposes. The firmware version, checksum, programming interface, and the test program reference will also have an effect on the result of the testing if powered operation or programmed response is expected in the testing results.
Having this reference data decreases the possibility of testing the wrong revision of the assembly, loading the incorrect program into the assembly, and comparing the results to outdated reference data. If there is any uncertainty regarding the board revision, the fixture program, or the firmware state, a fail result may not indicate a true assembly problem and a pass result may not indicate the condition of the assembly as intended.
Basis: Protocol, Limit Table, and Pass/Fail Judgment
Test results should be documented using a test protocol or limit table, which will show how to refer back to that result at a later time. If the same measured value is found during the course of performing the same measurement again, some organizations may call it an accept and others may call it a reject. For SUGA, the protocol and limit table should make clear which result is acceptable, which result needs review, and which condition requires follow-up before the board moves forward.
When Basic Checks Are Not Enough
Basic electrical checks can verify useful signals early in the production process, but these checks identify only some of the risks associated with PCB assemblies. Many of the greater risks do not become apparent until the board has been programmed, powered on, operating, or under load conditions.
Firmware or Program State Changes the Review
A programmed board can display different behaviors based on a variety of factors, such as firmware version, checksum, interface settings, and boot state. If the expected behavior of the board depends on the loaded firmware, SUGA will define the firmware state that must be confirmed prior to testing so the test results are relevant to decisions about the board's capabilities.
If a board has passed basic electrical screening and fails to perform such functions as powering on, establishing communication, responding to commands, or providing the intended functionality in programmed fashion, the board has passed basic checks, but has not yet passed through an operational acceptance decision relative to the firmware that is currently loaded. Continuity checks alone may not always reveal the root cause of an issue. The review must correlate the result with the proper firmware status and the approved test expectation.
Load and Operating State Change the Review
Load profile and operating state shape how the board is evaluated. Some failures appear only under load, while others depend on sensor input, connector interface, or specific use modes. A board may successfully pass a static electrical continuity check but may fail during subsequent performance testing of current consumption, output waveform shape, signal amplitude, thermal performance, or activity.
For these situations, the primary concern is whether the board can perform satisfactorily according to project-defined requirements under the end-use profile. The expected load, current input, output response, or operating sequence must be clearly defined prior to using this as a basis for what is considered valid test evidence.
Stress Screening Depends on an Approved Test Plan
Stress screening, such as burn-in or aging testing, should be used based on an agreed test plan instead of relying on the notion that stress screening should always be done. Stress testing is of considerable value when showing evidence that the product will withstand an extended period of exposure to high-temperature, high-power, or high-stress operating environments; however, the specific settings and approval criteria should be agreed upon prior to the initiation of stress testing.
Stress testing or screening can be discussed between SUGA and the relevant project representatives when product risk, project specifications, or use profile justify it. A basic pass result should not be interpreted as evidence of performance under operational stress unless aging or burn-in testing was defined and performed.
Identify the Right Test Evidence When a Board Fails
When a PCBA shows a failure signal, the cause should not be assumed from that signal alone; the review should check the findings, test access, required conditions, and evidence needed for repair, rework, or engineering disposition.
Fault Symptoms and PCB Test Paths
| Fault Symptom | Review Priority | Likely Test Path | Evidence to Capture | Review Basis | When to Escalate |
|---|---|---|---|---|---|
| Open Circuit | High | Flying Probe Testing or ICT | Netlist; Failed Net ID; Pad Access | Accessible Node or Test Points Exist | Repeated Fail on Same Net |
| Short Circuit | High | Flying Probe Testing, ICT, or Basic Electrical Testing | Failed Net Pair; Resistance Reading; Board Location | Power-Off Condition Before Powered Test | Same Short Across Repeated Measurements |
| Wrong Component Value | Medium | ICT or MDA Testing | BOM Value; Measured Value; Component Reference | Approved BOM and Substitute Status | Value Mismatch Against Approved BOM |
| Missing Component | Medium | ICT, MDA Testing, Visual Verification When Present | Component Reference; Fixture Result; Location | Component Access and Polarity Marking | Missing Part Affects Powered Function |
| Polarity Error | Medium | ICT, MDA Testing, or FCT When Powered Behavior Is Affected | BOM Polarity; Assembly Drawing; Test Fail Point | Polarity Marking and Footprint Orientation | Reverse Polarity or Abnormal Output |
| Power-Up Failure | High | Basic Electrical Testing, Followed by FCT | Input Voltage; Current Draw; Limit Table | Power Rail Sequence and Safe Load Condition | Abnormal Current; No Boot; Unstable Rail |
| Firmware Mismatch | Medium | Programming Verification and FCT | Firmware Version; Checksum; Boot Response | Approved Firmware File and Programming Interface | Version Conflict or Failed Functional Response |
| Intermittent Contact | High | FCT; Burn-In or Aging Test When Stress Screening Is Approved | Fail Timing; Connector Position; Fixture Contact Point | Fixture Contact vs. Board-Level Fault | Fail Appears Only Under Movement, Repeat Cycle, or Stress Condition |
| Function Failure Under Load | High | FCT; Burn-In or Aging Test When Load or Thermal Stress Screening Is Approved | Test Protocol; Load Condition; Acceptance Limit | Defined Function and Operating Condition | Failure Occurs Only During Powered Operation |
| Uncovered Net | High | Coverage Gap Review; No Direct Testing Available | Test-Point Map; Netlist; Uncovered Net List | Engineering Sign-Off for Untested Scope | Hidden Risk Remains Outside Tested Scope |
Review Priority note: Review Priority represents review urgency based on safety risk, powered-test impact, repeat-fail behavior, and unresolved shipment risk; it is not a frequency ranking.
Start from the Failure Signal
A sign of an error can originate from multiple sources: an electrical event; a powered response; a programming fault; a visual observation; or multiple failed attempts to repeat the test. The sign itself is only the first stage. There are many factors that could cause the failure signal: open nets, short circuits, incorrect values, absent components, incorrect polarity, or a failure to power up. For each of these, there needs to be corroborating evidence to establish the cause. Combining the signal with the board revision, accessible test points, program state, and the established acceptance basis helps SUGA avoid treating a failure signal as a complete diagnosis.
Connect Evidence to the Likely Test Path
The second decision relates to which test evidence ultimately will resolve the failure concern. For example, an issue with continuity may be addressed through the electrical path. An issue with component values may require a full ICT or MDA-type test approach, provided the setup allows. An issue with powered behavior will typically need the functional state defined, the firmware state defined, a defined load, and an understanding of the responses to interfaces.
The test path selected should reflect the level of assurance that can be proven. For example, if the setup simply checks accessible nets, then the result of that test cannot be used to make any claims regarding powered behavior. Similarly, if the failure condition is only manifested under load, then there is no way to close out the concern with just the basic electrical pass. It is important that the evidence remains supportive of the condition that caused the failure signal.
Define When Follow-Up Is Needed
There are certain signals that need additional review before there can be progress from the board level. Signals that belong in this category include, but are not limited to: the same failure occurring repetitively, movement between pass and fail, safety-related behavior, failed power-up response, or an inconsistent test result compared to current symptoms.
Follow-up does not necessarily mean a final root cause has been determined for the issue. Follow-up means that there is insufficient evidence at this point to support moving on to the next decision. It is best to determine what was observed, what was run through testing, what is still unresolved, and what further testing or clarification is needed to gain more information.
Make Tested and Untested Scope Clear
To create a more meaningful test result, the tested scope should be visible. When using PCBA testing, the test results need to be read in conjunction with what was actually tested, what could not be tested, and what limits were set for decision-making. A limited test could lead to creating a greater level of assurance than what the evidence supports without the context of the tested scope.
Tested Scope Should Be Visible
The tested scope shows what the result actually covers. The tested scope can relate to testable nets, where the components are located, how the system was programmed to respond, powered function, and what load profile is present. Once the tested scope is clearly defined, it becomes possible to make meaningful practical decisions instead of a generalized comment about the entire assembly.
The results should be tied to the state in which they were tested. A board that has passed an access-based net check gives evidence for each of its testable nets. A board that has passed a defined powered function supports evidence for that function based on the agreed testing conditions. Although both tests provide varying levels of assurance, they are different levels of assurance and should not be viewed as a single outcome.
Uncovered Scope Should Be Disclosed
Uncovered scope can be caused by many factors, including barriers to access, lack of a test fixture, inability to access a net, absence of required firmware, and undefined operating state. While these may prevent certain test results from being useful, the receiving team should still have visibility of the tested scope, so as not to be misled by partial results.
Documentation of the uncovered scope gives the OEM team the opportunity to evaluate whether existing evidence is satisfactory, whether additional testing is required, and whether uncovered scope represents an acceptable level of risk for the current project phase. The intent of this documentation is to protect the integrity of the test results, while also preventing limited test results from being interpreted as complete PCBA validation.
Coverage Should Be Connected to Limits
Coverage is also related to limits. The coverage of a test result is not meaningful unless the measured value, functional response, or electrical reading is compared to the specified limit. Without a defined limit or reference, the result may indicate a pass, yet not include sufficient information to support a high level of confidence in the decision being made.
The defined scope of the test also links all aspects of access, reference data, program condition, and accepted limits of the test. This creates a common understanding between SUGA and the receiving team regarding what is confirmed and what remains open to further review before the assembly can advance to subsequent decisions.
Use Test Report Evidence for Review and Follow-Up
A PCB test report is intended to guide follow-up actions based on the evidence collected from the tests performed. The report should not be read merely as a result label without identifying the board, referencing the setup, referencing the basis for determining the result, or referencing the follow-up actions required based on the test.
PCB Test Report Evidence and Review Signals
| Report Area | Captured Evidence | Review Use | Missing Evidence Risk |
|---|---|---|---|
| Board identity | PCBA part number, revision, serial or lot reference | Confirms tested board identity | Test result may not match shipped revision |
| Test type | Testing method used under the approved test plan | Shows which PCB testing method was used | Test scope may be unclear |
| Tested scope | Covered nets, functions, or measured signals | Defines both the area tested and the area excluded | Creates false confidence in untested circuits |
| Setup reference | Fixture file, test program, firmware version | Supports repeatability review | Failure may come from setup mismatch |
| Pass or fail result | Failed net, failed function, measured value, limit status | Supports repair, rework, or shipment decision | Failure cause may remain unresolved |
| Limit basis | Test protocol, limit table, approved drawing, quality plan | Connects judgment to approved requirement | Result may be judged inconsistently |
| Uncovered scope | Untested nets, inaccessible points, undefined functions | Shows remaining risk before shipment | Hidden risk not visible in report |
| Failure follow-up | Retest result, rework confirmation, engineering sign-off when escalation conditions apply | Confirms closure of failed signal | Open issue may carry into shipment |
| Operator and date | Test date, operator ID, equipment or station ID | Supports traceability review | Lot-level trace may be incomplete |
Note: Report content reflects the approved test scope and requirements.
Identity, Scope, and Setup References
Test reports must clearly demonstrate which iteration of the board the result applies to. Using revision, configuration, test type, test scope, and setup reference information within a test report will prevent application of results to the wrong product version and will create a clear path for continued tracking and testing of that same part when revisions or engineering samples are in circulation.
This is crucial when more than one revision of the board, engineering prototype, or test iteration exists simultaneously. Without being able to identify the test or correlate it with the original revision or setup, any future review may not be readily identifiable as associated with an already released unit, temporary setup, or production rework. By clearly establishing the identity of the tested item or setup, the test report can remain a usable document even after the manufacturing activity is completed.
Result Evidence and Pass/Fail Basis
A test report should include enough information to link the failure back to every piece of evidence included in the report, such as measured value, failed net or signal, failed function, program response, or load profile, that would have led to the recorded test outcome. This information will also assist in establishing the basis for an acceptance decision.
The acceptance basis is important, as the decision's effectiveness will be limited if there is not a defined comparison point, such as the current reading, voltage response, resistance, or function output. If that defined comparison point is contained in the test report, it allows for easier use and discussion by manufacturing, quality, and final review personnel.
Follow-Up Evidence
All test reports should include evidence that establishes the basis for the recommendation that the board has failed or will require additional test activities to determine its status. Evidence supporting the repair of a unit should reference evidence gathered to support the repair, such as retest results or confirmation of work done. Retests only confirm the correction of a previously identified issue when they re-evaluate a specific area of concern. In addition, repair confirmations carry much more weight when the repair is clearly connected to the cause of the original failure and the result of the recheck.
What Helps Define Test Preparation Effort
The amount of effort required to prepare for testing depends mainly on the clarity of the testing objective and how well the condition of the tested assembly fits into the overall test scope.
For planning review, useful details include estimated test-point count, fixture need, firmware version, load condition, expected cycle time, report format, and any burn-in or aging conditions such as temperature range, duration, load state, and acceptance limits.
Effort: Fixture, Probe, and Program Preparation
Fixture, probe, and programming setup all add to the required test effort. Certain tests may need device fixtures, probe arrangements, contact checks, and programming before the tests can begin. This setup work helps align the test setup with the board layout and expected evidence. These activities should match the tests expected to yield the necessary evidence and produce records consistent with the setup effort.
The required setup will vary based on the test stage and repeatability need. For instance, when comparing a single prototype assembly with a production assembly, the setup activity may be higher for the repeated test; conversely, the setup activity may be lower for a sample that presents only an open or short failure than if all relevant tests and stages must be combined to support a continuous stream of result decisions from different assemblies. This helps avoid quoting a test or preparing a quote based on assumed setup burden associated with a particular request.
Alignment: Firmware, Limits, and Setup Consistency
The firmware and programming setup used for testing should include firmware versions, test limits, expected response criteria, and a summary of product test scope and application. All setup data must reference the same product revision and the same intended use of that product. When setup references are not aligned with the purpose of testing, the testing effort becomes one of interpreting the meaning of the test results instead of executing the test based on known setup conditions.
Alignment of the setup references for testing ensures usability of test results. Stable setup settings minimize the need for unnecessary retesting, false fail conversations, and ambiguous result decisions. Even if some setup references will not be available prior to testing expectations being established, those references must be accessible to the testers before finalizing any testing expectations.
Assumptions Before Quotation Review
If the test method, access status, program state, report expectation, or acceptance limit is not defined before quotation review has occurred, SUGA may return clarification questions before confirming the quote. A more extensive file list may not be a significant factor compared to how closely the requested test correlates to the state of the test assembly and the anticipated results from testing and subsequent product decisions. This relationship creates a distinction between a basic screening request and a complete test plan requiring fixture setup, powered setup requirements, multiple run requirements, and follow-up evidence needed for decision-making.
What to Check Before Requesting a Quote
Before requesting a quote for PCB testing, the focus should be the connection between the requested method, board access, required setup, selected coverage, and report evidence for the next production decision.
Method Fit Is Only the First Check
Choosing a test method is only the first check. For example, the test methods of Flying Probe, ICT, MDA, FCT, and powered functional review can each be used for different issues during testing, but the test name alone does not provide an indication of how extensively the PCBA has been tested.
The response to a request for quote should clearly explain why the requested test method is best chosen for the product's testing stage and for the specific failure mode. In the case of an open or short, electrical access should be the primary consideration when developing a test plan for that mode. Conversely, if failure occurs when the product is powered, the test plan should consider the current firmware, load profile, interfaces, and power profile rather than treating a simple electrical pass as complete evidence.
Setup Transparency Shows Whether Results Can Be Trusted
How the testing configurations or setups support reliable test results should be clear. The response should show PCB access, reference files, test configuration, and the basis for acceptance criteria clearly.
The importance of setup transparency is to reduce disputes which can arise from unclear setup references. For example, an assembly may fail a test for reasons unrelated to the assembly, such as an outdated program, an undefined setup requirement, a revision error, or another setup reference that had not been previously defined. Therefore, clear communication of the setup enables a reviewer to separate a true assembly failure from a setup-related issue.
Report Evidence Should Support Follow-Up Decisions
The final review of the evidence collected during the test will clarify what was performed to produce the reported result, where the evidence was derived from, and what actions need to be taken, if needed, if the board failed or was still not in a confirmed status.
While report fields can differ by the order processed, the evidence should be able to support the action for what is to be done next: repaired, reworked, retested, shipment review, or more information is needed. If there is no connection between the tested item and the report, then the test outcome label would be considered weak for taking action on.
What SUGA Needs to Review the Test Scope
A complete quote request helps SUGA understand whether the requested PCB testing involves a simple check, a functional test, a fixture-supported test, or a follow-up report. Available files help SUGA review the likely test scope before quote confirmation.
Core Project Files
The first and core information for a project will include the BOM, Gerber or equivalent, assembly drawing, revision number, and the netlist, if one is available. These files establish the path from the requested test to how the assembled PCB is made up in terms of component position, layout, and product version.
Example revision notes can indicate whether the request involves the latest revision board or an older product. If a netlist file or IPC-356 file is also available, SUGA can review electrical access before determining how the product will be tested.
Test-Specific References
If the quoted test covers programming, functional testing, MDA, FCT, or ICT, the expected result basis should include the firmware version, the test protocol to be followed, the limit table, and fixture or program references to be used. When applicable, the expected acceptance basis should also be supplied.
The references do not need to follow a specific format; they should support board identification and the basis for the result decision.
Scope Notes
Known load profile, operating mode, connector interface, report evidence, prior failure signals, or hard-to-reach areas may all appear as scope notes for SUGA's review. These notes will show SUGA if the request for testing is primarily a basic screen, functional verification, fault follow-up, or if additional test plans are necessary.
If some information is still unavailable, SUGA can still process the request and return follow-up clarification questions as necessary. When open items are presented earlier rather than later, there is a clearer understanding during the quote discussion.
Upload BOM & Gerber
FAQ
PCB Testing is a process of determining if a circuit board or assembled circuit board will function according to the defined electrical, programmed, powered, or functional requirements for that particular project; for an assembled PCBA, the PCB test must relate to board revision, access conditions, approved setup, and a pass/fail basis. PCB Testing is not the same as Visual Inspection or First Article Inspection.
Common PCB testing methods include fixtureless electrical checks, fixture-based production screening, component-level defect checks, powered functional testing, boundary scan, aging, or burn-in when defined by the project. There is no fixed list that applies to every project. The right method to use depends on several factors such as access, risk signal, product stage, and required evidence.
PCB Testing typically begins with selecting the appropriate testing method, confirming readiness of the test setup, conducting the test under agreed testing conditions, and capturing result evidence. The exact method for doing PCB tests will be based on whether the concern involves open/short detection, component verification, firmware functionality testing, powered functional tests, or evaluation following a fault signal.
In-Circuit Test is a method of testing an assembled PCB that uses a fixture and test points to conduct production screening for potential concerns, such as opens, shorts, incorrect values, or component-related faults when access allows. ICT coverage is determined by availability of test points, fixture contact, the program setup used, and the pass/fail criteria approved for the assembly.
Typical symptoms of an issue with a PCB or PCBA include a broken circuit, shorted circuit, incorrect component values, missing component, incorrect polarity, inability to power on, programming problem, firmware mismatch, or erratic behavior under an established operating condition. Failure signals do not indicate a definitive root cause; therefore, all information must still be reviewed.
The testing team first reviews the failure indication, physical attributes, PCB revision, and electrical state. After that, the likely testing method will be considered based on the evidence cited above and the situation. The board may need electrical access testing, component-level checking, powered functional checks, and follow-up if the failure signal remains unresolved.
A PCB, or printed circuit board, is the bare unpopulated printed circuit board, whereas a PCBA, or printed circuit board assembly, is the printed circuit board after it has been populated and soldered with electronic components. Testing of bare PCBs focuses solely on the fabricated board; however, when testing of PCBA occurs, all elements must be taken into consideration, such as incorrect component values or polarity, firmware, soldering, and powered state.
An acceptable PCB test report will identify the board, model or revision, type of test performed, what was included in the test, evidence of results, acceptable limits, and any items not included in the test that need follow-up action in the event that the test failed. In general, the structure can vary based on order, but the content must include sufficient evidence for repair, rework, shipment review, or clarification.
Submitted information includes BOM, Gerber files, assembly drawing, board revision, netlist or IPC-356 file when available, firmware reference, test protocol, limit table, fixture or program reference, expected report evidence, and known failure signals. Not every item applies to every project; available files help define scope and reduce assumptions.
ICT is usually considered before FCT when the goal is to screen accessible opens, shorts, wrong values, missing parts, or polarity issues before powered functional checks. FCT should be used when the decision depends on firmware response, load behavior, interface operation, or defined functional limits. The final sequence should match the board revision, fixture readiness, firmware state, and approved test protocol.