Book contents
- Frontmatter
- Contents
- Acknowledgments
- Foreword
- Preface
- About the Author
- Chapter 1 Leading-Edge Software Development
- Chapter 2 Understanding the Basics–Object-Oriented Concepts
- Chapter 3 Full Lifecycle Object-Oriented Testing (FLOOT)
- Chapter 4 Agile Model–Driven Development (AMDD)
- Chapter 5 Usage Modeling
- Chapter 6 User-Interface Development
- Chapter 7 Supplementary Requirements
- Chapter 8 Conceptual Domain Modeling
- Chapter 9 Business Process Modeling
- Chapter 10 Agile Architecture
- Chapter 11 Dynamic Object Modeling
- Chapter 12 Structural Design Modeling
- Chapter 13 Object-Oriented Programming
- Chapter 14 Agile Database Development
- Chapter 15 Where to Go from Here
- Glossary
- References and Recommended Reading
- Index
Chapter 3 - Full Lifecycle Object-Oriented Testing (FLOOT)
Published online by Cambridge University Press: 03 March 2010
- Frontmatter
- Contents
- Acknowledgments
- Foreword
- Preface
- About the Author
- Chapter 1 Leading-Edge Software Development
- Chapter 2 Understanding the Basics–Object-Oriented Concepts
- Chapter 3 Full Lifecycle Object-Oriented Testing (FLOOT)
- Chapter 4 Agile Model–Driven Development (AMDD)
- Chapter 5 Usage Modeling
- Chapter 6 User-Interface Development
- Chapter 7 Supplementary Requirements
- Chapter 8 Conceptual Domain Modeling
- Chapter 9 Business Process Modeling
- Chapter 10 Agile Architecture
- Chapter 11 Dynamic Object Modeling
- Chapter 12 Structural Design Modeling
- Chapter 13 Object-Oriented Programming
- Chapter 14 Agile Database Development
- Chapter 15 Where to Go from Here
- Glossary
- References and Recommended Reading
- Index
Summary
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.
- Type
- Chapter
- Information
- The Object PrimerAgile Model-Driven Development with UML 2.0, pp. 68 - 100Publisher: Cambridge University PressPrint publication year: 2004