QA != Tester

Last Saturday I had one of those epiphany moments for something way too obvious, still too shocking for me at the moment of speaking. It was related to the QA process and the place of the QA role in the software industry.

I got involved in a discussion on Saturday evening regarding several different technical specialties. There were three of us teaching classes at the Telerik Academy here. Trainees could end up as: developers, frontend engineers, support experts, QA guys etc.

Not surprisingly for me, most people tend to lean towards the development department, i.e. trying to join the dev forces and study exclusively for developers. The support and QA jobs are less appealing, even disgraceful for some of them. Everyone wants to be that cool kid who builds the universe with code and works on the next Google or Facebook.

That “terminology” issue is pretty common though, people are careful about how they determine themselves and try to group responsibilities based on the job title. Chris Lema wrote a post on “Programmer, Developer, Engineer” too. It makes sense, even though characteristics vary from company to company where technical roles such as: frontend developer, backend developer, team leader, PM, technical lead, evangelist, engineering director, tester, support, QA and many more can overlap when it comes to duties – and it’s hard to draw the line between all of them that could apply in every case.

The question here is: is every QA being the developer’s assistant or rather the quality manager where the development department reports two?

The stunning part for me was the actual, literal definition of QA. Let’s take that from Wikipedia:

Quality assurance (QA) refers to the engineering activities implemented in a quality system so that requirements for a product or service will be fulfilled.

QA includes management of the quality of raw materials, assemblies, products and components, services related to production, and management, production and inspection processes.

Consultants and contractors are sometimes employed when introducing new quality practices and methods, particularly where the relevant skills and expertise are not available within the organization or when allocating the available internal resources are not available.

That perspective is quite ambiguous, especially when you spend some time around the job boards. QA is branched into various divisions: QA, QA engineer, QA tester, QA support, QA analyst, QA supervisor and so on. Sounds to me as a catch-phrase that aims to fill in everywhere, just to make a longer job title (which sounds more respectful).

Most of the jobs out there actually don’t specify enough directions in the job description section as well. Unlike development or design where required skills and expertise are listed and the job description usually includes what sort of project is developed, the technology stack (or products you will use on the way) etc, here there are several trendy requirements or project duties from QA jobs online:

  • Demonstrates working knowledge of quality engineering policies, principles and best practices
  • Responsible for the planning, integration, casing, scripting and execution of all testing.
  • Perform tasks and work to achieve company goals and organizational objectives.
  • Follow company policies and procedures.
  • Set personal performance goals and provide input to departmental objectives.
  • Establish work priorities to meet targets and timelines.

Less than 30% of the job offers I read online require any specific skills related to the project. Few of the companies require “Bachelor degree in some technical specialty”. Many Senior QA jobs or the Lead QA ones look like internship proposals for high school students.

I have taught two Java 101 courses for QA engineers, in a Java-oriented corporation (VMware) for people with many years of QA experience in-house. Each one of them was a valuable unit from the workforce and yet most of them got little to no knowledge in the actual language running their VM and other products.

I spend 20-30% of my billable hours every week performing code reviews. It could be: theme reviews for the WordPress.org theme directory, reviewing plugins for bad practices for customers, revising the work of my colleagues and subcontractors, evaluating extensions to existing platforms or outlining change proposals for existing products. My contracts for these assignments are normally as a “consultant” or “developer”, but never QA. I never considered that being a core part of the QA definition, even if it’s so blurry in job offers as is in the actual execution of QA plans in different companies.

QA and QC (Quality Control) in hardware companies is pretty much one of the top technical roles available. Ensuring that a mainboard is fully functional and responding to the proper input ranges, being able to verify all weak spots of a key component from the chain requires expertise and experience beyond the duties and know-how of a developer, or integrator.

It seems to me that most companies are transforming the QA position to purely testing, or first tier support, or jobs for juniors and interns to cover while developers do the “real work”.

Nevertheless, from now on I will consider QA as a leading role in the software development process. Quality Assurance in a real working environment has to be somewhere near the “technical leader” or “VP of engineering” in the crew, taking care of all edge cases, envisioning the future and limiting side effects, leading to “problem free” product development, scalable architecture and happy managers and customers.

Leave a Reply