testing

Most test tools come bundled with vendor-specific scripting languages that I call vendorscripts. They are hard to learn, weakly implemented, and most important, they discourage collaboration between testers and developers. Testers deserve full-featured, standardized languages for their test development. Here's why.

You've had to explain and justify your job to Management, to Human Resources, and to everyone at your high school reunion. But now comes the ultimate test: Your child's assignment for the next show-and-tell is to describe what her mom or dad does for a living. You scramble for an easy way to explain—maybe for the first time—what you do at the office, but your software testing reference books just don't have enough pictures of cute animals to really do the trick. This book might be just what you're looking for.

This column asks the all-important question, "What isn't there that should be?" The same idea for spotting black holes also applies to spotting "holes in designs and requirements." For example, there are often connections between the quantity of bugs filed against an area and whether the area is thoroughly tested. There can also be holes in what KIND of bugs have been reported. Hendrickson lays out the territory for the search and goes on to suggest how to "look for where there's a lot of nothing."

You're a test manager. But do you manage only the testing? A frustrated test manager recently said, "With my SQA hat, I want to focus on finding defects and discovering risk in the product. With my support hat, I want to solve problems. With my tech pubs hat, I'm trying to get the documentation written. But last week, everyone needed my help at once. I'm only one person—how the heck do I do all that?" Well, maybe you shouldn't have to.