It occurred to me while I was at AWTA over the weekend that testing tools are like screwdrivers. There are different types for different problems (Philips and Standard or Performance Testing and Functional Testing), they come in all sorts of different sizes, and they all cost different amounts.

If you think of your average enterprise level automation tool, it’s similar to a mutlihead screwdriver. These tools offer everything under the sun (performance testing, functional testing, test management, defect tracking, data-driven technology, etc…) all you have to do is purchase the tool and start recording! They have a screwdriver bit for every type of testing you might want and several of the bits come in different sizes.

If you look at an open source tool, it’s more like a plain old screwdriver . It only has one head – so it only performs one specific task (like functional testing); and it only comes in one size (so it may only work with a specific technology like Java, .NET, or Internet Explorer). These limitations are often offset by the lower cost (notice I did not say free, someone still has to learn how to use the tool).

Now think about some of the problems you can encounter when using screwdrivers. The most common problem I encounter it that I don’t have the right size screwdriver the job at hand. Sometimes if I use a screwdriver, it’s to small and I can’t exert the force necessary to loosen the screw (common problem with open source tools). Other times it may be too big and I might strip the head of the screw (common problem with enterprise tools). If I own a multiheaded screwdriver, I might lose some of the bits (many companies don’t take the time to learn about all the things their tools can really do for them and thus invest in shelfware).

With this analogy in mind, think about the types of testing you do with your automation tools. Do you need a multiheaded screwdriver or just one right-sized screwdriver? I have been in situations where I’ve needed both. My last project needed a multiheaded screwdriver because I needed to provide and coordinate performance testing and functional testing for multiple platforms using multiple technologies. My current project only needs one or maybe two screwdrivers. We only use one technology an only support one browser.

What kind of screwdriver do you need?

This year I read numerous books on software testing. Over thirteen books had the words 'testing' or 'test' in the title. Of all of these, only four of them were really good books:

• Lessons Learned in Software Testing


• Test-Driven Development: By Example


• How to Break Software: A Practical Guide to Testing


• How to Break Software Security: Effective Techniques for Security Testing

Out of all thirteen, these were the only four I would recommend to someone who wanted to know about testing.

Most of the problems I found with the other books related to problems like the one I pointed out in Bad books on software testing. Things like universal statements about what testing is and what it should be. Or authors who list techniques for working in unrealistic project environments. Processes and documentation schemes that would make you cry if you actually implemented ALL of it. Or possibly it's the fact that most authors show little references to where their research comes from (if they have any at all). Finally, in the last few books I read I found an overwhelming amount of time spent with the waterfall development model (and subsequently the v-model).

So where is all the good information on software testing?

Not in books on software testing!

This year, the best books I read on software testing had nothing to do with testing. If you want a good book on the basics of exploratory testing, read Sometimes the Magic Works. If you want a book on performance testing, read To Engineer Is Human: The Role of Failure in Successful Design. Need to know more about usability testing, read The New Brain: How the Modern Age Is Rewiring Your Mind. If you want to become more effective in your role as a tester, read Amplifying Your Effectiveness. And if you want to be better equipped to understand your project environment, corporate culture, and the inner dynamics of your test team, read The True Believer: Thoughts on the Nature of Mass Movements.

I have concluded that most books on software testing are for people new to software testing. Of course this is purely anecdotal and based on the few books I have read (I do not claim to have an excessively large number of books on software testing).

I would however also point to a list of books recommended by Cem Kaner, James Bach, and Brett Pettichord. In Chapter Two of their book Lessons Learned in Software Testing, titled "Thinking Like a Tester", how many books on software testing do you think they recommend?

None.

They recommend:

• Tools of Critical Thinking: Metathoughts for Psychology


• Thinking and Deciding


• The Craft of Research


• Cognition in the Wild


• Theory and Evidence: The Development of Scientific Reasoning


• Proofs and Refutations : The Logic of Mathematical Discovery


• An Introduction to General Systems Thinking


• Discovery of Grounded Theory: Strategies for Qualitative Research


• Basics of Qualitative Research : Techniques and Procedures for Developing Grounded Theory


• Exploratory Data Analysis


• Conjectures and Refutations: The Growth of Scientific Knowledge


• Exploring Requirements: Quality Before Design


• How to Solve It


• Things That Make Us Smart: Defending Human Attributes in the Age of the Machine


• The Social Life of Information

Of all these books, only one of them could be argued to be a book on software testing.

With that in mind, I need some more good books on testing, and for the coming year I think I'm done reading books on testing. Can you recommend a good book? Please feel free to comment below.