Business Process Testing basics

This topic covers basics such as identifying roles, choosing design approaches and categorizing components.

Identify roles

Business Process Testing can be used by several different personas, each with varying levels of experience and different goals.

When working with Business Process Testing, roles are flexible. There are no product-dictated rules controlling which types of users can perform which Business Process Testing tasks (provided that users have the correct permissions).

The following table describes various roles that can be used when working with Business Process Testing.

Role	Description
Subject Matter Experts	Subject matter experts have specific knowledge of the application under test's logic, a high-level understanding of the entire system, and a detailed understanding of the elements and tasks fundamental to the application being tested. Subject matter experts are likely to: Determine the business processes to test. Identify activities common to multiple processes (such as a login procedure, which is used in many business process tests or flows). Create business components and manual steps. Define automated keyword GUI component steps. Create flows and business process tests.
Automation Engineers, also known as Test Automation Experts	Automation engineers are experts in automated testing using a testing tool such as OpenText Functional Testing. The automation engineer is only needed if the Business Process Testing framework includes automated tests. Note: Automation engineers can work directly in Business Process Testing or access Business Process Testing functionality from within OpenText Functional Testing. Automation engineers are likely to: Define automated keyword GUI component steps. Define automated GUI scripted components. Define automated API scripted components. Prepare resources required for testing features: Application areas, which can be defined within OpenText Application Quality Management and other testing tools. Function libraries with general scripts, which are encapsulated into general operation keyword GUI steps. Shared object repositories, representing the objects in the application being tested. You can use these objects to create steps in business components with keyword GUI automation. Automation engineers may also be responsible for some of the tasks listed for the subject matter expert. Automation engineers can also create, debug, and modify business components in the testing tool.
QA Testers	QA testers are likely to: Define data for iterations and configurations. Run tests to verify that they are designed appropriately and run as expected. Review test results.
Test Architects	Test architects design and implement the testing framework. Test architects are likely to: Determine the design approach. Decide how to categorize, name, organize, and use components. Set up standards for using Business Process Testing in the various OpenText Application Quality Management modules.
OpenText Application Quality Management Administrators	Set up and configure Business Process Testing and its users.

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 workflow in an organization may differ for different projects, or at different stages of the application development life cycle. For more

Categorize components

Because Business Process Testing is a component-based testing framework, components are largely responsible for driving the system being tested. The framework encourages component design and reuse, so the method you use to categorize your components has a large impact on the ability of your framework to manage your testing abilities successfully.

Logical components

A logical component represents the use of a part of the screen with one or more controls, or a set of API calls which combine to perform some application logic. This category is based on a specific context in the application under text.

For example, a Login component represents the login process, based on a login window that allows you to enter a user name and password, and then click a Login button.

Application object components

An application object component might represent an object on the screen or a call to a single API.

This category is usually independent of the context within the application under test, and can be used in many situations. You decide the level of granularity that most encourages reuse.

For example:

A Button component represents the button object.
A Grid component represents a grid object in a pane or window.
An Interrogate component represents the interrogation of the application under test's backend database.

Generic components

A generic component performs actions outside of the context of the application under test. It can be reused in tests of different applications.

For example, a Launch component represents the launching of a browser.

Note: Flows can be thought of as complex components or small business component tests. Flows comprise a set of components in a fixed sequence to perform a specific task. A flow can be part of a test just like any other component, but when the flow runs, Business Process Testing executes the components that the flow contains.