Skip to main content

Posts

Showing posts from 2009

Agilistry, practice space for Agile software development

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

Selenesse, nee WebTest

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'

telecommuting policy

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

ui test tool search

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

backchannel

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

when to use analogy

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

CFP: Peer conference "Writing About Testing" May 21/22 Durango CO

CFP: Peer conference "Writing About Testing" May 21/22 Durango CO I am organizing a a peer conference for people working in software testing and software development who write about their work in public. The conference will be organized LAWST-style, much like the recurring Austin Workshop on Test Automation or the Tester-Developer/Developer-Tester conference I helped organize in 2007. The original proposal is on my blog here: http://chrismcmahonsblog.blogspot.com/2009/08/proposed-peer-conference-writing-about.html There is significant demand for public information about software testing and software development and software process. This conference is for people who want to influence the public discourse on these subjects through public writing. If you are interested in the subject, but not necessarily interested in the peer conference, there is a private mail list for writing about testing whose members include both writers and publishers. I (or any other member of the

against kanban part 3

At the agile2009 conference, David Carlton and Brian Marick presented something they called "Idea Factory", an overview of three sociological systems by which the scientific community comes to regard a certain thing as fact. Carlton's presentation was particularly intriguing. He cited work pointing out that disparate communities come together in what are called "trading spaces" in order to pool aspects of their expertise to create new work. One of the signs of a "trading space" is a creole or pidgin language created by the participants in the trading space and used by participants in the trading space to negotiate among themselves. Such language may seem weird or impenetrable by outsiders, but participants wield it in order to accomplish things among themselves. In contrast, Six Sigma, ISO9000, and now Lean/kanban, are imposed upon the agile development trading space. They are concepts and processes and ideas forged from managing factories, fitted (

against kanban part 2

After conversations with various well-meaning folk at the Agile 2009 conference about some details of Lean and kanban, I remain more opposed to a general implementation of them than ever. But I'm willing to grant that a single kanban call might have value. Liz Keogh had a good example:  a group of agile coaching consultants, each with multiple clients, each client moving at different rates, with more clients waiting for attention.  The consultants track their work with cards on a board. (Note: tracking work with cards on a board is NOT kanban...) When one consultant finishes with a client, that consultant adds a card to the board saying GIVE ME WORK. As I understand it, this is the essence of kanban:  as Eric Willike told me, the essential image of kanban is a colored card in an empty basket, sent up the line to have the basket filled again. But what a frighteningly low-bandwidth transaction!  This means of communication is for infants: GIMME followed by either YES or NO.  Put a bu

proposed: peer conference "Writing About Testing"

