Looking beyond the titles (and an explanation of my QA CAN'T CODE movement)

In every facet of my life, I'm a self-proclaimed "jack of all trades, master of none". And being a jack of all trades often goes hand in hand with being a fast learner. While there are many people out there who identify their skills and abilities, and hone them to be a master of their craft, I am not one of them. However, I have always believed that this has actually been a key factor of my success in software testing. I have had experiences in software and hardware, script-directed manual testing and self-directed exploratory testing, planning testing and executing testing, reading and yes, even writing code. 

I have written at least some code in over 12 programming languages. Couple that with exposure to various frameworks at work, attending workshops and doing projects in my spare time and I'd say I have at least a basic level of understanding of some programming concepts. But I bet most of my coworkers don't know this about me. And why should they? - I am, by current title, a "Software Quality Assurance Specialist" and to most people that means I am a blackbox, manual software tester.

That is not their fault. It's a labelling issue. It's a perspective issue. Dare I say, it is a stereotype issue. I almost feel as though the industry has done a disservice by adding modifiers and variations to the title. Quality Assurance Developer, Software Developer in Test, Test Engineer - what do all these titles have in common? They perpetuate the belief that "typical QA can't code". And herein, I believe, lies the problem. 

If I am a Software Quality Assurance Specialist*, then I believe my specialty is anything that can help contribute to the quality of the product. 

This spans a far wider range than functional testing of features and products. If you look upstream in the development process, this means advocating quality in design meetings and helping build testability into new features. If you look in the "middle" of the development process, this could mean smart functional testing of the product or tool development to ease the workload with scripts or other tools. To me, smart functional testing means testing complex scenarios and applying automation where automation is best suited. Looking further downstream, the responsibilities could include being involved in the support process to analyze escaped defects, close the feedback loop and iterating over the whole testing process for constant process improvement.

I'm not advocating that every member of the test team should have all of these skills - that would be a little too Agile Utopian. But if you're a tester, building up your skills toolbox never hurt. So it would be wise to keep in mind the full range of areas where testers can contribute, and seek to improve skills across those areas. Then work your ass off to apply the skills within your current team, so that the rest of the team is aware you possess these awesome skills! I'm sure it will net you new and exciting challenges, more respect from your team members and leaders, and a bump in product quality (which surely no one is going to complain about).

I once volunteered to write an in-house tool that plugged into another system being used, in a language I had zero experience with. It was desperately wanted, but no developer time could be spared on it. I whipped up the tool, learned a new language in the process and in the eyes of management, "saved the day". Suddenly, that "Quality Assurance Developer" title I had been asking for was granted, and I was being given more time to work on tools, automation initiatives and more!

Anyways, the point is that titles mean nothing - so don't let the lack of a "developer" title stop you from learning to code and finding ways to apply that. In a previous post, I revealed that I've chosen to use the phrase "QA CAN'T CODE" (ironically, of course) - because QA can and should code, among many other things.



*Despite being a Software Quality Assurance Specialist, I typically don't associate with the term "QA". I usually try to refer to myself as a Software Tester.

A rant - QA CAN'T CODE

So...this is happening:

I've heard it too many times. So now I plan to wear it in irony. There's this notion that lingers and hasn't been dispelled yet - one that perpetuates the belief that "QA can't code". 

I'd like to send two messages with this simple statement.

1. This is a push for a re-branding. I am not a fan of the job title QA (aka "Quality Assurance"). I've said it before - "I don't assure quality; I test software." Maybe quality inspectors can't infact write code, which is fine. But then I don't want to be a quality inspector.
2. This is also meant to be an ironic statement to spark a discussion. Why can't QA code? I'm a QA Specialist by title..and I can write code. So why then do I often hear amongst the industry that writing code is reserved for developers? In the modern "Agile" era, where every member is responsible for every stage of the development process in one capacity or another, QA can code. Infact, QA should code!

There's a larger and more well thought out blog post to follow on this topic. For now, I'm just going to mention that these shirts will be available for sale (at no profit to me) for anyone that agrees, and feels like making this bold statement with me.

*EDIT*: Design has changed thanks to a suggestion from Jim Hazen!