The Watir Podcast Episode 65 – Cheezy’s Return

Jeff Morgan, AKA Cheezy, comes onto the Watir Podcast to discuss the new release of his Page Objects gem, his Fig Newton gem, Data Magic gem, Service Mock gem, and agile.

Book Review Pt2: Black-box testing: techniques for functional testing of software and systems

Chapter 1: Introduction

This chapter introduces testing purposes, roles, and methods.

The first thing that hits me are the definitions. Is this book like 20 years old or something? The Performance Bug and Security Bug definitions have grey hair. I like how Dr. Beizer dances around the unit, component, and integration tests. I can now understand it as well as I’ve ever understood it – but I won’t try explaining this to a child because they’ll tear me apart. People don’t try to break software anymore. They find where it’s already broken, it’s weaknesses, and it’s limitations. Otherwise, I generally agree with the definitions.

I agree with the numbered reasons for testing software. Most of these reasons can be incorporated into a cucumber scenario. The “penultimate objective” implies that using some kind of find-rate will help make a decision about readiness – I disagree because it could be a problem with the pesticide paradox.

In the Test Strategies section, test strategy is so much more than test techniques. I’m surprised to see them treated an synonyms. But there… BAM! Behavioral testing IS black box testing. I also like that the author doesn’t assume that unit tests are white box tests – one could test units and methods without knowing the code within them, only the promise of the interfaces.

I noticed that when the author talks about the progressive cost of testing units, to components, to integration, to system testing, he leaves out that the biggest cost of those bugs found late are because the time passed since the bug’s introduction is greater AND the number of people involved in repeating past work is higher (building, deploying, and possibly releasing).

In the testing isn’t everything section, I am wondering what happened to Formal Inspections. I’m fully trained in them, though I haven’t participated in one since probably 1997. I like how he says don’t try to justify automated tools as if that ever worked. I hate to do it but I have to do it.

The process section seems pretty old school as well. Old fashion we must have group discipline vs. current day we must have personal discipline. Or maybe I’m just remembering the command & control days poorly, and the short-cuts of today as not poorly enough.

I did not love this chapter. It’s basic and out of date. If I were to teach this chapter to younger testers/developers, I would focus on what has expired, and what replaced it. Then I would ask for reflections of what the students wish we had retained from the days this book was written.