Test Plan Overview – Examples/Successes

[Nicholas]

Hi everyone,

Presently my company has a wiki page test plan overview for each item of work completed by a team (think approximately a 6-8week unit of work.) This is the first time I’ve seen such a thing used and I must admit I’m unimpressed. It seems like everyone copies a template which largely states some very brief information specific to their unit of work, then reams of template text regarding the types of testing that will be carried out.

I’ve mentioned this seems useless to my manager but I’m fairly new here so perhaps I’m missing some detail. Still my manager can see something in what I’m saying and wants to overhaul it, the current Idea is a table/matrix at a higher level. I’m implementing this as we speak but I wonder if anyone else has had a similar scenario and I’m wondering what they have done?

I’m told the use case for this is so management have an idea of what testing is being done at a high-level as well as external dependencies. I’ve argued this is waste but we’re going with the compromise for now

[Jesper]

Was once in a development shop that had the whole story as a wiki page, with a template to match: High level design, tech details, testing, acceptance criteria etc. It was a living doc being augmented all the way to “definition of done”. About the same amount of work that you mention. The dev tool then had some gates for the story, with some checklists to consider at the various points:
– Feature ready: is there a high level design, is there an estimate, acceptance criteria etc
– Feature ready for test: is there testcases and automated checks
– Feature done: Nothing to declare, ready to ship.

But a wiki is just a tool, I can remember the above scenario with word templates too – I know I wrote the templates 🙂 Perhaps you can rewrite the template to have more open questions – or perhaps be more of a install wizard or survey monkey – I have wanted to do that for a long time. Sometimes what is required is 80% standard text and references, and then 20 specific content.

Perhaps you can do something wiki hyperlinked magic that ties/links the high level testing areas and external dependencies to the specific test plan.. perhaps it would make great decision input to have a wiki page for each integration etc.

Jesper, here are some blog posts for further reading:
http://www.stickyminds.com/article/using-business-decisions-drive-your-testing-coverage

Asking Open Questions

[Anonymous]

Hi Nicholas,

Much like Jesper mentions, this is not limited to wiki pages, I have this issue in my present work with Word documents so I share your frustration.

I’ve taken 2 steps for my sanity with favourable results. Firstly I’ve taken the template and binned most of the sections which where of little value and tried to focus on the core information. Secondly I’ve engaged with the govenance areas who were insisting on using the template to understand what information they needed to see.

By stripping down the template to what I’m testing and how I’m testing it I have a much clearer story to present to the readership. It has also given me worked examples I can use to work through with the governance guys to see show how streamlining the information means they still get the info they need but its in a better format and arguably more importantly means we, as writers, will not waste time with a process we know adds no value.

[Nicholas]

Hey guys,

thank you for the responses, it’s good to know I’m not facing an individual problem and I suspect this has been coming up time and time again over the years.

As mentioned we currently have a matrix, each row comes from a ‘Feature’ so it can be easily mapped to other team documents surrounding the work for the next few weeks. We then have it broken down by column in terms of the types of testing performed at each stage. For example on my dev machine I’ve run our functional tests, on integration environments I’ve ran our manual smoke tests and any other team depending on our application/component will run their smoke tests. It means there’s an easy ‘checkbox’ feel for the high-level. As it’s early days, I’m afraid I cannot report on how successful or useful this is!

I’m still looking for any other examples from people who think they’ve got it pretty nailed down?

Thanks,

Nick

[Dmitriy]

Nicholas wrote:

Hey guys,

thank you for the responses, it’s good to know I’m not facing an individual problem and I suspect this has been coming up time and time again over the years.

As mentioned we currently have a matrix, each row comes from a ‘Feature’ so it can be easily mapped to other team documents surrounding the work for the next few weeks. We then have it broken down by column in terms of the types of testing performed at each stage. For example on my dev machine I’ve run our functional tests, on integration environments I’ve ran our manual smoke tests and any other team depending on our application/component will run their smoke tests. It means there’s an easy ‘checkbox’ feel for the high-level. As it’s early days, I’m afraid I cannot report on how successful or useful this is!

I’m still looking for any other examples from people who think they’ve got it pretty nailed down?

Thanks,

Nick

Here is good templates, maybe it will be good for you.
https://strongqa.com/qa-portal/testing-docs-templates/test-plan

[Stephen]

I’m currently designing and implementing a Test Dashboard for our management.
We have many projects going on at the same time, some in planning, some in design, some in execution, some in early life support, and others closed.
The risk with a dashboard is trying to provide to much information. Currently we are limited to SharePoint and tables, we don’t have a suitable test management tool for this, or links to the Project data maintained by others.

So I’m providing a simple line for each project that includes,
ID, Customer, Title, Description, State of the project (Inception, Assessment, Design, Development, Testing, Release in early life care, released and project closed), RAG status (Red and in trouble/needs help, Amber and at risk but in hand, Green and all on target), Test Manager/Lead, Project Manager, Various milestones (Test Plan signed of, Test Scripts signed off, Test Schedule agreed).

From here the management can drill down and get a project management style Quad Chart showing main issues, Acheivements last period, actions for next period, and more detailed milestones with dates and status.

From here they can drill down further to the standard Metrics produced from test management tools.

The Metrics are automatic, the Quads are a weekly manual update, the dashboard is part manual and part managed by the PM.

It does feel like a lot of work, which is why I’m also scoping out a test tool. Currently gathering/analysing requirements from various users (Testers, Test Leads, Test Managers, Stakeholders, Customers, Management and Senior Management – anyone that could find it useful or be a customer of the information it can provide)

I don’t think I have it nailed down yet, but currently my daily reports are eagerly anticipated by senior management and the dashboard is proving useful and generating the right questions – i.e. questions that show management know what is going.

[Author]

Posts