Ideas needed for ways to approach testing summaries

Hi everyone, I have a question around what valuable information can be included in a testing summary to the whole team. Currently after a release we have a show & tell retro (roughly once every 2 months) which primarily involves the developers/POs demonstrating new features/improvements that they have worked on to the whole team. At the start of these meetings I usually present a testing summary of every bug fix & new feature/improvement that I have tested in this same period, categorised into feature space and then comparing these to the numbers from the previous release. I have been doing it like this because this was what was wanted but I personally don’t feel that just reading numbers vs numbers is giving much value. I was wondering how other people present summaries of their testing, interested to hear different approaches.

A question to ask your PO’s and developers:
What do you want to hear about testing (which will add value)?

In every place I’ve worked, the answer has been different.

In one place, they wanted a story about testing and the quality of the product, usually together with a demonstration. If I so much as mentioned a metric, I would lose my audience in a heartbeat.

In another place, I would focus on how I updated the tests, and the time it cost to make the testing changes, and how much it would (theoretically) save in the future. (For example, automating the update process for a hardware, by hand it would be a week’s work, automated is an hour, saving 39 hours (minus maintenance time), which is a hundred hours a year (given approximately quarterly updates, hardware doesn’t move so quickly).

In yet another place, they wanted just the metrics. Nothing else. So “753 tests via automation, 63 tests by hand, 98% passed, the failures are X, Y, Z, which are blocking/not blocking. Have a nice day.”

6 Likes