Controlled copy

Automation Strategy
Prepared By Reviewed by Approved By
Name
Role
Signature
Date
MM/DD/YYYY
<Project Name>_Automation Project Sign-!!
Signature
Name
Date
MM/DD/YYYY
Controlled copy Test Automation Plan
"able ! #ontent$
I. Overview ........................................................................................................................... 3
A. Purpose & Scope ....................................................................................................................... 3
B. Objective ..................................................................................................................................... 3
C. Test Automation Scope ............................................................................................................. 3
II. Automation Approach .................................................................................................... 4
A. Data Driven ................................................................................................................................
B. Script Deve!opment ...................................................................................................................
C. Automation an" Conventions ................................................................................................... #
D. Test Automation Stan"ar"s ...................................................................................................... #
$. Automation %atri& ..................................................................................................................... '
(. Script %aintenance ..................................................................................................................... '
). $va!uation o* $rrors an" (ai!ures ........................................................................................... +,
-. Test Automation $nvironment ................................................................................................ +,
I. Test Data .................................................................................................................................... ++
III. Prob!em .eportin/ an" Data .ecor"in/ .................................................................... ++
I0. Assumptions1 Depen"encies1 Concerns an" .is2s ................................................. ++
0. Automation Team .o!es an" .esponsibi!ities ........................................................... ++
0I. %i!estones an" De!iverab!es ...................................................................................... +3
0II. Test Team Trainin/ .e4uirements ............................................................................ +3
A. Trainin/ Sche"u!es to o**shore team ..................................................................................... +3
0III. .e*erences )!ossar5 .e*erence ............................................................................... +3
I6. Appen"i& A .................................................................................................................. +3
6. Chan/e 7o/ .................................................................................................................. +3
Controlled copy Test Automation Plan
%& verview
A& Purpo$e ' Scope
The purpose and scope of the document is to prepare a plan for Test
automation of <Project Name> Project. The scope of this document includes
the following:
! Plan for Test "utomation and co#erage
2) "utomation $hec%list
&! Plan for 'n#ironment
B. bjective
The o(jecti#e of test automation is to automate the following modules
present in the <Project> )*tem +roups
<Module >
<Module ,>
<Module &>
<Module ->
<Module .>
<Module />
#& "e$t Automation Scope
. Test automation en#ironment will (e setup at offshore (0 the offshore
1" testing team.
,. The offshore 1" testing team will also do test scripting2 #erification and
#alidation of results with co3ordination from the onsite testing team.
&. <Mercur04s "utomation Tools> will (e used for automation.
-. "utomation Testing scope is limited to Pla0(ac% the scripts in the
following 56 and Tools.
"ool "ool (er$ion perating
Sy$tem
<Tool Name> <7ersion> 8indows
9P/NT/,:::
Controlled copy Test Automation Plan
%%& Automation Approac)
The automation project will follow Module $entric "pproach as its framewor%. *t will
ha#e ;e<uirements Phase2 Module Phase2 Design Phase2 6cript $reation2 6cript ;e#iew
and "cceptance testing.
;e<uirements Phase in#ol#es gathering automation test re<uirements from the
manual test cases. This in#ol#es identif0ing test cases for automation and
prioriti=ing (ased on the needs. The comple>it0 factor for each script is also
defined. The "utomation Project Plan and "utomation ;e<uest Matri> would (e
the deli#era(les at the end of this phase.
Module Phase in#ol#es grouping similar test cases into groups and anal0=ing the
functions performed in each group. The common functions are written as a single
function and can (e used as reusa(le function across scripts. The module flow
diagram and script flow diagram will (e incorporated in the Design document.
Design Phase in#ol#es creation and re#iew of design document for all "utomation
tas%s. The deli#era(le for this phase would (e "utomation Design Document.
6cript creation phase will start once the design re#iew is complete. 6cript
$reation will (e done at 5ffshore. This in#ol#es creation of scripts for all modules
(ased on the priorities. 1TP /.. is used for creation of scripts. *f an0 other higher
#ersion of this tool is found appropriate it will (e used for automation.
?nit testing will (e performed (0 the de#eloper with the 6ample data.
6cript re#iew will (e done at offshore. The respecti#e leads and "utomation leads
at offshore will perform the re#iew.
"cceptance testing will (e done (0 the 5nsite leads. The respecti#e leads will
perform the acceptance testing (ased on the real time data. Training will (e
pro#ided to all onsite team once the acceptance testing is completed.
"ll the test cases identified2 as part of this project will (e translated into automated
scripts. 6ince re3usa(ilit0 and modularit0 are %e0 points in the automation effort2 we
ha#e created an automation framewor% called Module $entric "pproach. The main
o(jecti#e of this approach is to increase reusa(ilit0 of codes2 reduce redundanc0 in
codes2 and eas0 for maintenance.
The similar functions are written as reusa(le actions and will (e called from the script.
@unctions will also (e written to perform alternati#e or negati#e steps to #erif0 negati#e
and error conditions in the Test cases. ;ather than retrie#ing the data from within the
function2 arguments and data will (e passed as parameters in the function call. Ma%ing
the scripts function3centric will impro#e the a(ilit0 of an automation team to reuse the
code. "ll steps will (e documented in the function for reference. "n0 pre3re<uisites for
the function to run successfull0 will (e documented in the design document and in the
comments in the function header.
The Datata(le is a feature a#aila(le in Tool that will (e e>tensi#el0 used in order to
automaticall0 read from a data file and populate screen fields with data during run3time.
Data dri#en will (e done (0 maintaining a Data file A.>ls file!2 which will contain the
input data for the corresponding test case. This '>cel file is di#ided into #arious sections
and each of these sections pro#ide the num(er of records to (e added into the section
and the data. The data file name will (e documented in the script for reference.
There will (e a master scriptAaction! calling all the child scriptsAactions!.
"ll scripts will ha#e appropriate #erification points. 7erification points for %e0
intermediar0 functional results or states in the flow will (e inserted in3(etween steps and
Controlled copy Test Automation Plan
at the end of a script to #erif0 the e>pected results. The #erification points should also
chec% for e#er0 error condition possi(le from the ?*.
5n test e>ecution of each test script2 the test log will (e used to #erif0 the results for
#erification point passes and for the items that ha#e not passed.
*ntry #riteria
5nce the test casesAscenarios! are identified for automation from the manual test cases2
test criteria are defined2 the application under test is read0 for recording2 and the
automation process could start.
*+it #riteria
5nce the acceptance testing for a script is complete and the status for the re<uest is
changed to $losed2 the automation process will stop.
A& Data Driven
" data dri#en approach will (e followed in the preparation and e>ecution of scripts.
"s mentioned earlier in this document2 all the major @unctional @lows that are going to
(e automated using 1TP will ha#e one or more Data ta(les created for the screen input
li%e dates2 names etc. The script can read from and input to screen during run3time.
The datata(le feature is a#aila(le 1TP2 Test3>6ettings;esourcesDatata(le. The script
will read and fetch the datata(le name and the field name respecti#el0 and populate edit
controls in the screen.
" sample Datata(le used for searching the *tem group is attached in the appendi> for
reference.
B& Script Development
The automation scripts will (e created in a modular fashion. This means that scripts will
(e made re3usa(le. This also means (rea%ing down the functionalit0 into user defined
functions to ma%e it easier for de(ugging and maintenance. The ta(le (elow is an
e>ample of how a product specific test case script can (e (ro%en down into child and
parent scripts.
<Project> module contains a(out <num(er> test cases and in the module phase detail
anal0sis would (e done and the test cases would (e modulari=ed (ased on functions .
The functions that are distinct to the test cases would (e de#eloped as Parent script and
functions that are common to most of the test case would (e de#eloped as $hild scripts.
'>ample:
"e$t Automation
Document Name
,ajor -low Name
.Parent Script
Name/
,ajor !unction$ t)at
are occurring more
t)an once .#)ild
Script/
Script Name$
Controlled copy Test Automation Plan
@nTrimfunction
#& Automation and #onvention$
De$ign Document
Design Document will (e prepared for all the scripts as part of the Design phase.
*t includes scope of the script2 Purpose2 +roup strateg0 and logic frame2 Module
descriptions2 pre re<uisites2 module flow2 6cript flow2 De#eloper Notes and
;eferences.
a!
The Design Document Template has to (e followed for all the scripts.
Script -low
The script flow will (e created for all the scripts for (etter understanding and will
(e attached with the design document.
,odule -low
The module flow will (e created for all the scripts for (etter understanding and
will (e attached with the design document.
D& "e$t Automation Standard$
The 6cripting standards ha#e to (e followed for all the scripts.
Script Readability
The 6cript written/recorded should (e reada(le and presenta(le. The script
should (e in such a wa0 that the flow of the script is traced easil0. To achie#e these
goals we ha#e the following scripting standards
'#er0 logical step should (e preceded (0 a comment. The $omments should
follow the comment standards.
*ndentations should (e strictl0 followed
'#er0 script should ha#e a script le#el comment clearl0 mentioning the test case
that is emulated (0 the script2 author2 preconditions2 parameters Aif applica(le!2
post conditions2 and (rief description. The script header template for this
comment must (e maintained across all the scripts.
Script ,odularity
Modulari=ation of scripts helps in script maintaina(ilit0. The following are the
standards followed for modulari=ing the scripts.
'ach2 logicall0 separate2 operations should (e in a user defined Procedures or
functions or script. These su( scripts can (e called where#er needed.
Controlled copy Test Automation Plan
6u(routines can (e of three t0pes (ased on the operation performed (0 that
su(routine. There are different domains of functionalit0 that e>ist in the
application. Depending on that the common su(routines are classified as
+eneral purpose su(routines2 which are not domain specific2 and are shared
(etween the domains
Domain specific su(routines2 which are specific to that domain2 and are
used for emulating operations within the (oundar0 of that domain. Thus
onl0 the scripts that touch this particular domain will (e re<uired to use
these particular su(routines.
$ommon functions or ?tilities2 these are at a lower la0er of a(straction2 and
co#er single/small functionalit0.
*+ception 0andling
To maintain a smooth flow of the script one should ensure that all the une>pected
(eha#iors of the application are handled during Pla0(ac% of the +?* script. The standards
followed for these are as follows
"fter e#er0 step2 care should (e ta%en for possi(ilit0 of an0 warning/error
message popup. "n if3then3else structure should (e used to ensure this. No
application specific popup should (e treated as une>pected acti#e window (0
ro(ot.
'>istence of the window should (e #erified (efore an0 operation on that window.
6ufficient timeout should (e used.
Necessar0 #erification point should (e included to chec% whether the step was
successful.
There should not (e an0 possi(ilit0 of infinite loops in the script. Places where
such possi(ilit0 e>ists are loops that simulate waiting for application to respond2
li%e waiting for ta( to appear etc. *n an0 scenario2 the script should terminate
naturall02 and should log possi(le reason for failure2 in case the test case fails.
Beeping a timeout for such loops can ensure this.
$onsistent naming con#ention in scripting will impro#e reada(ilit0. The steps as to what
each script does and other comments where#er necessar0 will (e gi#en at the (eginning
of e#er0 script
"ll user interaction recordings will (e carried out consistentl0 with the mouse clic% action
and few %e0(oard actions Awhere#er re<uired! and identification of menus and com(o
(o> items should (e (0 name and not (0 *D. The reason recordings will not (e (ased on
%e0(oard actions is that there are no hot %e0s a#aila(le for screen le#el controls. Cence
screen na#igation using %e0(oard will (e a cum(ersome tas%. The recording will (e
carried out in a %nown des%top2 which will (e documented so that the same settings can
(e duplicated in another machine.
-ormat o! t)e )eader
Note1 The Ceader lines should (e commented.
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDD
Test Tool/7ersion :
Test Tool 6ettings :
;ecorded Erowser/#ersion :
@unction "utomated :
Preconditions : 8hat must (e set (efore the script runs
Post3conditions : The state of the s0stem when the script completes
Test $ase "utomated :
Parameteri=ation Done :
Controlled copy Test Automation Plan
"uthor : Testing 6er#ices
6cript Name :
6cript $reated on :
;e#iewed E0 :
;e#iew $omment :
Modified 5n :
Modified $omment :
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
DDDDDDDDDDDDDDDD
Controlled copy Test Automation Plan
*& Automation ,atri+
The list of "utomation tas%s that ha#e (een identified is mentioned in the (elow
document "utomation Matri>.doc
-& Script ,aintenance
There is a high maintenance o#erhead for automated test scripts as the0 ha#e to
(e continuousl0 %ept up to date2 otherwise 0ou will end up a(andoning hundreds
of hours wor% (ecause there has (een too man0 changes to an application to
ma%e modif0ing the test script worthwhile. "s a result2 it is important that the
test scripts are %ept up to date.
Thus once the scripts are created2 the0 need to (e #ersion controlled for their
changes. *n
8hen 8in;unner is connected to a TestDirector A which is a defect trac%ing/test
management tool! project with #ersion control support2 one can update and
re#ise the automated test scripts while maintaining old #ersions of each test. This
helps %eep trac% of the changes made to each test script2 see what was modified
from one #ersion of a script to another2 or return to a pre#ious #ersion of the test
script.
Cere2 we will discuss how to ha#e #ersion control of the scripts using $M 60nerg02
a third part0 #ersion control tool. The process can (e similiar if an0 other tool is
used li%e 766 or $76.
. The re<uester su(mits a change re<uest in accordance with the F6cript
;e<uest ProcessG.
,. The automation engineers re#iew the change re<uest and assign it to an
appropriate engineer. *n order to determine who (est to address the
re<uest2 the following items are ta%en into account:
a. 'ach de#eloper4s a#aila(ilit0
(. The le#el of effort of the change re<uest
c. 'ach de#eloper4s familiarit0 with similar re<uests
d. 'ach de#eloper4s familiarit0 with the moduleAs! to which the
script/tool applies
e. @or updates to e>isting scripts2 each de#eloper4s familiarit0 with the
script4s source language is considered.
3. The scripter then $hec%s out the latest #ersion of the scripts from $M 60nerg0
and mar%es the F"utomation ;e<uestG status in Test as F%n DevelopmentG.
-. Perform the changes to the script and does a unit test of the same.
5. *f the unit test passes then change the status of the "utomation re<uest in
Test director to FDevelopment #ompletedG. 'lse continue from 6tep -
6. "cceptance testing will (e performed (0 the concerned person who raised
the automation re<uest.*f it passes then change the status of the "utomation re<uest
in Test director to F#lo$edG. *f it fails then start from 6tep -.
7. *f the status of the automation re<uest is closed then change the test case
status in test director to FBa$elinedG.
H. The scripter then $hec%s *n all the modified scripts with updated readme
Controlled copy Test Automation Plan
document to $M 60nerg0 and ma%e the script read0 for use.
9. The status of the test case will (e changed to FBa$elinedG if the automation
of the test case is complete.
2& *valuation o! *rror$ and -ailure$
6ome of the failure conditions during script e>ecution ha#e (een ta(ulated for reference.
6. No 60mptom Pro(lem
Description
Possi(le "ction ;emar%s
. The script stops
a(ruptl0
@ailure to find a
window
;e3run the script (0 using
a (rea%point
The s0stem
resources are
low
;e3(oot the machine
@ailure to find a
file or director0
Aas defined in
the '>cel
6preadsheet!
$orrect the spreadsheet
and re3start the script
Put files in the correct
location and re3start the
script
,. The script runs to
completion (ut
there are $onte>t
sensiti#e errors
@ailure of a
#erification
point.
"nal0=e the failure to
confirm if it is a defect
and log the defect in Test
director
The #erification Point ma0
need to (e o#erwrite as
the (aseline ma0 ha#e
changed. @i> the pro(lem
(0 updating the (aseline.
Erea% in flow
due to a failure
to identif0 a ?*
feature or
control in the
screen
@i> the pro(lem (0
twea%ing script or (0 re3
running the script.
-. "e$t Automation *nvironment
Iicensed <Tool> to (e installed on 5ffshore 1" machine with at least ,H ME ;"M and
at least . +E hard dis% space should (e a#aila(le.
?ser ids will (e setup (0 the administrator to login and wor% on the repositor0 from the
1" machine.
Test en#ironment to e>ecute the scripts has to (e performed as per the notes a#aila(le
in the design document of e#er0 script.
;ecording and '>ecution of the script will (e done as mentioned (elow
Controlled copy Test Automation Plan
Tool Tool 7ersion 5perating
60stem
<Mercur04s tool name> <7ersion> 8indows
9P/NT/,:::
I. "e$t Data
Test data will (e ta%en from the data(ase.
The onsite team will pro#ide test data on re<uest.
The offshore team will prepare Datata(le (ased on the test data for automation
needs.
III. Problem Reporting and Data Recording
The ;esults of the script e>ecution of the <Project>"pplication test
cases will (e reported in the log files of the tool used for automation.
The ;esults of the script e>ecution of the component cases will (e
reported as defect files.
%(& A$$umption$3 Dependencie$3 #oncern$ and Ri$4$
The tool with wor%ing licenses should (e a#aila(le for the en#ironment to (e
set up and scripts to (e run.
5nsite team leads ha#e to inform the offshore team a(out the changes in the
test cases and test data and +?* la0outs.
5ffshore Testing team has to update the datata(le if there is an0 change in
the test data.
(& Automation "eam Role$ and Re$pon$ibilitie$
;ole ;esponsi(ilities Name
5nsite Iead ;e#iews Design Document2 6cript and
acceptance testing
5nsite
$oordinator
;e#iew and coordination.
5ffshore
$oordinator
;e#iew and coordination.
5ffshore Team
mem(er
De#elops Design Document2 De#elops 6cript2
6cript modification2 acceptance testing
Controlled copy Test Automation Plan
(%& ,ile$tone$ and Deliverable$
Milestone Tas% 6tart Date 'nd Date 'stimated
'ffortA *n
Person
Da0s!
Deli#era(les
"utomation Project Plan Project Plan "ppro#al
;e<uirements
Design Document
$reation
"utomation design
document.
6cript $reation 6cripts
6cript ;e#iew "ppro#ed 6cripts
"cceptance Testing @inal 6ignoff
"utomation ;eport
"utomation ;esult
6ummar0
(%%& "e$t "eam "raining Re5uirement$
Training
;e<uirement Training "pproach
Target Date
for
$ompletion
;oles/;esources
to (e Trained
Trainers
6cript
'>ecution and
Datata(le
modification
on Tools
Training will (e
conducted after
acceptance testing.
5nsite Team
Tool "d#anced
6cripting
Training will (e
conducted on need
(asis
5ffshore team Testing
6er#ices
"utomation
team
A& "raining Sc)edule$ to o!!$)ore team
Product Training Description Target date
of
$ompletion
;esources
to (e
trained
Trainers
0III. Re!erence$ 2lo$$ary Re!erence
"erm De!inition Pertain$ to1
TD Test Director Test Management Tool
"P6 "hold Pricing 60stem "pplication
;E;; ;ules Eased ;ecommended ;etails "pplication
1TP 1uic% Test Professional 1TP /..
+?* +raphical ?ser *nterface 5(jects in a screen
56 5perating 60stem
Controlled copy Test Automation Plan
?* ?ser *nterface
%6& Appendi+ A
Automation #)ec4 7i$t
6& #)ange 7og
Please note that this ta(le needs to (e maintained e#en if a $onfiguration
Management tool is used.
(er$ion
Number
#)ange$ made
7.: Initial Draft