I'd start by looking at the answers to this question. Chris Kenst gives an excellent definition of a scenario test and how it differs from test cases, acceptance tests, and so forth. My answer is a thumbnail of how I generate scenarios using a not-quite-real-world example.

Performing a scenario test is the same as performing any other test: you set up the required prerequisites, perform whatever test steps you need, and evaluate the results of your actions. It's difficult to get more specific because of the scope involved: relevant scenarios will depend on your application(s) and user base.

An example: Let's say your application is a social game, something like Temple Run, with a paid no-ads version in addition to the free version with advertising. Your user base will fall into some broad groupings, with overlaps:

• Novice users - will typically have very low scores per game, react slowly to changes in the game environment, have unlocked few if any of the powerups unless they paid to unlock items.
• Intermediate users - typically score medium to high scores per game, have unlocked most or all powerups and have accumulated some extra items that they can use to unlock items in-game.
• Power users - typically score highly in most games, have unlocked everything and have accumulated so much of the in-game currency they can unlock anything new without having to use real money.

All three skill levels overlap with paid and unpaid user profiles.

A scenario test for this situation will take a user persona and a gameplay style and work with them - if, similar to Temple Run 2, your game has daily reward challenges that include things like running a specified distance without collecting any coins, you treat these challenges as a scenario goal (i.e. the thing you're testing) and your testing aims to cover the ways to achieve that scenario goal.

So, for instance, a test scenario here might involve multiple test cases:

• The challenge can only be achieved on the first distance x (i.e. the player must run, say, the first 2000 meters of the game without collecting any coins or powerups).
• After the challenge has been achieved, the player may collect any number of coins and powerups without "losing" the achievement.
• The play may (or may not, depending on game rules) die and purchase resurrection without impacting the achievement.

The scenario itself might be:

An intermediate level player with a paid version of the game attempting to achieve a challenge of running the first 2000 meters in game without collecting any coins or powerups.

(I'm not going to touch the feasibility of actually testing out this scenario - someone who's become an advanced player of a game is going to have a hard time simulating a novice player's reaction time because that's a parasympathetic nervous system thing. But it's an easily understood example).

I'd start by looking at the answers to this question. Chris Kenst gives an excellent definition of a scenario test and how it differs from test cases, acceptance tests, and so forth. My answer is a thumbnail of how I generate scenarios using a not-quite-real-world example.

Performing a scenario test is the same as performing any other test: you set up the required prerequisites, perform whatever test steps you need, and evaluate the results of your actions. It's difficult to get more specific because of the scope involved: relevant scenarios will depend on your application(s) and user base.

An example: Let's say your application is a social game, something like Temple Run, with a paid no-ads version in addition to the free version with advertising. Your user base will fall into some broad groupings, with overlaps:

• Novice users - will typically have very low scores per game, react slowly to changes in the game environment, have unlocked few if any of the powerups unless they paid to unlock items.
• Intermediate users - typically score medium to high scores per game, have unlocked most or all powerups and have accumulated some extra items that they can use to unlock items in-game.
• Power users - typically score highly in most games, have unlocked everything and have accumulated so much of the in-game currency they can unlock anything new without having to use real money.

All three skill levels overlap with paid and unpaid user profiles.

A scenario test for this situation will take a user persona and a gameplay style and work with them - if, similar to Temple Run 2, your game has daily reward challenges that include things like running a specified distance without collecting any coins, you treat these challenges as a scenario goal (i.e. the thing you're testing) and your testing aims to cover the ways to achieve that scenario goal.

So, for instance, a test scenario here might involve multiple test cases:

• The challenge can only be achieved on the first distance x (i.e. the player must run, say, the first 2000 meters of the game without collecting any coins or powerups).
• After the challenge has been achieved, the player may collect any number of coins and powerups without "losing" the achievement.
• The play may (or may not, depending on game rules) die and purchase resurrection without impacting the achievement.

The scenario itself might be:

An intermediate level player with a paid version of the game attempting to achieve a challenge of running the first 2000 meters in game without collecting any coins or powerups.

(I'm not going to touch the feasibility of actually testing out this scenario - someone who's become an advanced player of a game is going to have a hard time simulating a novice player's reaction time because that's a parasympathetic nervous system thing. But it's an easily understood example).