Testability with Agile

One of the most painful episodes in the birthing process of a new software product under the Waterfall method has got be the testing and validation stage. It is a trying time for the parents (the developers), the doctor (the project manager) and the relatives (stakeholders). It is stressful because, like a real birth, it is unclear how long it will take and how it will turn out. Unfortunately for the Waterfall development method, few software products emerge complete and meeting everyone's expectations.

One of the reasons is cultural. Testing is traditionally not generally viewed as "value added" to a product, and is typically assigned limited resources. As a result, professional testers or Quality Assurance (QA) Engineers are not generally considered as valuable to the company's business objectives as "real" engineers. This leads to a commonly shared belief in development, marketing and sales organizations that QA is a "necessary evil."

Another reason is that software is getting increasingly complex. Complexity is exponentially related to the number of software functions that are dependent on each other. (In Web 2.0 applications that is "most of them"). So the longer the wait to test, the more complexity, and the more difficult and expensive it is to determine if a product is ready for release. Further, the emergence of Web Browsers as the de facto user interface was supposed to automatically create cross-platform software, but this is not the reality for Web 2.0 applications, which rarely work in all operating systems and Browsers in their initial release.

With Agile Methodologies, testing is built into development process. (Although this appears to violate an intuitive and deeply held belief about not letting "cats watch milk," it actually works). It works because developers want to produce fault-free working software code as much as anyone else wants them to. In fact, Agile testing philosophy allows developers to do what they do best and enjoy the most: Develop code (that tests the code). They test smallest "units" or working pieces of code. A significant size application can have hundreds, even thousands of these unit tests, which collectively become an ever-expanding and reusable test suite for the software. It does require additional up-front investment to create these unit tests, but saves money at the end of the process by dramatically reducing-or eliminating-the number of costly "surprises" and serious problems that require fixing at the back-end with the Waterfall method.

Testing code as you build it (actually creating the tests before you build the code) has some additional benefits. One is that it allows for every piece of new code to be tested for latent errors and conflicts with existing code before it becomes part of the main body of code. This is accomplished through a process called Continuous Integration, which is the software engineering practice of committing every change to a software project to a revision control system. Another is that all the existing code, and the new code, is tested as a unit, automatically, whenever new code is added to the system. This means that a new product release can be made whenever the stakeholders' representative decides it's time to launch it. The complete functioning code base is always tested and ready to be delivered as a product. When to launch a new product or functionality becomes a business, not an engineering, decision.