Why I change my in-house job title to match the testing I’m doing

One small habit I’ve developed is updating my in-house job title to reflect the kind of testing I’m focused on at that moment. 

Sometimes the title is straightforward. Sometimes it is slightly ridiculous. Either way, it is rooted in the real work. This month's is “Tester of Meows, Mark-up and Mayhem”, which emerged from exploratory testing involving cat emojis, Pirate Ipsum, HTML links to cat pictures, and other deliberately awkward inputs. 

Underneath the silliness, it is the same work many of us do every day: probing how a system behaves when content moves beyond the neat and expected paths. The cats and jokes are decorative. The test coverage is not. 

A small way to make testing more legible inside a business 

One reason I started doing this was that so much of testing work is still easy for non-testers to flatten into QA myths and misconceptions. 

From inside QA, we know how much thinking sits behind exploratory work: risk assessment, pattern recognition, input design, curiosity, inference, and deliberate attempts to stress assumptions. From outside QA, that can easily get reduced to “making sure the button works” or “trying to break it”. 

A changing internal title has become one of the lightweight ways to make that work a little more visible. Not in a grand or formal sense, and not as a substitute for proper reporting, but as a small signal. It gives colleagues a glimpse of what kind of quality work is happening without needing a meeting, a slide deck, or a wall of explanation. 

I suspect many testers already do versions of this in other ways: naming things well, framing bug reports carefully, choosing examples that land, or using humour to make a point stick. This just happens to be one of mine. 

Why I mix humorous inputs with traditional test data 

I still use traditional test data. That part does not change. 

You still need your realistic names, empty fields, maximum lengths, malformed entries, special characters, dates, currencies, boundary values, and all the sensible things we would expect in a proper test approach. But there is real value in mixing that with more playful or distinctive content as well. 

A cat emoji can expose encoding issues. A wall of Pirate Ipsum can make layout weaknesses or brittle assumptions more obvious. An HTML link to a cat picture can surface inconsistencies in sanitisation or rendering. Sometimes, humorous content is useful precisely because it is memorable. Teams remember the bug with the pirate text, dad jokes or the cat link far more easily than the bug found with test123. 

That memorability helps when communicating with non-testers. It can often make the work easier to follow or understand. A strange but vivid example can carry the point faster than a technically correct one. 

Making testing more approachable without watering it down 

I think many of us spend a fair amount of time translating testing work for people outside the discipline. 

Not simplifying the craft itself, but making its value easier to see. That might mean explaining why a small defect matters, why a weird edge case is worth attention, or why “nobody would do that” is not a comforting phrase in software. 

Humorous inputs can help with that translation. They make the work feel more human and less abstract. They can also make testing look less like an obscure gatekeeping function and change the "nobody would do that" into "how do I do that".

Sometimes it even helps when you are delivering bad news 

Another small advantage is that humour can soften the edges when you are delivering unwelcome findings. 

We have all been in situations where QA is bringing inconvenient news: this breaks under certain conditions, this behaviour is inconsistent, this release carries risk, this field does not cope well with real-world input. A little levity will not fix the issue, and it should never undermine the seriousness of the message, but it can make the conversation easier to receive. 

A tiny habit, but a useful one 

For me, changing my in-house job title has become a small communication tool. It reflects the actual testing I’m doing, and adds a bit of personality to something that is often invisible until it goes wrong. 

It is not a framework. It is not a strategy deck. It is just one tiny habit. But sometimes tiny habits are what make the work easier to see.