Rex Black

One development engineer told me that he “felt very depressed” after reading the risk analysis documents my test staff had prepared. I find it more depressing, however, to ignore the possibility of failure during development, only to live with the reality of preventable failure after release.

The non sequitur interview involves asking some question that seems to be analogous or related to testing. The classic example is, “Tell me how you would test a salt shaker.” I find this silly. I call this a non sequitur interview style because it does not follow that, just because someone can craft a clever tale about testing simple real-world objects, they can test complex software and systems. You are hiring a test professional, not a raconteur.

I sometimes hire people whom I think will grow into a job, but I never hire people I think are trying to con their way into a job.

People, regardless of where they are, are not widgets. They want responsibility. They want respect. They want to be valued. They want us to be interested in developing their skills and their careers, even if they work for a third-party contractor. They want feedback.

The most dangerous kind of wrong is the kind of wrong that sounds reasonable, as I've said elsewhere in this book.

That said, professional pessimism differs from obnoxious behavior. A tester should focus on catching bugs in the product, not on catching the project team member who might have introduced the bug. Furthermore, the tester must be sensitive to the possibility that a developer will see negative test results as a personal attack. Pointing out specific flaws in a balanced, fair way is helpful. Attacking the product categorically and in general terms is not.

Slothful test engineers force their colleagues to carry their weight.

I find that doing this skills analysis on a spreadsheet is nice. I like the measurement of skills at the individual and team level, although it is admittedly subjective and of limited precision. This makes an excellent hiring tool, as you'll see in a minute. I can also set goals for team skills growth as part of a quarterly team skills assessment, and then use education, training, and task assignment options to help the team and each person on it grow their skills over time.

I believe in building teams of testers where the engineers are at that level, and I believe in paying them at that level, too. If a senior software engineer in your company makes $100,000 per year, say, then a senior test engineer with the same number of years of experience, education, and training should make that amount, too.

Of course, some wags have told me that, if you schedule enough audition interviews, you might never actually have to hire anyone, but I don't recommend audition interviews as a primary testing technique!