Ever been in a project where it seems like everyone agrees on the requirements? If so, did you believe them? Or did you try to get below the surface to find out what truths the different stakeholders are carrying?
Quite some years ago I was called in as an acceptance test manager to an organization within public service that had ordered a customized it system from an external vendor. They knew what they needed the system for, but since the technology was new they had a hard time imagining exactly how the technology could help them working smarter and better in the future. But they trusted the vendor to help them with that.
- ‘We haven’t used a computer system for this before, it’s been managed by fax. We are a number of organizations who need to align around and use the system in order to be able to collaborate. And we have a really good booklet describing our processes and everyone knows what’s in it’, they told me.
The system was to be used by several public service organizations who had to cooperate around different tasks in order to serve the public. I read the booklet and it described on a high level what was expected from the different public organizations regarding the task. It was far from a “How to”-description of the day-to-day work. I needed to dig deeper to understand what to test.
Let’s do some workshops
My great fortune was that I had the privilege to have access to a group of representatives from each public service organization along with dedicated project members on the customer’s side. You could say that there were 3 major stakeholders (not development, maintenance, operations, etc. included), but that was not the whole truth, since each “stakeholder” consisted of several independent organizations or departments and their management was not always the same, even if it for some was the case.
I gathered all the appointed representatives in the same room to a number of workshops to have them help me to document how they worked together.
- ‘It’s all very easy’, I was told. ‘Everything is described in the booklet and we all know what it says. This whole exercise might be quite unnecessary.’
I explained to them that I had read the booklet, but that I needed to understand exactly what was done by whom in each step. And now the fun started.
Tickets to EuroSTAR 2019 Now Available – Book Now and Save!
The approach was to create activity diagrams and from them create use cases and then test cases (this was a few years ago J). It turned out that nobody agreed on virtually anything in the process. Everyone had their own interpretation of the booklet. Not only was there disagreement on how they should work between the different organizations. There was quite some disagreement on how to handle the work even between the same stakeholder’s representatives (same type of organization, not the same management).
After 4 working days with somewhat 15-20 people in the room we had 5 activity diagrams everyone could agree upon. From these 5 activity diagrams 28 use cases were written and out of these somewhat the same number E2E test cases were written.
Based upon the work in the 4 workshops we tested in a number of iterations over more than a year. We used a risk and requirement based approach when testing. Another gain that came along with these workshops was the huge amount of knowledge around the business that was gathered in these workshops. This gave the base to document the process for future use.
So, what is the great wisdom from this experience?
I would emphasize that you should not take one person’s (stakeholders) point of view as the whole truth. Every stakeholder has his or her own truth. Are there several people representing one stakeholder? Great! You are lucky! Now you can get more truth out of it. And maybe even get the different people to align around a solution and if not everyone gets exactly what they want, they at least understand why it looks like it does.
About the Author:
Katjana has worked in the IT business since 1998. She started as a programmer, continued with configuration management and since 2005 she has worked with test management. She has a wide range of experience and has set up test processes, test policies and test strategies on an organisational level. She has managed small and large projects on both acceptance and system test level, managed a large test center for a well known car manufacturer, worked with test case design and as a tester.
Katjana’s focus is on the customer benefit and their business.
If you want to read more from Katjana, check it out on LinkedIn. https://www.linkedin.com/in/katjana-brandt-a3159b3/
