When is a Tester not a Tester?

There are many competing thoughts on Software Testing and especially the roles we take on for those of us, as I do, who self define as Software Testers.

How much is too much? Are there any boundaries, and should they exist? If Testing is an activity, and Quality is a whole team responsibility, who are the Testers?

I’m going to indulge in discussing some thoughts and asking some questions. What I won’t do is give definitive answers, because as it should be, your context will be different to mine.

Agile Teams

For the approximately the first two years of my career I worked in an independent Test team, working on a Waterfall project. All work was estimated, and planned and was assigned to me. There was some comfort in this, I didn’t have to spend time figuring out if I was doing valuable work, I just did as I was told as well as I could.

Every since Citrix, where I was working in my early career, went though an “Agile Transformation”, I have joined teams and worked alongside Developers.

I’m confident independent Test teams still exist, and some companies will still be working in Waterfall. My context, is that Agile and indeed being agile, is now how I expect to work and where I have experience.

Food for thought, the Scrum Guide defines a Scrum teams as consisting of:

  • Developers
  • Product Owner
  • Scrum Master

There is no role in the guide for Tester.

Modern Software Testing Principles

The Modern Testing Principles - by Alan Page and Brent Jensen have gained some popularity, and caused some controversy in the Software Testing and Development communities.

Some read the principles to mean there should be no distinct role for Testers, and instead all members of the team should share testing responsibilities.

Outrageous, you might a say, if as me you are someone who self-defines as a Software Tester.

But wait a moment, this also lines up with the Scrum Guide! So, what is there left for us Software Testers to do?

The many roles of the Software Tester

While I identify as a Software Tester, that has never been my exact job title.

Roles I have held are:

  • Software Test Engineer
  • Software Quality Analyst
  • Quality Manager
  • QA Engineer
  • Quality Engineer

In all of these roles, I have done some things that are similar, and some things that are wildly different.

In all these roles, I have tested software. With the exception of my first few years at Citrix, I have always been a member of an agile team. The different teams I’ve been on have all done agile differently, but I’ve always joined in with whatever ceremonies and activities the team as done as part of building software.

As part of agile teams, I have:

  • Written user stories and set acceptance criteria
  • Refined work items (stories, tasks, etc) and added estimates
  • Managed backlogs and prioritized work
  • Taken part in and run stand-ups and retrospectives

I’ve also done many other communication and glue work type of tasks. In one role, when working for a small consultancy, I worked very closely with clients. Reproducing bugs and even helping to determine if things where not bugs, but in fact missing requirements that may need extra payments.

In some of my roles, I’ve also done some very technical tasks, that you may or may not consider part of Software Testing:

  • Developed testing tools
  • Developed automated checking frameworks
  • Fixed bugs in configuration and code
  • Built infrastructure, software and hardware for test labs

Some of the things I’ve done, could of been done by a Product Manager, a Business Analyst, a Scrum Master, a Designer, a Software Developer, a Solutions Architect or one of many other roles.

Food for thought: Does this mean I’ve been doing loads of “not Tester” work? Or does it mean the role of a Tester has wide and varied, and can be flexible enough to fill gaps that could be taken on by other roles?

Besides Scrum Master and Developer, many of these roles are also not defined in the Scrum guide.

So who is doing all the testing?

So, if it’s not being done by Software Testers, whatever their role and title, who is going to do all that testing?

Are we really going to take a huge step backwards in the Software industry, and stop testing?

This is where we need to have a think about context and maturity. Some teams may well do just fine with testing being done wholly by people who are titled as Developers.

What about when your existing Software Developers don’t have experience in testing software? Or maybe their idea of testing is no more advanced then checking against the acceptance criteria and maybe some unit tests.

A Product Owner might take on some parts of what a Software Tester does. Some people I’ve worked with that have Product in their title have wanted to try things out for themselves, they have asked great questions in demos and given team good feedback. This works great when your team is making Websites or other software that can be demoed visually. It’s less useful for teams working on back-end APIs or libraries.

