Having a template for how to approach QA in terms of software development is essential for planning, communication, and buy-in from all stakeholders. These documents also serve as a way to engage and involve everyone’s voice in order to prevent scenarios where team members say that they didn’t agree to xyz process/support. This is a common flow that I’ve added to over the years that helps remind me at the start of a project what I need to remember to specifically address. At the very least I wrote through the documents regardless if I decide that not every document is needed or if some of them can be combined. For instance, I have had small projects where I combined the test strategy and test plan into a single document. However, I made sure that it addressed all of the necessary areas, even if it was only to put “N/A” for a particular section.
Each box in the diagram has a series of events and sub-processes that need to be addressed, along with potential risks. The test strategy alone is one of the most important documents in any project. It’s really the first time to address the system specifications and statically test them for completeness. Issues found at this stage have the potential for saving the product from major issues down the road. Risks need to be identified and go through some sort of ROAM (Resolved, Owned, Accepted, Mitigated) process that garners agreement from the ENTIRE team. The test strategy truly is an entire team document for a given product/project. People viewing it as a “test” document is a huge mistake, because a lot of what is contained within it requires team buy-in and support throughout the entire SDLC.
