Where you find that you can't use WinRunner for automation?

Winrunner through the time and tide has proved to be quite a useful functional testing tool. This tool developed by HP has proved to be outstanding when it comes to testing of the automated functional graphical user interfaces. 

With the aid of this wonderful testing tool the user interactions that took place on the graphical user interfaces of the software systems or applications can be successfully recorded and playedback. 

Winrunner is a complete functional test suite and can even be extended to work with the QTP (quick test pro). Through the years this functional test suite has been continuously providing its support to the enterprises for quality assurance. 

Out of all its functions three are considered to be the most important ones and have been mentioned below:

1. Captures the user interactions taking place on the GUI of the application software.

2.  Verifies the captured user interactions.

3.  Automatically replays all the recorded user interactions.

   All the above three functions ensure that the defects are identified and it is ensured that all the business processes are being carried out well. The Winrunner introduced the use of TSL in parameterization and customization of the input supplied by the user. 

    

    Even though there are many benefits of the winrunner, it does suffer from some limitations. One of those limitations is that the winrunner cannot be used everywhere for automation. This is the topic of discussion of this article that where and all the winrunner can’t be used for automation. 

   1.Testers have figured out a number of uses for the winrunner, however, its primary role will always be to act as a testing tool for functional testing of the software systems and applications.

    2. In many conditions the winrunner is often used for load testing by some of the developers. 

   3. What makes the winrunner so powerful is its realization of the real world user. 

   4. Using winrunner in cooperation with the loadrunner achieves even better result. All these reasons have made the winrunner quite important software in the market.

  Winrunner can’t be used for automation in three situations as mentioned below:

     1.The size of the project is quite small i.e., it is a small scale project.

    2.The project calls for the need of manual intervention and cannot do without  it.

     3.The project is quite complex and exhibits a different behavior every time.

    There are certain instances when it has been observed that the winrunner does not even take the protocol layer in to consideration.

    But however, in such instances it has recorded the user interactions and played them. The winrunner program has been coded in such a way that it appears as if the various commands are being carried out by a real human user. 

   

   For the winrunner to function properly, it is needed that it gains full control over the computer system. Once it gains control over the system, it is ready to record and play back the user events. This is the reason why a load test cannot be initiated whenever the generation of load is required. 

  

    For the winrunner to simulate n number of users you need to have n number of computers and install winrunner software on all of them. 

   For the winrunner to record the response time of the user it is necessary that it is implemented within a load test since it has to deal with the processing that will take place in the hardware components of the computer system.