Michael Bolton I’m delighted to announce that I’ll be doing a one-hour lunchtime presentation on test framing for the Software Quality Discussion Group in Calgary, February 10, 2011. The session is free! However, space is limited to the first 50 people who register, so don’t delay. I’ll be in Calgary to present a public offering of Rapid Software Testing class, February 7-9, 2011. It’s being organized by Nancy Kelln of Unimagined Testing … Read more
On Monday, January 10, Ajay Balamurugadas tweeted, “When programmer has fixed a problem, he marks the prob as fixed. Programmer is often wrong. – #Testing computer software book Me: why?” I intended to challenge Ajay, but I made a mistake, and sent the message out to a general audience: “Challenge for you: think of at least ten reasons why the programmer might be wrong in marking a problem fixed. I’ll … Read more
The PDF file linked here is a transcript of a conversation over Skype, New Year’s Eve (December 31), 2010. The conversation was prompted by a Twitter exchange on exploratory testing (ET) started by Andy Glover, who observed that “When developing scripts you need to explore. But this tends to be exploring with out the s/w so I would say it’s not ET.: I disagree; developing scripts is test design, and … Read more
In the last posting, I remarked on some of the people with whom I chatted with at EuroSTAR, and whom I’m seeing as emerging leaders in a community of skilled testers. Here are a few more. Lynn McKee (Twitter: @lynn_mckee on Twitter) gave an inspiring and very well-attended talk on how to instill passion in testers—and in how to respect and defend the passion that’s there. Lynn walks her talk; … Read more
In this post, I’ll highlight a few more of the people that I met at EuroSTAR 2010. Please note that because there were so many people that I’d like to mention, there’s still more to come in subsequent posts. Also, I’ve included tons of links to these people and their work. Please use those links! Shmuel Gershon (@sgershon on Twitter) was in the Test Lab a lot, only one of … Read more
Way way back in 2003, Bret Pettichord first published a paper on schools of software testing. The paper was controversial. Some people found it helpful to identify different schools of thought, for the purpose of understanding ways in which reasonable people might disagree reasonably. Others found even the mention of disagreements within the field to be distasteful and divisive. Some people identified with particular schools. Others, sometimes indignantly, refused to … Read more
In Jerry Weinberg and Don Gause’s Exploring Requirements, there’s a set of context-free questions to ask about a product or service. The authors call them context-free questions, but to me, many of them are more like context-revealing questions. In the Rapid Software Testing class, the participants and the instructors make discoveries courtesy of our exercises and conversations. Here’s a list of questions that come up fairly consistently, or that we … Read more
In this series of blog posts, I’ve been talking about project estimation. But I’m a tester, and if you’re reading this blog, presumably you’re a tester too, or at least you’re interested in testing. So, all this has might have been interesting for project estimation in general, but what are the implications for test project estimation? Let’s start with the tester’s approach: question the question. Is there ever such a … Read more
Over the last few posts, exploratory automation has suggested some interesting things about project dynamics and estimation. What might we learn from these little mathematical experiments? The first thing we need to do is to emphasize the fact that we’re playing with numbers here. This exercise can’t offer any real construct validity, since an arbitrary chunk of time combined with a roll of the dice doesn’t match software development in … Read more
Last time out, we determined that mucking with the estimate to account for variance and surprises in projects is in several ways wanting. This time, we’ll make some choices about the tasks and the projects, and see where those choices might take us. Leave Problem Tasks Incomplete; Accept Missing Features There are a couple of variations on this strategy. The first is to Blow The Whistle At 100. That is, … Read more