• Design your test cases

• Turn the 'record' mode of the test automation tool to ON.

• Start executing the test cases manually

• The tool makes a guess about the object and the operation performed on the object (and wrong guesses always prove costly!) based on the events that have occurred on these objects. The tool then converts these to test scripts.

• These scripts can later on be played back.

There are inherent problems that are associated with this technique. To name a few:

• During the process of recording, if the tester makes a mistake and even if (s)he corrects it later, these are also recorded as a part of the script.

• Recorders can only make a guess about the events that were fired – it can never accurately determine the root cause action that triggered off this event. Consider this –
  You have a web page with a button and a textfield.
  Whenever the button is clicked, the texfield's value is changed to a specific text. Let us say that this is achieved by the code firing another 'text_changed' event whenever the button is clicked. What happens when you click on the button? The test recorder records two events – one for the original click and the second one that changes the textfield as two separate actions of the test. In reality there was only action performed – which was to click on the button!

To avoid this, experts advice to totally throw away recorders and use a pure scripted solution from the scratch. Although this is a great technique, it can become extremely tedious to do some of the preliminary tasks like mapping all the test objects. If this has to be done by the tester, then one would have to go into the source of the page (assuming AUT is a web application), identify each tag and then map them to some mnemonic name. Clearly this is a very tedious process.

The WET Script assistant utility offers an innovative solution that lies somewhere in between. We call this as the 'proxied UI' technique. Please note that this is not the same as test recorders that use a http proxy to record the http messages being sent to and from the system under test. WET is a true enduser simulation testing tool and does not use http as the testing mechanism. The script assistant UI comes with the convenience of records, while it overcomes some of their limitations. Using this technique, a draft version of the automated scripts is created by executing the manual tests on a simulated browser. The simulated browser is a UI application that is similar to a web browser in its look and feel but works differently. Using this simulated browser you can connect to an IE browser that is already running on your system and recreate the view of the IE browser. The tester can then instruct this simulated browser to perform various operations – which is converted to test scripts. For example, imagine the same web page as the one discussed previously –

• A page with a button and a textfield.

• On the browser page, you can actually 'enter text' in the textfield and 'click' the button.

• On the simulated browser page, you cannot do these operations. However for each of the elements (textfield / button), you have a context sensitive menu, which has a list of menu items corresponding to the actual operations that you can perform on the element. For example, a textfield would have 'set', 'clear' and 'append' as the options available. A button would have 'click' as its option.

• You use this context sensitive menu to perform the actual operation. For example, if you want to click the button - right click on the button object in the simulated browser view and choose 'click' from the context menu items.

• Based on this input, the simulated browser in turn performs the actual click operation on the real browser and at the same time generates the script corresponding to this operation.

Observe the fundamental difference between this technique and the record-playback mechanism. In the record-playback mechanism, the recorder, based on the events, assumes that certain operations were performed and generates scripts accordingly. In the 'proxied UI' technique, the tester explicitly instructs which operations are to be recorded. The second advantage – Using the 'proxied UI' technique, there is a 'review' stage between the 'actual operation' and the 'intended operation'. The tester does not directly perform operations on the simulated browser. Instead, the tester first does a right-click and then chooses the operation. By virtue of this, the scripts generated are far more accurate when compared to a blind record-playback technique.

All said and done, we do not want to make a claim that the scripts generated by the Wet script assistant are the final ready to use automation suite. Consider these as the skeletal drafts from which you can start building your test suite. To achieve a high degree of automation, you will have to take advantage of the advanced abilities provided by WET and powerful scripting abilities of Ruby (and thus WET). WET does not want to share the platform with those vendors who make the claim that using a script generation tool can instantly convert a novice user into a test automation engineer. We only want to try and achieve these:

• Bring down the learning curve for a manual tester who wants to make a career in software test automation

• Bring in the ability to allow a team composition with a mix of experienced automation engineers with entry level automation engineers. While the experienced engineers can concentrate on building frameworks, support libraries and mentoring the team, the others can be using the script assistant to generate the script skeletons / mapping UI objects, integrating existing test libraries, preconditions / teardowns with scripts, parameterizing tests using datatables and so on.

To summarize, WET is one of those tools which offers the convenience of recorders, without compromising on the requirements of a true test automation tool – the ability to take control of the application by using a powerful scripting / programming ability.