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:
For a description of each phase, see Work with Business Process Testing.
For an example of a common workflow using BPT Packaged Apps Kit, see Working 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.