I like to take reporting back to a couple of fundamental questions.
- Who are you reporting to?
- What do they need to know?
The answer to those questions is not constant, so it doesn't make sense to me to rely only on a constant reporting style. If you're emailing the same report to the same people week after week regardless of the work being done, then yeah it's probably going to be ignored. What I suggest you do instead is arm yourself with a repertoire of test reporting styles and pull them out as appropriate.
The things that you're working on will be different. It stands to reason that your reporting should change to suit. If you have a suite of regression checks, then great. Are the results of those important to anyone outside the dev team? Who else do you report to? What are they interested in?
If you're doing standups, then you can report anything the dev group needs to hear about there (or at least tell the relevant developers that you need their time).
If you're reporting to project managers or product team or whoever, then make sure you speak with them to find out what they want to know about before you start testing. There's no use reporting a bunch of stuff they don't care about (the caveat to that being that it's information that they don't know that they need to hear).
Reporting isn't necessarily the soulless boring drudgework that you do at the end of testing. You don't have to turn in a novel each time. There are plenty of ways to report. Here are a few. Have a think about the different situations you might employ these:
- Drive-by reporting: As you head past your audience on the way to somewhere else, give them a 30 second update on your progress
- Mike Kelly's MCOASTER heuristic for when people stop by for a status update
- Paired bug repros: Grab a developer and show them a bug (or several) you've found
- 1 page / 1 slide status update - put the relevant stuff in point form on 1 page. Give it to your audience and encourage them to ask questions
- Low-tech dashboard: A whiteboard somewhere public with information for people to see and digest at a glance - James Bach has a good version of this.
- Test session notes & debrief notes
- Screen captures and/or annotated images
I'm sure you can think of more.