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?
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.Sign up to join this community
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:
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 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).
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.
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.