Browse Prior Art Database

Creating and Modifying a Manufacturing Process using a Graphical Model

IP.com Disclosure Number: IPCOM000127309D
Original Publication Date: 2005-Aug-22
Included in the Prior Art Database: 2005-Aug-22
Document File: 5 page(s) / 667K

Publishing Venue

IBM

Abstract

The primary role of a Test Engineer is to design good tests. One could say that any time spent by a Test Engineer thinking about things other than how to design the best test process is time wasted. Our solution is to model the test process in a graphical tool. A graphical tool isolates the Test Engineer from the syntax. A new feature may be added or the implementation of an existing feature may be changed, resulting in changes to the syntax, but not affecting the graphical view. This allows the framework to be reshaped and enhanced with minimal impact on users. The graphical tool will not give you the option of inserting or building illegal structure. In addition, a graphical tool makes "copy, cut and paste" or "drag and drop" a natural tendency. Browse and search features can be built in. Bits of one procedure can be "linked" into another, allowing common tasks to be written once and maintained in one location. Because the graphical tool views the test process in a hierarchical tree model, the Test Engineer can view the entire process at a high overview level or drill down into the detail level that he or she is interested in.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 28% of the total text.

Page 1 of 5

Creating and Modifying a Manufacturing Process using a Graphical Model

     The primary role of a Test Engineer is to design good tests. One could say that any time spent by a Test Engineer thinking about things other than how to design the best test process is time wasted. Test Engineers are wasting too much time:

Learning the "syntax" of how to implement their ideas into a test framework, i.e. the "learning curve"

Learning the rules of the test framework, i.e. Can I do A after B, or do I need a C first?

Rewriting/understanding inherited test processes because the "syntax" for the test framework is hard to follow and forces no particular style Debugging "syntax" errors Fixing "syntax" errors "Re-inventing the wheel" by writing redundant procedures because "sharing" procedures is made too difficult and error prone by the framework "Fighting" the test framework to get it to do what is desired Writing/Programming procedures outside the test framework because the framework is too hard to use or inadequate Not being able to see the whole test process from end to end with current manufacturing test processes.

     Two of the most popular test frameworks used today result in many of the time wasters listed above. The first and oldest is to simply write a test script or program customized to the content of a particular model that needs testing. This can work well under certain conditions, but generally leads to re-inventing the wheel, syntax errors, debugging, rewriting/understanding inherited test processes, and learning the "syntax" time wasters. The last is the killer, because now you need Test Engineers who can also program or learn to program which is hard combination of skills to find.

     The second method is to remove the programming burden by creating a test framework that is driven by simple text files. Using text files is a good idea and one of the most common, but leads to other problems. The Test Engineer has to learn and work in the correct syntax. Unfortunately, the more control the syntax allows, the more complicated it becomes. There are three areas where the text file syntax is burdensome to a Test Engineer:

Error recovery. What if a test step fails? How does the Test Engineer instruct the


1.


2.


3.

test framework what to do in the case of a failure?

Optional items. How does one specify an optional test and the rules for running

optional tests?

Test groupings. How does one specify a test grouping that can be reused?

     It is often the case where Test Engineers find themselves managing more than four text files, usually with at least three to four syntax styles for a single product model. This quickly adds up to time wasted in all the above categories.

     Our solution to the problems listed above is to model the test process in a graphical tool. A graphical tool solves the problems:

Learning the "syntax" of how to implement their ideas into a test framework, i.e. the "learning curve"

    A graphical tool isolates the Test Engineer from the synta...