Best Practices in Test Automation

The following best practices should be followed while generating automated test scripts.
? Always document sufficient comments inside test scripts/reusable actions/function libraries
? Make document for each test scenario’s or flow of the test scripts and including with Path of OR, Function library, Parameter data details
? Implement sufficient exception handling steps so that the chances of script failure due to test run errors are reduced
? Never hardcode paths and other similar data. Instead use relative paths.? When modifications are required to the test scripts, save the old script as an older version.
? Creation of a QTP scenario should always be done on a test environment that must be “production-like”.
? Follow naming conventions as specified in the scripting guidelines document.
? A Script Usage Manual should be prepared after the preparation of the automation scripts, to make the user understand the ways of executing the automation scripts.

Exception Handling

Exceptions are unexpected event that occur during the normal execution flow.
Start of Scenario run Test scenarios may be executed in sequences in test sets. There are multiple options to guarantee that each scenario can run in a test set, independent of whether the previous scenario was successful or encountered a Test Run Error.
One option is that in each Scenario before the first reusable action of the scenario an extra Function is inserted. The function navigates the application to the required base state.This will facilitate that in the situation where a previous test in the set has failed, the next test of the set can start anyway by setting the oracle applications to the Navigator form (which is the start screen for each reusable action).
Another option is to create a specific Logon reusable action to be placed at the start of each scenario. This reusable action will first close all Oracle sessions that are open and will then open a new sessions according to a predefined environment and user.

Popup Error screens Handle all expected pop up error messages. Two approaches may be followed

? Close the popup and continue navigating through the scripts. Here the settings should be done to proceed to the next step on error.

? Terminate the test script and print the error log.

Application Errors Due to application errors test scenario execution breaks. When an application error is identified, prepare the error log and terminated the test. Prepare backend validation scripts and use them to validate event status frequently. When an error is noticed execute the exception handlers.

Common Directory Structure - Automation Frame Work

When Quality Center is not available, a common folder would be maintained in a shared network drive. The following directory structure will be used for automated test script development.

Functional Decomposition Model -Automation Frame Work

1. The main concept behind the "Functional Decomposition" script development methodology is to reduce all test cases to their most fundamental tasks. These tasks/components will be implemented as User-Defined Functions, Sub routine or Utility Scripts. The component scripts should perform these tasks independently of one another based on the data input.

The key modules/components of the test automation architecture for Platform automation will consist of the following:

1. Test Scripts
2. Reusable Actions
3. Library Files
4. Configuration Files
5. Utility scripts
6. Data Files
7. SQL Queries
8. Results/Log files

Data Driven Approach - Automation Frame work

It has been decided to follow a data driven approach for test automation of (Project/Platform Name) application. In a data driven approach, data is made independent of the test. Input data is provided from an external data source. MS Excel will be used as the external data input source. During test execution test data would be called inside the test from the external data sheets.
The following are the advantages of a data driven approach.

1. Ease of data maintenance
2. Iterate the same test with multiple set of test data
3. Baseline test data for different type of tests.

The test data used by testing team during manual test case development would be used while automated test script development.
Example:
<> takes input data –Customer Number, Order Type Ordered Items etc. The data would be stored in the excel file named SCN-Supplies_Data.xls. The same would be called inside QTP during test execution.

Plug and play model – Test Automation Architecture

• Each regression test scenario under will be implemented using a scenario level script (Driver Script). The scenario level test script will implement calls to component level scripts, which will be executed in sequence to complete the test execution flow. Such a plug and play model will enable us to add/remove components from the test scripts as and when modifications are required. Also, component scripts will be reused inside multiple scenario level test scripts.
  
  Example:
  (Scenario script header)
  (Initializations – Load the OR)
  (Initializations – Load the Excel Sheet)
  (Initializations – Load the Functional Library)
  (Initializations – Load the Expectation handling)
  Call ( login)
  Call (Test1)
  Call (Test2)
  Call (Test3)
  Call (Test4)
  Call (logout)
  (Initializations – Close all Initializations)
• The component level scripts are usually independent. When a modification is required in the “PO validation” process, the particular components only need to be worked on. Also, the modification will reflect in all scenario level scripts where “PO validation” is called.

Getting Child Object

Dim obj_ChkDesc

Set obj_ChkDesc=Description.Create

obj_ChkDesc(“html tag”).value = “INPUT”

obj_ChkDesc(“type”).value = “checkbox”

Dim allCheckboxes, singleCheckBox

Set allCheckboxes = Browse(“Browser”).Page(“Page”).ChildObjects(obj_ChkDesc)

For each singleCheckBox in allCheckboxes

singleCheckBox.Set “ON”

Next

Delete cookies with a single line of code

• Cookies are small chunk of information of code placed by the website on the user local/browser cache. QTP provides a way to view/delete cookies. The below mentioned methods can be used for various operation.
• WebUtil.
• DeleteCookie Delete specified cookie for the specified domain
• DeleteCookies Delete all cookies present on the local cache
• GetCookies for a specified domain
• AddCookie Add specified cookie for a specified domain
• There are many other functions available also. But I would not be going into the details of any of these. You can find all the function when you type “webutil.” In the QTP script editor.

Sample Automation Frame Work Diagram

• Function & Utilities: Collection user Define function based on the application or system
  Test Data & Environment Data: Collection test data
  Test Case Script: Test script for each module or flow of the application or system
  Share Object Repository: Object Repository
  Test Case Log File: Test Result for the test case or script log file

Note: Don’t use Quality centre for this frame work