Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 18

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.
Q&A

You might also like