Niroshan Rajadurai

The importance of completely testing software applications, and achieving it cost effectively is currently one of the major growth areas in the software development tools industry. There are many tools that offer solutions for automating the unit and unit integration test process for our application code. These tools can parse our code, and from a few simple options automatically create test drivers to stimulate our code under test, and test stubs for our dependencies. While these tools vary in capability and automation, they all offer an improvement on current manual testing processes that are in place.

One of the areas that is relatively poorly understood, and perhaps glossed over in the selection of these tools, is the process they go through to parse the code under test and automatically build the test framework. Every unit test automation tool in the market today needs to parse the source code under test to determine types, and interfaces for functions to be tested, and implement stubs for its dependencies. As a result all of these parsers understand standard C or C++ code, however every compiler not only supports the standard C or C++ language, they have extensions.

System Integration no matter the approach; modular, big bang, regressive, controlled or adhoc can often be one of the most critical phases of a project. This is often amplified when the final product consists of many software modules brought together in unison through a number of non-trivial interfaces. In our current world today we have many different interfaces, ranging from VME, PCI and PC104 buses, to ethernet, fibre, ATM, serial, wireless, bluetooth and other possible proprietary buses that will provide the final product with the technological edge to make it "tomorrow's must have item".

In such a changing dynamic world, the fundamental concepts we gleened from our forefathers who punched holes in cards to write programs has remained true. If you don't know what your sending and receiving over an interface, then other than through pure luck, or an extended integration phase composed of 'tiger teams' and an infinite budget, don't expect the problem solved quickly. In today's market, the once simplistic embedded processor with a few interrupts now has every interface conceived to man compressed into a single microchip no bigger than your thumbnail. Without a strategy to attack this problem, the harsh reality is that your project is doomed to fail. So lets take a look at how we can we solve this problem.

One of the challenges with developing software is to know when the software is at a sufficient quality such that we consider it ready to ship to our customers. The only provable way of ensuring that the our software will not contain any defects is to test it. Testing can occur at many stages, it could be unit testing, where we test a single class or source file in isolation to the rest of the system, integration testing, where we test the interaction of several units, while isolating others, or finally system testing where we test all of the software running as the final system. The challenge that software projects are faced with is to know when testing should stop. Is it sufficient to ensure every requirement has been tested?

I was lucky enough to view the EADS A400M demo flight at Farnborough 2010. This aircraft has a lot of significance to me, as I have worked closely with the engineers developing the software on this aircraft. Helping them test and verify it to the DO-178B certification standard.

Dim lights