Wednesday, November 30, 2005

“Let the River Run through It”

The first concern we encountered using WATIR was handling modals and pop-ups. I personally spent at least a week trying to figure this issue out. I posted to the users group and read every archived enter on the subject. Nothing seemed to click for my two brain cells.

I tossed the baton over to our crackerjack developers. In a very short period of time we had the modal concern fixed using Winclicker. I had tried this approach, but apparently I was not setting up the Winclicker method in the correct scope.

Here is the syntax we now use to handle modals.

This is a typical modal for our application:









Here is the Winclicker set up method:

def startClicker( button , waitTime = 3)
w = WinClicker.new
longName = @ie.dir.gsub("/" , "\\" )
shortName = w.getShortFileName(longName)
c = "start rubyw #{shortName }\\watir\\clickJSDialog.rb #{button } #{ waitTime} "
puts "Starting #{c}"
w.winsystem(c)
w=nil
#assert_same(expected, actual, [message] ) #Expects expected.equal?(actual)
end

The real key to making this successful is the Winclicker call needs to be made prior to activating the link that leads to the modal.

Like this:

startClicker("OK" , 3)

@ie.link(:text, "Logout").click

Another important note is the value about, which indicates the amount of wait time. The wait time can be very important if there are several modals in a series of events. Timing is everything and you have to work to get WATIR to flow through the modals.

The second hurdle was pop-up utilities. Again the development team lent there expertise and we are able to get the attach method functional. The attach method using a second thread to control the pop-up.

One important thing to note is that when working over a VPN connection the attach method does not seem to work. This is the case for our VPN connection. The script will stop on any attach method over VPN, but runs fine when executed from the office. I have no clue as to why this is the case, but I find it frustrating.

After clicking on the link that exposes a pop-up utility, using the attach method you can then manipulate the data on the pop-up utility.

Example syntax:

@ie.link(:text, "ADD NEW...").click

@ie.link(:text, "CONNECTION").click

ie2 = IE.attach(:title, "Connection")

ie2.selectBox( :name , "connPort1").select("port 1")

ie2.image(:src , /ps_transferto_button/).click

ie2.selectBox( :name , "connPort2").select("port 0")

ie2.selectBox( :name , "connSitesAvailable2").select("002-TX-DAL")

ie2.link(:url, /connSitesAvailable2/).click

All of the input I received from the WATIR community is that there is room for improvement in the mechanisms for handling modals and pop-ups using WATIR, but for now I am running through the application.

One other side note is that supposedly an add-on to WATIR called WET does a better job handling modals and pop-ups. We were not able to get WET to work, but I am sure with more effort this would be an alternative solution.

After overcoming these challenges we have been able to successfully write approximately 80 test scripts, providing 23% automation of our current test cases.

Wednesday, November 09, 2005

I am formally an Environmental Chemist, who in 1999 joined the ranks of Software Quality Assurance, which would be QA and not Q&A (pet peeve of one of my early mentors). I had very little programming experience other than some classes taken at Austin Community College and dabbling with HTML. My first exposure to a scripting language was the 4-Test Language used by Silk Performer and Silk Test. In a reasonable amount of time and some outstanding mentoring I picked the language up quickly. We were able to write some rather robust performance tests for the various applications we were responsible for. I recall the language was very strict and sometimes difficult to troubleshoot. I then attended the Silk Test certification courses. At the time I liked the power that Silk Test provided for functional testing. I was anxious to use Silk Test to help test our internationalized products by using a series of if statements and localized string content. No sooner than I got started on this project I was part of a “reduction in force”. The one thing I definitely remember is that the Segue suite of tools came with a healthy price tag.

Fortunately I landed a position with a start up company, who was test-driven and Agile. Here is where we implemented some extremely powerful methods using Webload. Webload was a terrific tool in that we could leverage performance tests as functional tests. We developed the testing methods almost as fast as the application was built. Sometime in 2002 Webload changed their application to be more GUI focused. The end result was this rendered many of our previously developed scripts almost useless. There were certain things we struggled with using 5.2 and these things were addressed in 6.0, but the trade off of redeveloping all of our scripts was huge. The bottom line was we never got back to the level of scripts we needed to be efficient at testing our product line application. In September of 2004, I decided to abandon Webload and continue our search for the Holy Grail of testing tools. I played with Open STA, Load Runner, and some emerging technology called WATIR, Web Application Testing in Ruby. Open STA was difficult to get off the ground. I do not recall the specifics, but it was quickly abandoned. I got a temporary license for using Load Runner. This was an awesome tool, but like other great tools came with a significant price tag. Well no sooner than I got my first WATIR script written I was again victim to a “reduction in force”.

I was fortunate and landed my current Gig. There was not much time early on for me to dive into test automation. I had to put my head to the grind stone and learn the testing environments and a robust application. My new mentor threw me to the wolves. The QA team was responsible for maintaining and configuring their test environment. My first challenge was to install AIX and get our application up and running. Definitely I felt like ex-prize fighter, Terry, the main character of “On the Water Front”. I took some serious blows, but after some hand holding I got it done. Now I just pray that the AIX machine does not crash! Once my domain knowledge was up to par, there was time for some automated test development. We were told to use an internal tool, Easy Test. This testing tool is content–driven using a table structure. It is really a powerful testing tool for both web and enterprise based applications. My two brain cells for the longest time just did not get it. I think the main reason was that I did not have the time to fully dive in and learn the tool. We were releasing a new product every 3-4 weeks, which left very little time for test automation. Once again there was a changing of the guard, but this time I was extremely fortunate to remain a member of a great Professional Services team. We developed a new application and right from the start we wanted to have test-driven development. WATIR was a logical choice.

The development team was excited about the potential of WATIR. We immediately hit a snag with WATIR’s ability to handle modals and pop ups. I struggled for a couple of weeks to no avail. I quickly abandoned WATIR and dove into Easy Test. Easy Test handled modals, pop ups, and even desktop file exchanges like a champion. I do not intend to do a line by line comparison of these two tools here, but I can summarize by saying I now have two very good weapons in my bag of tricks. My brain kept leading me back to WATIR. WATIR seemed to come more naturally to me. I still had not conquered the modal issue, so I asked a seasoned developer to take a look at it. In a couple of days she pointed out the flaws in my approach and I was back to using WATIR. Today we are using WATIR. As time permits I will share some additional challenges and thoughts on using WATIR as our main tool for functional testing. Most likely I will find time about once a week to post a thought or two on the trials and tribulations of WATIR.