After a test program is released to production, how can the engineer ensure that the testing criteria and specifications are maintained throughout the product life cycle? Usually, it is very difficult to control the quality of the test program once it is released to production, especially when the testing and fixtures are consigned to subcontractors that could reside in another state or country.
To alleviate this problem, a new technique monitors and controls test-program changes in a production environment. The proposed system has an access control feature commonly found in most commercial ATE. It also offers a data-validation feature, an audit trail feature, and reporting of recent test-program changes. Hopefully, the system will give test-support technicians the freedom to change test parameters for reasons such as engineering change orders (ECOs) and test instability while maintaining and controlling the integrity of the test.
System Requirements
The system uses a relational database to store test parameters and a high-level programming language for user interface and test-program logic. A relational database is recommended because it is good at capturing data changes, reporting, access control, and data-entry validations.
Capturing Test-Program Modifications
Table 1 shows test parameters for three resistors. Each test is a record in the table, and every test parameter occupies one column. The Reference Designator field and Revision Number field can identify each record. We can add fields to the table to store information such as who modified the test parameters, when the changes were made, the reason for the changes, and the status of the changes.
Table 2
shows how the test modifications are captured. In this table, R1 revision 1 had a genuine change, and R2 revision 1 had a potentially dangerous update due to its unusually wide tolerance. Additional fields such as date/time stamp and revision can be updated automatically by the system with some programming effort.Reporting Test Issues
With a test database, we can produce many useful reports using database queries. For instance, Report 1 shows all test modifications with open status. With this report, a test engineer could investigate why the tolerance of R2 was changed to 40% and take the necessary actions.
Other possible reports include the following:
History of debug for a particular component.
Work load and performance of test technicians.
Alerts (by e-mail) to test engineers of abnormal changes to a test program.
Number of ECOs that require test-program changes.
Number of test problems by problem category.
Component tests that are not stable.
You can avoid illegal changes to the test program by issuing access rights for different users. Most relational database systems have a default facility for creating new user accounts and granting permission for accessing records. For example, Microsoft Access gives each user an ID and password to access only permitted areas. Table 3 illustrates some possible access rights to the system.
A test engineer can include validation rules to constrain test-parameter changes. For example, you can specify that the test tolerance for the DC voltage measured at node Y will vary only 1% to 12%.
To specify such constraints in a database system such as Microsoft Access, we can add validation rules or write a simple program to check the valid range for the tolerance. Validations are performed before saving the test-program changes. If a test-record modification violates the validation rules, the system should respond with a warning message and disallow the changes.
The purpose of validation is to ensure test integrity or safety. Typical checks include abnormal tolerances, skipped tests, changes in the nominal value, an abnormal source level, and an improper power-supply level.
Linking Test-Program Logic to the Database
Since the basic design of this system separates the test-program logic from the test database, there must be a way to allow a test program to access data in a relational database. One popular way is via the Open Database Connectivity driver. Popular programming languages such as Microsoft Visual Basic provide Data Access Object to allow programmers to access database records in a Visual Basic program.
Advantages and Disadvantages
There are some important advantages to the proposed system:
Provides regular checks of the test specifications.
Helps management decide whether to recall products shipped during the period when the test was not properly done.
Analyzes the causes of false passes that occur when faulty products are found at the downstream stations after those faults supposedly were detected by upstream testers.
Monitors how well the test programs were maintained after being consigned to subcontractors.
Analyzes the work load and the common problems faced by test technicians.
But the proposal is not without its disadvantages:
Basic knowledge of the relational database and some database programming knowledge.
Initial effort to create database schema if the test data is not already in a relational database format.
Additional test-development time, depending on test-system requirements and the engineer’s knowledge of database programming.
Effort to maintain the database and programs.
Conclusion
A basic system capable of capturing, reporting, and controlling test-program changes can be created by separating the test-program logic from the test parameters. In this way, we use the database services, such as User Account Management, Access Control, and Reports, to monitor and control test-program changes. This method should reduce the time technicians need to prepare daily reports, improve the accuracy of reporting, and provide a prompt alert to the test engineer when a test is not right.
About the Author
James Tan Swee Chuan is an engineer at Singapore Technologies Electronics. Previously, he was affiliated with Smith Corona and Compaq Asia. The IEEE member has a bachelor of information technology degree and a diploma in electronic engineering. Singapore Technologies Electronics, Maintenance Operation Division, ATE Centre, 24 Ang Mo Kio St., 65 Singapore 569061, 011 65 4818888, ext. 536, e-mail: [email protected].
Reference Designator
Revision
Number
Nominal Value
Tolerance
Delay
Source Voltage
R1
0
3.3 k
5%
0.1
200 mV
R2
0
2.2 k
5%
–
200 mV
R3
0
10 k
10%
–
200 mV
Table 1
Reference Designator
Revision
Number
Nominal Value
Tolerance
Delay
Source Voltage
Modified by
Reasons for Change
Date/Time Stamp
Status
R1
0
3.3 k
5%
0.1
200 mV
–
–
–
–
R1
1
2.2 k
5%
0.1
200 mV
TSC
ECO #21
22/07/98
9 a.m.
Closed
R2
0
2.2 k
5%
–
200 mV
–
–
–
–
R2
1
2.2 k
40%
0.5
300 mV
LK
Test Not Stable
31/07/98
11 a.m.
Open Alert
R3
0
10 k
10%
–
200 mV
–
–
–
–
Table 2
Reference Designator
Revision
Number
Nominal Value
Tolerance
Delay
Source Voltage
Modified by
Reasons for Change
Date/Time Stamp
Status
R2
1
2.2 k
40%
0.5
300 mV
LK
Test Not Stable
31/07/98 11 a.m.
Open Alert
Report 1
Role
Rights
Test Supervisor
Super user with all the rights to modify a test program; can grant or revoke rights of any other users in the system
Test Engineer
All the rights to modify a test program; can specify validation rules for a test program
Test Technician
All the rights to modify a test program within the validation rules set by the test engineer
Test Operator
Only allowed to view the basic user interface; no rights for viewing or modifying the test parameters
Table 3
Copyright 1999 Nelson Publishing Inc.
July 1999
|
|