Rereading yesterday’s post, and also seeing some of the comments (and having some personal discussions offline), I can see that I might have inadvertently sent the wrong message:
My point is certainly not that testers just suck and everybody should just take some classes and apply for dev positions. My opinion is the absolute opposite of that! The software world desperately needs testers. The software test profession’s journalistic function is, in my opinion, absolutely essential to the health of software projects. As the world becomes more software oriented, the fate of civilization practically depends on the existence of great software testers.
Devs KILL testers at (bug bashes), 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.
How did anybody get the wrong impression?
I should have added some more words to those ideas. Here’s what I was trying to get at:
Coding can help you…
…by helping you find test oracles.
Let’s set a very, very broad definition of “coding.” When I say “coding” in the test domain, what I mean is “working at a technical level above that of your end-users.” Again, I want to throw away this notion of “testers are a dev team’s stand-in for an end-user.” It’s perfectly acceptable for all testers to know a lot more than their end-users. (They can learn all of the things, if they want to!)
Once you embrace that notion, there’s a lot to gain from a deep technical understanding of your domain and your product that might not look like “coding” but is not really black-box testing and wouldn’t make sense to your end-users. Knowing the DB structure of your data layer is a great example. If you can learn a few simple SQL queries, you can make yourself a lot more productive. Knowing how to read your product’s log files, knowing where to look for registry keys, using command-line tools to ping servers & restart services, that kind of stuff. I think that a great many testers who don’t think of themselves as coders are already doing this stuff; they’re further along than they think. If you can dig into your DB or registry to look for a bug, you’re already grey-boxing your tests.
…by speeding you up.
I think a lot of folks hear the term “technical tester” or “test engineer” and immediately think “test automator.” And test automation is a great tool for speeding up the delivery of information! But it’s not the only way that a bit of code can speed you up.
Or, put another way, there’s more to test automation than just automating tests. How much time do you spend a day configuring your environment and installing software? Could it be sped up by automating pieces of that? I brought up the example before of devs crushing testers at bug bashes. What exactly did they do? Well, in one case, a dev pointed a free link checker at a website and found 20 dead links… automatic win. In another case, a dev used Firebug to disable client-side form validation and made a bunch of web transactions that should have been impossible. These are things that a tester could do without writing a single line of code, but testers didn’t think of it. Think of ways that your computer can help you work faster. Then figure out how to get it to do that.
…by freeing you up.
This is where the automated regression suite comes in. If you are performing a set of manual checks over and over, make a robot do that and go do something more productive with your brain.
…by cluing you in.
Do you get notifications of check-ins? Can you do code reviews? This is getting to be a pretty high technical level and a lot of testers start to freak out thinking about this. Here’s an insight: Developers don’t always understand what they’re looking at when they sit down, either. If they’re doing code reviews (and it’s a good thing to try), see if you can sit in on them. They’re going to say a lot of stuff like “this part here is probably self-explanatory, this part here was already there, this part here I copied and pasted from StackOverflow.” DING DING. That third one is where you’re going to find a bug.
Sitting in on code reviews could help in other ways, too: They’ll help you on your journey in upping your skills, and the act of explaining the code to somebody might help your dev buddies think of things they forgot to consider.
…by improving code quality.
Unit testing is a tricky part of software development, doing it well is tough. As above, if you can sit in on a code review where unit tests are being explained, you’re going to get an opportunity to weigh in on what should be tested in the unit tests. There’s a lot of happy-path thinking in Unit Testing Land. It’s a perfect opportunity for a tester to bring up edge cases that the developer didn’t consider. “What if that directory is read-only?” “What if the device goes off the wireless network during this loop?” “Oh. Hmm.” Bug prevention at this stage is easy and it will make the code safer to change in the long run.
I want to emphasize that I think learning code will make you a better tester, it’s not that I think that all testers should just learn to be devs. Maybe in the future we’ll all have the same job title, maybe we won’t, but the testing function is critically important and coding can make you more effective in performing that function, whoever you are.