How to Break Software: A Practical Guide to Testing [With CDROM]

by James A. Whittaker and Herbert H. Thompson

Book Overview

How to Break Software is a departure from conventional testing in which testers prepare a written test plan and then use it as a script when testing the software. The testing techniques in this book are as flexible as conventional testing is rigid. And flexibility is needed in software projects in which requirements can change, bugs can become features and schedule pressures often force plans to be reassessed. Software testing is not such...

• Format: Paperback
• Language: English
• ISBN: 0201796198
• ISBN13: 9780201796193
• Release Date: May 2002
• Publisher: Pearson
• Length: 208 Pages
• Weight: 0.70 lbs.
• Dimensions: 0.5" x 7.1" x 9.2"

Customer Reviews

Testing Techniques based on Empirical Research

This slim volume presents a series of testing techniques, dubbed "attacks", that target common software errors. The list is based on an empirical analysis of a large number of bugs found in commercial software by the software testing labs at the Florida Institute of Technology. Each attack is illustrated with an actual bug found in everyday software. The analysis and the examples are mostly drawn from Microsoft software.

Perspective is everything

I think that this is an exceedingly useful book.Most books that purport to be about testing are really about something else. They're generally about planning, or process, or mathematics, or graph theory. Often, they're about making models of software so that you can demonstrate that there are indeed jillions of paths through a given piece of software--hardly news to anyone who's bothered to think about it for a while. Sometimes they're about the underlying theory of the thing you're supposed to be testing, such as "Web applications" or "security". All of these are useful things to think about, to be sure. Many of these books are large, and this one is small. I would venture to say, though, that few books talk about actual bugs as much as this one does, and provide such entertaining, cringeworthy examples.This book is about testing, and it's about thinking about testing. It provides a set of theories of error, and follows these with worked-out examples of using those theories of error to find bugs in real software. What a concept.In some reviews of this book, you'll find pious pronouncements about process; you'll see one that complains that this book doesn't have anything about testing J2EE applications; or that this book somehow applies only to Microsoft software. Those reviews all represent valid points of view, equivalent to the valid point of view that Moby Dick is a book about a big fish. Some of the information presented is quite basic. Mind, as a tester, testing trainer, and user of software, I've seen a lot of software--a LOT of software--not Microsoft products, some written in Java, built with well-defined process... but some pretty basic bugs. Mission to Mars, anyone?Some reviews also seem to believe that there is One True Way to develop and test software. That may be true, though I doubt it. But either way, it's unquestionably true that the followers of The One True Way are in the extreme minority, and the rest of us testers have to live by our wits, work under pressure in chaotic organizations, and find important bugs quickly.The book inspired me to think about the way that I approach a piece of software that I haven't seen before. I know some things about the underlying operating system (whatever it may be); I know something about the way data is represented in binary coding systems (whichever one might be in use at the time); I know something about the construction of programs (irrespective of the programming language); I know something about the way the program interacts with humans and other software. I also know something about the way programs and programmers can screw up--that is, I know something about certain risks. As a real tester in the real world, sometimes that and the program are all I have to work with. Nonetheless, I can use those things to find bugs effectively. Besides, even if I do have a specification, it's invariably incomplete, or wrong, or out of date, or so thick as to be unreadable in the ti

If you really want to learn testing, buy this book.

This book is part of the new wave of testing books that challenge not only the conventional wisdom about test process, but also challenge conventional wisdom about how to teach and write about testing. People who prefer testing textbooks that preach paperwork and process will be shocked, shocked, to discover that there are a lot of us who think it's a tester's job to find important bugs fast. We want books that give us strategies for actually finding problems. Paperwork and process help some, but not enough. We need something more. We need test-designer-sits-down-at-the-keyboard know-how.As a test designer, myself (and a competitor of Whittaker's) I can certainly find things to nitpick about this book. But I won't do that here, because the big picture is far more important. That picture is simply this: if you are confused about what to do to uncover problems in software before it ships, EVEN IF you have no specifications to test from and EVEN IF no one listens when you rant about "quality assurance processes" they should follow, then there are only a few testing books yet published that will help you. This is one of them.

The Best Practical Software Testing Book on the Market

"How to Break Software" will guide you through the art of breaking more than just software. You will break into the thoughts of how to find amazing bugs in some of the world's most used applications and along the way you will learn how to find amazing bugs in the software you test everyday.The practical knowledge gained by reading this book will have developers listening to your insight the next time you file a bug report.

More serious than the title implies - excellent book

Don't let the title or description fool you into thinking this is a book about ad hoc playing with applications with a goal to break them. In reality the book gives a structured approach to finding vulnerabilities in software. These vulnerabilities are weak points commonly found in software, and should be included in any test suite.The vulnerabilities are classified by a fault model, then the book systematically walks you through the procedures used to attack and break the software. Each vulnerability type is addressed:User Interface- inputs and outputs, with 6 attacks for breaking common input flaws and 4 for output flaws.- data and computation, with 3 attacks against stored data and 3 against computation and feature interaction.System Interface- 3 media-based and 3 file-based attacks against the file system.- how to test the application/operating system interface.The book also comes with a Windows application that helps you to create the hostile environment with which to 'attack' the software being tested. Therein lies the sophistication of the book, which employs fault injection as a technique. This technique is not commonly used in any but the most advanced testing environments, which raises this book's credibility from ad hoc to a serious approach to software engineering. More importantly, it provides test professionals, especially those who are testing Windows applications, a catalog of common vulnerabilities to address. More importantly, it teaches test professionals to approach parts of the testing process from an exploitation point of view - after all, their job is to break the software.My initial misgivings about this book vanished as soon as I started reading it, and were replaced by enthusiasm by the time I was finished. This book addresses a niche topic, but deserves a place in every software testing library.