Structural (Non-functional) Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 123

Because most software platform components come prepackaged (no source code
available), the white box techniques cannot be applied to the software platform. Because
the software platform behavior is seldom observed directly by the end user, most of
the black box testing techniques except intuition and experience cannot be applied to
the software platform as well. This is an area of testing that relies on the tester's own
experience of some kind as a system administrator role or the tester's collaboration with
system administrators. Several structural testing techniques have been described here.

8.2 INTERFACE TESTING

Interface testing focuses on data transferred between the application under test and
different software platform components. Examples of data transfer mechanisms that
need testing include data fi les, application program interfaces (APIs), database re-
quests, and network data transfers. One helpful way to develop interface testing is to
consider a four-step approach.

First, write tests that cause the application to produce data for transfer but
have the transfer itself inhibited. That will allow the tester to validate that the
application is producing the correct data in the correct format for use by the
receiving software platform components.
Second, remove the data transfer inhibitors and observe if the receiving
software platform component deals with the incoming data from the application
correctly. This will allow the tester to validate that the software platform is
correctly processing the already validated application data. If problems are
found with this data transfer, then you have isolated the problem to the vendor's
interface component or its data specification.
Third, write tests that cause the application to request data from other software
platform components, but manually substitute the requested data in lieu of a
“live” data feed from the involved software platform. This technique is referred
to as “stubbing” the inputs. You will need to create and validate the manual data
using the software platform component vendor interface specifications. This
will allow testers to validate that the application is correctly accepting the data
from the software platform.
Fourth, connect the application to the software platform components and rerun
the data requests with “live” data feeds. This will allow the tester to validate that
the software platform is producing data per its data specifications. If the problems
are found with these data, you have isolated the problem to the vendor's interface
component (does not work as advertised) or its data specifications.

Here is a pictorial view of these four steps.

1st: Application under test → Data (validate)

2nd: Application under test → Data → Support platform (validate)

3rd: Application under test (validate) ← Data ← Manual substitution

4th: Application under test ← Data (validate) ← Support platform