The next episode in this ongoing story about a test design techniques. At my client we need to test the interfaces between programs. This post is about the test design technique to use, the Program Interface Test (PIT).

“The PIT is a test design technique that is mainly used in the unit integration test“

The program interface test (PIT) is a test design technique that is used to test the interfaces between the various programs and/or modules. After testing the independent function of each program, this technique is used to verify whether the programs still function correctly after integration with real data flows.

The PIT is a test design technique that is mainly used in the unit integration test.

When two programs in a application work with each other the integration of these two needs to be tested. When executing test cases created with PIT it is verified whether program 1 and 2 function correctly together. If there is a program 3 or more, these are replaced with stubs and drivers. The integration between program 1 and 2 is done with real data.

“The goal of the PIT is to test the interfaces between the various programs and/or modules“

The goal of the PIT is to test the interfaces between the various programs and/or modules. And thus check if the various programs interpret the data flows the same way. This is because at these points in the programs many defects occur, differences between the two programs. These types of misinterpretations and incorrect execution are dealt with during this test. The program interface test focuses especially on the interfaces and not on the correctness and completeness of processing.

“The PIT covers the quality attribute functionality“

As with the DCoT, the PIT covers the quality characteristic (ISO 9126 or TMap) functionality of the test object. But also connectivity between the two programs.

Like with UCT and DCoT there are 5 steps that need to be taken:

“The PIT identifies the data flows in the integration“

The PIT determines that the test situations are identified by the data flows. There are two type of data flows; the direct data flows and the indirect data flows. A direct data flow is when a sender program transports the data directly to a receiving program without storing this data. An indirect data flow is when the sender program stores the data in a file and the receiving program collects the data from this file.

So first we need to identify the data flows (both direct and indirect) that are involved in the integration between the two programs. After this the attributes per data flows are identified. At last the domain of each attribute is determined and the validity rules for other attributes that are present are determined.

“Test situations with PIT are created by equivalence classes“

With the data attributes the equivalence classes is the basic technique to be used. Testing doesn’t have the option to include all possible attributes from the domains in the test cases. That is why the equivalence classes are used.

Determining the equivalence classes for each data flow is done by:

• If an attribute is not mandatory, then the empty set is also an equivalence partition;
• If the domain contains only a few values, then each value is an equivalence partition (single element);
• If the domain of the attribute contains a large number of numeric values, take: smallest, greatest and 0 (if within the domain);

If the domain of the attribute contains a large number of alphanumeric values, take: minimum number of positions, maximum number of positions and the other values.

“The logical test cases creation is done in two steps“

Creating logical test cases consists of two steps. First choose a representative from each equivalence class and second combine the representative into test cases.

In step one the a representative from each equivalence partition is chosen. When an equivalence class consists of a single attribute value, there is no choice. When an equivalence class contains several attribute values a choice should be made. Preferably, choose an attribute value that borders on another equivalence partition to be the representative and not one represented in the validity rules. This because these validity rules should be verified in other tests

When representatives are chosen, the representatives should be combined into test cases.

“The logical test cases will almost automatically be the physical test cases“

With the logical test cases in place the physical test cases should be derives simple. These logical test cases will almost automatically also be the physical test cases. Only descriptions must be made with the test cases as actions and checks. These actions are the actions for the sender programs to the test cases. The checks of the receiving program are also added. These checks are the determination of the expected result of the interface in the receiving.

“Test script derives from the starting point and physical test case“

The starting point for the physical test cases now needs a little more information. The initial data sets needed for the test are described, this also comes in handy for reasons of control and reuse. It helps if this data is provided with a meaningful name to recognize it. After this the test script can be build.

1. Rahul Gupta Says:
   August 26th, 2009 at 06:43

   Hi Andreas & Team,

   I saw http://www.testingthefuture.net at one of the discussions on Linkedin.com, under “Innovate Testing” group where I asked a question “What is Innovation in Testing?”
   Its good to see that we have so many people (like you and your team) who are willing to share the knowledge they have gained over the years in Testing field. I am not an expert but reading your posts really gives an insight of various aspects of testing to people like me who are willing to learn. Thanks a ton for your efforts and please keep on posting things like this.

   Regards,
   Rahul Gupta
   http://bugmagnate.blogspot.com

2. Rahul Gupta Says:
   August 26th, 2009 at 06:47

   @ Andreas/Team,

   One question on this post “PIT”. We as tester do not do Unit Testing but we do Integration testing of ‘n’ modules. Please define what role tester will play adopting this methodology/technique “PIT” and how is it different from normal “Integration Testing”?

3. Ewald Roodenrijs Says:
   August 26th, 2009 at 08:49

   Rahul,

   You can use the PIT technique also with those kind of integration testing. I used UIT as a reference, but I myself use it for acceptence testing in the project I’m in.

   Ewald

4. Ewald Roodenrijs Says:
   August 26th, 2009 at 08:54

   @ Rahul,

   Thanks for the feedback.

   It’s just Andréas and myself on this blog though

   Ewald

5. Trackbacks Says:
   February 5th, 2012 at 23:38
   • ADSL & WI-FI —FACTS AND FEATURES | Business BroadBand