Test Automation Frame Work

This document aims at providing state of the art methodology for test automation and guidelines to automate manual testing process currently in use. This requires that a formalised "manual testing process" currently exist in company or organisation. The basic requirements for starting automation process are 1. Detailed test cases, including predictable "expected results", which have been developed from Business unctional !pecifications and Design documentation ". # standalone Test $nvironment, including a Test Database that is restorable to a %nown constant, such that the test cases are able to be repeated each time there are modifications made to the application &ey reasons for the success of the #utomation 1.!election of proper tool. ".!electing proper methodology for #utomation. '.Trained #utomation $ngineer. (.)roper #utomation environment *hardware and software+ Different #utomation ,ethodologies available 1. The "Key-Word Driven" or "Test Plan Driven" Method

2. Fuctional Decomposition Method. . The "Key-Word Driven" or "Test Plan Driven" Method! The main concept behind the " unctional Decomposition" script development methodology is to reduce all test cases to their most fundamental tas%s, and write User-Defined Functions, Business Function Scripts, and "Sub-routine" or "Utility" Scripts which perform these tas%s independently of one another. -n general, these fundamental areas include. The design of unctional Decomposition ,ethod is as follows Driver Script

Test Case Script1

Test Case Script2

User defined Function Script

Data File1

Business Function Script

Subroutine Script

Data File2

Driver !cripts. )erform initialisation *if required+, then call the Test Case !cripts in the desired order. Test /ase !cripts. )erform the application test case logic using Business unction !cripts Business unction !cripts. )erform specific Business unctions within the application0 !ubroutine !cripts. )erform application specific tas%s required by two or more Business scripts0 1ser2Defined unctions. 3eneral, #pplication2!pecific, and !creen2#ccess unctions0

#dvantages. 1. 1tilising a modular design, and using files or records to both input and verify data, reduces redundancy and duplication of effort in creating automated test scripts. ". !cripts may be developed while application development is still in progress. -f functionality changes, only the specific "Business unction" script needs to be updated. '. !ince scripts are written to perform and test individual Business unctions, they can easily be combined in a "higher level" test script in order to accommodate complex test scenarios. (. Data input4output and expected results is stored as easily maintainable text records. The users expected results are used for verification, which is a requirement for !ystem Testing. 5. unctions return "T61$" or " #7!$" values to the calling script, rather than aborting, allowing for more effective error handling, and increasing the robustness of the test scripts. This, along with a well2designed "recovery" routine, enables "unattended" execution of test scripts.

Disadvantages. 8. 6equires proficiency in the !cripting language used by the tool *technical personnel+0 9. ,ultiple data2files are required for each Test /ase. There may be any number of data2inputs and verifications required, depending on how many different screens are accessed. This usually requires data2files to be %ept in separate directories by Test /ase. :. Tester must not only maintain the Detail Test )lan with specific data, but must also re2enter this data in the various required data2files. ;. -f a simple "text editor" such as Notepad is used to create and maintain the data2files, careful attention must be paid to the format required by the scripts4functions that process the files, or script2processing errors will occur due to data2file format and4or content being incorrect.

3.

The "Key-Word Driven" or "Test Plan Driven" Method! This method uses the actual Test /ase document developed by the tester using a spreadsheet containing special "&ey2<ords". This method preserves most of the advantages of the " unctional Decomposition" method, while eliminating most of the disadvantages. -n this method, the entire process is data-driven, including functionality. The Key ords control the processin!.

=ere the application functionality is divided in to smallest functions. 1tility scripts are written for these functions. # standard Test case document is written containing sequences of utility script and required data and verification data. 1tility scripts are executed one by one to perform > chec% required functionalities.

#rchitecture Driver Script Controller Script Detail Test Plan

Utility Script

User Defined function

The architecture of the "Test )lan Driven" method appears similar to that of the " unctional Decomposition" method, but in fact, they are substantially different. Driver !cript )erforms initialisation, if required0 /alls the #pplication2!pecific "/ontroller" !cript, passing to it the file2names of the Test /ases *which have been saved from the spreadsheets as a "tab2 delimited" files+0 The "/ontroller" !cript 6eads and processes the file2name received from Driver0 ,atches on "&ey <ords" contained in the input2file Builds a para"eter-list from the records that follow0 /alls "1tility" scripts associated with the "&ey <ords", passing the created parameter2list0 1tility !cripts )rocess input parameter2list received from the "/ontroller" script0 )erform specific tas%s *e.g. press a %ey or button, enter data, verify data, etc.+, calling "1ser Defined unctions" if required0 6eport any errors to a Test 6eport for the test case0 6eturn to "/ontroller" script0 1ser Defined unctions 3eneral and #pplication2!pecific functions may be called by any of the above script2types in order to perform specific tas%s0 #dvantages. This method has all of the advantages of the " unctional Decomposition" method, as well as the following. 1?. The Detail Test )lan can be written in Spreadsheet format containing all input and verification data. Therefore the tester only needs to write this once, rather than, for example, writing it in ord, and then creating input and verification files as is required by the " unctional Decomposition" method. 11. Test )lan does not necessarily have to be written using #$cel. #ny format can be used from which either "tab2delimited" or "comma2delimited" files can be saved *e.g. #ccess Database, etc.+. 1". -f "utility" scripts can be created by someone proficient in the #utomated tool@s !cripting language prior to the Detail Test )lan being written, then the tester can use the #utomated Test Tool i""ediately via the "spreadsheet2input" method, without needing to

learn the !cripting language. The tester need only learn the "&ey <ords" required, and the specific format to use within the Test )lan. This allows the tester to be productive with the test tool very quic%ly, and allows more extensive training in the test tool to be scheduled at a more convenient time. 1'. -f the Detail Test )lan already e$ists in some other format, it is not difficult to translate this into the "spreadsheet" format. 1(. #fter a number of "generic" 1tility scripts have already been created for testing an application, we can usually re2use most of these if we need to test another application. This would allow the organisation to get their automated testing "up and running" *for most applications+ within a few days, rather than wee%s.

Disadvantages. 1. Development of "customised" *#pplication2!pecific+ unctions and 1tilities requires proficiency in the tool@s !cripting language. Aote that this is also true of the " unctional Decomposition" method, and, fran%ly of any method used includin! "6ecord4)laybac%". ". -f application requires more than a few "customised" 1tilities, this will require the tester to learn a number of "&ey <ords" and special formats. This can be time2consuming, and may have an initial impact on Test )lan Development. Bnce the testers get used to this, however, the time required to produce a test case is greatly improved. '. This method involves writing %ey words for the smallest functions. <e may have to spend lot of time in identifying the %ey words. -f the application is big the unit functions become very large in number and it becomes difficult to maintain the scripts.

".Another approach #deviation$ %rom Test Plan Driven Method! The new approach involves identifying the independent activities. /reate main sequence for every independent activity. -dentify sub sequences in the main sequence. <rite functions for every sub sequence. <rite functions for every test case in the sub sequence. -dentifying !equence, !ub !equence and functions !equence. ,ain function, which performs independent activity. $x 6egistration. !ub !equence. unction, which leads to next level of function. unction. 6epresent validation function for every field present.

Architecture

Library Functions

ariables

Driver Script

Detail Test Plan

!eport

Detail

Test Plan !cript to be called along with verification unction ,ain !equence 1 starts here !ub sequence 1 in main sequence !1 !ub sequence " in main sequence !1 1nit function to perform unit testing in a !ub sequence !ub sequence " in main sequence !1 ,ain !equence " starts here !ub sequence 1 in main sequence !" 1nit function to perform unit testing in a !ub sequence 1nit function to perform unit testing in a !ub sequence 1nit function to perform unit testing in a !ub sequence !ub sequence 1 in main sequence !" -nput1 -nput"

#ction

!1 !121 !12" 1 !12' !" !"21 1 " '

!"2"

Driver !cript reads the detail Test )lan line by 7ine. -t calls the main sequence function first. Then call the sub sequence functions. -n every sub sequence function it calls unit functions, which are independent of each other and perform unit function. -f a function in sub sequence fails the next function is called. -f a sub sequence function is failed execution goes to next main sequence. The lo&ical %lo' o% the e(ecution is as %ollo's! P P)F P S1"2

S1

S1"1

F1

F2

F S2 P S2"1

F F1 P)F P S2"2

F2

Key Features 1.Cerification functions are part of the main script. ".# standard Test )lan is written. '.# standard out put format for report generation. (.-nupt data and verification data are part of the Test )lan . 5.!ingle sequence or group of main or all sequences can be executed . 8.# single test case, scenario or group of test cases can be executed . 9.Aew !equences or unit functions can easily be added to the test plan. Advanta&es The Detail Test )lan can be written in Spreadsheet format containing all input and verification data. Therefore the tester only needs to write this once, rather than, for example, writing it in ord, and then creating input and verification files as is required by the " unctional Decomposition" method. Test )lan does not necessarily have to be written using #$cel. #ny format can be used from which either "tab2delimited" or "comma2delimited" files can be saved *e.g. #ccess Database, etc.+. -f "utility" scripts can be created by someone proficient in the #utomated tool@s !cripting language prior to the Detail Test )lan being written, then the tester can use the #utomated Test Tool i""ediately via the "spreadsheet2input" method, without needing to learn the !cripting language. The tester need only learn the "&ey <ords" required, and the specific format to use within the Test )lan. This allows the tester to be productive with the test tool very quic%ly, and allows more extensive training in the test tool to be scheduled at a more convenient time. 15. -f the Detail Test )lan already e$ists in some other format, it is not difficult to translate this into the "spreadsheet" format. 18. #fter a number of "generic" 1tility scripts have already been created for testing an application, we can usually re2use most of these if we need to test another application. This would allow the organisation to get their automated testing "up and running" *for most applications+ within a few days, rather than wee%s. The driver script, which performs the basic logic of driving the test plan, can be written can be written only once for every tool and can used for all proDects using the same tool. Aew functionalities can easily incorporated by adding new sequences to the Test )lan.