Businessdriven test vs. Application

Problem: Users/business reps can have a hard time using their business knowledge in a new system context.
Test sessions and workshops that involve users / business reps (acceptance, prototype etc.) relies heavily on the business knowledge from the participants and the ability to turn this into meaningful test cases and scenarios. Seeing (and understanding) an application for the first time combines with a request to combine new impressions with business knowledge can be a though cookie for some.

Solution: Roleplay your way through the business scenarios.

I have had the pleasure of running quite a few test sessions involving real users, either with the purpose of writing test scenarios or running explorative test vs. a release or prototype. Common for the sessions is that they involve clever people that knows about the business, but not necessary anything about the new application that they are about to test. In order to unlock the business knowledge in the system context I have found that roleplaying with the business reps is very efficient.

 

 

This is how I would structure a business test workshop:

• Welcome, meet & greet + expectations
• Demo of application, showing a standard flow through the application
• Go play session, where participants get some time with hands on the application
• Roleplaying, explanation of the rules and concept
• Roleplaying session 1
• Recap of findings and recording of additional scenarios that might have been discovered.
• Roleplaying session 2
• Recap of findings & new scenarios
• Repeat until all scenarios have been played out / recorded

Rules are simple
Everybody gets to play a role as either business rep, customer or any other applicable role. Participants that usually deals with the customers are excellent for the customer role, as their first hand knowledge of customer requests will come in handy.
The gamemaster will be the test lead, he makes sure that scope of the scenario is not creaping, keeps flow in the test and records spinoff scenarios and defects for the recap session that follows the scenario.

Sessions consist of a scenario, that is defined in a headline and the roles involved. If you have some use cases start playing those, but refrain from giving the steps to the users, as it will kill their creativity. A word of advise here – Keep it simple, as scenario execution becomes time-consuming with complexity.

Preparations for a session is required much like any other test activity, where systems, data, access, scenarios etc. needs to be planned up front. If you are running this without a working prototype you need a mockup of the central parts of the system in order to facilitate the roleplaying sessions. 

Spin offs that you get from doing this: Useability, or lack of same will show instantly when the users gets their hands on the application for the first time – Make sure to take a lot of notes when users gets stuck, that is where useability bugs will be hiding.

Happy roleplaying & Have a nice weekend!

/Nicolai