June 18, 2009
After WatirCraftAs I've announced elsewhere earlier this month, Pete Dignan and I are shutting down WatirCraft LLC. We've each decided to go our separate ways. For several months now Pete has been focussing his attentions on his other business, ProtoTest. Next month, I will begin a full-time position at Convio as a QA engineer.
Both of us will probably continue to be involved with the Watir. Prototest has projects that are using Watir and the WatirCraft framework, and Convio has recently standardized on using Watir internally.
WatirCraft funded my work with Watir last year. There is certainly more work that needs to be done, but it will happen, as it had before, as a result of volunteer labor. I'm not sure how much time I will have for this going forward, but we have a lot of contributors and volunteers, so I have confidence that Watir will continue as an active project regardless of my own involvement.
The watircraft framework is a bit more up in the air. The original idea was to build a pretty good framework as open-source and then offer additional products and services that built on that. A lot of people like what we've developed so far, but it clearly could use more work. I'm not sure what is actually going to happen. I think its a good start and would certainly use it as a basis for any Watir test suites that I develop personally (e.g. at Convio). Convio also has been mostly using the Rasta framework, so I am looking at integrating that with the watircraft framework. Needless to say, the watircraft framework is open-source and hosted on github, so anyone is free to fork it and add features.
We set up Watirbuild.com to host continuous integration of the Watir project. This was originally set up by WatirCraft, but i'm now paying for the hosting of this site personally, as part of my personal commitment to the Watir project.
WatirCraft also developed Watir-based training. Over the past couple of months, I've taught this a couple of times, and have had good feedback from it. Both Pete and I have retained the rights to deliver training based on these materials, but I don't have any immediate plans, nor as far as I'm aware does Pete.
I'm trying to take a break from Watir right now -- from development of the driver and frameworks, from training and consulting. This is hard because there is so much momentum, and it pains me to risk losing that. We're ready to make a new release of Watir shortly. I have a roadmap for the watircraft framework based on all the feedback we've gotten. And I have leads for consulting. But I can only do so much, and I fear that too much of what I have been doing has been done out of inertia or a sense of obligation.
What I really want to do right now is write about Watir: why it has been important to me, the vision I've had for it, and the challenges that lie ahead. Stay tuned.
June 15, 2009
Books for StartupsOver the past year, I've been working on a startup software business. We're in the process of shutting it down now, actually, but that's a different story. During the past year, I've learned a lot about startups and business models. Two books have been particularly helpful to me in understanding the challenge of a startup and helping me focus on what's important.
Art of the Start, by Guy Kawasaki. The first few chapters are available for free download, and may be all that you need. This is a great book to help you with your business plan -- or better yet -- with your pitch. I went back to this book several times.
Founders at Work, by Jessica Livingston. Fascinating stories of the early days of technology startups. Based on interviews, there are stories both new companies and old. In several accounts, inside information is revealed about startups you've already read about. Learn about how Jobs ripped off Wozniak in Apple's early days, and how Wozniak feels about it now.
I strongly recommend these books for any one involved in a software startup.
April 24, 2009
Three Key Tools for Automated Testing: Language, Driver, HarnessWhen I started working on Watir, I was pushing a vision for automated testing. This vision still motivates my work with Watir. A couple of years ago, Brian Marick told me open-source developers should share their vision and let the community know why they built the tool. Here's the vision.
There are three essential elements of an automated testing system: language, driver and harness. Your tests need to be written in a language and you need a language to extend your testing system. I've long believed in scripting languages, such as Perl, Python and Ruby. I find that testers are more productive with them and find them easier to understand and use. I have reasons why I prefer Ruby, but there are other good automated testing systems written using other scripting languages. In fact over the years, I have built testing frameworks in Perl, Python and VB, usually building on languages that were already in use at the client. My emphasis on full-featured programming languages was a contrast to the proprietary languages that had been commonly used in commercial testing tool suites. I had no patience for them.
There are lots of languages to choose from. Finding a suitable driver, however, was often more difficult. A driver is what you need to drive your application. Watir is an example of a browser driver, suitable for web applications. Often the driver determines the language you use. Years ago, I used Expect as a driver for a command line application. Expect used TCL as its language, so the suite was written in TCL. I developed Watir because I wanted a browser driver in Ruby. Watir was our solution for Web Application Testing in Ruby.
The third thing you needed for a testing system was a harness. When we started, we all used Test::Unit, a Ruby test harness designed for unit testing. We found that it could be adapted for functional testing. More recently, Watir users have been using Rspec or Cucumber as their test harness. A test harness is responsible for executing tests and collecting and reporting results. Some people like to build their own test harnesses instead of using one of these.
I developed this vision while working with commercial testing tool suites like SilkTest and WinRunner. These packages are often referred to as tools, but I found that they actually comprised a collection of integrated tools. They had predefined usage expectations that often didn't match actual tester needs. Data-driven testing, for example, required us to break down the suite and then reassemble it in a more suitable configuration. I wanted testers to be able to identify the individual tools that made up a testing system.
Many new Watir users have trouble identifying where Watir (the driver) ends and Ruby (the language) begins. But learning this is key to becoming a proficient user. I'm told that some Java teachers don't like their students to use an IDE (such as Eclipse or Netbeans). Instead they want their students to learn to use the required tools separately -- the editor, the compiler. This way they learn the function of each tool. In the same way, I've also wanted testers to understand the functions of the different tools and components used in a testing system.
We often get questions from new Watir users whose answers are obvious once you understand this. Can Watir read CSV files? Can it do date math? Can it read from a database? The answer to all of these questions is that Watir can't do it, but Ruby can. No browser driver could do these things (it would be like asking whether your compiler supports search and replace), but any full-featured programming language can. It's just a matter of finding the library to do it. These questions are raised in the first place because testers are used to using commercial tool suites that were closed systems. So you only got the ability to do these kinds of things if the vendor added it to the package. Watir is part of an open system, so all the libraries are there already and more are being written all the time, often by people who are not part of the Watir community, per se, but rather part of the larger Ruby community.
March 03, 2009
A Test Application with ExamplesToday, someone wrote me. They need to do a Watir Demo and needed a good test app to use. Did I have something they could use? Of course I do.
We've been using the "Depot" test application for some time as a sample application for Watir training, demonstrations and framework development. It is a bookstore website, with a retail front end and an administrative back end. There are a lot of great things about it. You can run it on your own machine, so you don't need internet access. It is a non-trivial application. It has session state, a shopping cart and the backend requires login.
The "Depot" is part of the framework-examples project. The project also contains lots of examples of how to write Watir tests for it using different frameworks, including Rspec, Cucumber, Rasta and Roo (in a directory called Arc). And the WatirCraft framework. Indeed, we used this project to drive the development of the WatirCraft framework. We created examples using several different frameworks and then pulled the best of each into the WatirCraft framework. We stole the most from the Taza framework. Our WatirCraft example actually started as a Taza example (which is why there is no longer a "Taza" example in the project -- it morphed). Right now, in fact, this example amounts to the best documentation we have for the WatirCraft framework.
But any one looking to learn about any of these testing frameworks will probably find this to be pretty helpful.
February 06, 2009
The WatirCraft FrameworkIt still seems much too early to talk about it. I've been developing a testing framework for Watir users. We have one customer and some friends have been using it. It feels like a small twig fire that needs tending. I worry that too much attention will be like a big wind, blowing it out.
If you want to see it, you can look at a small page that I've put together about it for our customers. You can also take a look at the code . It is based on the Taza project , which Charley Baker leads. This framework is extracted from their projects at the Gap. (He works for the division that handles their websites, which are doing better than their stores.) I've also built several application-specific frameworks for previous employers am incorporating ideas from them into WatirCraft.
It seems early because most of my vision for this is still in my head and not yet in the code. And because I'm at a point where it feels easier to develop the features than to describe them. So talking about it, documenting it, writing about all seem like ways to delay creating it. But a little more feedback would be good, especially in a few more weeks and, of course, it will take time for people to try it out before they can provide feedback.
We also are looking for sponsors, people who would be willing to pay us to continue development on it. And I'm teaching classes next month (in Denver and Austin) to people who want to learn first hand about it.
It seems early, because I still don't have a proper homepage for this project, and I haven't really shared my vision. But, today, it's time for me to get back to the code. If you would like to sponsor this work, please contact me or Pete, my business partner in Denver. Or sign up for one of my classes. Thanks.
January 25, 2009
AWTA Notes are AvailableLast weekend I hosted the Eight Austin Workshop on Test Automation. We have a better record of this workshop than any previous. Notes from most of the sessions were recorded on our wiki, which also has links to photos, blog posts and podcasts. These were being posted daily during the workshop, along with a twitter stream, which had comments from several people who weren't able to join us. At the end of each day, I reviewed these discussions to get freedback on the day. People who were quiet in the room were speaking up online. I felt like an actor reading reviews of my opening night.
Since then, I've seen participants twittering more. There has also been a marked rise in discussion on the #watir IRC channel (although it was quiet during the workshop itself), as well as the watir mailing lists.
I'm really happy with the workshop. A lot of people helped in a lot of different ways. It's helped me frame my thoughts about frameworks: what people are doing, how the different frameworks can share more components, what people really need. I also got a chance to meet with many key contributors to the Watir project. The feedback overall has been very positive.
Next: Watir Frameworks