Topic: Pls Answe this questions

An answer to this is discussed in detail in our book Automated Software Testing in Table 8.5 "Test Development Guidelines."
Here are some of the suggestions:

1.) Data - avoid hard-coding data values into scripts, rendering them not usable (for example, a script with today’s date won't necessarily run tomorrow, when the script is looking for today's date) - use variables instead.
Generally a script will test more than one data value - another reaason to use variables, for example.

2.) Data Paths - also don't hard-code data paths, for example pointing to a location of a jar file, since this path is environment dependent - in order to allow for portability make sure to use environment variables, as needed

3.) Application Navigation - make sure to apply standard navigation to allow for reusable scripts

4.) Modularity - keep your scripts modular; for example if you record the start up of your browser in numerous scripts and the url changes you would have to make the url changes in many scripts, instead, however if you keep the browser start up in one script only and call the script within the other scripts instead, only one url change will need to be made

5.) Error Handling - develop guidelines on how test procedures will handle various errors

6) Logging – have the tool generate log files whenever feasible

7) Reuse – use existing tool libraries and functions whenever feasible; also evaluate your own scripting library for scripts to reuse

8) Loose Coupling – for example, whenever feasible avoid making the outcome of one procedure dependent on the start of another

9) Wildcards – whenever applicable use wildcards, so if the name of a screen changes slightly your script won’t necessarily be affected.

In summary, general programming guidelines apply, i.e. use looping and branching constructs; naming standards; cosmetic standards; and comment the scripts well.