While attending the Fall 2016 Test Master Academy “Reinventing Testers Week” in NYC I found myself again discussing the topic of titles. Many in the testing community don’t like the term “Quality Assurance” and don’t like it used at all when discussing Testing or Testers. While I agree that it is not an accurate term I don’t have the same allergic reaction to it. Currently at my company we still use the Quality Assurance title.

It’s a problematic title. Are we, as individuals, able to actually assure quality? If we’re honest with ourselves then answer is no. The act of testing itself does not raise or lower the quality of a product. In addition quality is, and should be, the responsibility of everyone involved in a project. Having a title of “Quality Assurance” potentially gives the wrong impression on what that person does or has control over.

However, if we acknowledge that Quality Assurance isn’t accurate then there are similar problems with the community preferred title of “Tester”. It gives a very reactive rather than proactive connotation. If someone is a Tester then it is assumed that something needs to be tested. If you don’t have anything to be tested then why do you need a Tester? Why include them in planning or the project at all until you have something for them to do?

For context my company is project based rather than product based. That means there are many different projects of different sizes and lengths going on at once. Part of my job includes estimating how many QA each project needs and for how long. I’ve had many conversations during this planning stage where QA are originally scheduled to start in Sprint 2 or 3 of a project in order to save a little budget because “there really wouldn’t be anything for them to test yet”. I explain that QA has set up, design reviews, documentation gathering, user story reviews, and testing smaller unfinished pieces to name just a few things that we do at a start of a project. There is plenty to do on a an Agile project. Falling into mini waterfalls of testing is a common anti-pattern of Agile and one we work hard on avoiding.

We can’t be reactive. We can’t be seen as people who are only brought in once there is something to be tested. That’s why I refer to “Tester” as a title as limiting. I want those who identify as Testers to be part of the planning process. We know common pitfalls and can work with our teams to avoid them. We have a lot of useful insight in design and requirements. Many nonfunctional requirements such as accessibility, performance and security to work on.

I love testing. I love people who call themselves “Testers”. My concern for the accuracy of the title is not a reflection on those who use it. The same for those called Quality Assurance such as myself. I want to make sure we are seen as equal contributors to a project. I want our testing skills to be seen, understood and valued. Titles can help or hinder that. If we have concerns about title accuracy then we should look critically at the alternatives as well.

In the end I don’t have a good alternative to either title. We keep “Quality Assurance” as that is what our clients use. We work hard to set clear expectations about who we are and what we do to offset inaccurate titles. I think our craft is evolving as are all crafts involved with software development. Solution Architects have become Technical Architects. Business Analysts have become Product Owners. Roles and responsibilities are shifting. We need to be prepared to evolve too. That might mean creating a new title that better fits modern approaches to the traditional testing role.

Personally it’s something I’ve been thinking about but don’t currently have a solution for. This is a very hastily written example of my thoughts on the subject intended as a springboard for further analysis and discussion.

I’m happy to hear from others as I continue to explore this topic.

• Medium