The following article “One thing not to forget when you are done testing” is a guest post by Joel Montvelisky, Chief Solution Architect at PractiTest, a test management tool and blog owner of QA Intelligence where he writes about all things related to Testing; the good, the bad and the funny.
OK, so you and your team just completed a full testing project.
You created new tests for it, ran your cycles on multiple devices achieving the coverage you needed for release, you found a bunch of important bugs that were fixed (and some that were set for a later version), and throughout the whole process you provided valuable feedback to the product team on the features that you ended up releasing.
All in all you and your team did a pretty good job – Congratulations!
Now, as it usually happens you are also late to start your next project (or two?!) and you just want to get running with those tests…
There is something else you need to do NOW that can make a whole difference regarding the way your organization perceives the professionalism of your team and your work: Write down a short summary report for your testing and its findings.
The fact is that as part of your testing efforts you generated a lot of valuable information and this information may not be known to everyone in the team, and specially not to the people who can make decisions based on it.
Make this report a short one, maybe even a small presentation of 2-5 slides.
You can start it by providing information about what your testing did and found, and comparing it to other projects that will give some perspective on it. For example you show how many tests you ran and bugs you found, and compare that to your 2 previous projects. Is there anything that can be learned based on this? Try looking at the things that changed and how did they affect these numbers. Provide concrete suggestions about improvements to these areas.
Along these same lines you can talk about how the system “looks and feels” to your users with this new update, especially to those users who will be migrating from an existing version of your system. Here is where you can talk about improvements (hopefully) on things like the response time or the amount of data they will be able to work with. If there are degradations of any kind make sure to mention them as well and explain why they were accepted and released. Also is the place to add any suggestions you may have.
Another thing to include in this summary,is a section about the interesting findings you encountered during the process and the issues your team ran into that could have been avoided if people knew about them before. To give some examples of things I have included in my previous summaries, you can talk about:
- Problems that originated when the project schedule was not calibrated to include the testing efforts, how that could have been avoided and how much time could have been saved by that.
- Misunderstandings originating from people who did not work based on a good process that ensured everyone in the team was aligned with the objectives of the project and the features to be released.
- Hardware and software that were missing, and could have been acquired previously.
The bottom line of this report is to create a realistic (good and bad!) view of what happened in the project, with the aim of improving the way your organization will work in the future. Some companies have retrospective processes in place, and if so this document can serve as a partial input to that sort of meeting.
But in many cases people are simply happy the project went out the door and want to move forward to the next project with a naive feeling that people will not make the same mistakes they already did moving forward.
Your summary report will (hopefully) help ensure this optimism is also calibrated with a nice dose of project-proven-realism.
If you also want to write a guest blog post on my blog, I am more than happy to receive your article via daniel [at] adventuresinqa [dot] [com].