What about automation, you might say? Automation is great, and should be a health part of your software development process. In my experience automation is not sufficient to evaluate the usefulness of software, access its value or experience the usability, emotional response or goodness. I’ve also seen some pretty awful automation, that hasn’t covered risks and has missed the key, high priority parts of what a product should do.

When developing automation myself, I’ve often found it is the analysis and testing I’ve done on the journey to build it, that has found the bugs, not the automation itself. In my experience, automation is not the answer in and of itself.

Quality Engineering

The return of the Software Tester! But this time, we are more likely to be called Quality Coach, or as I am a Quality Engineer.

I’m still learning about Quality Engineering, and what it is like to be a Quality Engineer. I’ve been a QE now for about 11 months at time of writing. And so far, it feels a lot like being a Software Tester, but with a wider scope and some opportunities for coaching.

So, is Quality Engineer just another way of saying Tester? Maybe. I hope not. I’ve had some very interesting conversations about Quality Engineering with Stu Crock, Neil Younger, Jessica Bane and Dan Ashby. Full disclosure, I currently work with Dan at Ada Health.

All agree that Quality Engineering is about more then simply the act of doing all the testing, within the context of a single team. The topic of coaching and supporting teams comes up often, and the idea of teaching by doing.

Quality Engineering could easily include building frameworks to support other people to do testing. Advocating for a whole team approach to quality, and considering quality issues beyond the immediate deliverable of the team, software. Quality Engineering also includes work to improve Processes, Designs, and generally improve the support for teams to produce better products.

Like Testing, Quality Engineering is not the same to all people. The main question is still the same: Does Quality Engineering, mean we need people with the role of Quality Engineer? This is where there is some disagreement, and again it comes down to context and maturity.

Can you do Quality Engineering without having any Quality Engineers or Testers? Yes! At least Stu is currently doing just that right now in his context. He is in a context where he is the Head of Quality Engineering in a company that has no Testers, no Quality Engineers. And last I checked in with Stu, it was going very well.

In another context, Neil and Jessica are at Omnipresent. They are currently scaling quickly, with new teams coming on board often. Neil started as the only Quality Engineer, but is now hiring others to support him as the number of teams that get value from a QE is growing faster then he scan scale the support he alone gives.

Finally to my own context. I work at Ada Health, a health technology company operating in a world where our software is classified as a medical device, and such requires compliance with regulation. Dan started two years ago at Ada Health as Director of Quality Services, and has proceeded to build an amazing team of Quality Engineers, that I am proud to be part of. In my context, most teams have their own Quality Engineer.

As a Quality Engineer at Ada Health, I belong to an agile team. It has been an interesting journey finding my feet as a QE, working with Developers some of whom had never worked with a Tester (of any role or title) before.

As well as supporting my immediate team, I have the pleasure of extending my scope and working with other teams in my group to support their testing activities. I am having a huge amount of success working with the Medical Knowledge Engineers (Doctors) to bring practices from Software Testing to their world of testing for medical correctness and safety.

Testing Advocacy

Karen Todd has been doing an amazing job talking about Testing Advocacy, and working with the community to define the term. If you haven’t already seen it, I highly recommend you check out @KarenTestsStuff on YouTube, where she has a number of great interviews discussing the topic.

I have my own reasons for considering myself a Testing Advocate:

  • I support and promote the craft of software testing, at work and in the community
  • I support the community to recognize contributions to software testing
  • I coach others in the joy of testing

Long live Software Testers

Nicola Lindgren recently asked on Twitter if a job tittle matters. At the time of writing, the poll is on 55% Yes, 45% No with 88 votes cast and 17 hours to go.

The context of her question was about seniority, and if you would take a job with a less senior title when moving jobs. But another way to think about the question is if job role matters to you?

To me, it matters. It matters because it helps shape the way I think about the role, and therefore the way I set myself expectations and this influences actions I take. It matters because it shapes the way others see the role, and their expectations.

Job title and role are not the only thing that matter, and both can be overcome or outgrown by context and communication.

In summary, I have always been, and never been, and always will be a Software Tester.

Written on May 27, 2022