The way I see it is if you write code that does something useful then you're a software engineer but from what I gather QA engineers seem to have an inferiority complex. It seems like QA engineers are much less reluctant to call themselves programmers than software engineers. Are there any real reasons for this divide and the perception that software engineers are the "real" programmers?

@ChrisF Why is this a duplicate? I see no mention of SQAs in that question.
–
KazarkMay 2 '13 at 14:14

@Kazark - I marked this as a duplicate over a year ago! I can't remember why I did now. There don't appear to be any flags so I was probably using the close /review queue. If you feel it's not a duplicate flag it for moderator attention so one of the other moderators can review it.
–
ChrisF♦May 2 '13 at 14:26

9 Answers
9

Although I'm still not overly familiar with the term QA Engineer, I'll answer this as a quality assurance analyst who is passionate about test automation. I'll also attempt to make it understandable.

It is definitely a misconception that I personally understand. Jobs' link rings very true as it was an amazing answer.

Most of this misconception comes from the fact that QA engineers (QA for the rest of this answer) do not tend to write application code. From the normal end user perspective, our code does not do anything. I can certainly speak to this, as, I consider myself decent with automation code, however, I still struggle writing what could be considered an actual application.

One other misconception that even many developers have, is that QA's are considered to be nothing more than script kiddies. To a point, this is true. Without the actual application under test, our code will fail. This also plays into Justins answer regarding specialization. I've met more than a few developers who can't wrap their head around how test automation works, or even why we would like to write it.

I suppose that there's also the fact that at many companies, test automation is something that is considered to be a nice to have, and spend the bulk of their time doing manual testing (raises hand).

The final point, some companies drill this into misconception into their QA's heads. I've worked for a few companies, where, if QA wasn't required for compliance, the Business would rather save the salaries and hire more software engineers/developers.

The fact of the matter is, however, that you're right, most QA's who spend time with test automation are on par with their developer equivalents. More so, I always smile a bit whenever I see a QA teaching a developer coding practices, or how to properly use a method, etc.

I don't believe that one role is inferior to the other, as both are vital to a successful software project. However, they are very different roles.

To say that "if you write code that does something useful you are a software engineer" is a poor generalization. Output of code is only part of a programmers day, and there is much more that goes into building software than just writing code. You need to be building the right solution with the right tools, using the right patterns and practices. Years of training and experience go into doing this well.

Likewise, QA Engineering is a very specialized and difficult job. They need to have a funadamental understanding of how software works and know how to test it. The art of writing tests for software is sometimes more difficult than writing the code itself. That said, it is again a very different process with a very different focus.

QA Engineers are not inferior to software engineers, but they are not the same either. I would not expect either to easily step into the others role.

In a small company one person could be a coder, an SQA, and a DBA all at the same time.
–
JobJun 26 '11 at 18:11

1

True, I've been in such scenarios. However, I've found that when filling additional roles I am usually doing it at a minimilast level, and not as a high functioning professional. For example, though I've filled the DBA role on some projects, out of necessity, I would not consider myself to be a DBA. Good DBA's would probably be insulted if I did. Likewise, though I can write Selenium test suites, I don't have all the skills necessary to be a solid QA Engineer.
–
Justin GuertinJun 26 '11 at 21:05

This is somewhat regional. Another title for a QA Engineer who can develop that is popular around here (Seattle area, USA) is "Software Development Engineer in Test". In other words, testers and QA Engineers do sometimes call themselves Software Engineers.

However, I do also think that there are many automation testers whose programming skill set is limited to what is needed to write good, maintainable test code but who would lack the skill set needed for a larger development project. For some testers, avoiding the Software Engineer title might be a simple matter of honesty: They are focused on testing, not developing.

Avoiding the Software Engineer title could also be a matter of personal branding: 'I am not "just another software engineer", I'm a QA specialist. Programming is just one of my many talents.'

Finally, they could be trying to avoid the "just wants to be a developer but can't make it" stereotype. If you are trying to avoid looking like a wanna-be, the last thing you want to do is imitate someone else's title. So, it might not be low self-esteem; maybe the QA Engineers don't feel like they need to measure themselves on the same scale that the development engineers are using.

I generally go for the "SDE in Test" title because I brand myself as a software developer who specializes in test, and I like to do test development work (building frameworks and testing tools, etc.). But I probably would want to avoid it if I were any less interested in developing test tools in addition to test cases.

Software engineers should be capable of designing software. QA engineers should be capabile of desiging testing strategies.
Effectively writing code (after having the design done) is a skill that both QA and Software Engineers should have.

This will probably get downvoted because people are so PC, but a difference is: qa is a lower title. I've never met a qa engineer that didn't want to be dev, but usually they have a hard time making the jump because of real or imagined notions about skill level of qa.

Even if I had enough rep on this site to downvote, I wouldn't as it's a valid opinion, and those people do exist, although maybe not as many as you might believe. In all of my years in QA, I've only met a handfull of colleagues who wanted to become dev's, and that was only because of the money involved.
–
Lyndon VroomanJun 26 '11 at 21:08

A QA Engineer discovers bugs and (logical) errors during testing, but he/she doesn't fix them. That's the job of the Software Engineer. Also, QA Engineers write code which is related only with testing, usually at a higher (for example scripting) level than Software Engineers. They don't really care about extending the functionality of a system, design its architecture, etc.

Unless they are designing and extending... the testing system! IE, you are incorrect. Even the project I'm on now has an entire dev team dedicated to extending testing automation.
–
Chris PitmanAug 24 '12 at 2:18

There is a very basic misconception in the software field that QA means Testing. This is absolutely wrong and I would like to clarify this. QA is Quality Assurance and revolves around "auditing a projects processes periodically to verify whether the processes identified in the project plan are being adhered to.". The results of the audit indicate the performance of the project with respect the plan. Testing on the other hand is a Quality Control function, and looks at the projects product to validate whether the products characteristics are matching the requirements.

To make it easier to understand;

a CMMi auditor performs a Quality Assurance Audit and not a Quality Control Audit.

a Software Tester performs Quality Control activities to identify deviations in the products attributes.

is this only your opinion or you can back it up somehow?
–
gnatAug 24 '14 at 7:57

I've wanted to make this distinction in the past when discussing ALM with colleagues. At the time, when I searched for material backing up these definitions I couldn't find anything concrete. Maybe my google-fu was weak that day. If you have a reference I would be in your debt :)
–
MetaFightAug 24 '14 at 9:04