I wrote an article on stories for production support teams quite a while ago. But I always meant to add a couple more.
The problem with production support is that nobody has time to ask for what they want, but it is all urgent and super critical. So the last thing you often feel like doing is to slow down and understand the context that the user is in (annoyed, relaxed, sitting in a cafe, in their most important sales meeting ever etc). Instead the focus is usually on fixing “it” before you know what “it” really is.
But this often leads to rework. So whenever I am doing enhancements I always spend a little time understanding why the enhancement is needed, who it is needed by and when/how it is likely to be used in the real world. To do this though, I think we always need to spend a little time understanding the people who will use the system and why they need something new.
There are many approaches to doing this, but one I often find useful is “PAC” or “People, Activities and Context”.
PAC refers to a series of steps to understand:
- The People using the system;
- The activities they will perform; and
- The context in which they will perform them.
The steps are quite straightforward:
P: People (Define the users)
Let’s start by breaking “the users” into three groups:
- Those who actually use the system for the purpose we built it for are the Primary users. Most regression testing is likely to focus on these users;
- The often forgotten Supporting users are those who interact with or use the system for the purpose of helping the Primary users to use it. For example production support or on-site support engineers; and
- Other stakeholders are those who do not directly use the system but who gain a benefit from the system or have a say in what it does.
Example primary users might include:
- Experienced and inexperienced users
- Wholesale and retail customers
- Users of different versions of the software – Basic Edition, Advanced Edition and Enterprise Addition for example.
- Local users and overseas users
- Onsite users, home users and mobile users
In each case you list the types of users and then ask yourself:
- Do they use different functionality?
- Do they use the same functionality differently or need a different experience using it?
The next step is to list the typical activities that the user might perform, that might impact or involve the system.
The trick here is NOT to just go through the requirements. Instead the focus is on the user and “what they will do during the day”.
So we might have a requirement for a user to login and another requirement to process member enquiries. But we might actually put down the activities of “talk to customers on the phone” and “send a report to the boss”.
Sending a report to the boss might involve running a report from the system (and thus match a requirement) or it might involve collecting information from several sources, including the system we are building. So the user might actually be logging into our system to run some general queries or to just look at some screens.
Similarly, several users might do the same activity, or one activity might involve multiple users. So don’t worry about linking the activities to a specific user yet, just put them all down in a list.
So the idea is to capture “what activities does a user get involved in”. These can then become the basis for requirements, test scenarios, stories, use cases or whatever you want.
The final component of PAC is context. This is important because the same user might perform the same activity very differently at different locations, using different toolkits or even in different emotional states.
So context can cover anything about the user’s environment or situation, for example:
- Will this be done at the office, at home or on the road.
- Some users might be in a major company while others are in a small office.
- Some users might be in the outback in Western Australia while others are in a major city in Japan.
- Will all users be using the same operating system, browser version etc. I find in particular that customers assume we support all browsers in all versions but IT. departments only test with one browser, assuming any others are unsupported.
- What hardware will people be using? Will this impact their response times or ability to see our graphics.
- During a disaster might be a different process to relaxing at the office.
- The user might be using the system in front of a complaining client or after work.
- when there is time to wait for reports to run.
- Is there a specific time when things are harder or more urgent, for example peak hour or the annual enrolment week at university where things will be both more important and more likely to fail;
- Are there blackout times like overnight backups, annual reporting periods or change freezes?
Bringing it together
Now that you have collated all the information you join the dots. So you look at each user and ask yourself whether they will do each activity and in what context they will be operating.
You can put this all in a table if desired:
|Enter new customersCollect money from customersRun reports for management
Pay out customer entitlements
Install the software
Look for problems when it fails
|Using a browser online
Using an ipad or galaxy tab
While a customer waits
At the end of the day
Physically worn out
From home or on the road
Of course completing the table is not the point. The real point is to use this information to create stories, requirements or tests.