TESTING: KEY TO ADAPTABILITY

by Jim Highsmith, Director, Agile Project Management Practice

"Software," as the old saying goes, "is the only engineering discipline in which the equivalent of changing the wing on an airplane constitutes maintenance" -- note the somewhat deprecating tone. This saying, however, obscures the point that it is possible to change the wing on our proverbial software airplane. Of all our modern products -- from airplanes to toasters -- software is the most malleable. Software enables a wide range of other products to be adaptable also.

So why does the 2002 article by C.K. Prahalad and M.S. Krishnan, "The Dynamic Synchronization of Strategy and Information Technology" (MIT Sloan Management Review, Vol. 43, No. 4, Summer 2002), decry the lag between business strategy and IT capability -- i.e., IT applications can't respond fast enough to business strategy changes? Why do legacy systems consume such a high percentage of IT resources? Traditionalists' answers to these problems have been to get the software right the first time by conducting extensive up-front analysis and design. Agile practitioners have introduced a different solution: minimize the cost of change.

This second strategy has several facets, including one I will discuss here: testing. I contend that one reason that software applications are difficult to maintain and enhance (i.e., are costly and slow) is that they are only half finished; half the code -- the test code -- is usually missing. We have long put testing into a category separate from programming, sometimes to the extent of creating separate organizations -- one to produce feature code and another to test that code. This might work if software products were like static buildings, but software products evolve constantly over five, 10, even 20 years. We build feature code, usually using automated tools, and then perform manual tests -- over and over and over again.

What are the attributes of well-designed software? Number 1: the product delivers value to the customer (i.e., it works). Number 2: the product can adapt quickly and cost-effectively to deliver customer value over time (i.e., it works over time). Product changes, whether we call them maintenance or enhancements or new releases, involve changing or adding code. Modified code requires testing. If we want to change feature code quickly and cost-effectively, we must be able to test that code quickly and cost-effectively. All too often, organizations employ sophisticated code development and maintenance tools -- and manual testing.

To improve the adaptability of a software product, test code must be given the same status as feature code. Test code must be developed in conjunction with feature code. Test code must be as automated as feature code. When a new feature can be developed in three days and testing its code takes two weeks, one of two things happens: (1) test time gets reduced, thereby adversely affecting product quality and future maintainability, or (2) delivering new features takes too long.

But there are other reasons that test code is critical. High-quality designs are maintained by systematic refactoring, which is enabled by good testing frameworks. Without quick and effective methods of testing, developers are reluctant to refactor for fear of breaking working code. Once systematic refactoring is abandoned, feature code quality degrades quickly, making code harder to test and more difficult to change. This increasing "technical debt" creates an ever-exploding cost of change. No amount of up-front planning, requirements specification, or design can solve this problem; creating and maintaining test code (at all levels -- unit, system, acceptance) as an integral part of the software development process can.

In the past, we've often used the wrong goal for testing -- ensuring that the product meets functional and performance requirements. A better goal for testing is ensuring that the product meets functional and performance requirements over time. Feature code delivers functionality. Test code delivers adaptability. We should view testing not as a way to prove that feature code works, but as a way of ensuring that feature code continues to work -- change after change after change.

-- Jim Highsmith, Director, Agile Project Management Practice