SOA Testing: An Introduction

What is SOA?

SOA stands for Service Orientated Architecture.  It’s a way of building an IT system that uses a series of separate executables which communicate with each other in what’s called a service layer.  To an outside user, the ‘join’ between these individual executables is invisible, and they seem to work as a single application.

There are many ways these executables can communicate with each other, but the most common method is to message each other using XML language.

Example of SOA

Lets take an example of a basic people-based database record system.

You can login as either an,

• Account Manager – a user who manages the accounts of other users who access records, however does not have access to the records themselves.
• Record User – a user who can access people records, and create/retrieve/update/delete people records as required.

From a system tester perspective, the system is a single black box application, and it’s used as a single entity in testing.

However looking at the design level – the developers have implemented it as 4 separate applications;

• LogIn – Verifies account name and password, and allows a validated user to login as either an Account Manager or Record User
• AccountsMan – An application that allows the user to create/retrieve/update/delete a user account.
• HCI_RU – The human computer interface or “front end” to the Record User application.
• MDB_RU – The “back end” application which handles record data, retrieves data from the database, verifies the data provided etc.

Testing an Application with a SOA tool

To test a SOA application, instead of testing all the applications together as is common practice within System testing, we can perform earlier testing on each individual application.

The emphasis on this to test an executable application in isolation, sending a message to it, and analysing the expected response returned from it.

In our example, we’re going to test the MDB_RU application – but we don’t have the HCI_RU (front end) ready yet.  So we’re going to use a SOA tool to send messages to it, and analyse the response.

  

The SOA Tool used to test this can be a dedicated bespoke test harness.  But such test harnesses can often be as expensive to build and maintain as the object under test.

Increasingly there are also dedicated SOA tools available to aid with testing such as soapUI or HP’s Service Test.  These are tools which are ready to handle sending and retrieving messages to a target port on an application under test.  Although most of the work for these is done, they don’t just work “out of the box” and will need to be tailored according to the application design and interface specifications, with possibly a developer aiding.

Using SOA tools can be a fairly technical form of testing – and will require some understanding of the messaging system.  For our example which uses XLM messaging, we create a test message to ask the MDB_RU to search for records for people called “John Babcock” and return any records …

Input message

<HCI_RU_msg>

                <header>Search</header>

                <searchKey>

                                <firstName>John</firstName>

                                <lastName>Babcock</lastName>

                </searchKey>

</HCI_RU_msg>

Output message

<RU_HCI_msg>

                <header>SearchResults</header>

                <numResults>2</ numResults >

                <results>

                                <firstName>John</firstName>

                                <middleName>Lee</middleName>

                                <lastName>Babcock</lastName>

                                <dateOfBirth>02/03/1970 </dateOfBirth>

                                <IRD_num>102365846</IRD_num>

                </results>

                <results>

                                <firstName>John</firstName>

                                <middleName>James</middleName>

                                <lastName>Babcock</lastName>

                                <dateOfBirth>15/09/1979 </dateOfBirth>

                                <IRD_num>012456735</IRD_num>

                </results>

</ RU_HCI _msg>

SOA testing exists in a “grey” area.  It’s not the pure black box testing of waiting for all the applications to be put together as an integrated system and testing the whole thing.  But neither is it truly white box testing – you don’t see the internal logic/actions within an application, just it’s responses.

Advantages of SOA Testing

In most environments, system testing can only begin once all applications are available an integrated into a test environment.

In reality though, different applications ready at different times – so in our example for instance, the the MDB_RU appication is completed 3 weeks before the MDB_HCI application is ready.  Traditionally without this we’d not be able to begin testin.  Being able to test the MDB_RU application using SOA will help identify any bugs early, and get the developers working to resolve them. 

One of the fundamental rules of testing states the earlier a defect is discovered, the less it will cost to repair it – this is the strength of SOA testing.

In addition it also allows testing in isolation.  When our example application was system tested, it retrieved someone’s details, it displayed someone’s date of birth as “00/00/0000”.  Is it the front end (MDB_HCI) or back end (MDB_RU) which is at fault here?  SOA testing would allow us to test each separately to determine the application at fault.  In our example it could be the back end is sending blank data because the client record has no associated date of birth, and thus the front end is interpreting null to be 00/00/0000.

Disadvantages of SOA Testing

Even using tools like soapUI or HP’s Service Test, SOA testing is more technical.  It also involves  more of a learning curve to get started, including a more detailed understanding of the “nuts and bolts” of how the applications are designed than in system testing.

It’s not a complete substitute for system testing, rather an exercise that can support it.  Each application can be tested to perfection in isolation, however it’s only as integrated that the end system will be delivered.

Finally one potential danger with testers taking on SOA is developers not testing their work sufficiently, feeling the SOA testers will pick up if they’re any problems.  This might not be a problem if builds can be created quickly – however if builds are only available once a day, this could mean a bad build knocking out all work for that entire day.

My Personal Experience

There is no doubt that SOAs like Clouds are becoming increasingly popular in solutions.  I've done testing on a couple of them - you're seeing SOA concept being utilised more and more, for instance when one Government department (such as healthcare) is trying to link into another (social security).

I recently introduced a test department to SOA testing using the basic SOAP UI.  The back end processing components were "ready for testing", but the front end wouldn't be ready for about 4 months.  Using SOAP testing tools, the team was able to test NOW, find problems NOW, have defects fixed NOW.  It was a pleasure to see a team really see the value of the tool in a big way, a real "road to Damascus" revelation that there were other ways to test using SOA and test early.