The Business Process Testing testing framework does not enforce any one particular model for incorporating business processes into your testing environment. The actual workflow in an organization may differ for different projects, or at different stages of the application development life cycle.
Defining low-level components first and then designing business process tests based on the defined components is called a bottom-up approach. This approach is particularly useful:
For regression testing
When the business processes in the organization are clearly defined
When users are new to Business Process Testing
The bottom-up approach includes the following phases in the following order:
The bottom-up approach is based on the following design phases:
Develop a component tree with components.
Create the component shell by adding basic details.
Create component content by adding manual and/or automated implementations. Component content can contain:
For task details on creating components, see Create business components in ALM.
Design the data that each business process test, flow, or component uses when run.
For task details, see Work with parameters, iterations, and configurations.
Build test plans and design business process tests and flows.
For task details, see Plan business process tests and flows.
Create a subset of the business process tests in your project and run them.
For task details, see Run business process tests and flows.
For an example of a common workflow using BPT Packaged Apps Kit, see Work with BPT Packaged Apps Kit.
The top-down approach is based on the perspective of the subject matter expert who has a high-level understanding of the entire system.
The top-down approach advocates the creation of business process testing entities for regression testing according to the following hierarchy:
Business process tests, which contain flows and/or business components
Flows, which contain business components
Business components, which contain manual steps and/or automation
The top-down approach includes the following phases in the following order:
The top-down approach is based on the following design phases:
Includes creating business process tests, and determining the test configurations needed for different use-cases.
When designing at the high-level:
This part of the design phase is often done by both the subject matter expert and the automation engineer together. For example, creating the business process tests and their configurations might be performed by the subject matter expert, while designing automated components might be performed by the automation engineer.
This part of the design phase is typically performed by the subject matter expert, but may also be done in conjunction with the automation engineer, depending on available resources and skills.
Includes the low-level implementation of business component content by:
This part of the design phase can be performed by the subject matter expert, the automation engineer, or both together.
This approach is based on using Business Process Testing to provide testing in sprints, as developers code features for the application under test. Components and tests are created and updated in parallel with development.
If the application under test is implemented in Java, components might be grouped by the classes that represent certain groups of UI elements, such as toolbar buttons. Each time a button is added to the toolbar, the component representing that class is updated.
This approach encourages:
Automation. Because sprints are short, it is important to automate as much as possible.
Component reuse. Component reuse can be designed in the same way that the developers implement modularly for reuse.
The following presents the Agile Development-centric approach.