Continue # Infosys Whitepaper 
 If there is a testcase for  uploading of a file, then it should explicitly tell which file to upload. If there is a testcase  for creating a folder with invalid characters, then it should state which characters to use  for creating the folder.  Such fine-tuning of the testcases before starting automation ensures reduction in the actual time  for developing the tool. It also guarantees that the tool actually executes the testcases in a way  that checks the desired functionality.  The right tool has to be decided: There are hundreds of automation tools available in the  market. A careful effort has to go into deciding which tool would be most suitable for automating  the testing of your product/application. Following criteria would be useful in making the decision:  � Is the automation suite required to work on different platforms? If platform-  independence is required, the demands on the automation suite will be very high. E.g. – If  the suite has to support different flavors of Unix, it might be suitable to go for platform- independent things like perl, etc.  � If the testing to be automated is GUI-based, it might be preferable to use a tool like  SilkTest, WinRunner, Rational Robot, etc. But every tool will have its own technical  limitations that prevent efficient automation. So, it is necessary to evaluate testing tools  for critical interfaces of the application that need to be automated.  � Sometimes, it might be best to develop a scripting tool using a suitable scripting language  instead of going for the ready-made tools available in the market. This is especially  preferable when the testing is on the server side.    The right mode (script recording/script development) has been decided: Most of the GUI  automation tools have a feature called ‘record and playback’ or, ‘capture replay’. Using this  feature, you execute the test manually while the test tool sits in the background and remembers  what you do. It then generates a script that you can run to re-execute the test. Script development,  on the other hand, implies writing the scripts for running the testcases in the language used by the  tool. Script development is akin to programming in a language like C or C++, but the purpose is  to execute the testcases in an automated style.   © QAI India Ltd, 3rd Annual International Software Testing Conference, 2001. No use for profit permitted.  

---

  Page: 6 / 12  

---

   Presented at the 3rd International Software Testing Conference, India  If you are going for GUI test automation, then points worth-considering while making a sane  decision are:  � Record and Playback approach to creation of test scripts and test suites is easy to develop  but difficult to maintain.  � Error recovery cannot be incorporated by just recording a test script.  � In data driven tests, achieving reusability of test scripts will be very limited. Creation of  test data and integration of the same with test scripts is the time consuming part. When a  function is coded for the same purpose with data input file, maximum re-usability and  ease is ensured.  More often than not, it will be required to strike a careful balance between the two modes, instead  of using one of the two modes. Using the recording mode alone will render the automation suite  non-reusable and using the scripting mode alone will require more investment of effort and time.  Though a middle path will be suggested generally, it might be worthwhile spending some time to  decide the right mode or right mix of modes as per the application/product under consideration.  Most of the further discussion will be useful only when the right mix is adopted or scripting is  followed altogether.  All in all, the suggested steps to be followed before starting with automation can be depicted in  the figure below: -  \            Fig.1: The pre-automation stage cycle      Check the stability  of the product /  application Decide the  interface to be  tested Define the scope  of automation  Identify  individual  testcases Fine-tune the test  case documents  Decide the right  tool  Decide the right mode/ right mix  of modes © QAI India Ltd, 3rd Annual International Software Testing Conference, 2001. No use for profit permitted.  

---

  Page: 7 / 12  

---

   Presented at the 3rd International Software Testing Conference, India  Automation how?  (The Regimen)  After taking care of the above stipulations, the right direction has been identified and now the  stage is all set to go for automation full-fledged. But in order to reach the destination, lots more  needs to be paid attention to. So, here we go: -  Following proper test scripting standards: Automated testing involves a mini-development  cycle. So, proper coding standards for test scripts should be prepared. Checklists should be  developed for review of test scripts. On the whole, all the software practices followed in the  development of an application or a product, which are applicable to the development of the  automation suite, should be put in place. Whatever tool is chosen, ultimately, a tool will be only  as good as the process being used to implement the tool.  Identifying common steps and converting them into functions: At the outset, the steps  common amongst different testcases should be identified and converted in the form of functions.  Such functions can be placed in a common file, from where they can be called by different  testcases by passing suitable parameters as per the need. This will encourages re-usability of code  and save effort and time. Besides, these functions can be used again when newer testcases are  added to the automation suite at a later stage.  Identifying other peripheral functions: After the functions as stated above have been identified,  it is advisable to identify the peripheral functions that will be required by all the testcases in  general. E.g. – A separate function for writing into log files can be written. This function can take  the error message, severity level of the error message and the path and name of the log file as the  input parameters. Depending on the requirements, more of such reusable functions can be  identified. Such functions will simplify and streamline the process of test script development in  the long run.  Providing room for extensibility: The automation suite should be written in a manner such that  additional testcases can be added to it. The additional testcases may cater to testing enhanced  © QAI India Ltd, 3rd Annual International Software Testing Conference, 2001. No use for profit permitted.  

---

  Page: 8 / 12  

---

   Presented at the 3rd International Software Testing Conference, India  functionality of an existing feature as well as testing new features incorporated in the  application/product. The suite should have such an architecture that it is extensible both in terms  of being able to add more functions and also in terms of being able to add more testcases by  calling the existing/new functions.  Generating proper logs: A common problem is what to do when automated tests fail. Failure  analysis is often difficult. Was this a false alarm or not? Did the test fail because of a flaw in the  test suite, a mistake in setting up for the tests, or an actual defect in the product? Hence, it is  required that the suite should generates logs of its own. But a good automation suite with  ambiguous logging messages is worse than manual testing. Few points that need to be taken care  of from logging point-of-view are: -  � An ideal automation suite should explicitly check for common setup mistakes before  running tests and generating detailed logs of its own. And logging needs to be as user- friendly as possible.  �  The logging should be done in a manner that facilitates statistical analysis of the results.  This implies that the log file should have the results in such a format such that can be  processed by parsing, and useful statistics can be generated.  Independence of selective execution: The scripts should be written/arranged in such a manner  that they provide the independence of executing individual testcases or at least testcases  belonging to the same module. This is important when the need is not to execute the entire suite,  but to verify particular bugs.  Signal-handling and clean exit on abrupt termination: It needs to be ensured that the suite  does all the clean up when terminated abruptly, consciously or unconsciously, by the user. It may  be required by the script to handle the termination/kill signal for a while so as to get the time for  clean up (and may be, complete the currently executing testcase, if the suite desires). Such signal  handling is extremely important in some particular cases. E.g. - When an automation suite is run  © QAI India Ltd, 3rd Annual International Software Testing Conference, 2001. No use for profit permitted.  

---

  Page: 9 / 12  

---

   Presented at the 3rd International Software Testing Conference, India  through command line on a Unix terminal as a foreground process and the user does a Ctrl-D in  order to stop the suite for whatever reasons. The