The principle of focusing continuously on quality emphasizes that quality, to be achieved, must be addressed throughout the project life-cycle. An iterative process is particularly adapted to achieving quality, since it offers many measurement and correction opportunities. Improving quality is more than simply "meeting requirements" or producing a product that meets user needs and expectations. Rather, quality also means identifying the measures and criteria that demonstrate how it was achieved and show clearly that the process can be repeated and managed. Ensuring high quality demands more than the participation of the testing team; it involves all team members and all parts of the life-cycle, and it requires that the entire team own quality.
Every team member should be willing to chip in to address a quality issue. One of the major benefits of iterative development is that it enables teams to test early and continuously (see Figure 3.1). By the end of a project, since the most important capabilities are implemented early on, the most essential software will have been up and running for months and will therefore likely have been tested for months. This early feedback regarding quality also allows you to understand and improve the quality of requirements, design, architecture, and the overall process you follow. It is no surprise that most projects adopting iterative development claim that higher quality is a primary tangible result of the improved process. Figure 3.1. Testing Is Initiated Early and Expanded Upon in Each Iteration.Iterative development enables early testing. Software is built in every iteration and tested as it is built. Regression testing detects whether new defects are introduced as new iterations add incremental functionality. (Adapted from Kroll 2003.) As you incrementally build your application, you should also incrementally build test automation to detect defects early, while minimizing up-front investments. As you design your system, consider how it should be tested. Making the right design decisions can greatly improve your ability to automate testing. You may also be able to generate test harnesses and drivers directly from the design models. This saves time, provides incentives for early testing, and increases the quality of testing by minimizing the number of bugs in the test software. Automated testing has been a key area of focus for, among others, the agile community; the aim here is to automate all unit testing of code and, to a lesser degree, acceptance testing, and to write tests before the code is written (test-first design). The anti-pattern to following this principle would be to do in-depth peer review of all intermediate artifacts and complete all unit testing before doing integration testing. In-depth peer review of all intermediate artifacts can delay your application testing and can thus be counterproductive. Integration testing is crucial for finding major issues, such as architectural problems, and needs to happen early and often, rather than only after all code has been unit tested. This chapter describes a series of practices that will help you improve the quality of your application.
Let's have a look at these practices. |