EDIT: Some points in the comments made me want to clarify some of what I’ve said here. A follow-up post is here.
I’m a tester, and I’m learning to code. Why? Do I intend to apply for a developer position?
I get that question all the time. It’s a tough one to answer. Since I don’t intend to apply for a developer job, my profession does not expect or demand that I go outside of work, buy a bunch of books, read a bunch of websites, and code long into the night learning how developers do what they do. Why would I do that?
Two Videos That Inspired Me
I saw two videos around the tail end of 2011 that opened my eyes to who I was in my industry. These videos made me want to change my job, to change how I work:
The first one was meant to be provocative. James Whittaker’s STARWest keynote All That Testing Is Getting In The Way of Quality was quite an eye-opener, as it was meant to be. If you’re a tester and you haven’t seen it, now is the time, watch it today. I admit, I remember walking away from watching it and telling somebody that the short version was “People at Google forget that a world exists outside Google,” but still, two ideas stuck:
- At Google, all developers can test, and all testers can code.
- A bug report is a waste of time. If you understand a problem why wouldn’t you just fix it?
The 2nd video was not meant to be provocative, and was not even a communication meant for testers. I recommend Erik Wolpaw’s Portal 2 discussion at NYU to anyone in the software industry, just for entertainment value and to see how Wolpaw’s passion and vision translated into an actual fun product. But from the testing perspective, Wolpaw had a comment I found really interesting: Somebody asked him if he had one piece of advice for game designers, and it was “learn to code, it can only help.”
Learn to code. It can only help. Really?
Two Things That Aren’t True
“It’s better if testers don’t have knowledge of the code.”
This is just bullshit. It’s the most delicious kind of bullshit, though! It’s self-serving to those that say it *and* to those that hear it. I’ve heard it from the mouths of lead devs, lead QAs, build engineers, executives, everyone. The value QA adds is that they don’t know how the code works.
I wonder whether, deep down, anyone really believes that.
Devs like this idea because they hate context-switching; testing isn’t coding and they’d rather just keep coding. They’d rather have somebody else do it, and they can rationalize it by saying that, hey, if we’re paying this guy to do testing he must be some kind of testing expert.
QAers like that idea because it’s like they magically got a skill when they got the job. Here you are, working in a technical discipline with little or no prior training, and your lack of a technical background is something that your organization… values…?
Nope. No. I refuse to work in a discipline where the thought is that I would become less valuable to my organization if I learned more about what my coworkers are doing. Ain’t nobody got time for that. And I don’t believe that any of my coworkers would consciously agree with that sentiment, either… not realizing that the sentiment is implicit in the statement “It’s better if testers don’t have knowledge of the code.”
“Devs just don’t know how to test well.”
I can forgive people for thinking this. As above: if you’ve got a room full of software engineers and two guys whose job it is to test their software, it’s natural to assume that those QA guys know something the devs don’t. Especially because those QA guys find bugs. The devs missed the bugs. QA found the bugs. Ergo, QA is better than Dev at finding bugs.
It’s not the case. Some people are naturally good at testing and some people are not, and everyone can get better through learning and practicing. This is equally true for testers and developers.
I say this without judgement, as I am a deeply lazy person myself: people are fundamentally lazy and tend not to do things they don’t enjoy. If devs are satisfied that someone else is going to find their bugs, they will not work hard to find them themselves. But here’s a funny thing: an average developer that devotes all of his or her attention to testing for an afternoon is more likely to find an important bug than an average tester on the same team.
That’s a bold statement, but I know it to be true. The reason I know it is that I’ve coordinated a lot of coordinated testing activities (“bug bashes”) company-wide over the past several years. These are usually laid out as competitions where people get points for finding good bugs. Devs KILL testers at these things, 100% of the time. So does UX. So does Docs. WTF?
How is this possible? Isn’t there some “testing body of knowledge” that QA knows but devs don’t? No, not really. At least, I haven’t witnessed such an animal. Sure, there are some cool techniques that we employ on my team (SBTM, soap opera testing, mindmapping etc) which QA brought into the organization, but I can explain all of them to you in an hour and then you can use them or not at your own discretion, be you a tester or a dev. There’s nothing magical about them, they’re just a couple of sometimes-effective things that people should try.
Ok, Debbie Downer, thanks a lot. *kicks dirt*
Ok, testers, this seems bad. Pretty dire. But it’s not a problem, it’s an opportunity. The software-making profession has a need, and you are the one to fill it! Because, with all that I’ve written, here’s something else: Making great software is extremely difficult. It is next-to-impossible to get it right. There isn’t time for people to worry about artificial, useless distinctions between roles like “developer,” “designer,” “tester,” etc. Everyone should be firing all of their neurons at this extremely difficult problem, and contributing everything they can in the smartest way they can think of.
Let’s say your team isn’t building an app, it’s building a house. You, the tester, are in charge of making sure that the house is right when it’s done. Do you wait until the house is mostly done, then walk in and start telling people to fix things, that they missed a spot? No. Don’t be an inspector. Inspectors are antagonists, they’re not on the team. Whose job is it to make sure that the inspection passes the first time? It’s one of the builders. One of the builders understands what it takes to make the house pass inspection, and is there every minute helping people do what they need to do to get it right. That’s you. You are that guy. Be that guy.
On a software team, that guy can code. The people around you want to make great software and they need your help to do it. You can contribute a lot more by pitching in than you can by telling them that they missed a spot. The more you understand about how software is built, the more you can contribute. Learn to code, it can only help.