MoT Glasgow - Communicating Testing Value

We had a really interesting evening discussing about communicating testing value. This was a topic voted for by the attendees, and it’s clear that there are still organisations who have yet to realise all the ways in which testers can help if given the support.

We structured the discussion around the following three points;

  1. Understanding what value we add, and how / when / where we add it
  2. Understanding to whom we add that value
  3. How best to influence / educate / communicate with those people

Understanding our Value-Add
The attendees came up with a believable but still bewildering array of ways that testers can and do help their organisations;

  • Automation coverage
  • Work with developers to come with automated test cases
  • Canary in the coal mine
  • Challenge requirements
  • Communication with other operational roles (up and downstream > Be more Salmon)
  • Context in which a product will be delivered
  • Continuous improvement
  • Putting the customer first at start of development
  • Move from documentation to prevention
  • Find out the known and unknown
  • Governance
  • Holistic view & understanding of Project
  • Information Gathering and Dissemination
  • Improve user stories
  • Improve requirements
  • Improve business’ tech understanding
  • Testing the process (we often have information that could help make other processes work better)
  • Process Improvements
  • Product Knowledge and understanding
  • Product / domain expertise
  • Proper integration (bringing parties together)
  • Risk Comprehension & Management
  • Quality Feedback
  • Having the system-wide view
  • Discussing testability with issues
  • View of other testing types which need to be carried out
  • First user of the system
  • Unspoken requirements
  • Engineer find one way thing works. Testers find ways things won’t work

Who we add value to
The subtitle to this section that someone came up with is “Stepping out of our lane”, something that’s come up in US politics recently. Again, it’s a fairly long and comprehensive list;

  • Those who pay the bills.
  • Stakeholders - PM, Users, Team, Support, Business, Customer
  • Decision maker
  • Product Owner
  • Project Manager
    • We can add value to project management by making suggestions.
    • There can be too much focus on the plan and dates, not the actual deliverable.
    • Identify clashes - project scheduling / smooth process
  • Developers (defect prevention), in our team and in other teams
    • Test can deliver value to developers by asking questions that open up complexity, or otherwise help them to understand better what they are doing.
  • UX - testers can add value by helping prevent horrible applications!
    • Not Just working software, but also “not horrible” software.
  • Test Managers
  • Other testers
  • Operations
  • Training
  • Customer Support
  • Customer Representative
  • Customer / End Users
    • We ultimately serve the end-users - however we test, it should result in better software for them
  • Auditors
  • The Environment (the ethical dimension)
  • Anyone who has in interest, Across the board
  • The Disenfranchised

In short, “step out of your lane” and realise you can add value to anyone and everyone even tangentially associated with the product or project.

How best to influence / educate / communicate
Finally, we came up with some tips to get people on your side and to educate them on how you can help;

  • Grow Trust
  • Be Persistent
  • Be pragmatic
  • Be vulnerable
  • Earn respect
  • Deliver value
  • Be aware of your audience; use terms they understand and a medium they like
  • Sell the benefits, don’t point out the issue
  • Own the story and make it credible
  • Change the story; finding the bug is not the celebration, preventing it is
  • Go to meetings / visit teams you might not have traditionally
  • Look at metrics - use one they understand and tell the story
  • Give options, offer solutions
  • Involve people and give them ownership to get buy in to testing value

Some misconceptions we might have to dispel;

  • We do best at fire prevention, not fire fighting
  • We believe people are doing their best
  • We are there to ask the challenging questions
  • We are not trying to have an argument, we’re trying to improve the process
  • We want to drive the improvement, not be a roadblock by breaking software
  • We want to understand your goal and help you meet it

Lots of great points from the attendees, so thanks to everyone who attended.

Hope you find it useful :slight_smile:


This was a fab session and I can see me referring to these notes again in the future. Thanks for organising and transcribing in such an organised fashion!

Great great information for me. Surely going to have this discussion at our meetup. Thank you!