I’m a self-taught programmer; I’ve never done it full-time. Most of the QA jobs that I have had over the years have included some amount of scripting and/or automated testing work, but it’s always been done alongside other QA tasks. When I was job hunting last year, I concluded that if I really wanted to remain competitive in my career, my next job needed to focus solely or primarily on writing test automation. Plus, I love to code, and I thought I would really enjoy such a job.
During my job hunt, my standard line about my coding skills was: I’m a decent coder, but because I’ve never done it full-time, I’m probably not qualified to fill a role where I’m the person primarily responsible for the development of an automation framework. When I interviewed here at Netspend for a senior automation developer job, I was told that they were seeking someone with a strong automation background but that they were less concerned whether the candidate knew the language being used, node.js/Javascript. Since node.js is a fairly new framework, and since Javascript is rarely used in automation, they (accurately, in my opinion) didn’t expect to find a candidate who had node.js/Javascript experience. Furthermore, they assumed that any qualified candidate could pick up the language.
It turned out that those were perfect expectations for me. During my interviews here, the interviewers were impressed with my extensive knowledge and experience with automation, and I passed their general programming tests. In regard to programming skills, they were more interested in my thought processes and logic than producing accurate code in the spur of the moment on a whiteboard. Plus, I did have a distant background with Javascript (not just in the browser; it was also the programming language of an automation tool that I used many years ago).
Now that I’ve been here at Netspend for about 8 months and developed a framework and automated tests for UI-testing, I’ve discovered that I misapprehended the skills that are necessary for building an automated testing framework. When I said I was probably not qualified to build an automation framework, I was thinking primarily of coding skills. I have learned the Javascript syntax and the node-specific knowledge necessary to build an automation framework, and I’ve built a robust framework and set of tests that adds value to our development process.
Last week, I worked with another senior QA engineer here at Netspend to define the desired skill sets of our different types of QA jobs: general QA, QA of our back-end systems, QA for our user-facing applications, and automated test developer (I’ll do another blog post about the results of this work). Here is the list of skills that we feel are necessary for an automated test developer in our organization:
- Source Control Management (we use git)
- How and Why
- Continuous Integration (we use Bamboo)
- Programming Basics, e.g.,
- Conditionals
- Data Types
- Program flow
- Advanced Programming, e.g.,
- Development Patterns / Architecture
- Abstractions / Refactoring
- Contributing to Framework development
- X-Path / DOM manipulation (for UI testing)
- Automation Test Concepts, e.g.,
- How to Validate what
- Types of automation
- Reducing to minimum set of tests
- Cost / Benefit analysis
- Database basics
- Linux basics
As it turns out (and as the people who hired me here–one of whom was the guy I worked with to create this list–astutely realized), being an expert coder of the language of choice doesn’t even make the list. I’ve been successful with the development of an automated testing framework here due to my knowledge of and experience with all of these areas.