More on the Coding Tester
Every day, it seems, I come across an article, a forum posting, a blog, or a tweet bemoaning the end-of-test-as-we-know-it because some company has hired / is hiring people with programming knowledge to become testers. I’ve written about coding-testers (here, and in other posts) before (as have many others that I’m too lazy to look up right now), and I think most folks recognize that /in some situations/, having testers who code is an advantage.
It’s important to note that the role of a coder-tester is NOT to automate everything (everyone knows that you should automate 100% of the tests that should be automated). Writing automation is one task of a coding tester, but certainly not the primary focus (yes, I know that in some companies, automation “experts” only write automated tests. In my opinion, these people are not really testers, so they don’t count).
I, my colleagues, and many of the best testers I know are good testers first (well, at least my colleagues are), but have programming chops that they can use to solve difficult testing problems. Automating a bunch of rote tasks (assuming robustness, accuracy of the verification, maintainability, and numerous other attributes) may be a difficult testing problem, but it’s just one testing problem. Good testers simply use the tools in their toolbox to solve the problems and challenges they run into.
My head isn’t in the sand though – I know that there are a lot of people hiring testers out there who are thinking, “I want to hire a bunch of coders to do my testing, because then they can automate everything!).” That, of course, is stupid, and I’m sorry that situation exists. If you run into these folks, feel free to send them my way, and I’ll be happy to explain a thousand other ways programming knowledge can help someone be a better tester, and why attempting to blindly automate everything is pure idiocy.
To be clear, I do not think that all testers need to have a computer science degree (remember, I have a graduate degree in music composition). I also don’t think testers must be able to program. It depends completely on what you want testers in your organization to do. It’s certainly possible to do great testing without using any programming skills – you just need to think about the role you want testers to perform (or what you want to call testing), and hire the people who fit that role.
On the other hand, I find it a bit silly to think that just because someone knows how to program, that they are somehow “tainted”, and will be unable to look at a program from the proper “tester angle” because they have a notion of how the stuff under the hood actually works. I’ve worked with a hundreds of testers who can code, and hundreds more who could not. In fifteen years of working with testers from both camps, I’ve seen no correlation of increased customer empathy or testing talent emerge from either camp. My study is only anecdotal, so if there are specific studies in this area, please point me to them.
A final thing to remember for anyone who thinks they’re somehow closer to the customer due their background (or lack of a background) is that you are not the customer. It doesn’t matter if you’re a former bank CEO testing a financial suite – you’re still not the customer. I think it’s critical to use whatever means you have to learn about the customer, or to understand the customer, but you will never be the customer. Regardless of the skills you (don’t) have.
Alan,
“… attempting to blindly automate everything is pure idiocy.” Nicely put, after all “It’s Automation, Not Automagic!”
And I have a degree in Zoology, and I know how to program and I’m a Tester.
“Good testers simply use the tools in their toolbox to solve the problems…”, yep totally agree with that one. Test tools are just that, tools. The real solution lies in the person using the tool and how they apply it to solve the problem at hand. We need to definitely use the “computer between our ears” first.
And I think there are basically two types of “testers”; business oriented and technically oriented. I fall into the latter category. But that is my opinion.
Hi Alan,
Excellent article! Automation is just one among the many skills required by a tester.
Apart from this we need to have problem solving skills, pattern detection, analytical and collaboration skills at workplace. I have also written an article on this at: http://technologyandleadership.com/key-takeaways-from-wta06-%E2%80%93-it%E2%80%99s-in-the-cards/
Regards,
Aruna
Great article. There are many types of testers – developers in test, customer acceptance testers, test tool experts, and so on – and the needs of the organization dictates which types are needed for different assignments.
Best regards,
Johan
The opposite is also frustrating, people who think because you know how to program, that you couldn’t possibly be interested in testing. “Really, why would you want to do that when you can program.”
It’s sometimes sad the boxes they tend to paint people into just because they possess on Skill. It’s like if I told you, I played the Trumpet in High School. You might assume I am still playing it. I’m not in fact, but the skill I learned reading music, comes in handy when singing in a group, or even Solo at a Church. Both are performance of music.
Maybe this isn’t such a great comparison, well here is another. I grew up in a town called Fort Ashby. When my dad was looking for work after being let go from his place of employment, he would travel and put in apps where ever he could. When he was in Charleston, he’d leave a contact number of the family member he was staying with. One time someone called, and my grandmother said, well he’s back in Fort Ashby.
The reply from the prospective employer, “Is he in the military?” I guess there’s an association that if your town of residence has the word ‘Fort’ in front of it, that it must be code for a modern day military installation. However, that was wrong in this case. Good article Alan, I enjoyed reading it.