DevelopSense Blog

One of the hallmarks of the Conference for the Association for Software Testing is adaptability. Each track session and keynote is followed by a facilitated discussion, and if there's energy to continue to the discussion when the official time is up, we go into overtime and find a place for the conversation to continue. This is unlike pretty much any conference that I've ever been to (although to its credit, QAI did something similar for a couple of its sessions in November of 2006, and I hope they've been keeping it up). Conferences should be about conferring. At CAST, if people want to keep talking and learning on a particular subject, we say let's find a way to make it happen.

In the same spirit, Jerry Weinberg's Monday tutorial, The Tester's Communication Clinic, sold out with more than a month to go, so we added another day to the conference—Thursday, July 17—to give more people the opportunity to attend. There are still some spots available for this second session, and a dynamite conference to precede it. So if you haven't done so already, get yourself registered.

Karen Johnson just posted a blog entry on testing search algorithms. I'm soon going to write an article on accidental test coverage. The intersection of these two topics can be found here, based on a search I recently did in the frequently asked questions list on an airline Web site.

Search Results for "power for laptops"

1.	Can I use my laptop during my flight?
2.	Where can I locate the timetable?
3.	Do you have a policy for transporting antlers?
4.	What are the requirements to obtain an exit row seat?
5.	What are the fees for traveling with or shipping my pet?
6.	What are the benefits of purchasing travel protection?
7.	I am a WorldPerks member, but I am not able to view my Electronic Credit Voucher online. Why is that?

Note a couple of interesting things.

First, the word "for" is highlighted in the list of links to found items, but "laptop" is not.

Second, when I go to the answer to item 1, the words "power" and "laptops" appear in the found article and are highlighted. If I change the search terms to "power for laptop", the same list is returned with "laptop" highlighted, but "laptops" isn't highlighted in the found item. So the search algorithm appears to be using the stemming that Karen talks about, but the highlighting algorithm isn't. From this I infer that the highlighting and search algorithms aren't quite talking to each other.

Second, check item 3 on the list. When I go to that item, the word "weight" is highlighted in the body of the found item. The word "for" appears in the text (and is not highlighted), but neither "power" nor "laptops" does. In order to check that the found word should be highlighted, I next did a search for "antlers", and the only item returned was item 3 above. All instances of "antlers" were highlighted in the item.

And, of course, there are only three weeks left to register for CAST.

So it's after May 31, and you're all depressed over having missed Early Bird registration for the Conference for the Association for Software Testing.

So maybe you haven't realized that there's still a way to get the Early Bird rate PLUS an added benefit. If you become a member of the AST, that's a scant fifty bucks. If you sign up for the conference at the member rate, that's (considering the program—a dozen great track sessions, four awesome keynotes, and four enlightening tutorials) an even scanter 750 bucks. Put 'em together and you get $800—exactly the price of the Early Bird rate—plus you get the benefits of an AST membership into the bargain. Joy! Register now!

(By the way, one tutorial is already sold out with more than a month to go before the conference, but let us know if you're interested, and maybe we can do something about that.)

CBC Radio is one of the things to make a Canadian proud. There's a wealth of stuff that I find valuable, entertaining and informative--Ideas (a largely open forum for all kinds of interesting topics); As It Happens (telephone-based interviews with people, usually on the where the action is happening, on all kinds of issues all over the world); Randy's Vinyl Tap (in which the former lead guitarist for the Guess Who takes us on a tour of some aspect of popular music, with the original tunes, anecdotes, and even a little musicology.

In the last couple of years, The Age of Persuasion has gone on the must-hear list. It's a show about advertising—the good (ads that are persuasive), the bad (ads that somehow miss being persuasive), and how it all works (a very well-crafted tour through psychology, language, economics, creativity...). And from that, this lesson about testing, cleverly disguised as a lesson about advertising:

"Home Depot doesn't sell three-quarter-inch drill bits; Home Depot sells three-quarter-inch holes."

This reminded me immediately of David Platt's wonderful aphorisms, "People don't want to drive somewhere; they want to be somewhere" and "People don't want to use your software; people want to have used your software."

Testers: is your testing focused around things that make people happy that they have used your product? Are you identifying things that make them suddenly or inappropriately aware that they are using your product?

If anyone asks me what general systems thinking is about, I will from henceforth point them to any Jessica Hagy index card that has an X/Y chart with an -OR- in the caption.

Or I may just point everyone to it anyway. This stuff is absolutely wonderful.

http://indexed.blogspot.com/

and also

http://freakonomics.blogs.nytimes.com/tag/indexed/

Note that I spared you the by-now obligatory reminder to register for the CAST Conference. Oh, damn!--no I didn't.

I'll be doing a presentation called "Six Short Talks About Software Testing" for the Toronto Association of System and Software Quality (TASSQ) on Tuesday evening, May 27, 2008. It'll be a 90-minute session wherein I'll give of a six set of lightning talks, with time for questions between each one and a longer discussion afterwards.

I'll be using a few of those minutes to talk about the CAST Conference, July 14-16 in Toronto; why I'm so excited about it; and why I think anyone who is even moderately interested in testing (not just testers, but also developers, business analysts, project managers, support people...) should attend.

Then, as is TASSQ tradition (at least when I'm in town), I'll take the speaker to the pub afterwards, where we'll both talk about testing and CAST some more with anyone who'd like to come along.

The Conference for the Association for Software Testing 2008 is coming up, July 14-16 in Toronto. The theme is "Interdisciplinary Approaches to Software Testing". It's an absolutely terrific program, featuring keynotes by Jerry Weinberg, Cem Kaner, Rob Sabourin, and Brian Fisher; tutorials by Jerry, Scott Barber, Hung Nguyen, and Julian Harty; and a dozen-or-so track sessions. You can read all about that part here: http://www.cast2008.org/Program.

As usual for CAST, the presentations are based on experience reports. The interdisciplinary theme makes things really interesting and rich. Martin Taylor and Brian Fisher will both be talking about data visualization. (I wonder if they'll talk about stuff like Hans Rosling's visualization tools?) Links between testing and the arts feature prominently. Jeremy Kominar from Research in Motion will be doing a session on what magic has taught him about testing; Jonathan Kohl and I will be doing a talk on relationships we've discovered between testing and music, especially with respect to learning; Adam White will be doing a presentation on improv theatre and how it has helped him to model testing projects and tasks.

There are track sessions on testing scientific software, embedded software, data warehousing, and mobile applications; and lessons learned from accounting software and civil engineering. Plus my friend Bart Broekman will be coming from Holland to present a track session called Testing Fuzzy Interfaces - Can We Learn from Biology and Wargaming?—like, how interdisciplinary is that?

Oh, and another thing: Jerry Weinberg will be using CAST as the official launch point for his new book, Perfect Software and Other Testing Myths. He'll be signing the book. (And doubtless talking about it. A lot.) He won't just be around for tutorial and the keynote, but for the entire conference, through Wednesday evening. As far as I know, it's his only conference appearance this year, except for the AYE Conference of which he's a host.

It ain't just about the presenters, either. The brains-per-square-foot factor amongst the other conference participants is higher than any testing conference anywhere. Participants is a key word, because CAST is different. The conference is like a scaled-up version of the LAWST peer conferences. Each presentation is followed by a facilitated discussion, in which those in attendance actively question and discuss the ideas that were raised. Sometimes the conversations are challenging for the presenter, sometimes they're, uh, challenging for the facilitator, but they're always revealing and stimulating, and open-ended. That is, if there's energy for a particular discussion, we find a way to keep it happening.

This isn't a commercial conference. The money goes right back into the AST, a not-for-profit organization. It's is a conference by testers, for testers.

And, well... not by marketers. As should be patently obvious by now, if you've been following our efforts. So we need your help!

1) We need you to come to the conference! Register here: http://www.cast2008.org/Registration

2) We need you to spread the word. Please, please, please, talk about the conference, blog about it, send the links around to your friends and colleagues and managers and project teams. Spread the word on newsgroups and forums. Talk about it at your local testing association. Even if you can't attend, you might alert a colleague who can--and they can tell you all about it. (That said, we'd rather see YOU, of course.)

3) Please ask your company for support in the form of sponsorship, by sending you and your fellow testers to the conference, or both. Since CAST is not-for-profit, the registration fees are very modest, especially in light of the quality of the presentations, the learning opportunities, and the chance to build community.

