User:Raghublr/Sandbox

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 you to perform all the operations required for testing web applications - like automatically clicking a link, entering text in a textfield, clicking a button etc. You 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. Ruby is an object oriented programming language that started more than a decade ago in Japan (by Yukihiro Matsumoto)[3]. WET retains all the features that Watir has and adds many usability related functionality like Datatable support, Object depot (aka object repository) and inbuilt Html reporting

History[edit]

WET started off as an Extension Toolkit to Watir, a framework for Web testing. When the developers of WET first started off, they wanted to use an opensource alternative for web testing for some of their internal projects. At that time Watir seemed to be the best available choice. When they started using the Watir tool, they found that there were certain usability features that was missing in the Watir framework. So they had to create an extension toolkit to suit the needs of the application that they were testing and called it as WET (Watir Extension Toolkit). As a token of appreciation to the opensource community, the code was released out to the opensource under a BSD license. As the codebase of WET has grown multiple times, it has many features of its own and now uses Watir only as a library to drive IE. In the current context, you will therefore not find a reference to Watir Extension Toolkit in most places. It is simply called as WET - Automated Web Testing Tool

Technical details[edit]

Working Principle[edit]

A UI Test automation is Conventionally done by either using a record and play back technique or by 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 reliabilty and maintainability problem posed by these.[4].
  • 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.,[5]

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. [6]

Be it a total scripting, record and playback or the Proxied UI solution, each comes with its one benefits and liabilities[7]. 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. [8] & [9]

Features[edit]

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, you may have 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 you to identify even these kind of objects by letting you 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.

Limitations[edit]

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

References[edit]

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

See Also[edit]

External links[edit]

Retrieved from "https://en.wikipedia.org/w/index.php?title=User:Raghublr/Sandbox&oldid=451434109"