This piece was a collaboration written by Kayleigh Oliver and Daniel Sayer, writer of the Unexpected QA blog.
There are so many job titles which cover the generic role of someone who works as a tester or someone within quality assurance (QA). Is it all recruiter babble? Does it denote the same roles and responsibilities?
Or are there significant differences in what a person will be expected to undertake determined by these job titles?
Here, Kayleigh and Dan will discuss the various current job titles for non-specialists they have encountered in their respective careers and work to define the high-level responsibilities of each title.
More specifically, they will describe the role of a tester or someone working in QA and put forward their explanations of what each title means, so you can formulate your own definitions and decide which would be best for you to pursue.
QA Engineer
Dan: The first thing to do when analyzing the job title is to break it down into its constituent parts, with QA short for quality assurance. I believe these parts convey the idea that the person occupying the QA role needs to focus on more than just testing. They should be the advocates of quality in their team, promoting others to increase the levels of quality in the work they undertake, the processes they follow, and the code they write.
The “engineer” portion in the context of quality assurance denotes more involvement in the release process for both defining and ensuring features, and changes are released with minimal negative impact to the end user.
Essentially, if we were to draw a Venn diagram of all quality/testing job titles, I would see “QA engineer” being slap bang in the middle, accounting for a little bit of every segment: testing, coding, process improvement, and championing.
Kayleigh: I agree with Dan about the QA part of this job title; any role with “QA” denotes that the person will be an advocate of the quality of the product.
The end user isn't usually involved within development, so it's the QA's role to champion their objectives for that end user and to help improve the processes used during development to ensure a high-quality product is delivered.
But when I see the word “engineer” in a job title, I don't think about the release process. This signifies that the role requires someone with technical skills. After all, the word “engineer” is rooted in the ability for that person to be able to construct, build, and develop something.
QA Developer
Dan: This is an interesting one. I would argue—and I’m probably going to cause some controversy here—that this role is made up. Linguistically, it doesn’t make sense to both test and develop (with testing being a large proportion of the QA responsibility to the team).
One of the reasons companies employ QAs as a separate entity from developers is to ensure functionality checking is done by a fresh pair of eyes. This is the same reason why QAs should employ techniques used by developers when writing code, such as code reviews. Some companies do not have QA as a separate unit and expect developers to test their own work; however, they aren’t called “QA developers.”
Therefore, if we take the perspective that the primary goal of any QA is to ensure the quality of the end product, it doesn’t feel feasible for someone to be a QA developer.
However, if you flip this on its head and try to envisage what someone would do if hired into a role with this title, I would imagine they would spend more time working on tools that enhance QA and be less involved in the production of features and changes to the main product. Why then not just have the title of developer?
Kayleigh: I disagree here. Not all developers are involved in the development of production code. Some just maintain the code and write tests, but they are developers and their focus is what's important. They are expected to write code that contributes to the development of features and continual improvement of those features within a readable, extendable, and maintainable codebase. A QA developer would focus on writing code that contributes to the development of tests for features within a readable, extendable, and maintainable codebase.
To me, this role would have someone with technical skills that (as Dan so rightly suggested) could be working with other teams like DevOps or solo, building testing tools to aid QA and testers during their day-to-day work.
This role could also be another way to refer to automation engineers. These are typically testers that spend the majority (if not all) of their time creating automation scripts that run on builds to detect defects before the project reaches production. Developers develop, but QA developers would have a particular focus on quality and how they can improve the quality of the product.
QA Tester
Dan: When I see the word “tester,” I immediately think about the manual process of pushing buttons and clicking through websites. This title denotes that the occupant focuses more on testing as a manual task but is still involved in shaping the overall quality of the processes in getting changes or features released (denoted by the QA section of the title).
The role of QA tester isn’t one I have seen that regularly, with my focus being in public services, online gambling, and web and app services. Usually, employers either want the tester to have a direct influence on the product from the start of the process or only test it once it's completed.
Kayleigh: I agree that the role of a QA tester is to perform manual testing. Again, this role requires the tester to be an advocate of quality from the end user's perspective and to champion change to improve the processes that build the product.
Historically, you'd find that testers working within the games industry would perform only manual testing, so they were called “QA testers.” However, more industries are recognizing the importance of releasing a high-quality product and how a low-quality product can affect their reputation, brand, and finances. Even the games industry has started employing QA engineers and automation engineers. This distinction in titles makes me more confident that this role is purely manual.
QA Analyst
Kayleigh: I think this is quite similar to the QA tester. However, I think the QA analyst would be more involved in the development cycle during the user acceptance testing (UAT) stages.
Dan: I agree that there are definite similarities to the role of QA tester; both roles have their main focus on manual testing. I was once told that the difference between a QA analyst and QA engineer was that the engineer was in charge of the release process whereas the analyst’s focus was up until the point of release. I’m sure there’s more to it than this anecdote, if we put this job title under the microscope. It has similarities to a business analyst and, potentially, crosses over in roles and responsibilities such as UAT stages, as Kayleigh mentioned.
Automation Engineer
Kayleigh: This is probably one of the most well-known job titles on this list so far. The role of automation engineer is to develop (hence the engineer part of the job title) automation scripts to test production code.
The types of tests written will largely depend on the company you work for. Automation engineers tend to write integration tests and UI tests.
Usually, automation engineers are more likely to write UI tests since they test the application from the end user's perspective. But depending on the company and its size, this role could write anything from low-level unit tests to high-level UI tests.
Dan: Again, I very much agree with you. “Automation engineer” is pretty much the Ronsil™ of job titles (does what it says on the tin). These guys (or girls) write automation tests, and that’s pretty much all they do. However, I don’t wish to belittle the task. With such a wide range of ways to contribute to automating the testing process, from unit to UI, there’s enough work to do to deserve a person specializing in this position.
Having been in a position where I was expected to write automation tests, these scripts need to be kept on top of. The slightest change or new feature can render all your tests obsolete, which is why strategies such as Page Object Model were devised; however, someone does have to implement this.
Software Tester
Dan: My thoughts on the role of a software tester are that it’s similar to that of a QA tester: mainly manual testing, focusing on the product and not on the process. It feels very much like a position where the work involves testing the product, and it either meets the expected criteria or it doesn’t.
My understanding may be swayed by the types of candidates I interviewed who came from a software tester background, but it did feel as if there was a perceptual difference between software tester and QA engineer.
Kayleigh: I would mostly agree again with Dan here. The software tester would focus on testing the functionality of the product to ensure it meets its intended use, but not test it from the perspective of whether it fulfills its business need. The word “software” is a generic catch-all that dictates you are a tester of digital products and not mechanical, like a lab or electrical tester.
Test Engineer
Dan: I believe the lack of specifying “software” in the job title identifies that the product under test could be hardware. However, I feel that this is where the differences cease. There doesn’t seem to be a hardware tester job title that’s employed with much frequency, so this is used for manual testers for hardware.
Kayleigh: Again, I'm disagreeing. Whenever a job title includes the word “engineer,” it implies a level of technical ability for that role. But other than that, I would agree this role focuses more on testing the product's functionality rather than the business value it adds or the end user's perspective.
Test Analyst
Dan: Test analyst is more of a Waterfall development process job title. Test analysts can either identify the targets from testing activities and enact the tasks to achieve these targets, or they can work in a more advisory position, assisting with preparation of test cycles, helping users during acceptance tests, and producing reports and analysis of the outcomes.
Kayleigh: This would be one role that suggests you're going to solely be doing manual work. However, this role would focus more on testing from an end user's perspective rather than merely ensuring the features are functionally performing.
Software Development Engineer in Test (SDET)
Kayleigh: This title was first used in 2005 by Microsoft. This title is the most technical for someone in the testing field because their role is to both develop and test, often across different stages of development. The person undertaking this role may develop many different types of tests, for example integration, contract acceptance, and UI.
To be able to perform all of these types of tests, you need to have an understanding of what makes a good test, the types of testing required at each level, and how to implement them.
Giving this type of technical tester a title with the word “development” means the candidate should have a greater technical ability. It also makes the title easier to understand to those outside of any development role. Anyone can guess what a software developer does, but you need to also explain the role of an automation engineer. This is the role that I believe is the closest to an SDET.
Dan: As you said, Kayleigh, this role has been around for a while now. An SDET is a developer that focuses on testing. SDETs are highly proficient in coding and development practices but do not get involved in the development side and remain focused on ensuring the product is in a testable position.
I feel the perception is that SDETs would rather code a script than manually execute a test, regardless of the time and effort it would take. I am aware of several places that would utilize SDETs to refactor code to make it more testable. This isn’t the norm but does go to show the wide skill set those employed in this position need to have. But how is this role different from that of automation engineer? I believe it’s the same job under a different name and cannot see a noticeable dissimilarity between responsibilities. However, if I was in this position, I would rather be known as a software development engineer in test. It has a nice ring to it, don’t you think?
Do Job Titles Really Matter?
Ultimately, a job title can give you only so much information into what you will be doing. Many jobs will be posted by non-QAs (recruiters, development managers, etc.) that even if there was a consensus on the titles above, there would still be so many nuances that you have to look at the job description to make an informed decision. You’ll find some uniquely named positions after a quick search on popular job sites, such as Test Ninja, which shows that our list and discussion isn’t exhaustive.
We both agree that the description of the role is more important than the title, as it'll convey the detail and day-to-day actions of the role. However, job titles are still used to denote the level of authority of an individual at a glance, so it does matter what title you are working under.
What to do if Your Job Title Isn't for You
Again, it's true that a job posting may be different from what you actually undertake in the role. You may find that your role is different than the title you originally applied for.
If you're not happy with your current title, we would suggest you speak to your manager and negotiate a title change in your next performance review. Remember to go with evidence of the additional tasks you undertake so you can justify a title that more represents your day-to-day workload.
If you're not happy with the extra responsibilities you've undertaken which don't usually fall under this role, we suggest you also talk to your manager. Maybe these extra tasks are pulling you away from doing your best work and spreading yourself too thin. Whatever you may be unhappy with, come to a compromise with your manager; don't just carry on.