Book Image

Software Testing Strategies

By : Matthew Heusser, Michael Larsen
Book Image

Software Testing Strategies

By: Matthew Heusser, Michael Larsen

Overview of this book

Software Testing Strategies covers a wide range of topics in the field of software testing, providing practical insights and strategies for professionals at every level. With equal emphasis on theoretical knowledge and practical application, this book is a valuable resource for programmers, testers, and anyone involved in software development. The first part delves into the fundamentals of software testing, teaching you about test design, tooling, and automation. The chapters help you get to grips with specialized testing areas, including security, internationalization, accessibility, and performance. The second part focuses on the integration of testing into the broader software delivery process, exploring different delivery models and puzzle pieces contributing to effective testing. You’ll discover how to craft your own test strategies and learn about lean approaches to software testing for optimizing processes. The final part goes beyond technicalities, addressing the broader context of testing. The chapters cover case studies, experience reports, and testing responsibilities, and discuss the philosophy and ethics of software testing. By the end of this book, you’ll be equipped to elevate your testing game and ensure software quality, and have an indispensable guide to the ever-evolving landscape of software quality assurance.
Table of Contents (22 chapters)
1
Part 1:The Practice of Software Testing
9
Part 2:Testing and Software Delivery
14
Part 3:Practicing Politics

Waterfall

The term waterfall is most popularly associated with Winston Royce’s paper [http://web.archive.org/web/20230511154936/https:/www.praxisframework.org/files/royce1970.pdf]. Back in 1970, Royce observed that the simplest model for software delivery was code and fix. Code and fix is what it sounds like – write code until you see a problem (likely a compile error), then code some more. While we laugh at this, it could be an appropriate style for, say, a complex spreadsheet where the customer, manager, and programmer are all the same person. That style might also work for a first-year computer programming assignment.

By the 1970s, software development was a big enough business to have programs supported by dozens of people. IBM’s system/360, developed in the 1960s and 1970s, had hundreds of programmers on staff. Even for much more modest projects, managers started to ask what seem like reasonable questions, such as the following:

  • How much will this...