Role-playing - not a dirty word

Role-playing - not a dirty word

"Testing Personas" or "User Personas" are a common tool in the "Testing world". Each character represents a certain percentage of the product's users. Using this method, we are able to create possible realistic usage scenarios, and "edge scenarios", Considering the habits and Uniqueness of the characters we will adopt. Testing Personas are used by Testers and product managers while writing specification documents/User stories.

About a month ago I had the honor to participate in an interesting panel of Testers. During the meeting a conversation occurred between two team leaders. It caught my full attention. They talked about a testing method called "Testing Personas". I found myself totally fascinated by the conversation, because it was one of the things that makes me love this profession so much. The privilege to use my imagination, to question, to explore, to think of "the unexpected" that is not obvious to someone else. The next day, full of motivation, I decided to write an article on the subject and share my POV on the method.

How does this method contribute to the planning and execution of our tests?

Testing Personas - gives us the opportunity to "experience" the system through their eyes and the reality of their world, each representing a certain percentage of the total user population of the product. In this way, we can try to predict patterns of use, potential problems for each, and to stage endpoint scenarios. For each product / module of a product, it is possible and desirable to create special characters that will suit the distribution of the target audience.

A bit of philosophy: When I think about testing a system, I use my best experience, creativity and critical thinking (with an emphasis on "my") to see where it can fail, collapse, not function as expected or prove inferior to its competitors. When I think like A Persona to make it "Flow - through its reality" I try to recreate its patterns of behavior and agenda - I get a "test experience" that can complete the overall test plan and contribute ideas to scenarios that I might not think of as "Daniel The tester".

So, how does it work?

The characters:

In order to optimize the process of creating the characters we need to perform our tests, we need to established a number of guidelines for their characterization. These guidelines will make things easier for us, and help us to follow an appropriate line of thought.We can create / characterize the personas in a specific document in a format that is convenient for us, and store it in a way it can be shared with our teammates. you can also find templates and examples on the web.

·      Name - characters require a catchy name, which will make it easier for us to connect to the character and stage her scenarios . It is no longer a vague concept - it has a name, and now we will begin to get to know its qualities and characteristics.

·      Photo - While this is not mandatory, but theoretically, the more we "enliven" the Persona in our consciousness - the more we can connect to it personally, think about things it may do and problems it is likely to come across.

·      Short description - In order not to burden the examiner (it is preferable to document the character for other team members) and yet to give the persona unique characteristics, we will add a short description.  Age, marital status, prominent character traits, its purpose of using our product, and even a catchy slogan that will describe the mysterious Persona in a sentence.

·      Representation of the intended users and Priority for planning the tests - what user segment is represented by the character? What is the Priority according to the audience percentage represented?

I suppose this is the place to point out that in terms of time-cost-benefit equation, it is advisable to direct the scenarios mainly to places of the greatest business importance,  to concentrate on the main technical and business logic and not necessarily on marginal aspects of the system. (With that said, if there is time we can surely benefit from this technique in all system aspects).

Once we have captured the concept, we will see the example in a nutshell:

Let's say the product we're testing is a procurement management system.The product enables Retailers/Buyers and their licensed order coordinators to create orders and send them to suppliers connected to the service.The target audience for the product is: Retailers/Buyers, order coordinators, suppliers on the receiving side.

So, what character can we create in order to sample a segment?     

 

Now, with Dana's help, we will try to create a user journey based on her everyday reality:

• Dana comes to work in the morning after she drove her two children to the kindergarten, launches the system and waits for it to open.
• It is 9:00 am and the phone begin to ring.
• A subcontracting buyer calls - he asks her to order multiple items from the same product group due to a centralized order.
• Immediately after Dana hangs up, another customer calls and wants to order the same products he orders every week.
• 11:00 PM Dana receives a phone call about a very big order that she must type in, and it includes many products from different product categories.
• During the conversation her boss calls and asks her to urgently send a short order for a "Super important" customer right now.
• 12:00 - While Dana is typing an order, her co-worker arrives at the office, and proposes her to eat lunch with him. Dana locks the computer without finishing the order and leaves.
• 13:00 - Dana's boss asks her to bring him a folder of documents urgently, while Dana makes an invitation to a secret security organization.
• She gets up from her chair without locking the computer, thinking she would find the folder before anyone went into the office and might see her screen.
• While Dana is out of place, the son of one of the girls in the office accidentally pressed the send button.
• 14:30 - While creating an order, Dana receives a phone call from the kindergarten that her child is not feeling well. Dana must leave work quickly. She finishes the order, clicks the send button, and runs out of the office without noticing that the sending has "failed".
• In the evening, the manager receives a phone call about the order that hasn't been received (the one that failed) and decides to log in to the system and check whether he will be able to re-send it.

We have just witnessed how with the help of the persona, we have created situations that simulate the reality of her world. Dana's events throughout the day should raise many trivial and important questions about each and every line on her agenda. these questions are supposed to make us professionals to Test, Speculate, Investigate, Imagine and question the solution our product provides to each of the events and aspects of the system we have addressed in our short story.

• Response and upload time.
• Usability.
• Multi-tasking ability, parallel process and multi-tab support.
• The ability of making centralized orders (multiple choice options, selecting an entire product folder, Product tree).
• Easy navigation between different products, customers and processes.
• Safety mechanisms before sending.
• Data Security.
• Is there an Auto Logout mechanism?
• Is data saved/ stored in the order in the case of automatic Logout?
• Is there a reservation operation in the event of a failure to send?
• Resend and automatic resend configuration options.
• Is there a possibility to save a repeating or template order to a specific supplier/retailer?
• Can a manager with the appropriate authorization view orders made by his employee? If so, will he be able to take actions or make changes in it?

These are just small points and accents. A fraction of what can be consolidated from Dana's short story. After we created Dana, we can create a Persona that will represent the buyers and suppliers Segments - a trivial and critical percentage of the system's users.

Points (in a nutshell) that should be considered in designing a Test plan using Personas:

• Active / less active users.
• Users that pay for the service.
• Casual users and registered users.
• Personal Information - Status / Family / Age.
• Demographic area.
• Various communication operators, hardware and software, and different time zones.
• Personal preferences and usage patterns (can include operating systems, mobile device segmentation, hours of activity, etc.).
• Personal hobbies and habits that can affect usage patterns.
• Behavior patterns - entrants frequency, multitasking, etc.
• What is the purpose of using the product for the specific user? What drives them to use our system?
• What is the added value that we bring to the same user compared to our competitors?
• Does he use a similar / competing product at the same time?
• Does it use any other product that can disrupt our harm our products performance / activity?
• Various permissions - administrators and user types.

I mentioned at the beginning of the article spec reviews, I really think that you can get a lot of benefit if as soon as the proposal stage - project managers will adopt this method too in order to improve the quality and width of the documents written. Thus, When the User Story reaches us for review, it is likely to be more mature for development. (From surfing the Internet I saw that there is awareness of this method of work abroad, and there are project teams that implement this tool in the work characterization and spec writing process). I hope this article will provide you with food for thought, and that you can benefit from it the next time you need to activate your imagination to attack the tests in a new interesting and challenging way.