Full Lifecycle Object-Oriented Testing (FLOOT)

Anything worth building is worth testing. You build a wide variety of artifacts, including models, documents, and source code. Software development is a complex endeavor. You create a variety of artifacts throughout a project, some of which you keep and some you do not. Regardless of whether you keep the artifact, the reason why you create it (I hope) is because it adds some sort of value. Perhaps you create a model in order to explore a business rule, a model that may then be used to drive your coding efforts. If the model is wrong then your code will be wrong too. If it is a complex business rule, one that requires a significant amount of time to implement, you might be motivated to validate your model before you act on it. If it's a simple business rule you might instead trust that your code-testing efforts will be sufficient. You will also find that many artifacts, such as user manuals and operations manuals, never become code yet still need to be validated. The point is that you will need testing techniques that enable you to validate the wide range of artifacts that you create during software development. In this chapter I explore the following: The cost of change; Testing philosophies; The FLOOT methodology; Regression testing; Quality assurance; Techniques for validating models; Techniques for testing code; Techniques for system testing; Techniques for user-based testing; and Test-driven development (TDD). THE COST OF CHANGE A critical concept that motivates full-lifecycle testing is the cost of change.