TestingGeek

Structure Of Script

A script in general should have following structure

• Header
• Include Section - All include files are mentioned here.
• Declaration Section - Declare all the variables and functions here.
• Main Section - Section containing starting point for this script
• Supplementary functions - All the declared functions are implemented here.

Header Structure

Any script that you create for automation, should have header section in it. This section will have general information about the script, it's usage, author, revision history etc. You can follow template similar to this for header section -

'===================================================

'File Name          :  Test_Case_001

'Date                   :  02 Jul 2007

'Author               :  xyz

'Description       :  Brief description of the test script

'Special Note      :  if any

'Revision History   :

'===================================================

Any major changes in the script should be captured in the revision history.

Avoid Co-ordinate based recording

The use of co-ordinate based recording and playback should be avoided as much as possible. Scripts created using this method are very difficult to maintain. Avoiding co-ordinates in the scripts also helps in making sure that scripts will run on different platforms and screen resolutions. There might be cases where co-ordinates are essential and there is no way to proceed without using co-ordinates. In cases like this, abstract the co-ordinates and use some variable in the scripts. This will help if those co-ordinates are changed in future or if co-ordinates are different in different screen resolutions.

Avoid platform specific classes

If your automation is supported on more than one platform, make sure that you do not use platform specific classes. There could be subtle differences in the class names of Windows 2000 and Windows XP system.

Freeing Resources

Resources being used by the scripts should be freed after the script execution. You should pay special attention to resources like file handles, database connections and free them as soon as you are done with their usage.

Debug Information

Every script should have some mechanism to log the execution and store results apart from the mechanism provided in the tool itself. These messages can help in maintaining the scripts and also gives subtle information if scripts do not work as expected.

Use of Accelerator Keys

When object under test is not recognized easily, you should try to use accelerator keys or tabbed or arrow navigation to access the object. Also, if you use tabs and arrow's to get the object focus, do not use them directly in the script. Similar to co-ordinates create a variable instead.

Usage of verification points

You should try to use verification points as little as possible.  Do not use verification points until unless it is absolutely necessary. Excessive usage of verification point makes it very difficult to maintain scripts if you have to think of internationalization for your scripts. Verification points might not work even if you change screen resolution. Because of these reasons, use verification points only when it is necessary.

Hard code path for drives

Any hard coded path referencing to files in your system or somewhere in network should not be used. If it is used, it should be documented clearly. Any hard coded path or usage of a mapped network drive creates a dependency. You should try to use relative paths instead of absolute path.

Documenting Functions

Every function or method you use in your script, should be documented properly. It should have information on the usage of function, information about the author and appropriate revision history.

Library reusability

Any time you create a new function, you should think can it be reused? Can you make it a bit more generic so that it can be used by other modules as well? Or is there any function in the library which can be used for the purpose. Try to code as little as possible by reusing existing functions if they are available. If you have to write, think how you can make them reusable and generic.

Hope with the help of these guidelines you will be able to work on your automation project in a better way. If you follow some guidelines and would like to share with us. Do That.