Test-driven IS strategy 1: introduction

By Andrew Clifford

Can the principles that underpin test-driven development be applied to the definition and execution of IS strategy?

Test-driven development is a well-established approach to systems development. The defining characteristic is that tests are written before code is written. Tests provide a structure for design and coding. Test-driven development is generally accepted as a fast approach to development that delivers a high quality product.

Test-driven development forces the developer to focus on the outcome of the work, and how the work can be proved to be correct. This focus is then repaid by freeing the developer from many of the difficulties of traditional approaches.

• Tests are an efficient way of representing requirements. It is easier to fully and unambiguously represent requirements in a set of tests than in a design.
• By clearly defining right and wrong outcomes, tests provide clarity to the process. If all tests are passed, the programs are correct. There is no need for procrastination. There is no need for extra work "just to be sure".
• By embodying existing functionality in test cases, there is a much lower risk that new changes will invalidate the existing system. Change can be made much more confidently, and if the testing process is automated, very much faster.
• There is a clear distinction between errors in the system (tests not passed) and errors in the requirements (tests are wrong). This separates problems of implementation from problems of intent. It clarifies communication, particularly when requirements change during development.
• The clear and unambiguous definition of requirements up-front, in the form of tests, helps prevent unnecessary elaboration of the design.
• Tests provide a very clear mechanism for making changes. Changes are specified by changes to the required outcome, not by changes to the design.

I have found test-driven development hugely valuable. It helps us develop our Metrici Advisor software with speed, ease and confidence. It makes our development process much more efficient, and helps us compete with businesses many times our size.

Test-driven development is not just about programming and testing. It is a way of thinking about design. It moves the focus away from the structure of the solution, to the definition of the requirements and how the correctness of the solution can be validated. This clarification of intent is what makes development so much easier and less risky.

As the name suggests, test-driven development is fundamentally a systems development practice. But the benefits of the approach - efficiency, clarity, low-risk, speed, good communication, good change management - are general benefits that all parts of IT could benefit from. Can we use the underlying principles - a focus on requirements and validation of correctness - to achieve these benefits across all parts of IT management? I believe we can, and that we can scale these ideas to the definition and execution of IS strategy.

To understand how, we need to look more closely, not at the technical aspects of testing, but at the principles that make test-driven development work so well. I will look at these principles in more detail next week.

Subscription