How do I explain the testing role to my team?

In January this year I made a commitment to myself to get more involved in the testing community and to start helping others within my organisation understand what qualities testers can bring to a team other than “checking stuff works”.

It’s a noble cause and one I felt I could tackle, so much so I included this as one of my personal objectives for the year. In order for me to better communicate my value to teams, I’ve been studying testing as a craft.

I’ve been keen to understand how to frame conversations so that people see more to me than a quality gate (of which I am nothing of the sort). My hope was that through coaching and education, my team would be able to adopt my methods and the “T Shaped Team” pipe dream would become a reality.

This has been a frustrating experience though, I’ve been left out of conversations as they were “too technical”, asked to “sign off” a product numerous times or at the opposite end of the spectrum been assured unit testing (which I played no part in) covers the testing of a feature therefore I did not need to look at this one.

I’ve been reading “Lessons Learned In Software Testing” by James Bach, Cem Caner and Bret Pettichord. There is a lesson in there that struck a chord with me.

Lesson 15: “Don’t expect anyone to understand testing, or what you need to do it well”

For a long period of my career, testing was something I saw a job many people in the team could do. I had my place of course, but other people could help because there were more developers than testers (usually).

I’ve been a strong advocate for pair testing in my team (something that has worked wonderfully recently) and even floated the idea of mob programming which I thought would aid in my quest to providing insight into the value of testing whilst simultaneously building the product (faster feedback is never a bad thing).

I’ve come to the realisation though that non-testers don’t get it (and that’s perfectly fine). We’ve generated test ideas as a team and even improved unit and integration test coverage but when I leave them to their own devices, the mindset dissipates.

To put things into context I could pair with a developer on a story and they could coach me through writing high quality code. I could in some cases, even go away and write code based off of what I have been taught and deliver a feature. The problem though lies in the tacit knowledge a developer carries when we pair. Explanations about development that go way beyond the boundaries of my knowledge (even for someone who considers themselves a fairly competent programmer).

The same applies to testing. Under a testers guidance, a developer (or a product owner or any other non-testing professional) may feel empowered to help test a product but leave them alone and they could feel vulnerable as their guide is no longer on hand.

In order to truly help people understand testing, the tacit knowledge we hold in regards to our approach should be brought out in the open and explained in a systematic manner.

I try to frame most of my conversations around risk these days. What are the risks with the product and do any of them threaten the value of the product to the customer?

I am of the belief that if the conversation centres on the context of why testing is a thing, people will start to understand it’s true value.

Generating test ideas, while a skill in it’s own right is only half the battle. Relating them back to potential risks in order to convince people of their importance when it comes to mitigating them is the just as (if not more) important.

I have started to undertake the task of correcting anyone who suggests I sign a product off to be released. I do no such thing. I inform, advise and update all interested parties on the current state of the product.

When deadlines are tight, decisions may need to be made in regards to how work is prioritised. As testers, it is our job to present the information in such a manner that allows product owners and managers to make informed decisions in regards to priority and customer suitability.

Closing Thoughts

In closing, I still feel like I am not quite fully there but my team is getting better at discussing testing day by day.

I hope one day, I’m not relied upon. I’ll always have my place on the team as the testing specialist but if I am unavailable our work shouldn’t suffer or worse, come to a grinding holt as a result of it.


5 thoughts on “How do I explain the testing role to my team?

  1. > been assured unit testing (which I played no part in) covers the testing of a feature therefore I did not need to look at this one.

    The greatest success I’ve had in demonstrating my worth as a tester has been by finding critical bugs that made it past unit tests and any other “testing”. (I say “testing” because often what people did was mindlessly follow a pre-written script instead of actively exploring the application). Everything else flowed from that. Developers would ask how I manage to find the bugs, giving me the opportunity to discuss the kind of mindset, practices, empathy, and involvement that support effective testing. I’ve had more success getting developers to understand an effective testing mindset than I’ve had with some testers.

  2. Nice post Chris, thanks for sharing!

    I like how you’re focusing on product risks. I’m interested in understanding how that plays out in your team – Is it only you thinking about the risks & related test ideas to help mitigate those risks?

    Also wrt to your statement “When deadlines are tight, decisions may need to be made in regards to how work is prioritised”

    Have you been in a situation where the team has deprioritised testing due to tight deadlines & did you use the risk conversation to try & get testing back on the table? If not, what were your other strategies (if any)?

    Thanks in advance,


    1. Hi Duncan, thanks for commenting.

      So for the most part it is just me who is asking questions related to risk but that is slowly changing. I’m relatively new to the team so product knowledge wears a little thin sometimes and I simply ask, “what are the risks with this change?”

      To my teams credit they have never brushed the question off with a meaningless answer. Our planning sessions have started to be framed around WHY we are making the change and risks that come with that reasoning.

      As far as prioritisation goes my thought process here was more about acceptance of risk rather than completely negating testing all together.

      Thankfully I’ve never been in a situation in my current role where I’ve had to defend testing. It could be that during an exploration of a new feature that I identify a risk that can be exploited by doing X, Y or Z. A short conversation with the Development Lead and Product Owner allows us to quickly ascertain the threat of this risk in a customer facing environment and whether this needs immediately fixing or we can commit to fixing in the next sprint.

      This was actually a struggle for me at first because as a tester I always thought bugs should be fixed immediately if we find them but my job is simply to inform the people around me of my findings and then as a team we can accept them or reject them assuming the risks of doing so have been clearly communicated.



      1. Love starting with Why! 🙂

        Thanks for elaborating – great to see the learning from experience in order to be a more effective team member.

        One last comment – I promise… “my job is simply to inform”. Is it?
        – what’s simple about it? (I bet informing can sometimes be tricky)
        – do you only inform, or are the team looking to you for some qualitative feedback as well?


      2. I’ve recently had a conversation with a colleague of mine about this, it’s an idealistic view if I’m honest. (Simply Informing people about a product)

        Using the word simply probably doesn’t do it justice either.

        My choice of words were based around the notion that my role is concerned with providing people with information in order to help make decisions rather than making the decisions myself. That being said I see it as a group decision of the entire team to decide when a feature is release ready.

        “Inform” is also a little cold and I do try and frame my feedback in the form of “how do I feel my findings reflect on the quality of the feature”. Which again comes back to risks. My findings threaten the product value via these risks identified. (Does that make sense?)

        Also, informing is definitely tricky and I’ve found it challenging presenting findings to different stakeholders. Language used is so important (I could probably write a whole post on that – that’s next month sorted! 😀)

        Again. I love the debate. Thanks for engaging

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s