Continuing Testing Education of Non-Testers

Over a decade ago, we executed a testing transformation at the enterprise level. The intent was to define testing boundaries, introduce risk-based testing, and, in general, attempt to provide some consistent method of testing across multiple platforms. Our testing community had a spectrum of responses as you might imagine but eventually, in my opinion, embraced the transformation and made it their own. A less subtle intent was to help non-testers understand the effort of testing.

Always one for experimenting, I encouraged testers to adopt all the aspects of the transformation and even struggled with them as we attempted practical implementations of risk-based testing. I attended (and presented) at STP Con during the early part of the enterprise rollout. After a attending a presentation by Bob Galen, I asked him about culture change and an expected time period. He said it takes about three years.

Through the course of three enterprise level projects (about 5 or 6 years), I saw testers embrace the transformation and some even became advocates. I did my share of educating non-testers (mostly project managers) in both the testing and the transformation.

I recently started on a new project in a Test Engineer Lead role. I’m finding it profoundly frustrating to still have to educate project managers who have been at the company as long or longer than me. In my opinion, they still think of “work” as developing the product and think nothing of inviting only developers to key meetings.

Still, I will forge ahead and have “The Conversation”. I advocated for this during my STP Con presentation. It goes something like this.

With the introduction of the Testing Transformation, and especially with the adoption of agile methods, developers and testers have become equals on a project. The benefit and value of their collaboration has been demonstrated on . One reason why this succeeds is they, testers and developers, have equal representation at planning, requirements, and design meetings. I would like your help in continuing this level of success in creating high quality products at a good pace.

Even this conversation - at least parts of it - require, sigh, iteration.

It’s 2019 and one would think the world knows that quality is a team sport.

If you experience this then I want you to know I support you. If you haven’t experienced this, I encourage you to embrace the fear and have a frank chat with your PM. I believe we, fellow testers, can make this culture change one project at a time.

Thanks for listening!



Reading this makes me appreciate even further the way we work here. Product owners and QAs work closely together, sitting on calls with clients and so on. Thinking about it, maybe the term ‘tester’ is an obstacle here. To some outside of the trade, it may be seen as someone who comes into play at the end, to… test the finished product rather than being involved at all stages, which we all know is an old fashioned way of thinking. Then, though, we get into the problems with the term ‘QA’, and how quality can’t really be assured (I prefer Quality Advocate anyway).

Thanks @chris_dabnor and thanks for reading!

I concur - Quality Advocate, Question Asker, Quality Accomplice ANYTHING but QA!

Since you mentioned it, I’d be happy to explore alternate terms for “tester”. It should be descriptive and invoke a sense of adventure, curiosity, humor, intelligence, and sagacity.


Guru? Mentor? Not sure whether the word quality would still fit though. And you may have answered a question inadvertently. I’d written Question Asker > Quality Advocate > Quality Accomplice and didn’t know where it had come from. Seemed a bit too smart for me to have come up with…

Quality is a team sport and that might catch on as DevOps sees a wider implementation. I expect the traditional project roles to evolve.

Regarding the alternates for QA, I mused on this a while back here. I think this could be part of the education but I believe testers should take the lead on their participation in projects.


Sorry, that’s where I read it, but had failed to put your name on my notes. Really good article by the way. I’d started to do a mind map with those titles in the centre to try and form ideas of how and why to implement them (as I grow into the role of departmental head, the why is becoming more important in shaping the how).

I think that people are aware of the need for quality, but there’s a difference between being aware of it and actively engaging with it.