By the way, if you're having trouble persuading Them to send you to the conference, check this out this wonderful article by Jon Suzuki (posted on the AYE Conference web site, speaking of conferences worth lobbying to attend). You're a tester; think outside the box. Here's just one suggestion: most companies have budgets for marketing and networking, and you might be able to attend CAST as part of a sponsorship deal if the cupboard is bare in the training budget. Did I mention that the conference hotel is only $114 per person per night? In downtown Toronto? In Canadian dollars? (Okay, so some things ain't what they used to be.)

Once again, the program is here, the registration page is here, early bird registration closes in a little over a month, Toronto is a wonderful town, this will be a fantastic conference, and I'm done raving for a couple of days.

Until today, my reading of Mary Reilly's Play As Exploratory Learning had been limited to occasional stolen glances into Cem Kaner's library, but a copy of this out-of-print book arrived today. Browsing (that is, a little exploratory reading) yielded this (from Chapter 3, "An Explanation of Play", page 117):

"The pursuit of the rumored goodness and usefulness that play might have for man is plagued by the difficulties inherent in the processes of exploration. One of the first problems is the very obviousness of play. It is a behaviour endlessly in plain sight, and because it is a behaviour there in plain sight it lacks the intrigue that the unknown has for scientists. Intellectuals go to any lengths to avoid the obvious and theorists in particular disdain it. The real difficulty that confronts any broadened explanation of play is that it is an obvious commonplace behaviour breeding contempt dampening investigatory interest."

