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

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

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.

Originally published at https://automationhacks.io on October 8, 2020.

Lead SDET at Gojek, Bengaluru, I ❤️ to code in Kotlin, Python 🐍, and Java to build scalable test automation frameworks. Blog at automationhacks.io 🇮🇳

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store