Why I don’t call myself a tester, or: defining what I do

This post was published on January 4, 2017

Warning: rambling ahead!

Recently, I’ve been forced to think about roles in my profession, and what role it is exactly that I fulfill when at work. ‘Forced’ sounds way more negative than it is, by the way.. In fact, I think it has been a good thing, because it has helped me to think and better define what it is I actually do… So, thanks to Richard:

and Maaret (she’s quoting this blog post, by the way):

for making me think about the restrictive activity of pinning roles and labels on people. Nobody conforms 100% to the definition of a given role, should such a definition ever be created and agreed upon by everybody (good luck with that!). On the other hand, being able to explain what I do and what value I can add to a person, a team or an organization is something I can’t really do without, especially as a freelance contractor. And that, sadly, involves roles and labels, because that’s mainly how the keyword-driven IT freelancing and contracting business works.

So far, I’ve mainly defined what I do by referring to what I’m not, something you can see in the tweets I referred to above:

  • I am not a developer, at least not when compared to what the majority of people think of when they think of a developer. For someone involved in test automation (which is a form of software development), I write a shockingly low amount of code. I can’t even remember exactly when the last time was I wrote code that was used in actual automated test execution. Somewhere at the beginning of last year, I think…
  • I am not a tester. The last time I evaluated and experimented with an application in order to assess its quality and usefulness has been years ago. I think it involved TMap test design techniques and rather large Excel sheets…
  • I don’t fit into an Agile team. This is the most recent realization I’ve made. A lot of projects that come my way ask me to be a member of an Agile team, contributing to testing, test automation and possibly some other tasks. That just doesn’t fit with what I like to do or how I like to work. For starters, I think it’s kind of hard to be a member of an Agile team when you’re only there two days a week. You just miss too much. But I like to work on multiple projects at the same time and also have some time left for training, business development and other fun stuff. Unfortunately, the freelance project market here largely consists of projects for 32-40 hours a week, with Agile being a very popular way of working..

On the other hand:

  • I work a lot with developers, helping them to realize WHY they need to spend time creating automated tests and WHAT approach might work best. I gladly leave the HOW to them, since they’ll run circles around me with their development skills. This requires me to stay sort of up to date with tools, approaches and practices in software development, even though I don’t write code (often).
  • I work a lot with testers, helping them to think properly about what test automation can do for them and how to ‘sell’ it to other stakeholders. This requires me to stay up to date with how testers think and work, even though I don’t test myself.
  • I work a lot with Agile teams, helping them to create and especially test software more efficiently through smart application of tools. This requires me to stay up to date with team dynamics, Agile practices and trends, even though I haven’t been contributing to daily standups and sprint planning sessions for a while.

But I still have a hard time defining exactly what it IS that I do! My LinkedIn tagline says this:

_Test automation Service virtualization Consultant Trainer Writer Speaker_

Those probably come closest to what I do. Most importantly, it states in what fields I am active (test automation and service virtualization). What other people call consulting makes up for most of my time spent working at the moment (I’d like that to change a little, but that’s a different story). But I don’t like the word ‘consultant’ or ‘consulting’. It makes me think too much of people with big mouths, expensive suits and six months of actual experience. And I don’t wear expensive suits. Or suits in general.

The rest of my time is spent training a little (hopefully more in the near future), writing a little (same goes for this) and speaking a little (and for this too). Yet, I don’t consider myself a trainer, a writer or a speaker. But maybe I am all of them. As well as a developer. And a tester. I don’t know.

Long story short, what I think it boils down to is that I help people, teams and organizations perform better in the areas of test automation and service virtualization. Areas that are of course not to be considered as goals of their own, but rather as servant to the larger scale goals of more effective testing, software development and doing business in general.

I think the key word here is ‘help’. I like to help. It isn’t about me. It shouldn’t be. If it looks like it is about me, please say so, because I’d like to avoid that by all means possible. As a start, next week I’ll talk test automation or service virtualization again.

Oh, and of course happy 2017 to all of you! I’m very much looking forward to helping people even more this year.

"