Load Balancing Automation Scripts Execution

Some years back I developed a tool whose primary objective was to optimally utilize the automation lab machines and to achieve faster execution cycles. This tool was developed using Visual Basic using WinSock component of the programming language. This tool automates many tasks of automation scripts execution including uninstalling existing build on all targeted machines, installing new build on all targeted machines, executing the scripts on basis of next available machine logic, provides a console to the administrator where he can view the utilization of the machine, check the status of each machine, and status of each script execution. Let us discuss each component of the tool in detail.

There are two major components of the tool, server and client. Client is a small program is installed in each client machine, which listens on a particular port for instructions from server and also sends status of client machine, script execution status to server periodically. A properties file is created on remote client which stores the configuration details of hardware, software of the client and details of server. If GUI automation tool provides script event model (tools like Silk Test provides such options), we can write custom code in events of the tool (like before script start, script execution is in progress, script execution is completed, an error occurred etc.,) to update the status to a common database table or in XML file. This approach of designing the tool is feasible only if the automation tool supports command line execution. If status is written in DB, then there will be no burden on client program of sending the script execution status to server. If status is written to a text file or XML file, then client program has to propagate the status to server for every change in event.

Server is an ASP web site which provides an option of choosing the scripts from existing inventory based on tags, priority and type associated with each script and creating a master driver with the selection. Server interface provides an option to maintain repository of client machines along with their hardware and software configurations. Once scripts are selected and master driver is created, then administrator can select the client machines based on the configuration requirement and can invoke the execution of master driver. Server provides an option to check which client machines are available and which are not available. Scripts repository maintains Average Execution Time of each script and Last Execution Time, based on this data server program provides total estimated execution time of master drive. Client program places the log files, error logs, and screen shots on a shared folder or ftp site from which administrator can access these resources from server page whenever administrator wants to debug the error in case of script failure. Server also provides various reports to get the status of overall script execution, and at the end of the master driver execution, it zips all logs, error screenshots into a file and copies the zip file to a ftp location. I have also added options like subscribing to email notifications in case of errors, completion etc.

Prerequisites for using such tools are stabilization of the automation scripts, good recovery mechanism, ease of debugging the errors, stabilized automation framework, providing required information to report bugs. These tools are very useful in Continuous Integration of the builds. We can even automate installing the new build as soon as a successful build is created on build machine and start executing the scripts. Since scripts are executed soon after build is created in nightly build machine, test execution results will be available to engineers by the time they are in office next day. This tool also saves the hardware costs by connecting all machines to a common monitor with a switch and utilizing the existing hardware optimally. Such tools also helps to run the tests frequently to uncover the bugs for any change in the system.