Test Automation Best Practices (high-level presentation)

Test Automation Best Practices by Leonard Fingerman Email: esmlf@yahoo.com

Why Automate Testing ?

Improve software quality by reducing time to market

Improve reliability and consistency of testing processes

Allow manual testers do more complex & more suited for human kinds of tests (exploratory, usability etc.)

Enforce SLAs (service level agreements)

Ultimate goal is to save your business $$$...

Common Types of Automated Testing

Unit Testing (xUnit, TestNG etc)

Performance Testing (LoadRunner, WebLoad etc)

Functional System Testing (via UI, API, Web Services or Database) Model-based Regression

Some Functional Automated Test Tools

No GUI Object repository

Only web application support

Good browser support

Good language support (Java, Ruby,C# )

Can be easily extended as JUnit suite

Open-source

Selenium RC & IDE

VisualBasic scripting is limited

No IDE (may change in new release)

Licensed Product

Supports Web 2.0, Java or .NET applications

Full GUI Object Map repository

Seamless integration with QualityCenter

HP/Mercury Quick Test Pro (QTP)

Insufficient browser support

Licensed product

Built as Eclipse Plug-In with full IDE and Java support

Supports Web 2.0, Java or .NET applications

Full GUI Object Map repository

IBM/Rational Functional Tester (RFT) Cons Pros Tool

You selected a tool…now what?

A tool is supposed to do it all, right… ?

Don’t fall into tool vendor’s sales pitch …remember Record & Playback is not real test automation

According to recent IDT study ( www.idtus.com )

How to ensure success of TA project

Essentially automated test system is a piece of software designed to test your application  treat it as such

Evaluate an automated tool

POC (proof of concept) based on your native apps

Choose a tool that fits your business requirements & technical expertise

Plan

Establish goals & objectives ; budget; use or hire competent resources

Be ready to have quality metrics to validate the ROI (return of investment)

Design

Keep in mind the user community of TA system (Usability)

Choose an architecture that reduces maintenance and is extensible

Implement

Practice OOD principles of reusability & modularity (employ encapsulation & abstraction)

Introduce version control of your code

Establish code review process

Test & Maintain

Unit test your code

Constantly re-evaluate reasons for maintenance and improve TA architecture to minimize maintenance

Note: the tool is abstracted by higher-level framework component library

Data-driven automation framework

Automation is data-centric

User defines just data sets to drive tests with

Will have an external data source (DB tables, Excel spreadsheets, XML for data sets)

Flow control (navigation) is normally done by the test script not by the data source

Ex: data set exercises creation of new sales accounts functionality; stored in a DB table account_data

MA Boston 02111 2332 Washington st Mick Jagger Jr. RollingStones Inc. GA Atlanta 30075 5775 Main st Phil Collins Genesis Inc. State City Zip Street PrimarySalesPerson CompanyName

RFT code snippet

public void testMain(Object[] args)

{

String name;String primarySalesPerson;String address;String zip;String city;String state;

String query = "Select * from account_data";String AccessDBPath = Constants.FL_DB_PATH;

//Data abstraction class DataHandler – methods process data and return data values

DataHandler dlrAcctData = new DataHandler (AccessDBPath,query);

ArrayList listDlrAcctData = dlrAcctData.getRowsOfData();

try {

for ( int i=0;i<listDlrAcctData.size();i++){

coName = dlrAcctData.getValueForColumnName(i,“CompanyName");

primarySalesPerson = dlrAcctData.getValueForColumnName(i,"primarySalesPerson");

Type.text(CustomerCreate. field_name (),coName );

Click.object(CustomerCreate. image_primarySalesPersonIcon () );

Type.text(text_employeeModalPanelCommonN(),primarySalesPerson);

…

}

dlrAcctData .closeDB();

}

…

Keyword-driven automation framework

Automation is action-centric

De-compose your test cases/modules into granular re-usable keywords

The idea is for non-coders to be able to create automated test cases with action keywords

User defines flow control of the test via action keywords

Example: Test Case “Verify Checking Account Balance”

Enter Username and Password and Click submit button  step 1 is action Login

Enter “Phil Collins” as a Sales Person and Click Submit button

Verify the Sales Person was successfully created and Logout

So you may want to choose the following re-usable action keywords:

EnterText , Click , Login , VerifyExists

Keyword-driven automation framework

May have an external data source (DB tables, Excel spreadsheets, XML for data sets) with action keywords e.g.

.url:=.*createdSalesPerStatus.html .id:=SubmitSalesPer Button Click CreateSalesPerson Click Submit 3 UserLogin Module .value:=User Created Successfully .id:=CreationStatus DIV VerifyExists CreateSalesPersonStatus Verify Sales Person Creation Successful 4 .value:=Phil Collins .text:=SalesPerName Field EnterText CreateSalesPerson Enter New Sales Person data 2 .text:=Login Successful .id:=LoginSubmit N/A Login Home Login 1 Expected Object Type Action Page Description Step

Hybrid automation framework

Combines the best of both worlds

User defines data sets to drive tests with

User also defines flow control of the test via action keywords

May have an external data source (DB tables, Excel spreadsheets, XML for data sets) with action keywords in addition to generic and test case specific data sets

Q & A