0

Automating Google Web Toolkit(GWT) applications with QTP and Selenium

Tuesday, September 22, 2009

Hello,

From past couple of days I was trying to automate Google Web Toolkit( henceforth mentioned as GWT). There are certain issues that needs to be addressed explicitly.

1. Some time objects are not recognized or object class property gets changed every time the UI gets rendered.

Solution: The element IDs in such applications can be dynamic and tend to change based on the way a screen is rendered.
It does not support XPath as such but you can use HTML DOM (in case you are working on IE only) to find the elements.

QuickTest Code
Browser("Main Dashboard").Page("Provider Search_2").WebElement("Show Advanced Options").Click

Call SendKey()

Function SendKey()
Wait(WaitTime)' May not be needed -- depends on the server
ExecuteFile "\\tsheth\Quick\FunctionLibrary\Send.vbs
Wait(WaitTime) 'May not be needed -- depends on the server
End Function


This is the VBS code:
Option Explicit
Dim ws
Set ws = CreateObject("WScript.Shell")
Ws.SendKeys "~"

HTML Code from page under test








1. It records the wrong element.

Solution:
it sometimes recording xpaths on co mputed attributes which you can't forsee with a reasonable investment of time. In this case I assign my own IDs
(DOM.setAttribute(element,"myId"))
to elements and use the respective locators (that's selenium jargon for an expression be it xpath, javascript etc which returns a DOM element). If you decide to go that way, do yourself a favor and try to design your widgets in a way that this ID assignment is done more or less automatically.
2. It doesn't record clicks on images.

Solution: You have to add a user extension to the selenium recorder - don't worry, it's javascript, it's easy and it is somewhere on their site.

3. It can't find the elements it's supposed to click on?

Solution: That's the A in Ajax - Selenium wants to click on an element as result of a click on a link or button that is not there yet. You will make good friends with waitForText or waitForElement which you will have to append manually to your scripts where you see it fit. This way you tell selenium to pause the execution until the page has changed into the state you want it to. You can set timeouts there after which you assume that your test has failed.
You will have to come to peace with the setFrame function which (It works more or less like the 'cd' command on the command prompt where you descent into child frames or navigate up to the parent frame of the current frame.

4. It doesn't do well with closed windows.

Solution: When you have a listener that closes a window, you essentially are killing the living space of Selenium. In this case move the 'close' call to a deferred command.

5. QTP with the Web Add-In does indeed work with Ext GWT.

Of course, because even the simplest of EXT widgets are complex UI controls made up of multiple generic WebElements, using Record & Playback will not get you very far in interacting with and validating these controls.We've implemented a library of functions specific to supporting ExtJS and Ext GWT controls as part of the overall generic framework we use for validating our web-based applications.


That library currently supports interaction with, and validation of Ext comboBoxes, grids, panels, windows, form edit fields, tool tips, and menus.Our biggest challenge has been updating the library functions each time a new version of the Ext GWT controls are released, as our functions make extensive use of the innerhtml and outerhtml properties of the various WebElements that comprise a single Ext widget.

I tried with the descriptive programming (QTP) on the GWT application and it worked well 75% of the time and other 25% of time it failed to recognize the objects.





"Most of us are pretty comfortable with the way we are, what we're doing and how we operate. But today the typical organization is telling the middle manager that he has to be a different kind of manager. These middle managers have been promoted throughout their careers and gotten bonuses based on their performance,
but that's now history. ..." (Carr, Hard, Trahant: "Change Process")

Good Bye!!

0

An approach to build a data driven framework

Sunday, August 16, 2009





Data driven scripts are those application-specific scripts captured or manually coded in the automation tool’s proprietary language and then modified to accommodate variable data. Variables will be used for key application input fields and program selections allowing the script to drive the application with external data supplied by the calling routine or the shell that invoked the test script.


Variable Data, Hard Coded Component Identification: These data driven scripts often still contain the hard coded and sometimes very fragile recognition strings for the window components they navigate. When this is the case, the scripts are easily broken when an application change or revision occurs. And when these scripts start breaking, we are not necessarily talking about just a few. We are sometimes talking about a great many, if not all the scripts, for the entire application.
Figure 1 is an example of activating a server-side image map link in a web application with an automation tool scripting language:

Image Click "DocumentTitle=Welcome;\;ImageIndex=1" "Coords=25,20"


This particular scenario of clicking on the image map might exist thousands of times throughout all the scripts that test this application. The preceding example identifies the image by the title given to the document and the index of the image on the page. The hard coded image identification might work successfully all the way through the production release of that version of the application. Consequently, testers responsible for the automated test scripts may gain a false sense of security and satisfaction with these results.



However, the next release cycle may find some or all of these scripts broken because either the title of the document or the index of the image has changed. Sometimes, with the right tools, this might not be too hard to fix. Sometimes, no matter what tools, it will be frustratingly difficult.
Remember, we are potentially talking about thousands of broken lines of test script code. And this is just one particular change. Where there is one, there will likely be others.
Highly Technical or Duplicate Test Designs:Another common feature of data driven scripts is that virtually all of the test design effort for the application is developed in the scripting language of the automation tool. Either that, or it is duplicated in both manual and automated script versions. This means that everyone involved with automated test development or automated test execution for the application must likely become proficient in the environment and programming language of the automation tool.


Simple Datadriven framework is as given below:



A test automation framework relying on data driven scripts is definitely the easiest and quickest to implement if you have and keep the technical staff to maintain it. But it is the hardest of the data driven approaches to maintain and perpetuate and very often leads to long-term failure.
Credits: Carl
“Here is the test to find whether your mission on earth is finished. If you're alive, it isn't.”- Richard Bach

0

Curiosity and Testing

Thursday, March 26, 2009

Hello Readers,

Curiosity and Software Testing goes hand in hand.
Making Software testing community better, efficient and stronger we all need to contribute.

Please visit Mr. Pradeep Soundararajan's blog here

"... our basic ideas about what are better or worse practices are strongly influenced by people we perceive as knowing how to make software." -James Bach

Good Bye for now, Take care.