Share this page

# Choose design approaches

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.

In this topic:

Note: The sections in this help are structured according to the bottom-up approach.

## Bottom-up approach

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:

Phase | Description
--- | ---
Component Specification | 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: Manual implementation for manual components Automation, for automated components Both manual implementation and automation For task details on creating components, see Create business components in OpenText Application Quality Management.
Data Handling | Design the data that each business process test, flow, or component uses when run. For task details, see Work with parameters, iterations, and configurations.
Test Planning | Build test plans and design business process tests and flows. For task details, see Plan business process tests and flows.
Test Execution | 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.

Back to top

## Top-down approach

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:

Design Phase | Description
--- | ---
High-level design | Includes creating business process tests, and determining the test configurations needed for different use-cases. When designing at the high-level: Facilitate automation by designing modularly. Design tests to use smaller, reusable components. Use reusable components, which makes maintaining tests easier. Keep in mind that automation engineers can use the design as a structure for creating methods that facilitate automation, instead of for creating scripted components. 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.
Mid-level design | Includes the: Creation of flows (sets of business components in a logical order that can be run). Flows are considered "compound components." Creation of business components (reusable units). Only the shell of the component is created during this phase. Specification of criteria for more granular test coverage (requirements) as necessary. Linking to other OpenText Application Quality Management entities. Parameterizing and promoting parameters. Adding business components to business process tests and flows. 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.
Low-level implementation | Includes the low-level implementation of business component content by: Creating component steps (the content of the business component), including automated steps when necessary Grouping components Setting up iterations (for business process tests, flows, groups, and components) Linking parameters This part of the design phase can be performed by the subject matter expert, the automation engineer, or both together.

Back to top

## Agile development-centric approach

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.

Example:

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.

Back to top

See also:

- Business Process Testing basics

https://admhelp.microfocus.com Application Quality Management 8942
Tips to improve your search results... OpenText™ Application Quality Management Help Center OpenText™ Application Quality Management Help Center OpenText™ Application Quality Management Help 26.1 All View Local Help Center View Online Help Center Version: