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

Photo by Emily Morter on Unsplash

Background

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

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

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 engineeronly 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 anearlier 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 onDeveloper 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

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

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

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.

Manager SDET at Gojek, Bengaluru, I ❤️ to build scalable test automation frameworks and teams. Blog at automationhacks.io 🇮🇳