Jason Gorman is an interesting guy, and has a lot to say. I agree with lots of it, especially his iconoclastic position on agilism. This time, I’d like to disagree with two paragraphs in a recent blog entry. The second one first.
But I suspect in 5-10 years’ time, as test-driven development becomes more popular and teams become more ambitious in their testing efforts, test developers will be in great demand and will be able to command high salaries. I see them becoming as important as architects are viewed as today. Maybe more so, since they actually add value on a project 😉 (Only kidding)
This seems to have been coming up a lot, so I’ll say it here: I’m agnostic about architects, but testers don’t add value to a project; as James Bach suggests, testers help to defend the value that’s already there, or help to identify ways in which value may be lacking. Testers raise questions and make observations; the people who make decisions based on those observations are the ones who add value. We help them do that, but we don’t do it intrinsically on our own.
Realistically, you must be a developer before you can become a test developer, since learning how to create high quality code takes longer to master than learning how to write effective tests. That’s not to denegrate the discipline of software testing: anyone who’s read Robert Binder’s book on Testing Object Oriented Systems will know that, if you wanted to, you could dedicate a lifetime to understanding testing. But, let’s be honest now, it takes longer to learn how to code from scratch than it does to learn how to break code*. (* Is that my inbox I can hear filling up again?)
Well, first, testers don’t break code; the code was already broken when it showed up. (I think I heard this first from Alan Jorgenson.) That’s a fairly trivial objection, though.
The more serious problem is with the assertion that “learning how to create high quality code takes longer to master than learning how to write effective tests”. Testing is not merely a matter of writing test code. Testing is about questioning the value of a product and the potential threats to that value. It takes the better part of a lifetime, I think, to understand value. Every time I think I have a handle on that, someone or something comes along to teach me another lesson in humility. But until we’re sure we’re able to ask the right questions about value, I’ll contend that we can’t know the right answers to whether our code is of high quality or not. By that reckoning, let’s be honest now: learning how to create high-quality code and learning how to question should be inseparable. It’s a rare person who can do either one very well, and even an even rarer person that can do both very well. That’s why we need developers and testers—and why we tend to need a few of each.
Testers may not add value directly to projects, but I think testers do add value to projects indirectly, by doing exactly what you described.
IMO, considered questions are of great value to a project, or at least they can be – something akin to unrefined ore, which the developers need to then refine into actual value for the product.
Looking at it from a slightly different angle, if you don’t “defend the value that’s already there, or help to identify ways in which value may be lacking”, then that value that already exists could diminish.
As for the second point, I agree that good programming skills are not required for testing (though I’m definitely biased, since I’m a tester with relatively basic programming training). End-users are usually not programmers (unless you happen to be working on a programming tool), and so there is definitely worth in having someone who is technically proficient in a general sense, but can still put themselves in the “beginner’s mind” with relative ease.
Michael,
You are correct. Testing is much more than writing test code.
In the book Jason referenced, Robert Binder states “Manual testing, of course, still plays a role. But testing is mainly about the development of an automated system to implement an application-specific test design.” I wholeheartedly disagree with this statement, and I make a living developing automated systems for testing. This idea that testing is more about developing programs that exercise other programs seems to be growing in popularity. I often see this thinking in Jason’s writing. (I also like some of what Jason writes.)
I hear this in Bob Martin’s statements about manual testing being immoral. I hear this in Ken Schwaber’s reference to “QA” as people doing incredible things in a “hopeless profession”. (I have also heard both praise good testing by skilled testers, but those aren’t the things I often hear repeated.)
All too often, I hear and read the words test and testing being tossed around with the assertion that all things called tests are the same, and are therefore interchangeable. If all things called testing are equal, then I would be the first to lobby for replacing skilled testers with developers than can create code called tests. TDD may be a great tool for helping developers build whatever they decide to build, but it is not the same a testing focused on providing management with information about value. These are very different things.
Developers create. Testers critique. Good developers test what they create. The Agile and TDD emphasis on developers testing their own work is wonderful. I agree with Jason that a developer that is good at testing their own work is more valuable than one that is not so good at testing. However, the ideas that code-centered TDD can replace value-centered testing by skilled testers is bad.
Testing is much more than exercising code. It is about finding and communicating useful information about value with limited time and resources. At the heart of good testing is a thinking person that questions the software and the people designing and building the software. The tools of testing are secondary.
It is difficult for a single person to be both creator and critic. These require different skills and focus.
As a teenager, I created a software management program for floppy disk based computers. I was proud of my creation. My creation took advantage of new technology and had features that similar products did not have. I tested my creation. I refactored my code many times. The code was clean. The program was fast. I used my creation on a daily basis for over a year. I shared it with close friends. I thought I had created something really cool. I submitted my creation to a company that was soliciting programs for publication. My baby was rejected. It was not rejected due to being poorly designed, coded, or tested. It was rejected because it was deemed to not be of value to enough of the publisher’s customers. I may have discovered this earlier if I had requested input from more than my closest friends.
Just like an American Idol contestant that can’t sing, we can save ourselves time, money, and embarrassment if we solicit the input of good critics before the world is watching.
I want great developers that can create beautiful music on my development team. I also want a few Simon Cowells and James Bachs to let us know when we may be fooling ourselves.
Ben
http://www.QuestioningSoftware.com
Thanks, Ben, for your wonderfully worded post.
If we’re uncertain about the reliability and value of code, writing more code seems like a highly fallible and paradoxical way to resolve the uncertainty.
I wish more people would treat automation as a tool and as a heuristic, rather than a panacea. But it’s like hammers and nails; to a man with an IDE, everything looks like a programming problem.
This whole thread shows the importance of language in the testing business. Well, in the whole software business.
First of all, when you lump dozens of activities under one word, “testing,” you’re bound to create fallacies with almost every sentence you utter. For instance, on the question of whether testers need to be skilled developers (as if develop means only one thing). I can certainly think of circumstances where a particular type of test requires a skilled developer to construct that test. So, yes, testers need to be skilled developers.
But wait, I can think if dozens of other tests that don’t require a skilled developer. Whoops, sorry, testers don’t need to be skilled developers.
My point? At some level of semantic mushiness, questions posed are meaningless, so their answers are meaningless. What do we mean by our words? What is the context in which we are using them? Come on, fellas, we’re not all sophomores any longer.
How about we stop this silly game of “my thing is bigger than your thing” and start trying to produce the same kind of precision in our language that we strive for in our software?
It’s been a while since this post was written but I stumbled over it only today.
Michael wrote:
It takes the better part of a lifetime, I think, to understand value. Every time I think I have a handle on that, someone or something comes along to teach me another lesson in humility.
These to sentences make me a bit curious. During the last few weeks I read some blog postings and mailing lists that say, and I agree with that, we’re reporting information to our managers on risks. To report the “correct” risks we should have been sent on the testing mission with certain objectives. If I assume that these objectives are the value everybody is talking about, why should we try to understand and not just take the informtion that is handed down to us and consider it as the value we are looking for.
Less thinking (on unimportant things) and more testing.
Markus: To report the “correct” risks we should have been sent on the testing mission with certain objectives. If I assume that these objectives are the value everybody is talking about, why should we try to understand and not just take the information that is handed down to us and consider it as the value we are looking for?
That’s a good question. The answer, I contend, is that there’s an additional service that we testers offer. It’s not merely our job to report on the risks that we’ve been told about. It’s also our job to identify and report risks that our clients may not have considered or realized at the inception of the project. Through the course of the project, everyone learns–developers, testers, clients, and all of the other members of the project community. As the product story develops, new characters and new plot lines emerge.
Our initial mission informs our actions, by all means, but our mission, our context, and our choices all evolve over time.
Less thinking (on unimportant things) and more testing.
I agree. But we must also remember that what’s unimportant (or unknown) today might become supremely important tomorrow.
I am a developer myself but I always suggest to testers that when confronted by an intransigent developer, one should say:
“Any monkey/vermin/microbe (put your own less-than-holy entity here 🙂 ) can write code that doesn’t work. It takes a significantly intelligent being to test that same code.”
Choose wisely your level of abuse before you choose your less than sentient being, and abusive language 🙂
Paul.
Good post.