June 22, 2008

WatirCraft is Betting on Test Automation

Pete Dignan and I are founding a company called WatirCraft. WatirCraft is a for-profit company that is supporting and maintaining Watir and providing additional products and services based on Watir. We are betting that we can build a business around making testers successful with automated testing.

Our top priorities right now are providing ongoing support for Watir as well as improving Watir’s ability to operate with more browsers and platforms. We recently released an updated version of Watir that included a number of patches contributed by the community, as well as a performance improvement.

Watir’s number one weakness today is its focus on Windows and IE. We are working closely with Angrez Singh and the FireWatir team to bring our code bases together, rejoin the projects and improve the compatability between our implentations. Testers have every right to expect tests they write for one browser to able to be executed with another— without the use of browser-specific logic.

FireWatir supports Firefox on Windows, Linux and Mac. We are also looking further. We have recently had serious inquiries from test architects working on the development teams of two other important browsers, seeking advice on how to make Watir work with their browsers. And we also have plans to integrate Watir with Selenium-RC.

Many people today think of Watir as something that works with Windows and Internet Explorer. We seek to change that. We think Watir’s defining characteristic is its intuitive API for operating a browser. This API is sufficiently appealing that it has been translated to C# (Watin) and Java (Watij). And of course there are a couple of implementations of this API in Ruby (Watir, FireWatir, SafariWatir, Celerity). But we need to keep these Ruby implementations in sync, which is why we are developing a browser-independent test suite to validate Watir compatability between these code bases.

Making Watir more portable and more supportable will mean changes, some of which will be disruptive. We will be making some features more robust, and deprecating others. We plan to continue to support Watir as a community project. In fact, the Watir community is the key asset that we are building our business on. Every day, Watir users are helping each other, sharing their work and their visions, and making it easier for the next person who comes along. Pete, new to the Watir community, is amazed at the patience, good faith and dedication he has seen.

By founding this business, Pete and I are making a bet on Watir— not just the tool as it is today, but also the vision that inspires it. It is a vision that realizes that automation is about code and success requires understanding code, and making code understandable.

We are also betting that people want and will be willing to pay for a framework that is easier to use.

It has been great to learn about all the frameworks that have been built for Watir. Watir itself was always conceived as a library that could be used with any framework. Originally we mostly used Test::Unit, which was convenient and well-supported. But with time, other unit testing frameworks (such as Rspec and Shoulda) have arisen and it is just as easy to use Watir with them. It has been great to learn from all the frameworks that Watir users have created and shared.

Watir was concieved as much as an embodied critique of the then-prevailing testing tools as it was as a foundation for successful automation. It was thus designed around a standard scripting language, not a vendorscript. It was designed to be easy to write, rather than easy to record. And it was designed to be a library and not a framework. Many of the commercial tools have been burdened by tight bindings to leaden frameworks.

WatirCraft is developing a framework that will allow testers who aren’t wizards (and who don’t have wizards around to help) to nonetheless hit the ground running with Watir. Our framework won’t be for everybody and we will continue to encourage Watir’s many users to use whatever framework they wish, whether it be open-source, home-brewed or ours. Our goal, really, is to make Watir-based testing accessible to more people.

We are also betting on Ruby. We still sometimes hear regrets from testers that Watir isn’t written in Python. I don’t regret it one bit. I am thankful that Brian Marick pulled me on to the Ruby train with him years ago. I believe that we can build a better framework with less effort in Ruby than in Python. This is because Ruby has a set of features called meta-programming.

The advantages of meta-programming have been hard to explain to testers. “Meta-programming” is actually a new label for a set of advanced language features that Ruby has had for a long time. But these features are hard to explain and understand and most testers won’t be using them. Nonetheless, Ruby’s meta-programming features make it easier to build consise, intuitive frameworks. Indeed, this is a big reason behind the success of Rails.

We are also betting that the growing use of Agile Development practices will continue. Testers on agile teams are being hammered by shorter iterations. Regression testing is more and more necessary and yet there is less and less time to do it. At the same time, Agile Development is getting testers and developers to work together more closely—exactly what needs to happen if successful test automation is going to happen. We will continue to support automated testing that works not just for testers but for the whole team, and that integrates with agile practices such as developer testing, continuous integration and frequent commits. Personally, I’ve been working exclusively with Agile teams over the past four years. Only when you run tests daily (or more frequently) will you really do what is necessary to make automated testing work.

