If Your Test Leaders Aren’t Telling You To Write Code, They Are Lying!
Even if it’s by omission.
There’s this argument, almost daily, about whether software testers should learn programming. I’ll jump right in. It is unimaginable that someone would tell you NOT to learn something. That’s the first, and probably shittiest lie that inexperienced testers get fed. It’s further unimaginable, and downright irresponsible to tell people not to learn something that is very clearly where a large, well-paying, and above all interesting part of the industry is heading. Wanna work on innovative, data-driven projects with smart and driven people? You probably need to pull up terminal and at least get your toes wet, y’all.
The worst part of the lie is that it imposes that coding is a difficult grind and will only cause more problems than it solves. I even saw Alister Scott’s blog post referenced as an argument against coding, ironic as it is.
It’s not easy, I’m awful at it, but no one is saying you have to write prod code on day one (or ever!) — you start by learning just like you start learning everything else, but my experience has been positive. Here are some things that happened:
- Last year my team won HomeAway’s hackathon. I had a really good idea so I got to assemble a superstar team with a couple of architects, a great designer and some Sr. ad & marketing people. It was an all-star cast, and we won the whole thing and five grand. This year I re-entered as a jokey reinterpretation of the same concept and built more or less the same app, but this time completely on my own (no cheating off the old codebase). Here’s what I learned: I learned how the front end (that I test) connects to the backend in a very real, hands on way. I learned how the new version of our in-house bootstrap affects the front end (that I test) before it was even implemented. I learned that all the listing types (that I test) times number of migrations means a headache. And I learned about a bug in the same search page that… I test. Just understanding what’s going on helps me learn about the vulnerabilities in my code, it helps me understand what challenges developers face, and all because I get to see, and solve problems on my own. It helps me figure out where and how bugs manifest, and ultimately get better information into dev hands. That’s kind of cool.
- People want to help. Throughout my 4.5 years in working with developers, I haven’t been told “NO” when I asked someone a question. I got asked if I’ve googled it, or whether I looked on Stack Overflow a few times, but I’ve never been told no. Mostly I think it’s because I work with nice people, but if you think about it, you probably do too.
- You don’t have to write feature code. Because some managers think of test code as a second class citizen, their reports think of learning to write code as if it’s a one way ticket into dev ranks. Sure, some take advantage of that, but many might outright not want to go into development, and others might think they don’t have what it takes. It’s fucking scary but it’s also not true. Start with writing enough code to make your repetitive tasks fast so you can concentrate on what you are good at; the cognitive stuff.
- A developer and a test engineer writing code side-by-side are benefiting from a codebase that is testable, and tested from the beginning. How cool would it be to recognize each other’s strengths, and how do you not absorb knowledge and understanding from working with someone who is an expert at it.
- Even my limited skills, I write deploy scripts, checks, and now I’m writing feature code for a UI A/B test. Not because I want to be a “developer”, but because I’m curious and I see it as a challenge. Are you curious? Do you like a challenge?
And yes, some people will use a job in Test to get into development. And no, you don’t have to! Forget this misconception; it is not “all testers are now developers”, but it is “all team members have to support the ultimate goal”. My team’s goal is to release good code every day (four times a week). What is your team’s ultimate goal? How are you helping them get there with quality code? And how can you get better at it?
Is the above true for all industries? Perhaps not yet; but as more teams accelerate, our roles will keep on changing across the board. As responsible professionals, it is our duty to be at the forefront of that change. To shape and drive our direction, and not merely be the grumbling consumers of absolute truths passed down from business & development teams.
On a personal level, the attraction of software testing is the promise of going against the grain, of exercising curiosity through investigation, of questioning the status quo and finding strength in analytics. We are already engineers. We are already problems solvers. Let’s start playing to those strength and helping ourselves.