Friday, April 25, 2008

WATIR Fall

“Open-source tools will not apply to our traditional water fall approach to software development”

The most alarming aspect of this statement was that it was made as we were politely debating the use of QTP versus open-source testing tools. My first thought was, what does an old traditional development process have to do with tool selection?

It has been awhile since a single statement resonated with me over night.

In my view this statement implies that testing must wait until development is complete.

Approach to using QTP is record some GUI interactions and play them back. Next step might be to change values for some of the variables and repeat the test. Ideally the variables are pushed into a data table where the values can be read and a single test executed multiple times. If a tester or scripter is really curious they will look under the hood and find ways to improve the code generated by the record playback

In today’s world we are constantly hearing from management the key to success is time to market. I have seen numerous power points where these words appear. If testing waits until development is complete, then are we doing everything we can to get our products faster to the market?

Test automation should be considered throughout the process. The role of testing teams is to encourage testing from start to finish. Ideally test automation is being implemented in parallel to the development. Quality teams should be encouraging test driven development. As unit tests are being created, WATIR tests can be developed in advance of ever seeing the final code. Conversations take place with the developers and you can determine what an object on the UI is going to look like. Is it a radio button? If so ask the developer what tag name that radio button will have. Go write a test case in Ruby to test that radio button.

Really all you need to know that a requirement is going to be met on page X by implementing a radio button and you write:

assert(@ie.radio(:id, "requirement1").exists?)

@ie.radio(:id, "requirement1").set

Or

@ie.radio(:id, "requirement1").isSet


What else is on that page? There is a link. Is the link an image or something else? What is the name of the link? Where should the link take me? This can clearly be done in parallel with development.

@ie.link(:id, "loginButton").click

Client has a requirement that on this page there should be a certain warning message, so you write:

assert(@ie.contains_text('Danger Danger Will Robinson'))

These test cases took just a few seconds to write. Eventually these tests will need to be placed into a flow and executed, but the foundations can quickly be made from the requirements. Will this help get the software faster to the market? I certainly think so!

Large corporations need to shift the paradigm of long process water fall mentality to Smarter Faster Cheaper, Agile. Companies need to make their processed more agile and meet the demands of their clients by delivery better software fast.

Are there more complex tests than the few illustrated above? Absolutely!

This is where a team of testers collaborating can write extremely robust multi-purpose sets in Ruby. A quick example would be team A already has written some code to validate the content of an XML response. Team B needs to do the same thing, but for a different application. So the next step is to borrow the code and implement.

To be continued…