Test Strategy
Fundamentals of a Test Strategy document
A Test Strategy document conversion the overall test approach and goals to a project. A test plan covers how specific features/functionality will be tested.
A test strategy is useful reference project document to highlight the testing coverage of a major new feature. A test strategy should be done with every major project. Small projects and bug fixes are not something that needs a test strategy document.
Test Strategy Topics
Here are the main categories of a Test Strategy Document:
- Goal - What is the goal of the particular test strategy
- Sign-Off - Have some sign-off by the QA Lead, Dev Lead, Business Owner and Project Architect
- Scope - Identify the product features and risk areas. Include important milestones.
- Test schedule - Know when the project is going live and any rollout plan.
- Release Testing - Cover testing that will be performed at each release deployment. Good to keep a history for tracking purposes.
- Schedule Risks - What are areas of the project that could impact the release of the feature. Example might be third party support, special configurations, account settings.
- QA Resources - Who should people contact if there are issues?
- Timeline - Similar to the Test Schedule, but more focus on the project, what's QA involvement in the release of the feature.
- Jira Tickets - List of the story tickets for this project.
- Project Library - Links to the important documents to this project.
- Competition - List of similar features that are done in other companies. This is useful to understand how consumers may view this product.
Three Tips on Test Strategy Document
This is a live document and the QA Lead should be updating the document - at least once per week. Timelines and releases are areas that get the most updates.
Once the Test Strategy document structure is in place, the document should be shared with the project stakeholders Once it's been signed-off then the document should be shared with other QA Members.
Once the project is completed - usually when the project maintenance has been completed, the document should conclude with a "Transition Plan." This is when the test cases become part of the general release testing. Usually the QA Lead would go through the test cases to tag items that should be automated for regular regression.