WET Web Tester

From Wikipedia, the free encyclopedia

WET Web Tester[1] is a web testing tool that drives an IE Browser directly and so the automated testing done is equivalent to how a user would drive the web pages. The tool allows a user to perform all the operations required for testing web applications - like automatically clicking a link, entering text in a text field, clicking a button etc. One may also perform various checks as a part of the testing process by using Checkpoints. The latest version of WET is 0.9.8.

WET sits on top of Watir[2], an automated test tool which uses the Ruby scripting language. WET retains all the features that Watir has and adds many usability related functionality like Data table support, Object depot (aka object repository) and inbuilt Html reporting

Contents

[edit] History

WET started off as an Extension Toolkit to Watir, a framework for Web testing, released as an opensource product and called it as WET (Watir Extension Toolkit).

[edit] Technical details

[edit] Working Principle

A UI Test automation is Conventionally done by either using a record and playback technique or by scripting completely.

  • In the record-playback technique, the tool automatically captures the events generated by the tester's actions and converts them to test scripts. These scripts can then be played back subsequently. While the record and playback technique allows testers to quickly create tests, experienced testers tend to detest using this approach due to the reliability and maintainability problem posed by these.[3].
  • The scripting technique relies on an experienced tester writing test scripts from the scratch. Experienced test automation engineers follow a complete software engineer process and treat the test automation effort as another development effort. While this technique offers the advantages of a well maintanable and reliable code, it suffers from certain drawbacks like requiring a greater experience pool, a larger budget, etc.,[4]

The third technique is a middle solution that offers some of the conveniences of recorders while retaining the complete scripting power. WET has adopted this technique, called as the Proxied UI technique for test automation. Using this methodology, a tester instructs an IE browser (using some sort of a wizard) to perform various steps like clicking a link, setting text in a textfield, selecting a list box, etc. The tool then converts these instructions to test scripts. Unlike the recorders, where scripts are generated by the tool automatically based on the actions that the user performed on the actual browser, in this case scripts are created only when the tester asks the tool to do so. This by itself increases the accuracy of the generated scripts. Using these scripts as the baseline, a tester can increase the test coverage by writing scripts to suit his application under test. [5]

Be it a total scripting, record and playback or the Proxied UI solution, each comes with its one benefits and liabilities[6]. One advantage of the Proxied UI technique is that it gives control to the tester to decide how much of script generation is to be used vs. how much of hand written scripts. This is a decision that needs to be taken based on the application under test and the test coverage required. In a good project, there should be a proper mix between these techniques so that the benefits of each technique can be availed. [7] & [8]

[edit] Features

The following are the important features of WET:

  • WET UI - Priliminary Script development can be done using the WET UI which is easy to use. Using the WET UI, a tester can create Test Definitions, Object Repositories and the first draft of the test scripts.
  • Scripting using Ruby - WET uses Ruby, an object oriented scripting language, which in turns gives WET a powerful scripting ability
  • Object depot - The Object depot (aka Object Repository) allows a tester to map all the application's objects into centralized repositories. This helps in a higher maintanibility of scripts.
  • Object identification using multiple parameters - Many web pages are designed in such a way that the same page has elements with similar attribtues - For example, there may be textfields with the label 'name' - one may be for the User's name while the other may be for the Developer's name. WET allows a tester to identify even these kind of objects by letting to search for objects using multiple parameters.
  • 'Test definitions' to define tests - The structure and flow of a WET test is controlled by a test definitions file. This flow closely mimics the regular manual testing process.
  • Slick HTML results - After the tests are completed, the results are printed out in neat HTML Format
  • Integrated Datatable support - Testers can write datadriven tests by using the Integrated datatable support. Datatables can either be as Excel files or an Xml format.
  • Popup handling - WET handles Win32 popups quite reliably.

[edit] Limitations

The following are some shortcomings in WET:

  • Supports only the IE browser. Cannot be used for compatibility testing.
  • The Simulated browser view of WET doesn't work accurately for a complex pages. For these sort of pages, one has to view objects in a treeview only.
  • No integration with SCM / bug tracking tools
  • Does not have support for keyword driven tests

[edit] References

  1. ^ http://wet.qantom.org
  2. ^ http://wtr.rubyforge.org
  3. ^ http://www.io.com/~wazmo/blog/archives/2005_08.html
  4. ^ http://www.psqtconference.com/2004east/tracks/Tuesday/GuidelinesforScriptingLanguagesPaper.pdf
  5. ^ http://wet.qantom.org/uiproxy_philosophy.html
  6. ^ http://www.satisfice.com/articles/test_automation_snake_oil.pdf
  7. ^ http://www.benchmarkqa.com/PDFs/automation_myths.pdf
  8. ^ http://www.satisfice.com/articles/test_automation_snake_oil.pdf

[edit] See Also

[edit] External links

Retrieved from "http://en.wikipedia.org../../../w/e/t/WET_Web_Tester_d8e5.html"