Identifying Business Scenarios
Unit tests are usually gathered from the project documentation. During Blueprint the configuration and development workstreams have spent untold hours with the business in workshops and conferences, teasing out the requirements and detailing them in the functional and technical specs, in Fit/Gap documents, and/or in the Requirements Traceability Matrix, and from these documents each workstream can write their unit tests to test that the delivered configuration and WRIEFs meet the documented requirements. Ideally a test manager would be included in these workshops to document the business scenarios at the same time, but all too frequently the test manager is only brought on board towards the end of Blueprint; another common problem is that the implementation has so many workshops happening concurrently, either for different workstreams or for different entities within the business, that it would be impossible for a sole test manager to cover them all.
Therefore, Business Scenarios are usually gathered in a separate exercise with the business between the end of Blueprint and the start of Integration Testing, while the rest of the project is busy actually building, configuring, and unit testing the system that we will be testing.
A Business Scenario will start life as a plain-language explanation of what the scenario intends to happen, for example:
“Customer X purchases Material Y in quantity 100 cartons; the delivery is packed in Warehouse Z and delivered to the customer from the warehouse shipping point Z(a). Transportation costs are included in the invoice, and the customer pays on the invoice the following month.”
Or there may be a variant scenario where there is a subtle change, such as:
“Customer X purchases Material Y in quantity 100 cartons; the delivery is packed in Warehouse Z; the customer picks up the delivery from the warehouse shipping point Z(a). There are no transportation costs and the customer pays on the invoice the following month.”
The business-language scenarios then need to be converted into SAP transactions to match the blueprint design, configuration, and developments. That transactional flow can then be replicated in your test case management system to create the scenario for testing.
Business scenario processes are generally “owned” by a functional area within the business, for example the procurement of raw materials process might be owned by the Procurement function, domestic sales processes might be owned by the Sales function, etc. Different businesses have different names for each functional area, and the ownership of scenarios might be different across businesses, but the principle of ownership by a functional area within the business is typical.
Because they are used in integration and user acceptance testing, business scenarios tend to involve more than one functional area, regardless of ownership. The process flow below is obviously simplified, but shows the interaction between functional areas:
Disclaimer: Just as ownership of a scenario may differ from business to business, the scenario steps can be different depending on the specific configuration. Any scenarios detailed here are intended to be for illustration purposes only, and you should always check with your design team to confirm scenario processes within your business.
The business scenarios detailed on other pages in this site tend to be manufacturing-oriented, and follow the following general convention for process flow:
|Previous Page - Business Scenarios||Next Page - Setting Up a Scenario in HP ALM - 1|