Software Project Plans: A How To Guide for Project Staff
Every software project carries a quiet, persistent anxiety: the fear that something has been missed. A feature quietly broken. An edge case never tested. A handoff poorly documented. The consequences range from embarrassing to catastrophic - and yet, in project teams around the world, testing documentation remains the discipline most likely to be improvised, deferred, or quietly abandoned under deadline pressure.
Software Test Plans: A How-To Guide for Project Staff exists to close that gap.
Grounded in the rigorous framework of IEEE Standard 829 - the gold standard for software test documentation - this book does something rare in technical literature: it makes a complex, multi-layered standard genuinely accessible. David Tuffley distils the full apparatus of professional software testing into a practical, clearly structured guide that any project team member can follow, whether they are a seasoned test engineer or a developer writing their first formal test plan.
The book maps the complete documentation lifecycle of a software testing program. It begins with the Test Plan itself - the governing document that defines what will be tested, how it will be tested, by whom, and by when. From there, Tuffley walks readers through each document in the testing suite: the Test Design Specification, which translates strategy into specific test scenarios; the Test Case, which pins down inputs, expected outputs, and pass/fail criteria with precision; and the Test Procedure Specification, the step-by-step operational guide that sits in a tester's hands during execution.
The book then turns to the accountability trail - the documents that prove testing actually happened and record everything that went wrong. The Test Item Transmittal Report governs what enters the test environment. The Test Log captures events as they unfold. The Test Incident Report formalises the investigation of anomalies, triggering corrective action. And the Test Summary Report closes the loop: a management-facing synthesis of results, variances, and quality assessments that gives leadership the evidence they need to make confident release decisions.
Throughout, Tuffley is careful to anchor each document in the software development lifecycle - explaining not just what to write, but when to write it and why it matters at that precise moment in the project. The result is a guide that reads less like a standard and more like a conversation with a knowledgeable colleague who has seen what happens when documentation is done well and what happens when it isn't.
The definitions section alone is worth the price of admission. White box testing versus black box testing. Bottom-up versus top-down strategies. Integration testing versus system testing versus acceptance testing. These distinctions are explained with clarity and economy, giving readers the conceptual vocabulary to participate meaningfully in testing discussions at any level of the organisation.
What separates this book from dry compliance manuals is its orientation toward the practical human reality of software projects: the project manager who needs a baseline for performance measurement; the quality assurance manager who must demonstrate process compliance; the test team that needs step-by-step guidance without extraneous clutter; the customer who must formally accept the product and needs evidence that justifies that confidence.
Software testing is not the glamorous end of development. But it is the end where quality is either confirmed or compromised. This book gives every member of a project team the tools to get it right - systematically, repeatably, and with the documentation to prove it.
Customer Reviews
ThriftBooks ® and the ThriftBooks ® logo are registered trademarks of Thrift Books Global, LLC