It seems like there is more demand than ever among the technical publications for information about software testing. Experience reports, theoretical pieces, tool documentation, all seem to be in great demand right now. At the same time, I think the overall quality of what I've been reading about testing is declining, as people rush to meet that demand without adequate preparation or knowledge. I'm interested enough to do the legwork to host such a peer conference, assuming the potential participants were willing to come to Durango. If not, I'd be willing to travel to attend such a conference, and to help facilitate, promote, or whatever is needed to bring it off. I envision soliciting participation from two groups: established writers with a history of publication with outlets like SQE, STP, InformIT, O'Reilly, etc. etc.; and also new voices looking to start writing for these sorts of publishers (I very much hope that there really are new voices writing about testing

a year of STPedia

This month marks one year of the column Matt Heusser and I co-write every month for Software Test and Performance magazine, "STPedia". It was great to mark our anniversary in a double-length column on "Agile Testing in Practice" in July's newly redesigned print version of ST&P and to help out with the launch of ST&P's redesigned portal, stpcollaborative . ST&P are changing things around for the better. The format of the column is that we have a paragraph or two introducing the topic for the month, then we define dictionary-style a set of terms related to the topic, then usually we draw some sort of conclusion from how the terms are related. ST&P has a 6-month editorial calendar, so at this point we've treated many subjects twice. And really, how much is there to say about source control? From here on out we're going to range a little more widely in our choice of topic. A little Inside Baseball, for those who are interested in h

against kanban

I've been somewhat alarmed by the enthusiasm with which the agile community has embraced Lean manufacturing principles, especially kanban. While I'm sure that kanban is effective in some circumstances, I am also convinced that it exposes software teams to real risk of impaired function. Like many of my qa/tester colleagues who were working in the field in the 90s, I used to be a real process-head. I was part of projects that enthusiastically implemented Six Sigma, CMM, ISO9000, as well as other approaches like RUP, spiral development, etc. etc. We thought then that if only we could get the process right, we could crank out great software just like factories crank out cars and engineers crank out bridges. Six Sigma and ISO9000 were lifted straight from manufacturing. CMM was the product of a lot of analysts who looked at some properties of a selected set of software projects. Then the Agile movement came along, and with it new processes, the most significant of which turned

validate order with regular expressions

Today I wrote some UI tests to validate that certain text appears on pages in a particular order. Since I've done this now in two different jobs using two different tools, I thought it might be of interest to others. There are a couple of reasons you might want to do this. For example, a page might have a list of records sorted by certain aspects of the record. Here's a crude example: |name |date|description| |chris|july|tester | |tracy|june|gardener | One set of critical tests validates that name/date/description appear in the right order; that chris/july/tester appears in the right order; and that tracy/june/gardener appears in the right order. Another critical test is that chris appears above tracy in the display. The first challenge for the tester is to identify and be able to address the smallest part of the page that contains the text under consideration. Every tool does this in a slightly different way, but Firebug is your friend here. The next challenge is to

UI test framework design using Watir

I wrote a little toy test automation framework recently. It's a keyword-driven framework, and the test data is kept in a CSV file. The test data look like this: goto,http://www.google.com,, text_field,name,q,pickaxe button,name,btnG,click match,Programming Ruby,text This is the classic Google Search example from the Watir documentation. I used CSV because it's the simplest implementation. This is, after all, a toy. In the real world this might be HTML tables or wiki tables or a spreadsheet. What we want is for anyone to be able to write a test quickly and easily after a little bit of training on FireBug or the IE Developer Toolbar. (Test design is a different issue. Let's not talk about that now.) The framework grabs the test data and interprets each row in order. A simple dispatcher invokes the correct execution method depending on what the first element in the row of test data is. This has two advantages. For one thing, there are a finite number of types of page e

a really good bug report

I had occasion to use FireWatir recently and found a strange bit of behavior trying to manipulate a select_list element. I posted an executable bug report to the Watir-general mail list. (Please read the whole (short) discussion.) I have not been working closely with Watir for some time, so I missed some obvious diagnostic paths. Even so, though I got a reasonable explanation for the observed behavior, I pushed it farther, wondering why I did not receive a NoMethodError trying to do what I did. Please note: at no time did I ever editorialize; nor criticize; nor invent solutions. I merely discussed observed behavior with interested parties in disinterested tones. And upon examination, I had turned up not one, but two different bugs. I am pleased once again to have contributed to the Watir project. Furthermore, I think the discussion linked above is pretty close to a Platonic ideal of bug reports.

at liberty

blogging is so old-school . Thanks again Jeff! I have been amazed by and touched by and thankful for and proud of all the people who have sent nice messages, said nice things, and sent me leads since I was laid off from the best job I've had in a decade. I am seeking a telecommuting software testing/QA job or related work. I have expert-level skills and experience, a shockingly good resume, and awesome references from some of the best software people in the world.

agile COBOL is no oxymoron

Dr. Brian Hanks of Fort Lewis College said on Twitter just now: "Agile Cobol - the new oxymoron" I have to disagree. In the late 90s I worked testing a life-critical 911 data-validation system written in COBOL and C. I was the tester when we migrated from key-sequenced data files (basically VSAM, or very close) to an SQL database (albeit one with no relational integrity-- we had to write that into the code). When I joined the company, system releases were chaos. By the time I left, system releases were orderly, done on a regular basis, with great confidence. We evolved what was essentially an agile process to regularly ship running, tested features that our customers wanted. But we broke every rule in the book (of the time) to do it. We had customers talking to developers all the time, we had sysadmins reviewing features before release, we had testers reading code and running debuggers, we (quietly) ignored test plans in 5-inch binders. The Agile Manifesto validated th

Ruby net/http+SSL+Basic Auth

Since one post from this blog is (or at least used to be) a little chunk of official documentation for Basic Auth in Ruby, I decided I should write this down also. Socialtext is switching some of the SaaS servers to be https all the time. So I had to rejigger my selenium test-runner script, because it reads (test data) from and writes (test results) to the wiki. I found this very elegant example . My take on it looks like def put_test_results_to_wiki http = Net::HTTP.new(@test_host,443) req = Net::HTTP::Put.new(@put_loc, initheader = {'Content-Type' =>'text/x.socialtext-wiki'}) http.use_ssl = true req.basic_auth @test_user, @test_pass req.body = ".pre\n" + @content + "\n.pre" response = http.request(req) puts response end What is a little peculiar about this is that Basic Auth is very much optional for SSL connections. Normally the client would do a GET, the ser