Choose methodologies

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.

The sections in this help are structured according to the bottom-up methodology.

Bottom-up methodology

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:

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

Build test plans and design business process tests and flows.

For task details, see Plan business process tests and flows.

Data Handling

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.

Test Execution

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.

Back to top

Top-down methodology

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:

Design Phase Description
High-level design

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:

  • By designing with modularity in mind. Design tests to use smaller, reusable components that automated tests can call multiple times.
  • By designing tests with reusable components, which makes maintaining tests easier.
  • By designing with the understanding 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.

Creating the structure for business process tests and determining the needed test configurations are typically performed by the subject matter expert.
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 that perform specific tasks in a business process). 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.

  • 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)

  • Parameterizing

This part of the design phase can be performed by the subject matter expert, the automation engineer, or both together.

Back to top

Agile methodology

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:

Parent topic: Overview

Back to top