I’ve just started listening to The Bright Sessions, which is a fantastic podcast about therapy sessions for ‘unusual individuals’. Also, if you’ve not listened to The Black Tapes or Tanis yet, and you love your supernatural/paranormal/creepy mysteries, then you’re missing out!
We testers bloody love vocab don’t we? Some of the debates and comments I’ve seen on blogs and in slack are really high level – sometimes I feel I need a firmer background in philosophy and formal logic to even begin to join in. While that’s intimidating at times, it’s also incredibly interesting. I’ve mentioned before how much I love the passion of the testing community. We love what we do, and are constantly striving to be better. As a community, we’re also (unsurprisingly) specific in our wording. Which sometimes leads to debates about wording to the detriment of the actual discussion going on (I’m sure I’m not the only one whose seen a discussion on twitter shut down by someone replying with ‘you mean checking’ and then patting themselves on the back – so clever! That is another rant though. For the most part, we’re a friendly bunch).
One of the debates that is always going on is the subject of vocabulary. The testing, not checking debate. The controversy around certifications and what counts as ‘professional testing’ anyway? The one I want to talk about it one that I struggle with a lot, and that’s the subject of job titles.
When people ask me what I do, I say I’m a tester. My job title is QA tester. I do like the idea of testing the quality assurance that our company does, and in theory, I do do that.
When you’re testing, you’re not just testing the functionality in front of you. You’re testing assumptions, both your own and that of the developer who built the work. You’re testing how the feature fits in with what has come before it. One of the reasons I am so insistent on meeting the client as early as possible and being in workshops for requirements gathering is to get a feel for the client, their business, and what their priorities are. For example, we have a client that is really visual. Most of the time we need to wireframe features, or sketch them out as he finds it hard to fully visualise something using words alone, so we know to be more vigilant on the front end side of things. But it’s only through meeting the client and gauging their priorities that we know where to focus.
QA is the whole team’s responsibility for the most part, from the start of the project to the end (there are some contexts where one person being QA makes sense, but it tends to be more regulatory than testing). There are plenty of people who talk about this better than me, and I’ll link to them in the shownotes.
When I introduce myself, I say I am a tester, though that feels like I’m mis-selling myself. Hell, most of the podcast is less about the nitty gritty side of testing and is instead about requirements gathering, and building the right product. That’s where my priorities lie. I love testing, exploratory testing is seriously one of my favourite things, but I much prefer doing that on something I know (to the best of our abilities, and in the context of the project) fits the client’s needs.
However, I’m also aware that without the term tester? I wouldn’t be here, doing this. I wouldn’t be in slack, I wouldn’t have gone to Brighton. The community we’ve built under this ridiculously broad umbrella is wonderful, and without it, would this community exist? Yes, a rose by any other name etc, but would the community find another umbrella term.
I don’t think I’ve come to any great conclusions here – I still have no idea to describe my job function. I love the idea of testing QA, and then UAT can be the client testing our QA process as well, but other than that? I have no idea. I’m grateful we all identify broadly as testers, regardless of how ill-fitting that term is, because I love talking, reading, listening, and meeting you all!