Well, ain't that just like exploratory approaches to testing? (For "play" read "exploratory testing"; for "scientists" and "theorists", read "many programmers"; and for "intellectuals" read "traditional testing theorists".) Explaining exploratory testing is hard because we appear to be simply "trying the program to see if it works". What's not obvious to the untrained observer is the stuff that's going on behind the eyeballs: modeling the test space; determining coverage, oracles, and procedures; and making decisions about how to configure, operate, observe, and evaluate the product. It would be nice if other people could see all that stuff, but we can't. So, as a community, those of us who recognize the value of exploratory approaches—that is, the fact that they're central to excellent testing—are going to have to keep talking about them.

Jason Gorman is an interesting guy, and has a lot to say. I agree with lots of it, especially his iconoclastic position on agilism. This time, I'd like to disagree with two paragraphs in a recent blog entry. The second one first.

But I suspect in 5-10 years' time, as test-driven development becomes more popular and teams become more ambitious in their testing efforts, test developers will be in great demand and will be able to command high salaries. I see them becoming as important as architects are viewed as today. Maybe more so, since they actually add value on a project ;-) (Only kidding)

This seems to have been coming up a lot, so I'll say it here: I'm agnostic about architects, but testers don't add value to a project; as James Bach suggests, testers help to defend the value that's already there, or help to identify ways in which value may be lacking. Testers raise questions and make observations; the people who make decisions based on those observations are the ones who add value. We help them do that, but we don't do it intrinsically on our own.

Realistically, you must be a developer before you can become a test developer, since learning how to create high quality code takes longer to master than learning how to write effective tests. That's not to denegrate the discipline of software testing: anyone who's read Robert Binder's book on Testing Object Oriented Systems will know that, if you wanted to, you could dedicate a lifetime to understanding testing. But, let's be honest now, it takes longer to learn how to code from scratch than it does to learn how to break code*. (* Is that my inbox I can hear filling up again?)

Well, first, testers don't break code; the code was already broken when it showed up. (I think I heard this first from Alan Jorgenson.) That's a fairly trivial objection, though.

The more serious problem is with the assertion that "learning how to create high quality code takes longer to master than learning how to write effective tests". Testing is not merely a matter of writing test code. Testing is about questioning the value of a product and the potential threats to that value. It takes the better part of a lifetime, I think, to understand value. Every time I think I have a handle on that, someone or something comes along to teach me another lesson in humility. But until we're sure we're able to ask the right questions about value, I'll contend that we can't know the right answers to whether our code is of high quality or not. By that reckoning, let's be honest now: learning how to create high-quality code and learning how to question should be inseparable. It's a rare person who can do either one very well, and even an even rarer person that can do both very well. That's why we need developers and testers—and why we tend to need a few of each.