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)