Get the most out of asking a question.
My view can by summarised something like this:
I wrote something about it here:
I have had many times in my career when managers have asked for different types of reports or information that doesn’t actually tell them anything that will help them make meaningful decisions - if we can help them understand the type of quality information they need, value can be created.
This sounds like 100% manual testing in a waterfall environment. It is the kind of testing and the kind of environment that I would reject.
I would ask what the value is in spending time on reporting instead of testing. Also, what dysfunction(s) is this activity trying to compensate for?
Yep,
Work with the team, talk often, and support each other.
If anyone else needs something ask them why, what for, and what’s the most efficient way to communicate that info to them.
Software development is typically a lie, in terms of working in teams. Why a lie? Because no teamwork happens. Look at how people organise themselves and collaborate in non-software approaches. For example, team sports.
In software teams, it is typically for people to work in secret and to make that work public, when they consider the work “done”. That is not teamwork. It is people working independently towards a shared goal.
If reports are being asked for, the interactions with “management” are insufficient. If it is all manual testing, perhaps the process is just too time-consuming. Solve this not by trying to improve testing, but improving the workflow of the entire system. Deliver much smaller increments, for example. That is, CI.
I like to share a Testing Summary.
Dashboard with the following fields:
Elizabeth Zagroba (@ezagroba) shares helpful advice in this Ask Me Anything video.
For me it tends to vary a lot on different projects.
My model though is likely very different from what you have for example there not really a testing phase though we do track what has been tested at feature and risk level so that can be viewed by stakeholders at any point.
We produce test session notes, everyone has access if they are really interested in the detail and testers thought process when they test but the important communication aspect of this is we include and exec summary aimed at developers, key issues found, questions, points of importance.
Developers not managers are our primary stakeholders, rapid feedback loops allow for rapid fixes so there’s no real backlog in testing over a day or two.
A couple are completely new products, so whilst the fit the above model we will also likely have what could be called a release phase, that will be a bit different as we’ll do a full system test there again alongside automated coverage even though most issues will have been cleared through the above.
This changes that report a bit as the primary audience is no longer developers but those who are receiving that release. Again though short, to the point and only things that would be of interest to them, we ask in advance what those sort of things are and adapt accordingly.