How Do You Make Your Testing Visible To Stakeholders?

I’ve seen this question pop up so often recently in various forms!

how we make our day to day activity as testers visible to stakeholders (devs, management, etc)?

@ckenst had some excellent advice about this when the latest question came up:

My suggestion is to talk with your stakeholders and figure out the best way for them to consume this.

which @tybar backed up with

This…I spent way too long at the start of my career trying to write up lots of documentation that no one ended up reading…figuring out what people actually want to know from your work is pretty big.

@rightsaidjames offered

IMO the best way to increase the visibility of your testing activities by making the outputs of said testing visible to the stakeholders who matter to you. This might be through narrative testing reports (perhaps with screenshots and a list of findings) on Jira issues, or via a test results dashboard that shows recent runs of your automation. You could also make it so that certain automation failures block deployments, which would have the secondary benefit of making your colleagues aware of the specific guards you have put in place to stop certain feature regressions from being deployed.

What have you tried to make your testing visible to your stakeholders?


This is a really interesting subject and is really context specific.

I agree with @ckenst that it depends on the information that the stakeholders require and how they will consume it.

Reams and reams of reports aren’t really that useful, but neither are metrics that don’t inform anyone of the confidence that we have in this current iteration of the project.

I’ve had some success with the use of metroretro boards that capture a general feeling of confidence in the product, as well as things like identified risks, bugs or whatever else is useful for the stakeholders.

Dashboards in JIRA are good for capturing some testing activities and bug tracking, but don’t necessarily tell the whole story.

I’m really interested to see how others get over the whole reporting conundrum.

The Testing Peers recently had a podcast episode on reporting:


One of the main rules of communication is know your audience so before you report anything to anyone you need to know who that anyone is and what they want.

Another good rule is if your different audiences have different needs they get different communications. Like a project manager might just want to know if there is some impediment that they need to help resolve. A fellow tester might need to know what test areas remains so they can pick up items.

Another tip on the way is that the main output of testing is information. Typically the main information is “What is the state of the product and what threats to the business does it contain, so we can take an informed decision if we will make this available to the customers or not.”. Which is not the same as “I have done all my planned testing.”. As already mentioned this is a very context specific thing to communicate. Both the people that you communicate to and the domain you work in.

In one place I worked we produced a test report (one page only) after each sprint (2 weeks) and put it up on a wall in the office. Then all the managers and stakeholders had a meeting and they walked to this wall and had a look at them. Then we came up with a little feedback loop where you can introduce “Was this information useful to you?” and from that change the report according to that feedback. This was a very educational experience.