Software Testing is not a craft

This weekend, while reading Whittaker’s book, How to Break Software, I came across the following quote:

“My conclusion is that testing is an intellectual endeavor and not part of arts and crafts. So testing is not something anyone masters. Once you stop learning, your knowledge becomes obsolete very fast. Thus, to realize your testing potential, you must commit to continuous learning.”
– James A. Whittaker, How to Break Software: A Practical Guide to Testing, 2003

Something about it stuck with me through the weekend and I found myself thinking about it while pondering the next workweek, while cleaning and while watching the Superbowl. Software testing is not a craft. I thought of the techniques that one can learn and become an expert at applying in different scenarios. I thought about the intuition testers develop about where bugs are lurking and about the practiced critical reading of requirements documents. It seems like a craft. A skill you can hone in on, develop, improve and apply. I imagine expert software testers settling in to that calm space that I suppose a master craftsman enters when beginning a project: a sphere of control, understanding for their role.

But then, I thought of some of the best testers I have known. They are the ones who never learned “how to test” but rather learned the theory of how to approach testing. Their great knowledge seemed to fuel different techniques depending on what they were testing. They were often the first ones to come up with a new solution. They were often the most excited about their work, most adept at finding issues and most importantly, the most genuinely invested in making the software better.

Then I understood- good testers try to master their craft- try to learn the techniques and apply them correctly and diligently to every project with the care and skill of a craftsman. But great testers are the ones who never plan to master anything. Instead they approach each project as something new to solve, based on their previous knowledge, sure – but as something new that must be actively perused to be understood. That pursuit – not of mastery, but of knowledge and application – is the difference. The approach to testing makes all the difference between verifying correct behavior and seeking out bugs. Changing the way you think about what you are trying to achieve changes the bugs you find.  So of course, changing the way you approach learning about software testing will change what you achieve- mastery or the continuous pursuit of improvement and knowledge.


One response to this post.

  1. Partially I agree with you. Testing and mastering software testing is a life-long pursuit. What the software craftsmanship movement made clear in their postulate is the fact that learning software development as a craft is also a life-long pursuit of learning and exchange among the community. So, I would say to that definition of craft does software testing as well apply – to yours obviously not.

    What I learned recently while studying “On the cruelty of really teaching computing science” from Edsger Dijkstra is the fact that most of these analogies may help the brain to cope with the understanding, but they don’t help in general. Craft just like engineering are to some degree a valid analogy, but not in general, to software development (programming, testing, delivery). This is the essence that we need to understand.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: