Applying the 7Ps Framework to Testing in an Agile Environment
If you are looking to find a way to capture the essence of what your testing within an agile project should look like, the 7 Ps approach can work really well. Not only can this approach help you to define the essence of your testing without being overly prescriptive, it has the added benefit that it can be used to involve all stakeholders, either in single or multiple sessions.
The 7 Ps are:
Purpose - “Why are we testing?”
The question may not be as simple as it appears, and the answers can be surprising. Too often, we test simply because that’s what we are told to do or because it’s what we have always done; or because it is “best practice”, without ever really stopping to ask ourselves “why?”.
By involving stakeholders in the process of answering the question, “what is the purpose of testing this software?”; we can discover interesting drivers, areas of concern and even significant challenges to our preconceived ideas.
Use the discussion to understand the types of testing that will need to be conducted, as well as the drivers and stakeholder expectations with regards to what should be tested and why.
Product - “What are we testing, what’s the product (or what are we expecting to produce in this sprint)?''
The discussion around this area can help drive out the features that are of importance to the stakeholders. Maybe due to the perceived value the feature provides or maybe due to the perceived risk associated with the feature.
Use the discussion on the product to help ascertain priorities, understand interdependencies and to define what is in scope for testing.
People - “Who needs to be involved in the testing and what role will they play?”
By taking time to understand who is needed to make testing successful, you can avoid a number of issues, such not having the right skill set available, calendar clashes, not knowing who to speak to for specific areas of testing or product knowledge.
Use the discussion to identify who should be involved in the creation and execution of tests and who is required to support the testing, such as environment engineers, data analysts and other specialists. Identify the full range of stakeholders and understand their individual requirements.
Process - “How will we go about testing?”
It's easy to think of testing simply as the execution of tests, but of course, there is a whole lot more to it than that. A host of methods and approaches that you can adopt. Understanding the process and who does what can help speed up testing and ensures that everything that needs to get covered...gets covered!
Use the discussion to set out what processes will be followed and in what order. Also, who is required to be involved at each stage. You can use the outputs from people and process to create a RACI if required.
Pitfalls - “What could possibly go wrong?”
Understanding what could go wrong, the possible “gotcha’s” and where there could be areas of conflict, is the first step towards devising a strategy to avoid or minimise the impact of pitfalls.
Use the discussion to highlight areas of risk and to explore what might cause testing to be derailed, then you can decide how best to address the issues in advance. If your project runs a risk log, then the output from the discussion can be added to the risk log where appropriate.
Preparation - “What do we need to do to be ready to test?”
Preparation activity can cover a wide spectrum of activities, the obvious areas will be test scripts, test environments, test data, etc. However, there may be other less obvious areas that need preparation, for example., systems training, quick reference guides, model office set up or even getting security clearance for visitors to attend the test execution.
Use the discussion to explore what needs to be prepared in order for testing to progress smoothly. If appropriate, make sure the preparation activities are added to the backlog and correctly sized.
Practicalities - “What are the logistic associated with testing?”
All testing has associated logistics and whilst some will be covered in the preparation section, other will need to be considered here. On more than one occasion, my most important contribution to an early morning out of hours testing session was to ensure that there were enough bacon sarnies for those coming in on a cold Saturday morning!
Use the discussion to consider the practicalities of the testing. For example, if working remotely, how will the testing be kicked off and co-ordinated? If working out of hours, who will notify site security?
Running the Session
The session can be run in a number of different formats. You can cover all seven P's in one session or you can split them up across a number of sessions. You can have all stakeholders together or you can hold individual sessions.
Be mindful that there are some key elements that contribute to the success of this approach regardless of how you run the session(s):
- Make sure the seven headings are visible to all. If the meeting is being conducted remotely, display the headings on the screen (PowerPoint, Trello etc.) in a meeting room.
- Encourage active participation from all attendees, gently shutting down any that are hijacking or dominating the discussion. Encourage those who are holding back to share their thoughts.
- Refer back to earlier sections as the meeting progresses, any of the P’s can have an impact on any of the others, so take time to check back and see.
- Don’t wait for a section to dry up and falter before moving on to the next. It’s a fine balancing act between allowing enough time but not losing momentum. Remember, people can always add more points later.
The 7 Ps can provide a valuable framework for exploring what testing is required for your project. The results of the meeting will then need to be reviewed, collated and worked into a coherent plan.