Click to learn about components Click to learn about data and parameters Click to learn about business process tests and flows Click to learn about running business process tests and flows Click to learn about business process tests and flows Click to learn about data and parameters Click to learn about components Click to learn about running business process tests and flows

Choosing 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.

Note: The sections in this help are structured according to the 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:

For a description of each phase, see Working 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:

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 ALM 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.

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.