Using Personas and the Relationships Between PToT Elements
PS Personas – Technique Element
Sub section – Approaches
There are lots of relationships we have to consider in testing. In this post, I’ll briefly discuss those relationships and how the Periodic Table of Testing can be used to map them. Then share a real-life example of how using the personas ‘thought technique’ lead to using other elements on the table.
Any idea, technique or approach can only take you so far without some view of those things surrounding it. Even a Hermit (a person wanting no contact with others), no matter how isolated, has relationships that need to be considered such as their surrounding environment.
Understanding relationships can often be instrumental in identifying appropriate scope that helps ensure we deliver quality in our products. The Periodic Table of Testing is exactly the same. A Technique Element can have a relationship to a Testing Element and in turn a Testing Element can lead to (have a relationship with) a Technical (or any other) Element.
Real example:
Below is an example of how a Technique Element lead our team to a Testing Element that helped describe our relationship with our Customers. By creating Customer Tours or Journeys we could then mimic the Customers behaviour, particularly when using Personas to navigate the system in a particular way. Those Tours and Journeys then lent themselves to a Technical implementation through automated tests and the creation of Living Documentation.
Working on a project to create a customer portal to access mortgage account information was a great opportunity to introduce personas. I’d read a lot about personas but the main takeaway for me was how they could be used to highlight key differentiators. For our project, the key differentiation was the accounts status at the point of use. I’ve read and seen a lot of information on personas and some recommend highly detailed and complicated outlines. For me a lot of the detail in those were superfluous and didn’t add any real value. For projects lasting years they could hold some worth but for me were distractions from the main point of them.
Back to the project and our main differentiation. Mortgage accounts have several status variations including the account being up to date, in arrears, with an arrangement, in litigation, in possession and so on. We used different personas to represent those different states.
With input from the team we even used the names of the personas we created to represent variations in surnames to see how they would be displayed in the UI. And so, Sally Steadman, Adam Thompson-Pritchard and Olivier O’Connell amongst others were ‘born’. While the personas had genders, ages and key personality traits their development didn’t go much further as the status of their accounts was the key differentiation required. Once we had the personas and a shared understanding of what each one meant we expanded the idea to other elements. As well as creating customer journeys for them and noting the different information and help items they would see, we wrote feature files for them that became both our automated testing and in turn our living documentation.
Thanks to our shared understanding we were able to create a ‘Preview’ version of the site and added fake services. This meant you could register and sign in as one of the personas and explore or complete user journeys just as the Customer would. We used these to execute our automated UI tests giving us stable responses. Cool stuff I thought!
However we might conduct testing and wherever our starting point; the relationships of different techniques and methods must be considered in our quest to investigate and add value to the best of our abilities.
References:
Alan Cooper Origin of Personas: https://www.cooper.com/journal/2008/05/the_origin_of_personas
Agile introduction: http://www.agilemodeling.com/artifacts/personas.htm
Generic Testing Personas: http://katrinatester.blogspot.co.uk/2015/01/generic-testing-personas.html (great example of minimal personas)