Header Ads

How to Put Automation Standards in Scripts


Automation process starts with capture and playback. It is the beginning. We need to upgrade our script with validations,Synchronization points, conditional points need to be added. We have upgraded from mouse based co-ordinate testing to proper element testing. Slowly our code base increases.

Apart from our regular test engineers,automation will be used by several other engineers(even functional test engineers too).It is important to have some standards in place.More and more standards , if placed,automation will be streamed lined and this will reduce human dependency and human error.This will ensure the same meaning for all. Reduces the code duplicity.Which means the reduce the effort of coding ,higher ROI. A structure if well documented and standardised yields more results and quality scripts than a quick undocumented and dirty approach. it will help to scale up the automation.Expensive tool is not necessarily needed or the best tool need not be picked. With the available tools, if we are able to put little standards , brings wonders.
Another important aspect of automation introduction in agile to provide coverage so that development team have safety net around them to change the code.Regression testing is only successful if we have such coverage and safety features around development.
Continuous integration using jenkins etc and test a build in automatic way will ensure the hygiene of development code. One can opt for any opensource tool to automate the testing with supporting infrastructure.
Quality of automation testing needs to be established.Automation should have many folds. The major aspect again smoke or monkey way of testing the new build. Even the basic security ,sanity and deep drive into application may come handy in changing environment.
By putting framework in place we can get  quality scripts,reusable code,stability and extend ability. Putting standards,guidelines automation will be matured enough to go in unattended mode. Else management  needs to incur the monitoring cost. 

The standards can be divided into three sections.
  1. Development standards
  2. Cosmetic Section
  3. Infrastructure Section

Development Standards:
  • Naming conventions for variables –camel casing.
  • Naming convention for global variable-must start with g
  • Naming convention for function name,class name follow starting of word with capital.also function needs to start with the return type.
  • Documentation and open discussion-A great discussion often leads to great findings. Follow the principle -If you don't know ask!!
  • How to guide to write a test script
  • Standards for naming an object
  • Data file construction
  • Constant should be all upper case
Cosmetic section mainly talk about the spacing. proper loop structure spacing. It is said code must be human readable first and then machine readable. Header is an important aspect of cosmetic section. Each function or class should have a header section to talk about the same. Comment must be included to make the code human understandable.
here is a set of does not don’ts
  • use of tagging gives better search facility.tagging can be mentioned in the commented area.
  • only one statement per line
  • maximum of 80 to 100 characters per line so that testers do not need to scroll right to see the content.
  • indent sub items’'
  • use of proper parenthesis of using operators.
  • turn on option explicit statement this will force variables to have certain values instead of junk,null values
  • parameters needs to be defined as pass by value or pass by reference
  • keywords like if then etc should be in the same line.
Infrastructure standards starts with a version control. When we have lot of test developers around , It is necessary to put a source control system in place. This is just to make sure that we do not step in ,others foot or break any existing functionalities. An automatic build process will be an cherry on the cake. It will ensure continuous building as soon as somebody checks in code. Jenkins,Cruse Control,hudson are few examples of Continuous Integration. 

Naming convention:
Local- Use camel casing-small letter "l" in the at the first letter of the variable.Like lFirstName. It denotes that it is a local variable.
Global-Same, if the scope is defined by global just use a small "g" at the beginning of the variable.Like-gCustomerNumber it denotes that the variable is global and accessed from anywhere.
CONST- Use all capital words for variable that are constant in nature.Like-CONST CDATE.
Functions should start with FN_ followed by function name like- FN_getDate()
Similarly for Action is QTP should be names as AN_Action name like-AN_CreateCustomer
Append a small r before function and action if they are reusable in nature.
rFN_getDate() or rAN_CreateCustomer

The script name can be varied from framework to framework. Best practice is to give a module name before the script name. Like-CO_CreateCustomer(Co stands for Customer operation). It must be capital letters.

Function Library should start with FN followed by function library name and ends with a lib.like-FN_CreateOrder_lib

For a small project we may go with .mtr but when project goes big it is better to use .tsr object repository.ORs should start with the Module name like-CO_Customer.tsr

All of these infrastructure,standards will come with a cost.Management should have enough budget for such activities.Management actions often result in the death of an automation effort. Many a time automation maintenance cost and effort is ignored,thinking automation fresh development is easy. In actual it is neither easy nor cheap. You need experts to solve issues. It is just not record play back.   

a structured approach is always needed to work properly in a team together. It is important to structure the test assets(name,testdata file,scripts,testcases,config file etc). Another best option to work with multiple environments is to use relative folder options.
Second approach is to share the function lists created by different automators. functions should be as generic as possible.
The best way to achieve this is to use

  1. One global function library
  2. Use business specific library 
Store all the structure in the version control system.Extra folders could be-

  1. Documentation-Related to framework
  2. General-Function to initialize the framework
  3. Language-Functions specific to any language

Powered by Blogger.