Book Review of the Domain Testing Workbook

The Testing Domain Workbook is the most extensive and exhaustive work you will ever find on a specific testing technique (or related techniques if you include equivalence class analysis and boundary testing as the book does).

What I like best is the combination of academic background and roots combined with practical experience and industrial practice. All the concepts are presented in a simple and approachable manner with pointers to more details for those desiring more.

While the book appears daunting in size, it is only because of the extensive examples and exercises. The core of the book is very approachable and less than 100 pages. To gain mastery, working through the exercises is most useful, but you can do that over time.

Many practical aspects and considerations for testing are covered that are usually skipped over in broad testing surveys or short articles. For example, many books talk about different approaches such as risk-based, or pair-wise testing. Books may also cover the issue of combining values for a test, but Testing Domain Workbook walks you through the details and implications of what each approach entails when applied to combining values for a domain test. Further, it provides extensive guidance of when (in which context) the advice is most applicable (or not) such as:

If you’re doing system testing after the programmers have done extensive unit testing of their variables, it will be unnecessary and wasteful to do thorough testing of secondary dimensions.

The book incorporates many viewpoints, sometimes strong opinions, and pithy statements such as:

Boundaries are funny things. When people say “No one would need a value that big,” what they really mean is “I can’t imagine why anyone would need a value that big.” The world is often less constrained than the limits of our imagination.

The book is exacting and consistent in its terminology, but the reader needs to be careful to keep the concepts clear and distinct. For example:

Well-designed domain tests are powerful and efficient but aren’t necessarily representative. Boundary values are suitable for domain testing even if those values would be rare in use.

The best representative of the class is the one that makes the most powerful test.

So the best representative, most powerful, is not necessarily the most representative of typical values. The book focuses on boundary values and bug hunting so that typical values are unlikely to be used even though they are part of the domain. You need to use more than the one well-developed technique of this book as the authors themselves state. For example: well-designed scenario tests are usually representative but they’re often not powerful. To test a program well, you’ll use several different techniques.

You may become a better tester if you read this book. You will become a much better tester if you actually work through the exercises of the book.

 

Keith Stobie
Keith Stobie is a Quality Engineer Architect at salesforce.com who specializes in web services, distributed systems, and general testing especially design. Previously he has been at TIvo and for Bing Infrastructure where he planned, designed, and reviewed software architecture and tests. In Microsoft’s Protocol Engineering Team he worked on Protocol Quality Assurance Process including model-based testing (MBT) to develop test framework, harnessing, and model patterns. With three decades of distributed systems testing experience Keith’s interests are in testing methodology, tools technology, and quality process. Check out his blog (http://testmuse.wordpress.com) to learn more about his work.
Keith Stobie
Keith Stobie is a Quality Engineer Architect at salesforce.com who specializes in web services, distributed systems, and general testing especially design. Previously he has been at TIvo and for Bing Infrastructure where he planned, designed, and reviewed software architecture and tests. In Microsoft’s Protocol Engineering Team he worked on Protocol Quality Assurance Process including model-based testing (MBT) to develop test framework, harnessing, and model patterns. With three decades of distributed systems testing experience Keith’s interests are in testing methodology, tools technology, and quality process.

The Related Post

This article was developed from concepts in the book Global Software Test Automation: Discussion of Software Testing for Executives. Introduction When thinking of the types of Software Testing, many mistakenly equate the mechanism by which the testing is performed with types of Software Testing. The mechanism simply refers to whether you are using Manual or ...
There are many ways to approach test design. These approaches range from checklists to very precise algorithms in which test conditions are combined to achieve the most efficiency in testing. There are situations, such as in testing mobile applications, complex systems and cyber security, where tests need to be creative, cover a lot of functionality, ...
Differences in interpretation of requirements and specifications by programmers and testers is a common source of bugs. For many, perhaps most, development teams the terms requirement and specification are used interchangeably with no detrimental effect. In everyday development conversations the terms are used synonymously, one is as likely to mean the “spec” as the “requirements.”
March Issue 2020: Smarter Testing Strategies for The Modern SDLC
This article first appeared in BETTER SOFTWARE, May/June 2005. Executives and managers, get your performance testing teams out of the pit and ahead of the pack Introduction As an activity, performance testing is widely misunderstood, particularly by executives and managers. This misunderstanding can cause a variety of difficulties-including outright project failure. This article details the ...
Do testers have to write code? For years, whenever someone asked me if I thought testers had to know how to write code, I’ve responded: “Of course not.” The way I see it, test automation is inherently a programming activity. Anyone tasked with automating tests should know how to program. But not all testers are ...
The 12 Do’s and Don’ts of Test Automation When I started my career as a Software Tester a decade ago, Test Automation was viewed with some skepticism.
D. Richard Kuhn – Computer Scientist, National Institute of Standards & Technology LogiGear: How did you get into software testing? What did you find interesting about it? Mr. Kuhn: About 10 years ago Dolores Wallace and I were investigating the causes of software failures in medical devices, using 15 years of data from the FDA. ...
This is an adaptation of a presentation entitled Software Testing 3.0 given by Hung Nguyen, LogiGear CEO, President, and Founder. The presentation was given as the keynote at the Spring 2007 STPCON conference in San Mateo, California. Watch for an upcoming whitepaper based on this topic. Introduction This first article of this two article series ...
Let’s look at a few distinctions between the two process improvement practices that make all the difference in their usefulness for making projects and job situations better! An extreme way to look at the goals of these practices is: what makes your work easier (retrospective) versus what did someone else decide is best practice (post-mortem)? ...
Creative Director at the Software Testing Club, Rob Lambert always has something to say about testing. Lambert regularly blogs at TheSocialTester where he engages his readers with test cases, perspectives and trends. “Because It’s Always Been Done This Way” Study the following (badly drawn) image and see if there is anything obvious popping in to ...
  Explore It! is one of the very best software testing books ever written. It is packed with great ideas and Elisabeth Hendrickson’s writing style makes it very enjoyable to read. Hendrickson has a well-deserved reputation in the global software testing community as someone who has the enviable ability to clearly communicate highly-practical, well-thought-out ideas. ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe