About HP BPT

HP Business Process Testing

 Automated testing can be used in an environment with multiple SAP Applications, Ex. R/3, SAP SA, SAP FI, EBP, BW, etc. It also covers the usages and requirements which are critical to deploy an Automated Testing solution. This article will help Consultants alike gain insight in the application of Automated Testing in an SAP Environment and help to bring the best return on investment.

HP Business Process Testing

Automated testing can be used in an environment with multiple SAP Applications, Ex. R/3, SAP SA, SAP FI, EBP, BW, etc. It also covers the usages and requirements which are critical to deploy an Automated Testing solution. This article will help Consultants alike gain insight in the application of Automated Testing in an SAP Environment and help to bring the best return on investment.

Understand Business Process Testing

Business Process Testing is a role-based testing model that enables Subject Matter Experts—who understand the various parts of the application being tested—to create business process tests in Quality Center. Automation Engineers—who are experts in Quick Test and automated testing—use Quick Test to define all of the resources and settings required to create business process tests. Integration between Quick Test and Quality Center enables the Automation Engineer to effectively maintain the resources and settings, while enabling Subject Matter Experts to implement business process tests.

Business Process Testing uses a keyword-driven methodology for testing, based on the creation and implementation of business components and business process tests. A business component is an easily-maintained, reusable unit comprising one or more steps that perform a specific task within an application. A business process test comprises a series of business components, which together test a specific scenario or business process. For example, for a Web-based application, a business process test might contain five components—one for logging on to the application, another for navigating to specific pages, a third for entering data and selecting options in each of these pages, a fourth for submitting a form, and a fifth component for logging off of the application. Business components and business process tests are generally created inQuality Center by Subject Matter Experts, although Automation Engineers can also create business components in Quick Test.

Components in QTP

QuickTest enables you to create and modify two types of components: business components and scripted components. A business component is an easily-maintained, reusable unit comprising one or more steps that perform a specific task. A scripted component is an automated component that can contain programming logic. Scripted components share functionality with both test actions and business components.

Automation Engineer:

The Automation Engineer is an expert in using an automated testing tool, such as QuickTest Professional. The Automation Engineer works with the Subject Matter Expert to identify the resources that are needed for the various business process tests.

The Automation Engineer then prepares the resources and settings required for testing the features associated with each specific component, and stores them in an application area within the same Quality Center project used by the Subject Matter Experts who create and run the business process tests for the specific application.

Each application area serves as a single entity in which to store all of the resources and settings required for a component, providing a single point of maintenance for all elements associated with the testing of a specific part of an application. Application areas generally include one or more shared object repositories, a list of keywords that are available for use with a component, function libraries containing automated functions (operations), recovery scenarios for failed steps, and other resources and settings that are needed for a component to run correctly. Components are linked to the resources and settings in the application area. Therefore, when changes are made in the application area, all associated components are automatically updated.

The Automation Engineer uses Quick Test features and functionality to create these resources from within Quick Test. For example, in Quick Test, the Automation Engineer can create and populate various object repositories with test objects that represent the different objects in the application being tested, even before the application is fully developed. The Automation Engineer can then add repository parameters, and so forth, as needed. The Automation Engineer can manage the various object repositories using the Object Repository Manager, and merge repositories using the Object Repository Merge Tool. Automation Engineers can also use Quick Test to create and debug function libraries containing functions that use programming logic to encapsulate the steps needed

HP Business Process Testing Terminology:

Application Area:

A collection of resources and settings that are used for the creation and implementation of business components. These include function libraries, shared object repositories, keywords, testing preferences, and other testing resources, such as recovery scenarios. An application area provides a single point of maintenance for all elements associated with the testing of a specific part of your application. You can define separate application areas for each part of your application and then associate your components with the appropriate application areas.

Business Component (or Component):

An easily-maintained, reusable unit comprising one or more steps that perform a specific task. Business components may require input values from an external source or from other components, and they can return output values to other components.

Also known as Keyword-Driven Component

Manual Component:

 A non-automated business component created in Quality Center. In QuickTest, you can view and work with manual components only after converting them to automated business components.

Scripted Component:

An automated component that can contain programming logic and can be edited in QuickTest using the Keyword View, the Expert View, and other QuickTest tools and options

Keyword View:

A spreadsheet-like view that enables tests and components to be created, viewed, and debugged using a keyword-driven, modular, table format.

Function Library:

A document containing VBScript functions, subroutines, modules, and so forth. These functions can be used as operations (keywords) in components. You can create and debug function library documents using the QuickTest function library editor.

Business Process Test:

A scenario comprising a serial flow of business components, designed to test a specific business process of an application.

Component Input Parameters:

Variable values that a business component can receive and use as the values for specific, parameterized steps in the component.

Component Output Parameters:

Values that a business component can return. These values can be viewed in the business process test results and can also be used as input for a component that is used later in the test.

Local Input Parameters:

Variable values defined within a component. These values can be received and used by a later parameterized step in the same component

Local Output Parameters:

Values that an operation or a component step can return for use within the same component. These values can be viewed in the business process test results and can also be used as input for a later step in the component.

Roles:

The various types of users who are involved in Business Process Testing

Automation Engineer:

An expert in QuickTest Professional automated testing. The Automation Engineer defines and manages the resources that are needed to create and work with business components. The Automation Engineer creates application areas that specify all of the resources and settings needed to enable Subject Matter Experts to create business components and business process tests in Quality Center. The Automation Engineer can create and modify function libraries, and populate a shared object repository with test objects that represent the different objects in the application being tested. The Automation Engineer can also create and debug business components in QuickTest.

Subject Matter Expert:

A person who has specific knowledge of the application logic, a high-level understanding of the entire system, and a detailed understanding of the individual elements and tasks that are fundamental to the application being tested. The Subject Matter Expert uses Quality Center to create and run components and business process tests.

SAP TAO FAQ's

• What is SAP TAO?
• Which Version you are using?
• What is the Latest Version in SAP TAO?
• What are the Advantages in SAP TAO?
•  What are the Patches required for SAP TAO?
• What is BPT?
• Difference between BPT & SAP TAO?
• Which Framework using for SAP TAO?
• What is CBASE?
•  What is the SAP TAO Architecture?
• What are the Prerequisites for SAP TAO?
• SAP Solution Manager Mandatory for SAP TAO 1.0? 
• SAP Solution Manager Mandatory for SAP TAO 2.X?
• What is UI Scanner?
• What is Inspector?
• How many ways to Create a components using TAO 1.0? 
•  How many ways to Create a components using TAO 2.x?
• Which service pack required for SAP TAO 2.7?
• What is Import/Export?
• What is Consolidate?
• What is PFA?
•  What is Change Analyzer?
• What is a Component?

       HP BPT FAQ's

• What is BPT?
• How many ways to create a Component using BPT?
• What is Application Area?
• What is Keyword Driven Components?
• What is Scripted Component?
• What is BPT Architecture?
• How to passing values?
• How to grouping the Components?
• What are the disadvantages for BPT?
• How to Iterate the components?

About SAP TAO

About Automation:

Automation testing is an emerging field that draws maximum benefits with minimum effort. The benefit of automation testing is its ability to increase the efficiency of resources, increase test coverage, and increase the quality and reliability of the software.

Regression testing is always being a key area during an implementation of SAP R/3. SAP implementation will be generally multi year, multi phased, and multi location; hence the Regression testing is a critical area. Key challenges here are frequency of regression testing cycle, huge number of critical business processes needs to be covered during regression and definitely cost involved in it.

SAP Test Acceleration & Optimization:

The SAP Test Acceleration and Optimization (SAP TAO) software streamlines the creation and maintenance of ERP business process testing.

The SAP TAO Client application runs on a Windows system. It performs three key functions: inspecting transactions from a SAP server, exporting the transactions to HP Quality Center, and consolidating components or scripts from HP Quality Center.

SAP TAO Features:

Inspection: Eliminates record/replay activities, significantly reduces upfront development time, and greatly reduces ongoing maintenance due to re-scanning capabilities and component concept

UI Scanner: Automatically scans the SAP metadata to generate all necessary test components, and uploads in to HP Quality centre automatically.

Data-driven testing: This framework supports data-driven testing by importing data from an external data sheet.

Conditional checking: Conditional constructs such as ‘if’ can be implemented using components and keywords to handle different flows based on various conditions.

Calling built in components and reusable BPT components: Common components or scripted components can be triggered through consolidated script. This framework supports a functional decomposition approach. This increases the reusability of components, which in turn reduces the unnecessary repetition of steps.

Reports: SAP TAO log file can also be used to perform effective analysis on execution reports. These reports can be customized to display the pass or fail condition of any functionality, and can capture the snapshot of the application.

Use of variables: Variables can be defined using scripted components and used across the generated test script. This can be used to capture runtime values, which can be reused as input elsewhere during test execution.

Exception handling: In this framework we can instruct QTP to execute the script on warning messages, information messages, and information pop ups by incorporating if, else looping in the script. This helps enhance script with various exceptional handling capabilities.

SAP TAO Features

Testing Deployment: SAP TAO, in tandem with HP Quality Center, dramatically reduces the amount of time required to build and execute test scripts

Less effort: The effort involved in coding, recording and reviewing is minimized, the tester simply has to drag and drop the built-in components, reducing the time required for development of scenarios, Recording is also not required as the TAO Test Component Repository is used.

Reuse:  SAP TAO eliminates the need to create new tests whenever a component changes. If one component changes in a group of tests, just replace that component and then re-consolidate the tests

No scripting skills required by the end user: No coding skills required to automate and to review the business scenarios. The scenarios are user friendly with good readability. Scripts can be interpreted easily by a person who does not have complete knowledge of the tool.

Maintenance: SAP TAO allows you to record component parameters. SAP TAO provides a Microsoft Excel spreadsheet to save parameters for reuse and maintenance. You can also move components from HP Quality Center to SAP TAO for additional backup possibilities

Robustness: The SAP TAO Inspection process ensures that SAP TAO tests are more robust during changes. Inspection examines the data content within a component, not just the screen object behavior

Improved Cycle Time: Accelerated execution 20-25 times faster testing through built-in business components, Lower overall development time due to reduced recalls and post-release fixes

Framework Architecture:

Architecture forms the foundation of any software application. It should be robust enough to handle the desired functions efficiently and effectively. In this approach, the goal is to develop reusable business process test framework that can be used directly across any SAP system without spending any extra time on it.

The SAP TAO Client application runs on a Windows system. It performs three key functions: inspecting transactions from a SAP server, exporting the transactions to HP Quality Center, and consolidating components or scripts from HP Quality Center.

In order to make all the components of the system work in sync, it is important to define the components, its functionalities, as well as the binding relationship between them.

The Framework Architecture comprises of the following components:

Framework

The framework consists of the following sub-components, namely:

·        Inspect

·        Import/Export

·        Consolidation

·        TAO Test Component Repository

·        Common functions

Driver Script / Test Cases:

The Consolidated Driver Script is the combination of the individual Transaction Scripts along with the built in components from TAO. The Data Management sheet is used to run the Transaction scripts for different sets of Data.

Common Functions:

The common functions are the functions that are reusable across all platforms. These functions are application independent, and converted in to business components. Separating common functions from the business components ensures maximum utilization of reusable scenarios, and in turn reduces the maintenance effort of scripts.

Common functions include conditional functions, loop functions, etc.

Data Load Components:

Data flow control is determined via a worksheet in cooperation with the Initialize Script component.

Data Management Solution:

Data Management solution allows for easy data maintenance, iteration control and increased flexibility. This is achieved through standard Microsoft Excel work sheet.

External test data is given as inputs to the test scripts to perform the same operations on the application using different set of data. This spreadsheet holds multiple combinations of inputs to be fed to test the application. The best practice here is to keep the data sheet in a common place, preferably in the SAP TAO root folder.

Reporting:

After execution of the test script, it is necessary to get the results of the execution. Apart from the test execution report generated by the QTP tool, SAP TAO creates a detail test logs which contains screen shots, debug files, and test results file with step by step information.

Testers can customize SAP TAO log file using common function components, these log files provide details for which business component have failed or passed while running a test suite. This helps in performing effective analysis on the execution report.

Component Folder Structure:

The BPT methodology utilizes Business Components to build tests. These components act as reusable building blocks that can be combined and recombined to meet business process testing needs.

Components found within the Business Components module of Quality Center under the SAP R3 folder.  This folder is further organized in three categories:

§         SAP Transaction Components

§         SAP Common Functions

§         SAP Buttons

SAP Transaction Components:

The SAP Components have been separated into transactions identified by their SAP T-Code. These transaction-specific components can be found under the SAP R3 – Transactions folder.  The contents of this folder are further organized into subfolders based on T-code.  These components are large enough to stay manageable, but also small enough so that if branching functionality needs to be tested within these transactions, it can be done without having to create additional component variations.

SAP Common Functions:

Components within the SAP R3 – Common Functions folder are usable across the entire SAP application.  In this section such operations as navigating between transactions, pressing the keyboard Enter key, or logging off have been coded and parameterized to facilitate ease of use.  This folder is divided into separate subfolders denoting the different types of common functions:

§         Actions

§         GUI Functions

§         Verifications

Each component within this section has been created to perform a specific operation, yet at the same time they are written in a generic fashion to be usable regardless of transaction.

Actions:

The Actions folder contains components for operations that are frequently performed throughout the SAP application.  Besides Login and Logout, other such components include Launch_SAP_Connection, Goto_Transaction, and Save_Record. 

GUI Functions:

The SAP graphic user interface (GUI) can essentially be broken down into a collection of text boxes, combo boxes, check boxes, etc.  Components used to access and perform basic operations on these generic elements can be found within the GUI Functions folder.

Verification's:

Tests are created primarily to verify the functionality of an application, and consequently, components are provided to handle this specific task.  The Verifications folder contains all such components and provides a wide array of verification checks, ranging from whether a text box contains the valid data to whether a button click has navigated the user to the correct transaction.

Steps for Script Development:

Executable component are developed using SAP TAO. The following steps are taken into consideration to build the test case:

1. In the SAP TAO Client, use the Inspector/UI Scanner to specify the transactions that you need to create a test script. Add other transactions as needed.
2. Open HP Quality Center to view the list of your selected components.
3. Drag and drop the transactions in the order that they occur in the business process.
4. HP Quality Center includes a list of common screen commands, such as Open, Enter, and Exit. Move the screen commands using drag and drop as needed.
5. Parameterize the data in the Excel spreadsheet or the HP Quality Center database.
6. On SAP TAO, consolidate the data into a single component that consists of the transaction code and screen operations.
7. In the HP Quality Center, create a second business process script using the single component.
8. Execute the test script and review it for any discrepancies.

Save the components in a directory that you can easily access when you need to update a screen or a transaction

SAP TAO Best Practices Recommendations:

Even though creating Business Processes Test Script using TAO might seem like a simple task, there are multiple factors and caveats that need to be taken into account

The initial Components base might prove complete for some BP’s, but there will surely be the need to create new components in order to complete all the scripts.

Though the UI Scanner will automatically generate the required components, it might be required to manually modify the QTP code, or even to manually create a whole component.

VB Script knowledge is welcomed, since sometimes, there might even be the need to create new functions in the libraries, or modify the existing ones.

Make sure you always use the most up to date versions of the SAP TAO.

Before starting the scripting, try to manually navigate the Business Process, so every step involved is clear and complete

Testing starts at the applet level and works outwards towards total integration of the SAP application

Develop a thorough data model to test the application and by the various user roles.

Develop test cases for reuse.

Develop different test types throughout the testing process (i.e., unit, system, positive, negative, etc.).

Design more functional test cases to cover all views and business objects.

Clearly identify the expected results for each test case.

Develop a traceability matrix to understand the test case coverage with the requirements.

Best Practices for Customizing:

Initialize_Script component is the first component for every test case. Ensure you have the correct shared network path to each applicable data table.

Include the Screen shot function after every verification point and / or when the system generates any return values (i.e., Sales order number).

Develop m0odular based components for repeatable processes to optimize the maintenance phase.

Never use a Transaction Code as a parameter.

Use test statuses (i.e., pass, fail, run required, etc.) appropriately within Quality Center to properly define the status of a given artifact to determine its true state.

Create custom component templates for users to add details to automated test scripts. 

Create Excel templates with login information to support external data.

SAP GUI Functions

Hi Friends ,
I will be writting all SAP GUI functions under the label "SAP GUI Functions"  :


1) SAP Function for Login to SAP GUI
    * Function Usage : Login to SAP GUI 
     *Arguments: strServerDescription - SAP Server
                        strClient - SAP Client
                        strUser - User ID
                        strPassword - Password
                       strLan - Language
   * Function Type   : Utility Function
    *Return values:         :Return SAP main screen name, otherwise returns '-1', if fail
'##################################################################

Public Function fn_Login(strServerDescription,strClient,strUser,strPassword,strLan)
'*Calling Autolog-in function
  SAPGuiUtil.AutoLogon strServerDescription,strClient,strUser,strPassword,strLan
'*Checking for the existing session
If    SAPGuiSession("guicomponenttype:=12").SAPGuiWindow("guicomponenttype:=21").Exist  Then
  Set ScreenObj = SAPGuiSession("guicomponenttype:=12").SAPGuiWindow("guicomponenttype:=21")
ElseIf   SAPGuiSession("guicomponenttype:=12","name:=ses\[2\]").SAPGuiWindow("guicomponenttype:=21").Exist Then
Set ScreenObj = SAPGuiSession("guicomponenttype:=12","name:=ses\[2\]").SAPGuiWindow("guicomponenttype:=21")
ElseIf   SAPGuiSession("guicomponenttype:=12","name:=ses\[1\]").SAPGuiWindow("guicomponenttype:=21").Exist Then
Set ScreenObj = SAPGuiSession("guicomponenttype:=12","name:=ses\[1\]").SAPGuiWindow("guicomponenttype:=21")
    End If
'*GetROProperty of active session object
If ScreenObj.Exist Then
fn_Login= ScreenObj.GetROProperty("screennumber")
Else
fn_Login= False
Reporter.ReportEvent micFail,"fn_Login","Login was unsuccessful"
End If    
End Function

'##################################################################
2) Logout from SAP
*Function Usage : Logout from SAP  
*Arguments: : N/A 
*Function Type  : Global Utility Function
*Return values:           : N/A
'##################################################################

Public Function fn_LogOut()
'*Closing all SAP sessions
    SAPGuiUtil.CloseConnections
'*Reporting to QTP
Reporter.ReportEvent micPass, "LogOff" , "Logged out of SAP"
End Function

'##################################################################
3) SAP Function for to close PDF fine by using QTP Script : 
    *Function Description: fn_ClosePDF
    *Function Usage:When required to Close the PDF use this function
    *Transactional Input Data   :None
    *Master Input Data   : None
     *Return values:           :None
'##################################################################

Public Function fn_ClosePDF()
'*Declaring variables
     Dim ShellObj
        '*Create Shell Object for Shortcut Keys
Set ShellObj = CreateObject("WScript.Shell")
'*Attach a receipt (pdf) to the Printed PDF file.
Window("micclass:=Window","regexpwndtitle:=Adobe Acrobat Professional").Close
SystemUtil.CloseProcessByName "Acrobat.exe"
'*Releasing variables
Set ShellObj=Nothing
End Function

'##################################################################