Test engineer

A (hardware) test engineer (TE) is a professional who determines how to create a process that would test a particular product in manufacturing, or related area like RMA department, in order to guarantee that the product will be shipped out with good quality. Test engineers are also responsible for determining the best way a test can be performed in order to achieve 100% test coverage of all components using different test process.

Test engineers can have different expertise which depends on what test process they are more familiar with (although many known TE have full familiarity from the PCB level process like ICT, JTAG, and 5DX) to PCBA and system level process like board functional test (BFT or FT), burn-in test, system level test (ST). Among some known process used in manufacturing where a TE is needed are as follows:

* In-circuit test (ICT)
* Stand-alone JTAG test
* Automated x-ray inspection (5DX/AXI) (also known as X-ray test)
* Automated optical inspection (AOI) test
* Continuity or flying probe test
* (Board) functional test (BFT/FT)
* Burn-in test
* Environmental stress screening (ESS) test
* Highly accelerated life test (HALT)
* Highly accelerated stress screening (HASS) test
* Ongoing reliability test (ORT)
* System test (ST)
* Final quality audit process (FQA) test

Early project involvement from design phase

Test engineers often work with the program managers during the PRD and MRD definition which is the earliest of the new product introduction (NPI) stage. Test engineers define how a product is designed for testability and manufacturability. This includes the following:

* Making sure the product has correct label specs and placement that would make it possible for the unit to be traceable and programmable. Implementing good label specs results in having correct information programmed correctly into the unit under test (UUT) (sometimes called DUT or device under test). To make this possible, the test engineers enforce those labels location and are all readable and scannable, thus eliminating the need for a manual typing of information into the unit. Automatic placing of identification codes into the part during test and making them available for varification at later processing steps can help minimize these types of errors. Manual typing can introduce problems related to inaccurate information being programmed due to human errors. Also, without the test engineers input during PRD design phase, the hardware engineer in charge of designing of the silk-screen for the PCB may put those labels below some attachable board which will then later renders the labels useless (i.e. in a motherboard/daughterboard design and also a board that has a pluggable module, a label would be visible on the main board by itself but would be obstructed by the other boards that needs to be integrated). This information are often indicated in both PRD and MRD.
* Making sure that all components required to test and debug the UUT, which includes the console/serial port, are all accessible from the early part of the manufacturing process up to the last part which is often the final quality audit/assurance (FQA) process. This also includes making sure those components are available even after the units are returned by the customers for troubleshooting or repair. By following this guidelines, the team will eliminate unnecessary opening of the UUT just to access those components which may result in introducing errors into the unit (i.e. knocking off some capacitors or resistors when opening/sliding out the cover, dropping the tool inside the PCBA after opening, forgetting some other cables to reconnect before closing the unit for manufacturing process flow continuation, etc).
* Making sure that all components needed to test the unit are added into the cost matrix of the final product. This components may include the UART/RS232 chips for talking to the UUT, ethernet ports for upgrading the firmware, JTAG connectors, etc.
* Defining what manufacturing test process is needed based from the product definition.
* Verifying that the currently available test equipment is adequate for testing the proposed design. If new equipment is needed, budgetary concerns have been addressed and sufficient lead time exists for new equipment installation and verification. Also, new test equipment may require training for test equipment operators and supervisors.

By test engineers making sure that the above items are followed, future surprises should be minimized (like adding extra components, re-layout of the boards, etc) which drives up costs and development delays of the final product.

Working with cross platform teams, hardware and software team

Often people take shortcuts to be able to deliver final products. Problem is, because of these shortcuts, the product's manufacturability and testability becomes complicated (inability to read and write information, creating deviation from the process, etc) which impacts the manufacturing complexity of a product. Because of this complexity, bottlenecks in the manufacturing and delivery schedule delays are introduced.

With this in mind, test engineers always get involved in the following reviews as well:
* Schematics review - to make sure all components and data/electrical paths are accessible and testable
* Board layout review - to make sure all labels and components are accessible. No components are near the edges, covers, movable parts, etc. that would result into higher probability of a components being knocked off the board.
* Electrical specifications review - to make sure all we can drive the needed power into the board with any fixture needed in any of the process (ICT fixture needs to make sure it can supply the appropriate power to the board without external power supplies, the Burn-In and ESS chamber can provide the required voltage and current to a number of fixtures and at the same time without modifying the chambers specs so it can mix with other products)
* Diagnostics specifications review - to make sure command output formats are followed for simplification of whatever test automation tools will be develop. Also, to make sure that commands itself are available to test all components.

Yield gathering

Data gathering plays a very important part during the products' lifespan. In early stages, these data or test yields drive the product to see if it is mature enough to go into mass production. Certain companies have specific yield targets for each process that measures what is the yields expected and/or acceptable.

