WELCOME TO

KNOWLEDGE SHARING 2020

INTEROPERABILITY TESTING
 Introduction to Interoperability Testing

INTEROPERABILITY TESTING IS A SOFTWARE TESTING TYPE, THAT CHECKS WHETHER THE

SOFTWARE CAN INTERACT WITH OTHER SOFTWARE COMPONENTS AND SYSTEMS. THE
PURPOSE OF INTEROPERABILITY TESTS IS TO ENSURE THAT THE SOFTWARE PRODUCT IS ABLE TO
COMMUNICATE WITH OTHER COMPONENTS OR DEVICES WITHOUT ANY COMPATIBILITY
ISSUES.
INTEROPERABILITY = INTER + OPERATION + ABILITY

INTER – MEANS “BETWEEN OURSELVES”, “WITHIN EACH OTHER”, “MUTUAL”

OPERATION – MEANS “THE ACT OF FUNCTIONING”, “THE FACT OF BEING ACTIVE”

ABILITY – MEANS “CAPABLE OF PERFORMING THE GIVEN TASK”,

SO COMBINING THE 3 TERMS TOGETHER – INTEROPERABILITY MEANS 2 (OR MORE)

SYSTEMS, CAPABLE OF PERFORMING THEIR ALLOCATED TASK INDEPENDENTLY AND
ABLE TO COMMUNICATE WITH EACH OTHER AS EXPECTED WITHOUT AFFECTING THEIR
INDIVIDUAL ASSIGNED FUNCTIONALITY.
Many a time Interoperability is confused with Integration, Portability and
Compatibility.

Integration – Is a technique when the components of the same system interact with
each other. So in testing world, when we do Integration testing, we are actually
testing the behavior of 2 or more, lowest levels of components of the same system.

Example:

Portability – Is a technique when an application or system behaves as expected

when it is moved to another environment. So in Portability testing, we export the
application to some other environment and test its behavior. Like, if there is an
application which works well in Windows XP, should also work well in Windows 10.
Compatibility – Is a technique by which 2 or more applications interact in the same
environment. So in testing world, when we do Compatibility testing; we validate whether 2 or
more application or systems behave as expected in the same environment. The intention
here is to check that the two systems perform their expected tasks, without interfering each
other working, in the same environment.

Like – MS Word and Calculator are 2 different application and they perform their expected
behavior independently in the same operating system. So we say that these 2 applications
are compatible with each other.

Interoperability – Is a technique on how an application interacts with another application. So

when we do the Interoperability testing, we check how the data from one application is
transferred into another application without prior intimation, in a meaningful manner, and
further processed to give the accepted output.
Example #1:
Take an example of reserving your flight.

Consider you need to travel from New Delhi to New York. Now you don’t have a
direct flight. You have to travel from New Delhi to London and then take
connecting flight from London to New York.

Now because you have some time constraints, you reserve your flight from New
Delhi to London in “Jet Airways” and from London to New York in “Virgin Atlantic”.
So that means all your passenger details got traversed from Jet Airways to Virgin
Atlantic.

So here, Jet Airways and Virgin Atlantic, both are independent application all
together and while reserving your flight, your details of booking got exchanged
from Jet Airways to Virgin Atlantic in a meaningfull manner, without prior intimation.
We would need to do Interoperability testing to ensure that:

1. The applications in the network perform their expected behavior

independently
2. Can exchange information without prior notice
3. The information/data is exchanged without interrupting the individual
expected behavior
4. The data / information which is exchanged does not gets modified or
changed
HOW TO DO INTEROPERABILITY TESTING

1. PLAN: We can use standard test plan document, however, there is a need to know
and understand all the applications, their functionalities, behaviour, input it takes, and
output it reveals. Also, do not think of one application or two applications, rather think
of all the applications as a single unit. You need to have a bird’s eye view.

2. DO: This is the span of time where execution on functional and non-functional testing is
done, logging the defects, following up with development team to get those resolved,
regression and re-test of the system as a whole.

3. CHECK: This is the phase where we revisit our test results and try to map those with the
Requirement Traceability Matrix (RTM) and validate whether all the expected
requirements are met and whether all the applications are traversed. We check that
the data is traversed and exchanged correctly and smoothly between the
applications/systems. We would also need to validate that the data which is traversed
does not gets modified.
HOW TO DO INTEROPERABILITY TESTING (Contd.)

