Personally speaking

"You never really understand a person until you consider things from his point of view... until you climb in his skin and walk around in it." - Harper Lee, To Kill a Mockingbird

During my career as a tester, I've taken many roles - content administrator, software developer, CMS editor, telecoms manager, SEO analyst, purchaser (diamonds, luxury cars, sportswear, frozen fish), trainee headmaster, supermarket employee, sewing machine manufacturer, booker of private jets and (memorably) a 7 year old primary school student who is not very good at reading Spanish.

Now that's obviously not true (although I have purchased the occasional fish finger), but these are all roles of users on projects I've been involved with. This is how I tend to approach testing - assuming the role of the intended user (or users), viewing things through their eyes and acting as they would act. Whatever the project, there will be an intended recipient - for example, with a website it may be someone looking for information or wishing to make a purchase; a content editor who is trying to update information on the site; an SEO analyst checking traffic levels to a particular page; or even a site owner wanting to know how the site is performing financially. All perspectives are important and all need to be considered when planning testing.

My first thought when executing a test case is often "Who is doing this?". The answer to that helps me to understand not only how to approach the test, but also why the test exists in the first place - both of these help give a framework for the test and hint towards the types of issue that might occur as a result, allowing me to focus on the most likely fail points. The route through which you access a particular action can also have a bearing on the outcome - thinking like a user and using the route they are most likely to take will also point towards issues that will occur for real-life users in real-life scenarios, which, I would argue, are the issues we need to prioritise.

I also find that looking from the perspective of a third party helps prevent the defect-blindness that can occur with over-familiarity - adopting a persona allows you to reset expectations and reminds you that you need to look at the site as if you were seeing it for the first time. It can also be useful to bear in mind the experience a first-time user undergoes, as a user's perception of quality is likely to be influenced by their earliest actions (at least in the short term).

Personas can also help with defect severity assessment - a small grammatical error on a commerce website, while annoying, may not be noticed by a typical user (their attention is likely to be focussed elsewhere) and will likely come very low on a list of "must-fixes"; but when it appears on the front page of training materials for headteachers (as I once found) it's close to a showstopper. Indicating who will be affected by a problem in defect reports can also clarify what the actual issue is, so that it gets fixed appropriately (which can be particularly useful for accessibility-related issues) - you're less likely to have to send something back for retest if it's clear what perspective you're coming from.

Finally, when running tests a number of times (following defect fixes or for regression) it's all too easy to go through the motions and forget the original purpose of the test - so if you need a fresh perspective, try a persona to see the world through different eyes.