Testers identity crisis - QA/QE/AE/SDET/SET/TA? 🤷

Photo by Emily Morter on Unsplash

Background

In the vast field of Software engineering, there are few broad disciplines that team members typically work under, these usually defines an engineers primary identity on a cross-functional team

Some of these broad disciplines/roles are that of a Product Manager (PM), Frontend developer (Web/Mobile/Desktop), Backend Developer, Tester, Designer, Copywriter ,etc.

You can quite easily append “Engineer” to any of these roles and form a title.

The most common developer title that I’ve noticed is that of a “Software engineer” or SWE for short however it can be quite focussed on the specific stack/technologies that they primarily work on, for instance, some of these titles are Android engineer, iOS engineer, Backend engineer etc, usually these titles are quite unambiguous. They roughly give a good sense of the role that the person will play on the team

However, the Test discipline’s titles is a different story altogether, over sometime we as a community or industry have come up with innumerable different titles for activities that are essentially the same and in the end, that confuse more than they clarify.

Another common anti-pattern with these titles is that HR/Orgs might decide to associate salary ranges based on the title that a tester possesses which may or may not really do justice to the contributions or value that the engineer provides on an Agile team. In the absence of strong and experienced Test leadership, this is something that we can do very less about.

Test disciplines titles confusion

There is growing confusion about what the Test discipline calls itself, Some of the most noticeable titles in the industry for a “tester” are Test Engineer (TE), Quality engineer (QE), Quality Assurance Engineer (QAE), Software development Engineer in Test (SDET ) or more concisely Software Engineer in Test (SET), or something like an Automation engineer (AE), Test Automation Engineer (TAE), Test Automation Specialist (TAS), Test architect (TA)

You obviously can prefix these with Associate, Senior, Lead, Staff, Principal, Distinguished to indicate a level of seniority in terms of experience or the role that the person plays on the team but in general, I’ve observed that people like to take these titles way too seriously for their own good. They tend to focus a lot of time and energy chasing these, which does more harm than good

It’s very easy to become fixated on these and develop your entire personality or sense of identity around it. I hope this post can convince you otherwise

Sometime back, I wrote a post on why I think Titles for testers don’t really matter but for some reason, this question keeps on coming up time and again in conversations, that I sense many testers have similar thoughts (let me know if you feel otherwise in the comments) so, this post is an attempt to provide some more clarity and share what I personally feel about this.

Are they all the same

So, With all that background and context, At the end of the day, do you think all these are equivalent?

QA = QE = AE = SDET = SET = TA? 😕

The answer to this question is dependent on multiple factors

• your company/org context
• How the people in test leadership feel about their role
• What is the prior experience of the leadership team in your company regarding Test/Quality discipline
• You team members and how they have perceived other testers in their prior jobs

Different teams might associate different expectations of these titles

But, I’ve generally seen folks with these titles associating certain peculiar behaviors patterns or expectations, either by themselves or by others/leadership

• QA (Quality assurance): This is the most common title for a tester in the industry today, This engineer is deemed to be responsible for the quality of the product usually achieved by testing the product and in most cases automating the process, sometimes this title is also wrongly assumed to say that this engineer only does testing manually
• QE (Quality engineer): Pretty much the same as above but shows a bit more nuance of thought to have a de-emphasis on the “assurance” word which has its own set of negative connotations (If X assures quality as a tester, Y as a developer can just throw everything over the wall to him/her?, By the way, if you have to face this in your job, I wrote about this unique bug ping pong phenomenon in an earlier post)
• TE (Test engineer) = Again similar to above
• SDET/SET: Now, we are in a generally more fancy realm, We are now a software developer in Test, so folks with this title typically like to go ahead and only focus on Developer tooling, Test automation, building frameworks, and typically rewriting them again and again …
• AE (Automation engineer): pretty much the same as above
• TA (Test architect): Folks having architect suffix indicate a higher level of seniority in terms of years of experience, often achieved by having worked for a no of years in different contexts, This person usually designs higher solutions and the overall architecture and also gives high-level framework specifications for other test engineers to implement, a person in this role may or may not be very hands-on

Which one to choose

Should you choose this explicitly?

Well, You can pretty much choose whichever you personally resonate with the most (if you have the choice). However be very careful to not build your whole persona around it, so much so that it becomes your sole identity

It’s quite easy to fall the below trap with titles like QA.

I am a QA, so my job is to be the gatekeeper and assure the quality of the product

I’ve also observed testers having a bit of identity crisis around titles and sometimes even a self-worth and self-esteem issue, It’s quite easy to think that since some testers don’t have a coding background (probably discovering or falling into testing from different functions like Sales, IT, Customer support), they should not really focus on it and they might even regard themselves as lower than developers in the entire organization’s chain

Quite often engineering organizations are developer-driven with Engineering managers/heads/directors coming from a dev background. You should aim to be more of a Test coach and advocate for quality and testing practices on the team and ensure good testing happens. Regardless of who really does it (Dev/PM/Tester)

Do not think that since you are a tester, you cannot look at app/service level code. You should strive to understand these components in a good enough level of detail

What do I prefer

In general, I like to refer to myself as a tester but more broadly as a Software craftsman and engineer first

I don’t really like limit myself to just testing activities. I’m equally interested in all phases of software development and really like coding, reading dev code/books/articles and the sense of writing clean code that works is unparalleled, I’m equally happy when I discover hard to find bugs in the system and avoid a mistake that could have impacted our valuable customers

Personally, I feel there is so much to learn ,and honestly the testing focus means that you can poke and prod at the product in a whole different no of ways than, what you otherwise might if you are focussed on a specific developer discipline like Frontend/Backend engineering.

The whole testing craft really excites me. Whether it be exploratory testing or designing efficient automated suites in different tech stacks. At the end of the day, whatever activities I do, My primary aim is the accelerate the team and helps developers/team become faster and more confident in shipping code

While not sacrificing on quality and ensuring we put a well-designed product in the hands of the customer.

Considering all these, I’m happy as long as I get to do these and impact the product in a positive way.

So, Which of these titles really reflect the activities that I perform on a day to day basis?

If I had to choose one, I would pick “Software engineer in Test” as my preferred choice, since I personally feel that gives a good enough representation of what I do and resonates quite well with me. Even a more concise “Test engineer” works quite well. Also proposed by Google in the book How Google tests software, To me, these titles and their descriptions make a lot of sense.

Conclusion

Choose whichever works well for you. However, strive to be an engineer first and keep on working on learning your craft and improving every day. Don’t let your title define what you can or cannot do. Remember the title that you possess is NOT YOU, but something that is your organization’s shared understanding of the role/craft.

If you found this post useful, Do share it with a friend or colleague. Until next time. Happy Testing/Coding.