4. Identify all the applications that are part of the network.

5. Identify their respective functionalities.

6. For each application, identify the Input it takes and the output it returns.

7. Identify those data which would be traversing through all/most of the applications.

8. Identify the expected behavior for each combination of application and date that
needs to validated

9. Document it.
A. Application 1, Application 2, Application 3
and Application 4 are four different systems
B. Each of these systems has the definite set of
functionality which needs to be identified.
C. Input and outputs of each system need to be
identified.
D. In case of application1, it renders 2 outputs. 1 output
forms the input of application 3 and 1 output forms input
of application 2. The output from application 2 forms the
input to application 3 and application 4 and so on.
E. The validity for each of the input and output is
checked. The major point to consider here is that the
data which is traversing in the form of input and output
does not gets modified AND all the application is
covered.
Example #2:
Considering An Hospital Management System having
various departments and sub-departments with the
following test scenarios:

1. A patient who met with a road accident (OPD

Department – Accident), need to undergo a leg surgery (
ENT – General Surgery), then has to undergo the
physiotherapy (Support department – Physiotherapy) and
then gets discharge (Support Department – Closure)

2. A child admitted to critical care (Pediatrics – Critical

Care) needs to undergo a surgery (Pediatrics / ENT –
General Surgery) and then is discharged (Support
Department – Closure/PR)

3. An outside patient consults a general physician (OPD

department); takes the prescribed medicines (Support
Department – Pharmacy) and walks away.
 REQUIREMENT
TRACEABILITY
MATRIX (RTM)

1. The RTM shows the scope of our testing

2. It determines the depth of our testing efforts
3. Like in this example, we see that the “support
department” application which is the exit
point for all (most) of the application, hence
the testing effort for this particular
application is a bit more as compared to
other application.
CHALLENGES:

• Difficult to test all the application with all the permutations and combinations (Exhaustive
testing)

• Applications are developed in different hardware/software combinations and are

installed in different environments, so if any of the environment is down, it impacts the
testing.

• Because of the different software’s and environments, determining the testing strategy
and executing it is itself a big task.

• Stimulating the environment for conducting the test, is a big challenge.

• In case of any defect, doing the Root Cause Analysis is a big challenge.

• Because the applications are in a network, there would be times when the network is
down. Because of this, testing also gets affected.
How can I mitigate these challenges?

1) Try to use the advance testing techniques like :

OATS (Orthogonal Array testing technique)
State Transition Diagrams,
Cause and effect graphs
Equivalence portioning and Boundary value analysis.

2) Try to identify some historical data like – under which circumstances the systems were down, how much time
does it takes to be back in action.

3) PLAN – Use historical data, past experiences, skill of the team, environmental factors to identify the strategy of
the testing. The better your plan, the better would be your execution.

4) Start working on preparing the environment much before than your actual execution starts. Needless to say-
plan your steps when you are preparing the environment. Make sure that your environment is all set, ready and up
& running when your execution starts.

5) Before starting with the IOT, ensure that the individual applications are fully functionally tested with no defects.
Then in case of any defect, you would only need to look for the environmental factors that have resulted into some
error.
Interoperability Test on Mobiles:

In Mobiles, we do interoperability test whenever a new App (Mobile Application) is

launched. There are many areas that we have to consider when planning for this testing on
Mobile devices:

1. Types of mobile devices available for testing.

2. All the Mobile OS are developed in different programming language. Hence, the app
needs to be tested against all the variations of OS.
3. Understanding the legal factors and region related contracts.
4. Size / resolution of different devices are need to be taken into consideration.
5. Impact on the mobile inbuilt apps also needs to be considered.
6. You would need a plan
7. Create an RTM just like we did for a computer-based application testing.

The intention, strategy, risks, and execution would be same but the tools and
techniques would be different in case of mobiles.
Conclusion:

Interoperability testing is a huge task as there are lots of factors which

need to be considered while executing this technique. Keep in mind to
have sufficient time for bug fixing and retesting, as this is a huge effort
which requires that there should be provision for defect follow-ups.

It may happen that you may not attain 100% coverage, but we should
be smart enough to select our test cases in such a way that most of the
applications are covered in a single flow by using good test case writing
techniques.