Test engineer

From Wikipedia, the free encyclopedia

You have new messages (last change).
This article is about hardware test engineers. For software test engineers, see software testing.
This article or section may require cleanup to meet Wikipedia's quality standards.
Please help improve this article or replace this tag with a more specific message. This article has been tagged since October 2006. (help, talk)

A (hardware) test engineer is a professional who determines how to create a process that would test a particular product in manufacturing in order to guarantee that the product will be shipped out with good quality. Test Engineers (TE) 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 In-Circuit Test (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:

Contents

[edit] Early Project Involvement from Design Phase

Test Engineers often works with the program managers during the PRD and MRD definition which is the earliest of the New Product Introduction (NPI) stage. Test Engineers defines 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 [[Device Under Test|Unit Under Test (UUT)] (sometimes called DUT or Device Under Test)]. To make this possible, the test engineers enforce those labels needed are all readable and scannable thus eliminating the need for a manual typing of information into the unit. Manual typing only introduces problems related to inaccurate information being program 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 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 mostly 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.

By making sure that the above items are followed through by the test engineers, no other surprises will pop up (like adding extra components, relayout of the boards, etc) which drives cost and development delay of the final product.

[edit] Working With Cross Platform Teams, Hardware and Software Team

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

With this in mind, test engineers always gets 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 Specs 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)

[edit] Yield Gathering

Data gather plays a very important part during a products lifespan. In early stages, this data or test yields drives if a product is mature enough to go into mass production. Certain companies have specific yield targets for each process that measures what is the yields expected.

Data is also consistently gathered after the product gets passed mass production stage. This data is usually used to improve the quality of the products. For example, data may prove that common chips doesn't work well 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. This 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 a needed process can be trimmed down 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 thoroughly decide to eliminate those process)

[edit] 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 handling of commands and data input.
  • Automate data gathering.
  • Enforce test process flows are executed.

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

[edit] Defining Standard Test Documents

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

[edit] External links

Retrieved from "http://en.wikipedia.org../../../t/e/s/Test_engineer.html"