Which job title I prefer?

Publication date Read time 4 min Tags testing

I overthink question asked by a friend.

Recently, a friend asked me: “what job title best describes what you do at Red Hat?” He also gave following list of options to choose from:

  • Quality Engineer
  • Software Developer
  • Software Developer Engineer
  • Software Developer Engineer in Test
  • Software Developer Engineer in Test Automation
  • Software Engineer
  • Software Engineer in Test
  • Software Engineer in Test Automation
  • Automation Engineer
  • Automation Engineer In Test
  • Tester

Initially, I wanted to pick “Tester”. I have always self-identified as a tester, even more so since I started to better understand what it means.

But one thing stopped me from selecting this option right away – most of the work I have done in last couple of months isn’t something that we usually associate with testers.

  • I created a tool that gathers data scattered over multiple sources and creates single master list that acts as a source of truth for our automation. I also updated existing tools to use this data, and added new tool that publishes human-readable version of master list on our internal wiki.
  • I took the role of maintainer of our UI automation framework. I am responsible for setting general direction where project is heading, but I mostly triage reported issues and review code submissions. I also help others by teaching them how to use the framework, answering various questions and giving code pointers or implementation drafts.
  • I review PRs in our automation repositories. Many of them. My guesstimate is that I have seen at least 75% of all code submitted in last 6 months. Usually I focus on simplification opportunities and assuring that our checks are adequate and not shallow.

Since these are not activities that spring to my mind when I say “tester”, perhaps another name would be better suited?

I kind of like “Software Developer Engineer in Test” (SDET), and that could be my second choice. As a community, we talk a lot about cross-functional teams, and how there is no dedicated tester role in agile team, and about shifting left, and how quality is everyone’s responsibility, and how testers today act as “quality coaches”. So probably I can call myself software developer, just like other people working on the same product call themselves. Especially since activities listed above often fall under responsibilities of developers.

Software developer in test” also reminds me of T-shaped person. The idea is that every team member has some knowledge about a lot of things, and very deep knowledge about some specific thing, like JavaScript, databases, or CI systems. I find this fitting, as I do know a thing or two about multiple software-related topics, but my main area of expertise is testing.

Alas, there are implications of my understanding of the title that are not commonly shared in wider community. Since “SDET” was introduced, it always meant someone focused solely on “test automation”, frameworks and tools. I feel that all articles describing the role paint a picture of a person that has one solution to all problems - and that solution is him writing more code. SDETs will happily discuss maintainability, extensibility or code cleanliness, but won’t feel comfortable in conversation about oracles. In my experience, their frameworks will be top-notch, but they will use it for rather shallow testing.

Perhaps there is another way to reconcile “tester” label with things I am doing. Maybe defining property of a role is not what you do, but what you are prepared to do?

I am writing tools, maintaining frameworks and reviewing code, because in my organizational context we decided that this is the best use of my time and skills. But there are multiple other things I could be doing, if we decided these contributions were more valuable. I might provide feedback on new feature or product at any stage of development, give feedback on documentation or planned conference talk, verify developers work, triage bug reports, create internal documentation, write guidelines, design or improve processes. I did these things in the past and I will not refuse a request to do them again.

In other words, maybe key to understand role lies in its boundaries. Boundaries that can be determined through observation of activities that are accepted and refused by role-holder. For me, “tester” is all-encompassing label and includes all activities related to measuring and improving quality of the product, team behind it and their organizational and cultural environment. While SDET might refuse to perform “manual testing”, tester will happily do whatever is necessary.

It’s easy to get lost in discussion about job titles. There are multiple definitions floating around and people acting as if their definition was the only “true” one. At the end of the day, it might be good idea to take a step back and acknowledge that often this is not the most important issue at hand. I am committed to excel at the craft of testing, and this goal will remain unchanged whether my contract spells “quality engineer”, “software developer in test” or “tester”.