Why focussing on titles is an anti-pattern that should stop in the Testing world.
Titles for testers
A very common problem with the software industry is the use of titles to describe the function, someone, in that position performs.
Take the testing space, for example, below is the innumerable no of titles that I have heard so far in my career. More to come I am sure as something new and shiny is invented or the domain evolves.
- Software Tester
- QA (Quality Assurance, Quality Analyst, Quality Advocate, Quality Assistant … OMG, While you are at it, Add whatever suffix you fancy),
- SQA (Software quality assurance)
- QE (Quality engineer)
- SDET (Software development engineer in Test)
- SET (Software engineer in test)
- Automation engineer
- Test engineer (Suffix with I, II, III …. maybe?) or Prefix with (Senior, Staff, Super Staff, Principal, Heavenly engineer …)
- Test architect (Again go crazy with the prefixes or suffixes)
- Test manager
- Director/Head of Test
- Test/Quality Evangelist
Wow, I am imagining if people with all these titles hypothetically came into a room and start talking to each other, How would they describe their role and what do they do on a day to day basis?
Do we as testers ever stop for a moment and think.
- What do all these different titles really mean?
- How do these roles really differ from each other?
- Do people with all these titles inherently do something different?
The difference
The answer IMHO is Not much
People with all these different titles essentially do similar activities on a typical software development team.
Yes, the scope or nature of work changes a bit based on how experienced you are and the project and team requirements. But they are roughly in the same ballpark.
There are some titles that add gravitas to a person based on their experience level and the organization’s hierarchy but for the sake of arguments lets just divide them into two broad roles.
- Engineers (Gets work done)
- Managers (Supports engineers careers and helps break any roadblocks)
Titles don’t matter – Alan page
How should I apply for testing positions?
If you are a person who is chasing after the next suffix or prefix in your title, then you are probably chasing after the wrong thing. Any such addition is not going to add much value to you as a tester in your career.
If you are someone who is looking for a testing role in any organization. Go ahead and apply to any of these titles (if you have the relevant experience and skills ) and do not pay much attention to the innumerable no of suffixes and prefixes that come with it. Chances are this title confusion is present even in the organization with everyone having a different understanding of the terms based on their current or past thought models.
You’re on the ground role would be dynamic and as per team/project/company requirements and would anyways change as the company evolves.
What does a tester really do?
Hmm. With the above discussion, the most common question that comes to mind
If Titles do not make much sense? What does a tester really do / should do?
In a few words, Many things.
Testing as a role requires people who are generalists, in most cases T-Shaped and can wear multiple hats.
There is a whole set of activities that they do on a day to day basis that is all aimed at increasing the quality levels of the team. The domain/project/company that they work on might cause small shifts but these activities are largely inline.
Broadly a person with tester role does the following.
This list is not really meant to be exhaustive and should evolve based on your reality
- Product quality – Understands the product deeply, Its tech stack and exercises it in unique ways to find out any gaps in quality using available tools (exploratory, scripted or automated tests) in their belt
-
Risk analysis and Data – Assesses risk, Uses data and telemetry to assess:
- if the product is built as per spec?
- but more importantly, are we building the right product for our users?
- User advocate – ** Tester *tries to think like a user, Thinks of user journey flows, Questions the product on whether it does meet the user’s need.
- Coaching and Mentoring – Coaches the team (Dev/PM and other testers) on testing practices/mindset, Whole team quality, Encourages retrospection to improve the team over time.
- Planning/Strategy – Figures out the appropriate test strategy and the correct tools and ensures it happens (by any team member (Dev/PM/Sales) regardless of roles)
- Coding – Automates essential tests (when required), Writes and maintains frameworks, Reviews pull requests (Dev/Test automation) and suggests or make changes
- Communication and Collaboration * – Acts as a bridge between Dev, Business/PMs, and other stakeholders and provides information and insights around the state of quality in a product
In fact, I made a mind map to capture the set of activities that a tester does:
Conclusion
Phew. That’s a lot for a single individual to accomplish in a given timeline right?.
So naturally, we need people to specialize in a few of these areas while generalizing in others and that’s fine.
Expecting a title to be the clean separation between these activities might not be the best idea. The lines are always going to be a bit blurry.
So instead of sweating too much about the title.
Why not think about how you can learn more about these areas and improve. There are a ton of resources out there and going through these would most definitely add much more value for you in the long term.
Further, read
Apparently, I am not alone in this thought and there are many excellent articles already written about this, If this sparked something in your mind. Might as well go and read up a bit more:
Top comments (0)