The hidden project stakeholders Henrik Emilsson
This was originally a response to Rikard’s post “Multi-Dimensional Software Testing”, but here I have developed my thoughts a bit.
As I see it, there are more or less obvious stakeholders and stakeholders that might be more or less hidden. A “customer” might be such an obvious stakeholder. It might then just be a matter of recognizing which of these “customers” that matter and take those expectations into consideration when selecting test activities.
The project manager is another example of an obvious stakeholder.
And a product owner would naturally be considered an obvious stakeholder.
But how about the hidden stakeholders; and what are their interests in the project/team?
Maybe the members of the test team would have interests in the team’s work that would affect the testing activities (i.e. their own work)? Someone in the team might be dependent on other peoples work. Some people in the team might lack important skills which would affect the chosen test activities. Are there some people that only can work part time and thereby affect which times meetings are held in the team?
The members of the test team are them self stakeholders to the project and might have important interests. This might have impact on the testability, documentation effort, release schedules, communication, etc. Project members other than the testers are also stakeholders to the project and they might have their specific interests.
Business managers might have much to say about the testing activities; and they might especially be interested in the cost of the testing activities. They might have influence on hardware or software that would be needed and thereby affect the testing activities.
Other test groups that work in parallel might be interested in the outcome; and especially to make sure that your team doesn’t over-deliver and make their team look bad. And they might be interested in what type of cooperation that could take place in order to be more effective. They might also have an interest in what type of reporting to do in order to compile a common test report. Other test groups might also be interested in creating a common vocabulary to use in the test scripts.
The maintenance team that would receive the product after it has been released might be interested in the outcome. And especially they might be interested in the format of the test product i.e. documentation, test scripts, procedures, etc. They might also be interested in good practises that have come up during the project; and if these good practises were designed to work for the maintenance team, they have indeed already affected the testing activities in your team.
Certainly there are more hidden stakeholders than those above to take into consideration when selecting test activities or test strategy to focus on. But my goal is to illustrate the problem with a couple of hidden stakeholders in order to make you think about your situation and possible stakeholders that might matter for you.
Note:
Many of these stakeholders are already taken into consideration on a daily basis, but I believe that they are not considered as stakeholders. Maybe you would discover more important aspects of each stakeholder if you tried to analyse each of them more thoroughly.
E.g., try to list all people or roles that matter to the team and start to analyse what their interests are and how they might affect your team/project.
And you should not be surprised that some of these were hidden to you at first, and when their interests are revealed you might discover that they would have a large impact on your testing activities.
I’ve noticed that many projects have a vast amount of agendas from different stakeholders when it has to do with quality. In some cases the agendas go in opposite direction. It is extremely good to know your stakeholders and what their agendas are.
You might need to weigh the stakeholders, who has the most influence? Is it better to satisfy the CEO or the QA Manager? Does the customer come last? In most cases it has to do with politics.
This is very interesting! And adds a lot more complexity to the context-driven statements regarding “testing as a service to stakeholders”.
It makes sense that I, as a tester, is a hidden stakeholder. But how important?
I remember doing “Guerilla testing” on a sub project where we knew that the test lead had done a louzy job. We did hidden testing to prove our own worth, to “frame” the test lead (yes, that was not so nice and quite childish) and to report enough bugs to stop the release. Everyone else was satisfied with the release, but we knew it was tested far too little. We have different agendas when testing.
[…] you satisfied with your tests? Are your (hidden) stakeholders satisfied with your […]