What are some real world examples of Scenario testing?

Question

Please provide some real-world examples of performing a scenario test on a web application, desktop software, mobile app or anything.

How is a scenario test different from other types of test approaches?

thanks.

Answer 1

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).

Answer 2

For an ERP system, scenarios differ from other test phases in their length and depth. For example, a functional unit test of a sales order might go into depth to check every facet of a single order - the sales partner (sold to / ship to / bill to), the material and material type, shipping point, pricing conditions, incoterms, freight charges, etc.

Integration testing would test the links with external systems, for example sales orders interfaced to the third party warehouse for delivery.

A business scenario might then look at the end to end chain and validate the document flow through the entire process, for example Sales Order to Outbound Delivery to Pick/Pack/Goods Issue to Invoicing to Customer Payment, checking the paper flow (shipping docs and invoices), the material flow (storage locations and goods movements), and the accounting flow (account determination and postings) through the entire scenario. It involves multiple people and roles and is based on a real-life expectancy of what will happen in Production.

Answer 3

As a software testing company, scenario testing is mainly validating the complex architectural design areas that only comes with experience in a particular domain. An engineer with 6 months of experience in a particular domain compared to an engineer with 2 years of experience in the same domain. As an individual both have different approaches but realistically engineer having 2+ years of exp. will have a more scenario based approach rather than focusing on UI issues.