Test System Architecture, Cases, and Coverage
Chapters 1 and 2 provided a practical look at the process of defining a test organization's purview, understanding the risks to system quality that fall within that purview, and drawing up an overall plan for testing the most important of those risks. Now that you have a grasp of what's involved in these initial tasks, let's turn our attention to the specifics of building the test system itself.
First, we'll take a step back for a conceptual view of a test system and the relationships among the test system component parts. This section provides some definitions and describes the basic operation of a model test system. I use the phrase test system architecture to emphasize the fact that solid design and implementation are just as important for test systems as they are for the software and hardware we're testing.
After laying this foundation, I'll look at a method of defining test cases. This discussion presents a few test case templates that I find useful. In addition to some informal templates I've used, I'll cover the IEEE 829 templates. Whatever template you use, you'll need to decide how precisely to document your tests, so I'll also examine the level of detail required when writing test cases, including options that minimize the documentation, such as software attacks, bug hunting, and exploratory testing. Finally I'll analyze the issue of test coverage, discussing different approaches to measuring coverage, as well as ...