In the BBST Test Design slides (slide 122) Dr Cem Kaner describes a scenario as “a hypothetical story about the software. A scenario test is a test based on a scenario. A good scenario test has five characteristics:
- The scenario is a coherent story
- The story is credible
- Failure of the test would motivate a stakeholder with influence to argue that it should be fixed
- The test is complex (involves several features or data)
- The test result is easy to evaluate.”
Simply described, Business Scenarios are use cases that explain how SAP will work for the business in real-life scenarios. They are usually a coherent story (e.g. “Procure raw materials from vendor, receive the goods in the warehouse, and pay the vendor”), the story is credible (in our procurement example this is a daily event), the scenario has motivation (without raw materials we cannot manufacture our products), the scenario is complex and cross-functional (a Purchasing Department to raise a purchase order, Logistics to put away the procured items, and an Accounts Payable / Transactional Finance team to pay the invoice), and the test result is relatively easy to evaluate (checking all documents and material flows for accuracy). At their simplest, business scenarios are a set of business processes that define an end-to-end or point-to-point task in a self-contained manner.
It’s when we start to run point to point business scenarios that we really get to verify and validate how well the solution hangs together from a consolidated business perspective. Once the functional unit testing and integration / technical unit testing is complete, the end-to-end or point-to-point business scenarios can be run to check the full process and verify the paper flow (delivery docs and invoices), the material flow (storage locations and goods movements), and the accounting flow (account determination and postings).
For the purposes of the following pages, we’ll be using the following definitions:
Business Scenario: a collection of business processes that define a business task from end to end or point to point. The scenario requires one or more SAP components, and possibly non-SAP external partners or legacy systems via interfaces or manual inputs. A Business Scenario may have a number of variants, each of them describing a slightly different end to end business flow. The business flow is represented by an ordered sequence of business processes. Each Business Scenario should be designed to run on various combinations of data.
Business Process: a set of one or more logically related business components performed to achieve a defined business outcome. A Business Process will run across one or more SAP components and possibly non-SAP software. Business Processes can be reused in multiple Business Scenarios
Business Component: The lowest level of the scenario for our purposes, a Business Component is most commonly related to a single SAP Transaction, i.e. each transaction will form a Business Component. A transaction can be copied to create more than one Business Component depending on the context of the Business Process that it is assigned to (for example, separate Sales Order business components can be created for standard sales, free of charge, etc). Business Components can also consist of manual steps, background jobs, a web UI, or similar system activities.
These definitions tie in with SAP Solution Manager, which defines them as business scenarios, business processes, and business process steps. For those that use modelling applications these definitions can also align with ARIS process levels depending on your modelling implementation.
More information on Business Scenarios can be found on SAP’s website here:
The following pages provide more specific detail on:
- Business scenario process flow and identifying business scenarios
- Setting up a scenario in HP ALM
- SAP business scenarios
|Next Page - Business Scenario Process Flow|