I want to completely renew my testing documentation and it raised a question “Why do we need a separate test plan and test exit report”? Has anyone combined these 2 documents to make just one, if so how? I was wondering about a one-page test plan and a one-page test exit report in the same document and call it something but I don’t know what. Are test plans and exit reports super old fashioned and out dated, if so what can be used instead? I know mindmaps are used in some places instead of test plans but how do these then relate to an exit report?
Our org still uses plans and exit reports but in my area, I have reduced the exit report down to a one page RAG status table for the different elements:
All planned tests executed
P1/P2 Defects fixed
Perf Testing complete
Security Testing Complete
UAT sign off
Obviously if any aren’t green on the dashboard, then more information is provided.
Combining the plan and exit report makes sense , maybe making it a live evolving confluence page would be the best solution?
We have moved to producing “test summary reports”, drawing out the areas we looked at and why we did things that way, an account of what we found, which isn’t just list of bugs and fixes, but also any issues we identified which reflect on the design, or which we think might be valuable to know for onboarding and user training, or indeed things that Marketing might want to draw attention to.
This summary report is then circulated to those who need to know - devs, the product owner, the technical author and sometimes even the marketing team.
This might be a little of topic but it relates to what Robert is writing about the summary. At the time we basically did not have a test plan as you know it, as we had a strategy and a test summary report which basically contained three parts. One was the product health i.e. any outstanding issues and the perception of the state of the product after that iteration. We had a two week iteration cycle at the time. Then we had the process health. How efficient have we been in testing, at the time we had a lot of downtime with some test environment where we would report on the process health and any improvements that was made. Which leads to the third part where we basically wrote down our experiments we did to improve the two former. I.e. we want to do this to make product health better or that to make process health better.
Tying this back to the test plan, which was not first we test this and then that, or me or them will test that part, there was still a sense of an overall plan due to the outlet of reporting this at the end of the iteration. We also presented all teams report to the entire stakeholder team (Project manager, CTO, Dev. Manager, Test Manager etc) which made it more useful because we only put things in there which made sense to that audience.
So with that experience in mind I would definitely suggest to try to merge the to and defined what you report early so you can plan around that.
I am lately a fan of test reports written in a way @robertday describes, brief and intended for specific non-tester audiences.
My test plan on the other hand is a resourcing plan, and I can frankly find no good reason to put the 2 into one document, that and the fact that the plan usually has to be reviewed before the execution that goes into the report starts, keeping the document “live” along the entire process feels like unfinished work.
At my old company, we used the “Transition Plan”
Some basic info on the Transition Plan:
Identify the test cases, processes, and tools developed during the initial project to be transitioned into regular regression testing plans.
Transition these items from the QA lead, who was the owner during the initial project, to the proper QA application owner. Once ownership is transferred, the QA application owner is responsible for determining whether or not certain items will become part of the regression.
The QA transition plan is the final part of an initial project for the QA lead. Once completed (including sign-offs) the QA lead has completed their work on the project and should no longer be considered the primary point of contact for support. Transitioning out of a project isn’t as simple as creating the document and gathering signatures though. The process for transition will include meetings and training sessions to educate application owners and make sure that they feel comfortable taking over as the primary point of contact going forward.
Because nobody ever read or test plans and summaries we switched to having a documented general test approach with a couple of sentences about the current version. Instead of a 10 page summary we just have a living test status page with automatic bug lists etc. that I add a brief comment to when we’re done. It just lists how long we thought it would take us vs. how long we needed, bugs found and problematic areas, amount of bugs deemed important enough to be fixed in current version.
This means we still have something to give to interested managers but save a lot of time we were previously wasting.