Data is also consistently gathered after the product gets passed mass production stage (or general availability aka GA). These data are usually used to improve the quality of the products. For example, data may prove that common chips doesn't work well all the time with the CPU or design of the product. It may also show that a particular field replaceable unit (FRU) fails a number of times in the field. Because of those data, a new component or FRU can be qualified by hardware, software and manufacturing team to drive down the errors or eliminate those problems. These data are provided as input also to the next product with similar design.

In addition, yields will show if another process needs to be introduced (i.e. previous process cannot capture certain test errors due to limitation of fixturing or something else). Yields can also decide if an existing test process can be trimmed down (step-wise or time-wise) or even fully eliminated (i.e. if the ESS errors can be captured during the 3rd hour, test time can be cut down from a normal 24 hours down to maybe 4. Or if a process consistently yields 100% during a 15 month period, teams can get together and decide to eliminate that process at all)

Test automation

Test automation consumes the biggest part of the test engineers' role. The whole intention of automating the test is as follows:
* Enforce test steps to be followed within specifications and correct timing.
* Eliminates any manual typing of commands and data input.
* Automate data gathering.
* Enforce test process flow.

Overall, this drives manufacturing quality at the end of the line making sure that all units shipped out to customers are well tested, stressed, filtered out of any errors, and configured properly.

Defining standard test documents

Following are some of the documents that the test engineers maintain or define:

* Diagnostic design specification
* Manufacturing test requirement design specification
* Design for testability (DFT)
* Design for manufacturablitiy (DFM)
* Test plan

Contract manufacturer TE

A contract manufacturer (CM) also provides a test engineer for all their customers as well. The function of this test engineers varies depending what kind of level of support they will provide for their customers: providing "interactive and first level of defense"-only support or providing partial or ground up solutions.

Providing interactive and first level of defense support

Providing "interactive and first level of defense"-only support is the usual job of the CM TE. Their functions covers mostly the following:
* Reviewing the test solutions with their partner TE from the customer side.
* Analyzing if all the infrastructure requirements are feasible (from floor/line setup, network access to workstations and/or servers, operator manpower, etc).
* Getting familiar with the customer products' technology.
* Being able to manage, train and support operators who will actually perform the UUT testing.
* Able to debug and isolate problems
* Gather information for feedback to their partners

Because of their close involvement in the test line, they monitor the products going through the line and inspect the failed boards to decide if it really failed or if the failure was just caused by some improper test setup. Some examples of these false failures are:
* Forgot to connect the cable to talk to the UUT (or misplacing the cable or putting it loose). This will cause the test automation to time out for any respond from the UUT.
* Forgot to connect the loopback cables when testing a UUT with any networking interface (ethernet/optical/etc ports). This will cause the traffic test to fail.
* Skipped some test process. Some test process will configure the UUT to load some firmware or put it in some state (i.e preparing it to run in burn-in mode) so when the test automation starts, whatever known state it is expecting will not be satisfied and thus fail.
* Skipped to implement some deviations that would require hardware/software changes to the UUT.
* Forgot to power up the unit right away when the test automation started. This will result to the same problem as the first item of this list.
* Forgot to attach any other test fixture components
* etc

Providing partial or ground up solutions

There are small number of companies who preferred to hand out all the test engineering work to their CM. In this case, the CM TE will then be in-charge of providing the test automation solution, test fixture design, yield gathering plus the usual interactive and first level of defense for their customers.

Of course, handing out all test solutions to the CM has some pros and cons. Some of the advantages are:
* Cheaper cost, specially if the CM resides in another country where labor is at minimum.
* Beneficial if the company itself doesn't have or cannot find any TE that matches the company's requirements and skillset.

Some of the disadvantages are:
* Getting tied up to a single CM. It is hard to find a CM that is willing to share information to another CM.
* CM TE are seldom involved with product design stage/phase.
* Time constraints. They only get handed out the specs of the product during late NPI stage. Because of this, test solutions are rushed and quality are compromised.
* Conflict of interest. Company needs to know every level of information that goes through the line to monitor potential problem that would one day snowball. But CM doesn't provide this level of details, hence they only give out how many units passed or fail for the day. A unit could have been failing 5 times before it passed which may relates to some timing issues of some components of the product like the CPU or oscillators for example. The cleaner the first passed yield data that the CM provides, means the better quality the unit went through the assembly line. This means, CM would be enticed to provide the final result as their first passed yield data instead so it will reflect their higher quality side.

Because it is hard to find a test engineer who knows every aspect of testing methodology (from PCB test like ICT, JTAG test, flying probe test, 5DX test, etc... to PCBA test which includes writing test automation from functional test to FQA test among others), company usually outsource some development of this missing test piece to their CM. For example, if none of the in-house TE knows much about ICT fixtures, they will ask their CM to develop the ICT test solutions for them instead.

External links

* [http://www.evaluationengineering.com Online test engineer trade magazine]
* [http://www.itctestweek.org International Test Conference (ITC)]
* [http://www.savvytestengineer.blogspot.com The Savvy Test Engineer blog]