Howdy all,
this is my first question in the forum. Could anyone please share their experience conducting a test plan walkthrough with project stakeholders? And if you could also mention challenges that you may have come across during the walkthrough and techniques that you used to overcome those challenges? Thanks in advance.
Who are the stakeholders? What are you trying to achieve from it? Are you trying to share your test approach and strategy? What level of details your stakeholders are interested in?
Would a visual representation do the job? Or they prefer pages and pages of texts and some graphs?
Hi Luke, thanks for your response. I would say my stakeholders are development lead, project manager and the delivery manager for the proposed release/sprint. I was never in a test manager/lead role so personally I have never done it myself. But I have noticed my TM shares the test strategy/approach with other project stakeholders in a word document (usually around 30-40 pages) which often didnt receive any feedback as most of the stakeholders never interested to read through the lengthy document. So I have created this this thread to find out how others in this forum are doing this? Please advise if you were to present what kind of information would you present why do you think that is necessary? Thank you
I have done a few of these and to begin with I just walked everyone through the plan but these were useless as never got any useful feedback, all the developers tune out very quickly so just me talking at them for an hour.
So after a few times of that I switched it up and asked them which areas of the project did they have concerns about or was there anything they wanted to make sure we knew about. That then puts the onus on them to drive the direction of the meeting and makes sure that we either finished the meeting quickly or spent our time getting useful actionable feedback.
Newbie post.
My client is not so much interested in QA per se, so they dont really care about the planning and work products. So when I tried to present test plans and strategies, never got any valid responses or suggestions. seeing this approach not working, I went for a master test plan that covers the end to end strategy without specifics and presented it up to the technology leadership which got approved. Once it came to implementing individual projects, there wont be any specific test plans, but just the detailed test case which gets vetted by business users. By this approach, qc resources are spending time only on what my stakeholders need for the particular project.
Try brainstorming on risks and mitigation plan as a group. Mindmap can help if the stakeholders are keen.
At end of the day, quality is a team responsibility. It is unlikely be in a lengthy test plan or strategy, especially if it is for Sprint (2 weeks?).
A summary of the discussion afterwards, is your plan and strategy mostly done plus some specific requests you may have 
That’s what I did in Sprint refinement in my previous project (dev manager/lead, PO, test lead and anyone else required at the time).
I thought it worked well without the lengthy document
I had a similar problem once, but with review rather than a walkthrough.
We had a complex document with a lot of unneeded content that was difficult to read (i.e. using the template from ISO and/or IEEE, depending on the time). We couldn’t get anyone to read it enough to sign off on it, which hindered the testing, since we weren’t supposed to do anything that wasn’t approved.
So we switched it up. We ditched the official looking documentation for a readable document. We reduced the length of the content by more than 90% by removing anything that wasn’t required for US (rather than required for the template).
And that wasn’t enough either. Finally, out of a bit of desperation, I created a “visual” document of our plan/strategy, starting with a mind map. Suddenly, the team was interested. They could see on just a couple of pages exactly what we intended to do or were doing. And they started offering feedback based on the few charts we offered, which improved our testing.
From there, we revised the “mind map” method a bit more to more customized visuals and models, but kept most of the documentation visual. The team loved it, and started producing more of their own model-diagrams for their own portion of the work (i.e. system design documents and UML-style drawings).
To sum up, I’m a huge fan of, as @testerawesome said, “Visual representation” as a supporting method of communication.
Thank you everyone for your valuable responses. Seems like plenty of others travelled down this path before I posted the question. To conclude visual presentation would be the way to go and mindmap with charts proved to be efficient. Does anyone have a template or a web reference for this mindmap/visual test plan? I’m sure content is different for each project/organisation. But if you could please share a reference for head start would be grateful. Thank you
I glanced through a few of these, and thought that this one might be especially useful to give you a starting point.
After this, I find user journey mapping (taken from UX design) or user story mapping (taken from various other methodologies) to be very useful for two reasons.
Example mapping, while intended as a specification or design tool, will also help with creating testability if used correcly. Even better (or worse, depending on your point of view and your team), example mapping brings in more team members.
While Katrina Clokie’s blog is worth reading as a whole, this one in particular may be helpful:
Or better:
http://katrinatester.blogspot.com/search/label/Visual%20Models