July 29, 2008

Lessons Learned in Agile Development

This begins a series of short essays on Agile development. I am writing these for several reasons.

We are using many Agile methods in the development of Watir. We are using such methods as continuous integration and emergent architecture in our development. Many Watir users are curious about our development, but unfamiliar with some of our methods. I want them to understand.

Many Watir users and other testers are trying to understand Agile. Many are on teams that have recently begun using Agile methods, and are wondering whether it works. It does, but there are also lots of ways to fail. Testers, always quick to find faults, have a hard time with much of the Agile literature, written as it is with developers or managers in mind. I’m always thinking about the testers.

WatirCraft is also using Agile methods. Explaining Agile gives me a chance to explain to the current and future WatirCraft team some of the rationale behind our methods.

I began studying Agile testing six years ago and for the past four years have worked exclusively with talented, high-performing Agile teams. In the past few years, I’ve also been coaching my collegues on Agile methods in areas beyond testing. In that time, I’ve compiled quite a pile of notes on the topic, including key ideas and common misunderstandings. I’m happy to have this chance to share them.

Next: Agile is all about feedback.

Posted by bret at 02:57 PM | Comments (3)

July 26, 2008

Private Blogs

Yesterday, I spent yet another evening researching private blogging options. Several months ago, I started a private blog to share with the people who are helping us launch WatirCraft. I've had these before at previous companies. I think I was the first to start an internal blog at ThoughtWorks. At Dovetail, many people already had them when i arrived. Some used it as a training ground to get more comfortable with the format before blogging publicly. I liked it as a way to publish essays in a way that encouraged a public discussion. Something similar can be done with email, but there are a few drawbacks.

Invariably, email discussions leave someone important out, and can be difficult to add people to the discussion later. Internal blogs don't have this problem: any one in the company who finds out about the discussion can join in, sometimes even months later. I also find myself reluctant to send out emails because they can be so interrupting. With a blog, it seems easier to write something that is important but not urgent, and you'll get more thoughtful replies because people know that they replies will be archived.

I remember pushing the idea that QA people should be called “Testers” (and not “QA”) on my ThoughtWorks blog. We had pretty much come to agree on this point in the Context-Driven community before I joined ThoughtWorks, but I came to see that ThoughtWorks, like the industry at large, still labelled the role “QA”. Because I was then in a position of some standing (Director of Testing Practice), making an issue of this on my public blog would have been a positional move, likely polarizing both me and those who disagreed. By publishing my position internally, I essentially acknowledged that I wanted feedback from my collegues on this topic. I remember Rebecca Parsons suggested “QA/Tester,” which, though awkward, didn't run into the various objections I had laid out against QA, and since then I've been more comfortable with the “QA” term, even though I still usually prefer “Testers”.

At both ThoughtWorks and Dovetail, we made our blogs private simply by publishing regular blogs on our internal networks. You either had to be in our offices or connect over the VPN to see them. Web-based feedreaders (like Google Reader) wouldn't work, but you could use any client-based feedreader (Outlook has one) when you were connected to the company network.

I looked closely at Blogger and WordPress and also more generally across the field and was not able to find any ready-to-use blog engine that supported private blogs and provided a feed. It is possible for feeds to be password protected. For example, we use Highrise and it provides a password-protected feed containing recent changes. But i could not find such a thing for any blogs.

Apparently several blog engines added support for private blogging a couple of years ago, but left public feeds on them. These were crawled by search engines and people were finding their private posts on Google! The quick fix was to remove the feeds, and apparently the issue hasn't been addressed since. One option that might work for some would be to have a blog that isn't strictly private, but is protected from search engines, so you'd have to know the URL to read it. This option is offered by WordPress.

At WatirCraft, we have not yet set up a VPN, so that is not an option for us. For now, it seems the best way to run an internal blog is to make one private and then to set up an accompanying mailing list that you post to when there are updates on the blog.

Posted by bret at 08:41 AM | Comments (7)

July 15, 2008

Setting up Watir with Cruise Control

Last week I set up Watir so that its unit tests are run automatically whenever any changes are committed (“checked in”) to the development repository. This is done with Cruise Control, a tool which watches repositories, runs tests and posts results. The Watir tests are run at watirbuild.com and you can check the latest test results yourself. Indeed, the page has a button called “build now.” Click it and the tests will be run immediately on the server.

The general term for this process is continuous integration—a common practice with Agile teams. I’ll write more about why this practice is important for the Watir project another day. Today’s post is about what I did to set this up.

First, I got a server, a virtual private server (VPS) running Windows from VPSLAND. I would have preferred a machine running XP, since most Watir users use that, but the closest I could get was 32-bit Windows 2003 Server. Cost: $19 a month, courtesy of WatirCraft. This VPS is named watirbuild.com.

Next I installed the Google Toolbar, because I can’t find anything without it. I also had to loosen up security on IE so that I could use it to download the software I needed. (The server VPSland provided came with security really locked down.)

I then installed Ruby 1.8.6-26. The next step was to do a “gem update --system” to update the gem installer to the latest version (which Watir needs), but this command failed with this error.

c:/ruby/1.8/yaml.rb:133: [BUG] Segmentation fault

A little research showed that this was a common problem on RAM-constrained VPS’s. Apparently the pre-update gem installer is a memory hog and the VPS’s don’t have any swap space. The common workaround has been manually download the gems before installing them. (Only the remote gem installer runs into memory problems.) But I used a different approach.

I wanted our test environment to match, as much as possible, the environments that other people are using for testing, so I really wanted to have the latest gem installer. I also knew that it had better memory handling. So what I did was install Ruby on one of my own systems with more RAM, and then did a “gem update --system” on it. Then I zipped up the resulting “ruby” directory (using 7zip), uploaded it to watirbuild.com and then unzipped it there over the original installation. I was then able to do remote gem installs without any further trouble.

Because Watir now depends on several other gems. I did a “gem install watir” and then uninstalled the Watir gem itself. This left all the dependent gems installed.

Watir uses Subversion (SVN) as its development repository, so we needed a client to access that code. I installed the command line client.

The next step was to install the continuous integration tool itself. I chose CruiseControl.rb because it is Ruby-based and easy to configure. Pre-deployment testing had shown, however, that the latest release (1.3.0) did not work on Windows (After starting the server, it would get repeated "Access is denied." errors from SVN.) Instead I needed to use the latest from its development repository. They recently migrated that project from Subversion to Git, so that meant I needed to install a Git client. Once it was installed, installing Cruise was simply a matter of doing

git clone git://rubyforge.org/cruisecontrolrb.git

With Cruise installed, I added the Watir project:

cruise add watir https://svn.openqa.org/svn/watir/trunk/watir

I also needed to add a “cruise” target to Watir’s rakefile. Which I did with the following code:

desc 'Run unit tests'
task :test do
  load 'unittests/core_tests.rb'
end

task :cruise => :test

(This code is now part of the Watir project, so you wouldn't need to provide this code if you were running Watir. But you will need something similar if you are setting up your own project with CruiseControl.rb.)

Then I started Cruise using “cruise start -p 80”, and this immediately kicked off Watir’s unit tests. Some failed on first run, and I had to modify a couple of IE’s security settings to fix this.

To test everything, I checked in a minor documentation change to Watir and verified that the unit tests were automatically kicked off.

Posted by bret at 01:22 AM | Comments (1)