Test Automation Framework Design

The approach should take a path as explained below. For designing a framework, various elements need to be taken into consideration. Utilities/Components (re-usable) would be designed for the following elements that include (not limited to):

• Actions to be performed - Identification of actions to be automated for each object of the application
• Communicating Systems - Study of different internal systems, third-party systems and their communication methodology
• Business Rules - List of business layers and any specific algorithm has to be studied. A separate function needs to be created for each specific algorithm.
• Database Communication - Database validation and check point validations
• Communication with additional automation tools - In the scenario, where we would require communicating with different automation tool. All the communication requirements needs to be identified and designed
• Data retrieval - Retrieval of data from multiple input data stores
• Schedulers - Functionalities related to invoking of relevant scripts based on scheduler configuration
• Tool Extensibility - Overcoming tool limitations. Components for actions/validations for which the tool does not provide any support
• Device Communication - Device communication and data transfer related actions/validations
• Log - User-defined logs for analysis
• Error Handlers - Error handlers to handle known and unknown errors and log the information
• Custom Messages - Display of relevant defined messages
• Result Presentation - Customized and presentable reports on completion of test execution

Test automation framework would be designed based on the listed factors, using the following guidelines.

• Application-independent.
• Easy to expand, maintain, and perpetuate.
• Encapsulate the testers from the complexities of the test framework
• Identify and abstract common functions used across multiple test scripts
• Decouple complex business function testing from navigation, limit-testing, and other simple verification and validation activities.
• Decouple test data from the test scripts
• Structure scripts with minimal dependencies - Ensuring scripts executing unattended even on failures

Borrowed from: http://www.thoughtworks.com/articles/guide-test-automation

Custom Reporter

'Custom reporter sending data to simple txt file

'Usage: CustomReporter "strStatus", "strStepName", "strMessage"

Public Function CustomReporter(strStatus, strStepName, strMessage)

'Override it with our custom class

Dim Reporter

Set Reporter = New clsReporter

Reporter.ReportEvent strStatus, strStepName, strMessage

End Function 'CustomReporter

Define a funnel function to be called from the test actions

Public Function GetReporter

Set GetReporter = Reporter

End Function

'Class definition

'In the example, our class just reporter to a text file

Class clsReporter

Dim oFileReporter

Public Sub ReportEvent(iStatus, sStepName, sDetails)

oFileReporter.AppendAllText "c:\log.txt", now & " ===> " & iStatus & " - " & sStepName & " - " & sDetails & vbcrlf

End Sub

Private Sub Class_Initialize

Set oFIleReporter = DotNetFactory("System.IO.File")

End Sub

End Class

Load SOR using VBScript

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

'Usage:

'sTsrMap = "C:\MyProjects\objectRepository.tsr"

'LoadUnloadTsr sTsrMap

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

Public Function LoadUnloadTsr(sTsrMap)

Dim qtApp, qtRepositories

Set qtApp = CreateObject("QuickTest.Application")

' getting the action name.

ActionName = Environment("ActionName")

' creating an object in order to access repositories of the above action.

Set qtRepositories = qtApp.Test.Actions(ActionName).ObjectRepositories

' removing all previously associated repositories.

qtRepositories.RemoveAll

' loading the repository.

qtRepositories.Add sTsrMap,1

Set qtApp = Nothing

End Function

Keyword Driven Aproach

Keyword-driven testing is a Software testing technique that separates much of the programming work from the actual test steps so that the test steps can be developed earlier and can often be maintained with only minor updates, even when the application or testing needs change significantly.

In case of keyword driven testing, we need to do proper planning and initial huge effort. Anyway it will give benefit of easy maintenance and easily adding more test cases/scenarios.

As we see the keyword view in QTP IDE, the keyword driven testing involves specifying the test steps in below format
Object Action parameter
e.g
Browser(“FireFox”).Page(“QualityPointHome”).webEdit(“username”).Set “QualityPoint”

Here,

->Browser(“FireFox”).Page(“QualityPointHome”).webEdit(“username”) is the Object.
->”Set” is the Action.
->”QualityPoint” is the parameter.

Here we can change any of the three things to create test steps.
The Keyword Driven framework consists of the basic components given below

1. Control File
2. Test Case File
3. Startup Script
4. Driver Script
5. Utility Script

1. Control File

a) Consists details of all the Test scenarios to be automated.
b) User will be able to select a specific scenario to execute based on
turning on or off a flag in the Control File.
c) Control File is in the form of an excel worksheet and contains columns
for Scenario ID, Execute (Y/N), Object Repository Path, Test Case File
Path.

2. Test Case File
a) Contains the detailed steps to be carried out for the execution of a test
case
b) It is also in the form of an excel sheet and contains columns for
Keyword, Object Name, Parameter

3. Startup Script
a) The Startup script is utilised for the initialization and reads the control files.
b) It then calls the driver script to execute all the scenarios marked for execution in the control file.

4. Driver Script

a) It Reads the Test Case files. Checks the keywords and calls the appropriate utility script functions based on specific keyword
b) Error Handling is taken care of in the driver script.

5. Utility Scripts

a) Perform generic tasks that can be used across applications.

Advantage of keyword Driven Framework.

• The main advantage of this framework is the low cost for maintenance. If there is change to any test case then only the Test Case File needs to be updated and the Driver Script and Startup script will remain the same.
• No need to update the scripts in case of changes to the application.
The framework design will be purely based on your requirements and your way of thinking. There is no Solid rule to follow.

Personally, I would like to have my own framework (hybrid framework) designed according to my own requirements.
Anyway, the best practice is, we should create below sub folders in your root folder.

ObjectRepository-> To keep your shared object repositories.
Datatables->To keep QTP data tables and external Excel sheets.
Config-> To keep environment variable xml file
RecoveryScenario ->To keep your recovery scenario files.
Tests-> You can keep your QTP Tests here. You may include Test containing Reusable Actions here. And a Test which is getting used as driver script can also be stored here.
library->you can keep your vbs file which contains vbscript functions.
Results-> You can store Result files (Either QTP result file or customized result file) here.
Actually there won’t be any solid rules/approach for creating QTP framework.

Borrowed from: http://qtpbook.com/2011/08/23/keyword-driven-testing-and-framework-in-qtp/

QA Automation Feasibility using QTP

Review the application’s

objects

customization

manual test cases

test environments

data refresh

Review QTP’s ability to support the application’s

custom objects

dynamic objects

data

exception handling

QTP licenses
Other test automation tools

Common test automation approaches –

record/playback

data-driven

modular

keyword/action-based

database

Factors that impact the short and long-term re-usability

Cost of test automation maintenance

Automation test data strategy

Test automation phases

Resource skill sets