Business Process Testing is flexible and 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 methodology. This methodology is particularly useful when:
The business processes in the organization are clearly defined.
Users are new to Business Process Testing.
The bottom-up methodology includes the following phases in the following order:
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 How to Create Business Components in ALM.
Build test plans and design business process tests and flows.
For task details, see How to Plan Business Process Tests and Flows.
Design the data that each business process test, flow, or component uses when run.
For task details, see How to Handle Data in Business Process Testing.
Create a subset of the business process tests in your project and run them.
For task details, see How to Run Business Process Tests and Flows Manually and How to Run Automated Business Process Tests and Flows.
For an example of a common workflow using BPT Packaged Apps Kit, see Working with BPT Packaged Apps Kit.
The top-down methodology is based on the perspective of the subject matter expert who has a high-level understanding of the entire system.
The top-down methodology advocates the creation of business process testing entities 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 and/or automated steps
The top-down methodology includes the following phases in the following order:
The top-down methodology is based on the following design phases:
Includes the high-level design, creation of a structure for business process tests, and determining the test configurations for testing different use-cases that will be needed.
When designing at the high-level, facilitate automation:
This part of the design phase is often done by both the subject matter expert and the automation engineer together.
Creating the structure for business process tests and determining the needed test configurations are typically performed by the subject matter expert.
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.
The Agile methodology is based on using Business Process Testingto providing testing in sprints, as developers code features for the application under test.
The top-down methodology advocates the creation of business process testing entities according to the following criteria:
Components are created corresponding to features or UI elements developed during the sprint. For example, if developers design and create a new window that has a menu, a navigation pane, and a main data area, you might create three components corresponding to these UI elements.
Tests and flows, which contain the sprint's business components, are maintained so at the end of any sprint, the developed features can be tested immediately.
The Agile methodology includes the phases by sprint: