Implementation of Script Quality.

Prepared By: Niraj Kumbhar Supervised By: Santosh Dhere Quality Kiosk Technologies Pvt Ltd. Date: 30 June, 2011

Table of Contents
1. Ruby Coding Style. 2. Current Script Observations. 3. Solutions 4. Implementation Phase. 5. Script Template. 6. Audit Documentation.

Ruby Coding Style

Order your code as follows:

header block

require statements include statements

class and module definitions main program section testing code

Formatting:
Use ASCII (or UTF-8, if you have to). Use 2 space indent, no tabs. Use Unix-style line endings. Use spaces around operators, after commas, colons and semicolons, around { and before }. No spaces after (, [ and before ], ). Use two spaces before statement modifiers (postfix if/unless/while/until/rescue). Indent when as deep as case. Use an empty line before the return value of a method (unless it only has one line), and an empty line between defs. Use RDoc and its conventions for API documentation. Don't put an empty line between the comment block and the def. Use empty lines to break up a long method into logical paragraphs. Keep lines fewer than 80 characters. Avoid trailing whitespace.

Naming:
Use snake_case for methods. Use CamelCase for classes and modules. (Keep acronyms like HTTP, RFC, XML uppercase.) Use SCREAMING_SNAKE_CASE for other constants. The length of an identifier determines its scope. Use one-letter variables for short block/method parameters, according to this scheme: a,b,c: any object d: directory names e: elements of an Enumerable ex: rescued exceptions f: files and file names i,j: indexes k: the key part of a hash entry m: methods o: any object r: return values of short methods s: strings v: any value v: the value part of a hash entry x,y,z: numbers And in general, the first letter of the class name if all objects are of that type. Use _ or names prefixed with _ for unused variables. When using inject with short blocks, name the arguments |a, e| (mnemonic: accumulator, element) When defining binary operators, name the argument "other".

Comments:
Comments longer than a word are capitalized and use punctuation. Use two spaces after periods. Comments start with a pound/sharp (#) character and go to EOL . Avoid superfluous comments. Two blank lines between each class and module definition, and a single blank line between each method definition.

Syntax:
Use def with parentheses when there are arguments. Never use for, unless you exactly know why. Never use then. Use when x; ... for one-line cases. Use &&/|| for boolean expressions, and/or for control flow. (Rule of thumb: If you have to use outer parentheses, you are using the wrong operators.) Avoid multi line ?:, use if Avoid long methods and long parameter lists. Prefer {...} over do...end. Multi line {...} is fine: having different statement endings (} for blocks, end for if/while/...) makes it easier to see what ends where. But use do...end for "control flow" and "method definitions" . Avoid do...end when chaining. Avoid return where not required. Avoid line continuation (\) where not required.

General:
Code in a functional way, avoid mutation when it makes sense. Keep the code simple. Don't over design. Don't under design. Avoid bugs. Be consistent Use common sense.

Variables:
$global_variable @@class_variable @instance_variable [OtherClass::]CONSTANT local_variable

Current Script Observation

1. No Script header, comments. 2. No Coding standards and indentation. 3. Uses of unnecessary scripts in Test script folder. 4. Test environment is not properly configured. 5. Reset Download timeout 6. Using of unnecessary sleep. 7. Use of Timeout till page load. 8. Assertions handling. 9. Assertions Message Description not mentioned. 10. Pop-ups handling E. g Javascript ,File upload ,File Download pop-ups are handled within scripts. 11. Sometimes Screen shot is not taken during running scripts.

Solutions
1. Standard Script Template 2. Coding standard format. 3. Test script Folder should contain required framework configuration files and Test script which are to execute. 4. Test Environment should be same as Live Environment according to Framework and Internet, Intranet applications. E . g. Folder Structure Automation Ruby_Open office_Internet Ruby_Open office_Intranet Ruby_XML_Internet Ruby_XML_Intranet Each folder contains Test scripts Framework files --- Error image files, Script logger,Script Runner,OpenOffice files. 5. Assertions assert(boolean,message=nil) assert_equal(expected, actual, message=nil) assert_match(pattern, string, message="") assert_each(assertions) array of assertion

Using this assertions with message description related to assert conditions.

6. Pop -up handling. DIV Popup Basic Authentication File Downloads File Uploads JavaScript Pop Ups Script Error Security Alerts Security Information
Pop-up handling can be done within framework by defining a method of it.

7. Framework Configuration.
Test script Folder ---- will contains only execution scripts. Framework Folder ---- will contains only framework files, which will be at test\unit folder location.

8. Screen shot
Using Image Magic and R -magic screen shot is configured with Ruby.

Implementation Phase
1. Total Scripts Non- ICICI Monitoring Scripts 357 ICICI Monitoring Scripts 346

2. Implementation according to Floor Zone wise / Domain wise.

Implementation Phase Test Environment should be changed Script to be modified according given documents.[ wait_until, pop-up handler, coding conventions] Script should be tested and design according to ORS requirement given by Client, which include Threshold violation and Throttle and XML Framework. Team has to ensure that before deploying script has to check with all conditions matching like script design format, framework configuration, screen shot and no unnecessary files should be there.

Script Template

=begin ################################################################################### * Client Name: ClientName * Script Name: Client Application Name * Author: Niraj Kumbhar * Auditor: * Approved By: * Modifier: * Script Initiate Date and Time: 23/06/2011 13:00 * Script Modified Date and Time: * Domain: Domain Name * Monitoring Timing: * Monitoring Frequency: * Site Flow path: * Prerequisite: * Change Request/Defect Description * Change Description ################################################################################### =end

Description of Script Template:

Client Name: Specify Client Name as given in ORS Script Name: Specify Script Name as given in ORS. Monitoring Timing: Specify Monitoring Timing as given in ORS. e. g 24x7, timings. Monitoring Frequency: Specify Monitoring Frequency as given in ORS. E. g 15 min,30,min E .g Axis Bank Direct , then Client Name will be Axis Bank and Script Name will be Axis Bank Direct. Approved By: Person who approved the script / change in script. Author: Its Author responsibilities to fill up all this details from ORS and maintain. Script Initiate Date and Time : Date and Time mentioned when script is finally deployed in Live Environment. Modifier and Script Modified Date and Time: If script is modified for any change the latest updated name and time of modified should be mentioned. Domain Name : Specify Domain Name according BFSI-M Domain. Prerequisite: Any prerequisite regarding script requirement such as Java updated version, Flash player, Sikuli Interface. Change Request/Defect Description: Any new change in script flow from Client req. / any defect is found a short description is to be mention. Change Description: Specify change description done in script. Auditor: He/She has to checked all details are entered properly and other related script also.

Audit Document
List of points to be check while auditing script. Script header should be in proper format as designed. Check for necessary require statements , class name , test name in proper format. Check script is properly in indentation format and with comments. Check local variables are define with prefix variable type according to coding conventions and short description of it in comments. Check the script is designed w . r . t Operational requirement sheet (ORS) document.[ Script name, Log frequency,Monitoring timings, flow of script, page names] Check Assertions are given at navigation component of page and other assertions on different components of page. Execute the script it with Threshold requirements of page, Throttle assigned by client and verify the reading are as per provided true logs. Check the Log generated and screen shot also. Check whether backup of script and site flow is taken.