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