A Practitioner's Guide to Software Test Design

by Lee Copeland
I read this book to build knowledge on the top of my practical experience in software testing of multi-tier architectures. I am writing detail notes from this book in my review here.
The design of tests for software and other engineering products can be as challenging as the initial design of the product itself.Typically testing, and therefore test case design, is performed at four different levels: Unit, Integration, System, and Acceptance.Section I describes typical black box testing techniques and test case designs in equivalence class testing,boundary value testing,decision table testing,pairwise testing,state transition testing,domain analysis testing and use case testing.Equivalence class testing is a technique used to reduce the number of test cases to a manageable size while still maintaining reasonable coverage.An equivalence class consists of a set of data that is treated the same by the module or that should produce the same result. Any data value within a class is equivalent, in terms of testing, to any other value.Test case designs are explained by case study of online website of brokerage firm.Boundary value testing focuses on the boundaries because that is where so many defects hide. Experienced testers have encountered this situation many times.If the system under test has complex business rules, and if your business analysts or designers have not documented these rules in this form, testers should gather this information and represent it in decision table form. The reason is simple. Given the system behavior represented in this complete and compact form, test cases can be created directly from the decision table.State-Transition diagrams direct our testing efforts by identifying the states, events, actions, and transitions that should be tested.Test case designs based on state transition tables is explained by example of airline reservation system.Under white box test designs,control flow testing and data flow testing are described.White box testing is more than code testing,—it is path testing. Generally, the paths that are tested are within a module (unit testing). But we can apply the same techniques to test paths between modules within subsystems, between subsystems within systems, and even between entire systems.Control flow graphs are the foundation of control flow testing. These graphs document the module's control structure. Modules of code are converted to graphs, the paths through the graphs are analyzed, and test cases are created from that analysis.Section 3 of the book describes scripted testing,exploratory testing and test planning.Scripted testing is based on the sequential examination of requirements, followed by the design and documentation of test cases, followed by the execution of those test cases. The scripted tester's motto is, "Plan your work, work your plan." Exploratory testing is a very different paradigm. Rather than a sequential approach, exploratory testing emphasizes concurrent product learning, test design, and test execution. The tester designs and executes tests while exploring the product.
Most of the information in this book was known to me based on my testing endevours.The book also describes IEEE 829 standard for test documentation.IEEE 829 defines eight different documents - Test Plan,Test Design specification,Test case specification,Test procedure specification,Release notes,Test Incident report and test summary report.