Test planning is a common testing activity, yet every project and test lead does it with their own flavour of experience, context, and testing awareness.
Test planning is usually a multi-step process:
Initially, leads or qa managers attend the requirement gathering session where they observe the requirements and give their inputs to stakeholders or PMs wherever required.
Then the requirements are passed to PMs and the design team for Figma and PRD, once these are created, based on this Jira stories are created and Figma design & PRD are attached to each ticket. During this phase test plan document is created.
Then the QA Manager or lead again reviews the PRD and Figma, and raises the questions in case they have any. At this stage, some modifications may be done in the test plan document to align it with the requirements.
Then We hold a brainstorming session with the entire testing team to discuss the scope and strategies for each ticket. Once there is clarity on the testing approach, separate Jira tickets with story points are created and assigned to testers. Exploratory testing scenarios are also discussed during this meeting, and everyone is encouraged to contribute their ideas.
Then testers pick those tickets and start with writing test cases, then initiate the testing, during this phase, exploratory testing is performed to ensure that the product is capable of handling random user behavior.
Even though exploratory testing is not mentioned anywhere in the document, we do that regularly, to avoid any unforeseen situations. If any bug is noticed during the exploratory testing then the bug ticket is created and assigned to the PM for their input on handling it.
During the entire testing process PMs also regularly communicate with stakeholders and share any scenarios they notice that may not be noticed earlier which leads to a change in existing test planning.
Test plan is detailed documentation that attempts to define how we will carry out our testing.
All test planning is based on the risks we want to focus on during testing.
Created by James Bach as part of the Heuristic Test Strategy Model SFDIPOT is designed to help us consider a product from different perspectives
SFDIPOT mnemonic stands for
Structure—What the product is made of
Function—What the product does
Data—What the product processes
Interfaces—Ways in which the product can be interacted with
Platform—What the product depends on
Operations—How the product will be used
Time—How time affects the product
Although this mnemonic can be used on a strategic level, we can also apply it to smaller sections or features of a system…
We can use these different types of perspectives to re-evaluate the feature under test through different lenses to identify various risks.
Once we have identified risks prioritizing what needs to be focused on , helps us plan out and define how we will carry out our testing.
It can documented via jira, word or creating models