One of the best parts of working for New Relic is that most of us know how to write code. Regardless of our current roles, we likely have worked as a developer at one point in time. As an organization, this means we have an appreciation of code as a craft and know the importance of delivering a quality product.
For a while now, I’ve noticed a trend that appears to separate really successful companies from the also-rans. The successful ones are starting to recruit what I call ‘QA Developers’. As the title suggests, these individuals are truly developers and go beyond the role of traditional tester, engineer or automated scriptwriter.
The New Frontier
So, what’s this new type of QA position about? QA Developers care about the total quality of the product, not just about writing tests. They look for ways to improve the release process, internal processes and much, much more. We are developers at heart, either through experience, education or both.
Developers can no longer ‘throw’ features over the wall. That type of behavior in today’s fast-paced agile world doesn’t fly. While developers are creating new features, QA can be working in parallel, coding apps that verify features, making changes to build scripts, or prototyping test frameworks to work with a hot new cloud service provider. We don’t sit back and wait for something to test. QA has stories of their own in the backlog. We get involved and make proposals for change. In other words, we mix it up!
Making the Transition
My QA career started off by chance. I graduated with a degree in Computer Engineering and (like most of my colleagues) planned to have a career as a programmer. I settled in Dallas in the summer of 2005 and wasn’t able to find a job in software development. After a few months, I found a job as a computer repair technician. But while it was a step in the right direction, it wasn’t quite where I wanted to be.
Later that year, I attended a holiday party at a general contracting firm where my wife worked. Ironically, or perhaps not, they happened to have a small software division which was developing software for the construction industry. And they were hiring.
The position they were looking to fill was for a QA Engineer, not a developer. But after six months after graduation, I was eager to use the skills I’d learned at school. I looked at this opportunity as a stepping-stone. If I could get my foot in the door, maybe I could transition from a role in testing to that of a mainline developer once a position opened up. I interviewed and was offered the job. It was the opportunity I’d been waiting for!
Until that point, my QA experience was limited to roughly a third of a class in college. Suffice to say, I was a bit green. I dug in and did my best to start contributing to the team. In a year, much to my chagrin, I found I was good at finding defects. And I was able to exercise my coding urges more and more. I looked for any and all opportunities to work coding into my everyday activities despite being limited to a testing tool that primarily supported VBScript.
Due to downsizing, I found myself looking for a new job in 2009. Luckily, I landed at a place where I was given more freedom to pave my own road. I was tasked with creating our initial functional testing framework and took an approach that required a heavy amount of programming (C#), all while still in a ‘QA’ role. I still spent a sizable amount of time creating automated tests, but also branched out into the realm of Continuous Integration, contributing heavily to our initial pipeline that brought together testing, deployment and change management. It was during this time that a few things happened. I started believing in my development abilities more and realized I had achieved what I set out to do after graduation. I was a developer!
When I started speaking with New Relic last year, it was clear that the company had what I believe to be the right mindset when approaching this vision of quality. It was refreshing. Out of all the companies I had worked for or spoken to, New Relic was the first that really seemed to ‘get it’. If you took ‘QA’ out of the job description, it read just like that of a developer with a bend towards quality.
Tearing Down the Walls
The quality and development process work at its best when both parts of the team know how to write code. We may not all have the same level of experience in various languages, but we all code and can therefore help each other solve problems regardless of focus. This helps tear down the ‘walls’ that have commonly existed between developers and QA, ensuring the team actually works like a team. And more work can be done in parallel instead of in a waterfall nature.
When people used to ask me what I did for a living, I’d usually say, “Well, I test software,” or “I’m in QA.” Now I say, “I write code,” or “I’m a software developer focused on quality.” I spend almost as much time writing code as my developer counterparts, and I care about performance and all the other things my co-workers do. More of my time is spent testing code than other members of my team, but whenever I can, I’m writing code to facilitate better, repeatable testing. All these items spill over into the greater effort of delivering quality software to our customers!
I used to (and still) get asked if I ever want to transition to a full time developer role. In the past, I would have said yes. But now, I’m proud to say, “I am a developer. I get to write code everyday and a lot of it. My code is simply focused on a different area.” Thanks New Relic for giving me this opportunity.