Chris McMahon's Blog

Looking Back The world of software testing today is radically different than it was on this day a decade ago. On New Year's Day 2000 I had been a dedicated software tester for about three years. I was a leader on a team testing an application that provided location information to the dispatchers who handle 911 calls. I was intensely interested in the most progressive thinking about software testing available, because when we released a bug to production, someone could die because of it. I remained interested in the most progressive thinking about software testing throughout the decade. Looking closely, we owe a vast debt to three people: James Bach , Bret Pettichord , and Brian Marick . If they didn't supply every breakthrough idea in software testing in the last decade, one of them was nearby when it happened. There was a shot across the bow in 1996 when Bach published " Test Automation Snake Oil ". This would be the first of a relentless assault on proprietary...

Elisabeth Hendrickson and her colleagues with Quality Tree Software have announced the opening of Agilistry , their 'immersive training space' in Pleasanton California. I've been following Elisabeth's announcements along the way to making this happen, and from what I can tell, the Agilistry facility is set up as real agile working space... except conceived and designed from the ground up by some of the most intelligent, experienced agile practitioners in the world today. When I think of "training space" for software, I think of a trainer behind a podium with a whiteboard and a projector and some handouts, with trainees sitting at tables facing the podium. This isn't that. Agilistry isn't training space at all; Agilistry is *practice* space. It even says so on the web site: "Agilistry Studio; a practice space for Agile software development" And I'll bet that not many people know how to use a practice space. For beginners, practice space i...

Marisa Seal and I have officially taken over maintenance of Gojko Adzic's 'WebTest' project. If you want to know why, I wrote about it here . Marisa is doing the coding (so far; I've never written any Java and would like to learn) and I'm being something like a Customer. I've used similar tools in the past, and I know what I want this tool to do. Eventually we're going to need documentation for our first release (0.9?), so it seems like a good idea to write down what we're doing, and this seems like a fine place to do it. The first thing is that we want to change the name of the project to avoid confusion over the other tool with the same name, Canoo WebTest . My favorite so far is 'Selenesse'. Not only does it give a sense of the bridging nature of the tool, it also is very close to the word for the high-level selenium language known as 'Selenese', and since Selenium borrowed a lot of structure from Fitnesse early on, it'...

Many of the members of the writing-about-testing group are also experienced telecommuters. It turns out that a number of us have had bad experiences when telecommuting for organizations that lack a sane and rational telecommuting policy. So we wrote one. The following document has been through more than 80 revisions and contains text contributed by 5 separate authors, and also reflects the comments of even more participants. We hope you find a generic telecommuting policy useful. Telecommuting Policy Some organizations want to offer telecommuting as an amenity for work/life balance. Other organizations do not want to have to rely on local talent to build exceptional teams. Other organizations want to use telecommuting to reduce the cost of infrastructure such as office space. Regardless of the reason, any organization wishing to succeed with telecommuting must have a policy for handling remote working. An institutional standard must be in place such that everyone telecommuting...

I now work for 42lines . I was hired along with Marisa Seal to start the QA/testing practice for a very small totally distributed/remote software shop implementing agile processes as they make sense. I like this place. One of the things that 42lines wants to do is to begin UI-level test automation. I have a lot of experience doing this, but I've never done it from a standing start, so this was a great opportunity to get a good look at the state of the practice for UI-level test automation. For the last 3 years or so I've been using keyword-driven test frameworks that use a wiki to manage test data . I like these wiki-based table-based keyword-driven frameworks a lot. I'm a little suspicious of the BDD-style frameworks like Cucumber and others based on rspec-like text interpretation. Anecdotal evidence suggests that analyzing the causes of failing tests within BDD-style frameworks is an onerous task; also, I suspect that since BDD-style frameworks map closely to story...

Kent Beck mentioned recently that he can't think of a situation for which Google Wave is indispensable. Jason Huggins left this amazing comment on Beck's blog post. Wave could very well be indispensable for implementing a "backchannel". A backchannel is a multi-user space for commenting on some action being shared by everyone on the channel, whether it be listening to a speaker at a conference or attending a meeting during which people take turns speaking. A backchannel is perhaps most commonly implemented on IRC, but any reasonably robust multi-user messaging tool will serve. But it's not only conference attendees that need a backchannel. Coming up I have a couple of articles recommending required communications channels for distributed teams and very large teams, wherein I strongly recommend having a backchannel during team meetings. It really is a critical core practice for distributed teams. But even given an IRC backchannel, a lot of information gets ...

Analogy is a useful device when used to describe the things that we work on; but it is actively dangerous when used to describe our work itself. When we're building software, it is useful to be able to say for example "it's like a library, where someone can make use of a feature and then stop using it so that someone else can use that feature" or "it's like a train, where there are just a few places where anyone can get on or where anyone can get off" But when we use analogy to talk about our work, we invite misconception and misinterpretation. To say "writing software is like making a cake" invites misperception. Does writing software involve flour and sugar? Is there frosting involved? Of course someone who says such a thing *probably* means that to write software one must do certain steps in a certain order-- but it is far better to describe the actual steps ("red, green, refactor" is not an analogy) than to invoke analogy, be...