I recently carried out a TestSphere RiskStorming session with my Dev team and gathered a lot of data. I did however struggle to pull this together into a Test Plan to present to the team afterwards.
Is there any advice on the best way to collate this information? Should I focus on a few specific areas, should I ask the team which areas are most important, should I try and include all areas as these are the ones that the team chose to highlight. Any insight or advice would be greatly appreciated.
A risk map, which is virtually phase 1 & 2 visualised in a mind map, you can add green/red/amber tickets to the risks to indicate a shallow form of progress/status
In RiskStormingOnline.com, (the paid for version) you can save your session and edit iteratively. There’s a Fourth phase there which lets you log actions in the ‘who - what - outcome’ template.
a flat risk managment spreadsheet
My personal, current gripe is that, with ‘agile transitions’, I feel we’ve thrown Risk Management out the window together with the V-model and Waterfall stuff. It’s still a very needed and worthwhile activity!
This might also be one of the factors why testing suffers so often in projects from bad reputation.
The reason we’re there, risks, are hardly looked or discussed anymore.
RiskStorming is an easy way of getting that discussion back. Managing those risks afterwards is what we’re being paid for. I hope that with RiskStormingOnline we can support testers and teams in doing this effectively in the future… But I need more developmet power to achieve that.
Hope this helps and if you have any more questions, I’m always happy to chat: calendly.com/berenvd
We’re just a small company so won’t be able to justify the paid plan but a chat someday would be great. I’m a new tester and have never written a test plan before so it’s been hard to know where to start with the information I have gathered.
We have a brand new offering in the podcast space which is going to be public facing, so there are a few high risk areas to cover and test. I know what needs tested but it would be good to pull this into a one page plan, I’ve just never done it before.
I like the idea of the risk map though, this might give me/the team a better visualisation of what the risks are.
Context is king, Stephen. I suspect that Testsphere cards , although intended as an ideation tool, are not going to be context aware enough. Your test plan is going to want to cover all the things in your software creation, software publishing, and then of course dependent on the nature of the software the User Interaction/Experience (UX). And unless you have used them before, the cards won’t know your context. I love testsphere, but have only ever used them to “grow” or add new avenues to a template plan. You might, be at a place where there is no test manager, so that means it’s you! You will also be needing to create clear separation between strategy and plan , and also work out resourcing and time estimates. Things like what kinds of equipment, cloud storage and VM’s and networks will you need to even start to test. The Testsphere cards have probably given you a good “risk map”, and now you are itching to get started. A good place to start is to communicate well with stakeholders (developers are also stakeholders in this), especially about resource budget and time scale as you go. An actual “document” is less important than having a well communicated and “understood-by-all” plan.
I suggest finding an old thread on the forums that touches on test plans and then asking questions at the end of the thread. We really don’t that often object to old threads getting referred to or getting added to here, we are not that worried about zombies (or at least I’m not.) Or just link to and ask questions here. But it looks like we need more context to help more.
Is the product web-based, what is the subscriber model roughly going to look like? Basically is it B2B or is it direct to end user?
Is there a mobile client? Or is it a desktop app, or browser only?
Roughly what features are the most important ones and what “kind” of tech stacks, without naming actual vendors/products are in the picture?
As per usual DO NOT SHARE ANY SECRETS HERE, assume competitors may be reading, but give only as much detail as you feel comfortable. To start you off, here are some threads covering the topic.
It’s a web based app and we are adding a new offering which will add to our subscriber model but also be available to non-subscribers on a seperate paid plan. The new offering will be available to everyone, user to the world.
I’m thinking there might not be a need for a test plan per se, as I’m the only tester, but having something I can show/refer back to if someone asks “What tests did you do and how did you decide this?” would be advantageous. I like the idea of getting the devs involved to hash out what we can realistically achieve with testing and what might not be in scope, given timescales.
Welcome to Stephen. Sure, I mean I’m not on the pro circuit here myself, just been doing this a long time. but the reason you might write down your test plan is to help the next person, as well as yourself. A test report is often not a thing anyone will look at unless you are in a regulated industry. But I find it helps me track my progress longer term, while the test plan helps me track my goals day to day.
I’m a big fan of automated testing, probably because my previous career was in C/C++, so I like to have a excel sheet of all the manual tests and rank ones that I think can be automated with some benefit/value and confidence. That same sheet doubles as my test report for manual testing. So generally my plan is to automate as many as possible over time so that I don’t have to execute those manually. Trouble is, that sheet will grow and grow. The big part of my plan is however making sure I have a realistic idea of how the release works, who will be deciding on hitting the big red button, what we can do to help if we have to roll back/forward.
A podcasting app sounds way interesting, and will have so many aspects to cover because it involves so many components, and so many use cases. I assume you are talking Production here, not consumption. All kinds of things like RSS feed formats and the continuous updates and things like download stats now being shared as well as review support makes this a beast that wants some amount of focus to stop getting lost in. You are welcome to PM me, I normally only log in the mornings, and the rest of the time you stand a chance of catching one of the regulars when we drop into the google hangout www.bit.ly/testerhangout (google account required)
