Thursday 14 June 2018

I created the SDET role at my company and I wish that I hadn't...

Hindsight is 20/20, as "they" say.

"They" also say you have to make mistakes to learn from them. I say, learn from MY mistake so you don't have to make this one. Because some mistakes are really hard to recover from.

I was hired to develop automation frameworks and had been given the title "Software Engineer". To be honest, I didn't have the confidence to believe I deserved it. I even appended my own qualifier to the title in my online profiles, calling myself "Software Engineer (in Test)".

Fast forward a few months and I've been asked to lead a team of people doing the same job, developing and maintaining automation frameworks. So I set to work developing role descriptions and career growth plans - for the position I'd like to give people on my team: Software Development Engineer in Test (SDET).

I had used this title for automation related positions I helped create in the past, as well as having the title of Quality Assurance Developer earlier in my career. So when it came time to decide how to title the team members of my new automation focused team, I didn't put much thought to it. I completely glossed over the benefit I was being extended when I myself was given a Software Engineer title. Ooops.

In retrospect, after many conversations with industry professionals I respect, I realize that development is development regardless of what your focus area is. By tacking on a qualifier such as "in test", it opens up the discussion that these team members are not as skilled or deserving as team members with a "real" developer title. How often do we hear about developers being "good enough" to be in an SDET role? Or how about when development teams pass on junior applicants but recommend them for the automation role? And then you have to engage in discussions like where the SDET role fits in the pay scale of the organization (hint: in my experience, it's almost always been below developer, but above QA).

Simon Stewart made the claim (in a talk of his I attended at STPCon Spring 2018...and I hope he doesn't mind me attributing this to him) that finding good Automation Engineers (or SDETs, or SETIs, or Test Engineers, etc...) is actually very hard. Anyone who's been a hiring manager for this role will more than likely agree. And if this role is truly a hard one to fill, would that not warrant that position being worth more? Simon's claim was that there's plenty of developers in the candidate pool looking for positions, but we have to actively go out and hunt for months to find good SDETs. 

So, back to my 20/20 hindsight. I've been reflecting on this a lot lately and I've come to realize that my new opinion on the matter is that anyone developing in code should have a developer role and be treated like a developer. That is, held to the same standards, paid the same wages, etc. The bonus to this? The people focused on your test frameworks can float between automation development and feature development as required. You're finding the people with the test and automation skills and putting them on the development team. This doesn't mean other developers can't contribute to automation, and vice versa. It's about getting right skills in the door and making them available to assist the wider team.

I never gave much focus to titles in past. But take it from me: take the time and think carefully about it. Once in place, they can be quite hard to change.

5 steps for testers who want be more comfortable with code

In a previous post, I made mention of some tips I have for testers who lack confidence working with raw code. Here they are, in the order I think most easily executed. Of course, they could be done in any order, you can pick and choose which you even want to do, or you can do them in parallel. The idea is to just work towards being more comfortable talking about and writing code.

Look at code reviews.
Seriously. Just look at them. This is step one. You don't need to be added as an assignee or a reviewer, but start looking at them. When you do:
  • Look at what files change - how do they relate back to this particular feature/bug fix?
  • Look at what comments other reviewers leave - what kinds of things are they focusing on?
  • Try and understand what the code change is doing - read through and start to identify what kinds of functions live in the different files. 
Set up your laptop with a development environment.
You are part of the development team, after all - aren't you? So if your on-boarding as a tester didn't include setting up your environment the way a developer's is, find the docs and do it yourself. Or ask for it. Either way, I encourage that you get set up to pull code and run local builds. Not only does this give you the opportunity to see the code and spend time in the environment that the developers do, but it also allows you to be able to pull branches, run local builds, and get early eyes on features and code changes.

Use the terminal at every opportunity.
Just to get used to writing commands, and understanding what the terminal can do for you. There's so much power available to you. Once you learn some of the shortcuts, I promise you'll wish you had explored the environment sooner. This will also help you set a foundation for the skills needed to write bash scripts. Once you have that foundation, you can start to...

Experiment with writing scripts.
There are many opportunities for scripts to help you do tasks related to your job much more quickly and efficiently. Once you understand how to do things like cURL from a terminal window, you can start to script things like API calls for testing and validation. Consider any task you spend time doing more than once a candidate for a script. Once you've written a few of these, you'll be on your way to building a library of tools that help you complete menial and tedious actions with minimal effort - freeing you up to spend more time on the most impactful work.

Pair with developers.
Get face time with developers whenever you can. In my experience, they often more than willing to let you sit with them, shadow them, and work through problems together. By doing this, you'll see how they tackle problems and if they're really helpful, they'll talk through their process of building the feature with you. You can hear where they start, what kinds of things need to be added, modified or removed, any many other insights into the code base. You can also watch for and discuss coding conventions. Every organizations have their own conventions and standards and you'll want to be familiar with yours so as you learn you ensure that you're learning habits that align with the company. This sets you up to have your first few attempts at code be well received by your friendly neighborhood developers.


Feel free to comment below if you have any other useful tips for testers who may be nervous about participating in the code side of software engineering.