Today, most of the innovation in automated testing today is coming from agile developers. I find it quite exciting and hard to keep up with, there is so much of it. Yet many of these tools are written for developers, and testers have trouble using them. Indeed developers in some companies are already taking over responsibility for automating testing. Will this be the trend? Will there be a role for testers in the future of automated testing? Will this role be defined by developers?

We think testers do have a significant role in the future of automated testing. By working closely with both testers and developers we can make Watir an even better tool and sell additional tools and support that will make testers successful in an increasingly Agile world. We’re betting on it.

Posted by bret at 11:12 AM | Comments (3)

June 16, 2008

Watir 1.5.6 released with "Zippy" speed

Last week we released a new version of Watir. We've mostly been accumulating bug fixes and minor enhancements. However there is one new feature that may be worth the upgrade. We've added a speed improvement to Watir, which we call "Zippy" speed.


Watir now has a two-step install process (assuming you've already installed Ruby). Type this at the command prompt:
gem update --system
gem install watir
This will update your version of the Rubygems installer and then install the latest version of Watir. Some people have had install problems with 1.5.4 and 1.5.5. Those problems are now fixed.

We are also now recommending that people use Ruby 1.8.6-26 final with Watir. A Ruby bug affecting many Watir users in earlier versions of 1.8.6 is now fixed. If you are upgrading your version of Ruby, you basically have to do a fresh install. There is no upgrade option. Sorry.

Zippy Speed

When you first use Watir, it is rather slow. This is intentional. We made Watir run slow at first because we found that new users wanted to be able to watch their scripts and make sure they were working correctly. So we added some delays to slow Watir down to an auditable speed.

However, once you have confidence in your tests, you probably want to run them faster. This is just one command.

ie = Watir::IE.new
ie.speed = :fast
I know this is a surprise to some Watir users: we haven't done a great job of letting this trick be known. This feature has been in Watir for a long time, certainly as far back as Watir 1.4.

What is new is that we now have an even faster way to run Watir. We call this "zippy" and it works the same way.

ie = Watir::IE.new
ie.speed = :zippy
Normally, when Watir enters text into a text field, it does so letter by letter. Two reasons. One, it looks cooler. Two, there are rare cases where you have to do this to realistically engage Javascript attached to the text field that, say, limits the characters that can be entered. But with tests that had lots of data entry, this could really slow things down.

The new :zippy speed speeds up tests by enter text fields all at once. If you have tests that require character-by-character text entry, you'll need to continue to use :fast.

In the past, many Watir users realized that they could speed up their tests by using value instead of set. Thus, instead of

ie.text_field(:id, 'payment').set '25'
They would use
ie.text_field(:id, 'payment').value = '25'
The new :zippy speed does exactly the same thing, only behind the scenes so you don't have to modify your individual scripts.

Zippy speed was originally included in Watir 1.5.4, but I've been reluctant to brag about it until we got our install problems fixed. It is based on a proof of concept by Jonathan Kohl.

Should You Upgrade?

Other features new since 1.5.3 (released last fall) include support for Chinese character input and the ability to locate more elements using multiple attributes. However, multiple attribute support for text fields, buttons and other input elements has yet to be implemented. We know you are waiting for it.

You can now call the row method from within a table, also frequently requested. There are a number of other fixes. (See the Release Notes for details.)

I know many of you are still using Watir 1.4.1. There is only one reason I know of why you should not upgrade. We have had several reports that Watir 1.5.3 and later is slower with some complex pages. We recently got a reproducible case of this problem and will be looking at fixing it in 1.5.7.

Posted by bret at 05:04 PM | Comments (0)

June 09, 2008

The Next Advance in Testing

Ward Cunningham says:

I suspect there will be a tool at the center of the next advance in testing. The tool will enable the advance, but it won't be the advance. Like with jUnit, the tool will be useful before the advance has happened, but, when the books are written, they will devote far more attention to the practices surrounding the tool than the tool itself.

Posted by bret at 04:29 PM | Comments (2)