Software integration testing and the need for good communication

When I first started out as a software tester, all my testing effort centred on programs running on a thing called a mainframe. Apparently they do still exist – but as the years go by, they become harder to find.

Testing back then did seem easier than it does today as generally the program under test ran as a batch (in the background) performing some sort of serial task that updated a main file or section of a hierarchical database. I was given a requirement and often a system specification and from there I drafted my tests and started to prepare test data. Then reviewed my efforts, interviewed the business users to ensure my understanding was correct and revised the work undertaken.

The new program or programs duly arrived and a test environment was either built or amended in which to run my tests. My tests were executed and all defects etc. were reported back to the development team for correction and subsequent retest.

Move forward twenty years and nearly every software application in use will be a part of a bigger system or suite that will constantly communicate with other areas of the system and most often, the Internet (indeed – as I write this using Word 2007, pressing the F1 key brings up the help from the Internet). This poses the question: has the focus of testing software risk changed in such a way that we should consider integration between systems as something that should be a high priority on the tester’s agenda?

I have always felt that the greatest area of risk for any software project lay in the interfaces between systems (if there were any) and in today’s Internet driven world this is more relevant than ever before. Information passing from one system to another needs to arrive in the same state that it left. It needs to be understood by the receiving system and needs to conform to a stated standard (or its own specification) that requires the developers of both systems to maintain.

With such a rise in system communication the need for integration testing continues to rise dramatically and this places more of a burden on software development than ever before. Communication between different teams and business areas within a company isn’t always what it could be and the larger the company the worse communication can get. Add to the mix more than one company involved in a software solution and the problem intensifies.

To ensure your software system communicates correctly with that of another team or company, a certain amount of integration testing from both sides needs to be undertaken – and this does not always run smoothly. What is a high priority on your testing agenda may be a low priority on the agenda of the other software development team, thus leading to problems of timing (when to run tests), personnel availability and most of all the correction of defects and rerunning tests.

Many times in recent years I have created a test plan, completed my test schedule and had the plan approved and reached the time when integration tests are to be performed, only to have them effectively cancelled due to the non-availability of either the other test software system, the testers from the team area or both.

If this should happen within the same company, then the main problem here is a poor programme management, which leads to a lack of project coordination. With good programme management in place, all projects are controlled in such a way as to ensure that work effort is coordinated in the best interests of all projects and the company.

If you are performing integration tests with an external company and you have a problem of rescheduling your tests at short notice, then there has clearly been a lack of communication between the two organisations – and possibly between you and your counterparts.

So how can this be remedied? The short answer is that when it comes down to communication problems, they aren’t easily solved. Human beings can be easily side-tracked, influenced, over-burdened and forgetful. These will all contribute to a team member (or complete team) missing an important email or meeting request, which contains important planning information.

A company should have a policy in place defining how it will conduct project and programme management and how it expects all members of projects and project support staff to adhere to the working practices. This will ensure that when communication and coordination between teams is necessary, there is a mechanism in place to ensure it happens.

In my experience, projects run using PRINCE 1¹ methodology rarely suffered from a communication problem (within the same company), mainly due to the BAC², TAC² and UAC² regularly visiting all teams and producing checkpoint reports that were then referred back to the programme. With such a regime in place, non-communicating teams were quickly identified.

So, should all projects be using PRINCE? No of course not, times have changed and software development methodologies have moved on. That said, the element of regular check pointing by an independent team should be in place and should form part of the programme management policy that a company has in place.

Regular checkpoint meetings within a company are not difficult to enforce but it is not so easy between organisations. To combat the communication problem between companies, early dialogue regarding the integration of software systems is vital and the level of the project’s importance for either side needs to be stated (and restated). If possible, regular meetings should be undertaken (either by conference call or some other easy means) to ensure both companies are still working to the same agenda and your target testing date and any changes to the project (from both sides) can be reported.

In all cases where I have been involved in a weekly (and sometimes daily) update conference call with an external company, there have never been problems running integration tests at the prescribed time (except for unforeseen technical issues arising on the day).

Without a high level of communication, integration of new systems can be problematic and, just like the testing process itself, must be started early.

Julian Hayward

 

1 PRojects IN Controlled Environments (Now replaced by PRINCE 2)

2 Business, Technical, User Assurance Coordinator