Past Presentations
You can find an extensive list of presentations and courses that I've taught, including the slides and speaker notes for many of them, here.
Coming up—let's meet!
Highlights from my schedule appear below. If you notice that I'm in your part of the world, drop me a line if you'd like to get together. If you'd like to engage my services and worry that I'm not available, please note that my clients' schedules are subject to change, so mine is too. Please drop me a line in any case.
May 21-23, 2012
Utrecht, The Netherlands
A public session of the Rapid Software Testing class in the Netherlands, presented through Immune-IT. Register here.
May 24-25, 2012
Utrecht, The Netherlands
A public class of Rapid Software Testing for Managers, also presented through Immune-IT. Register here.
June 12-14, 2012
Cary, NC
Private training and consulting in Rapid Software Testing for a corporate client.
June 25-29, 2012
Atlanta, Georgia, USA
Private training and consulting in Rapid Software Testing for a corporate client.
July 10-12, 2012
Cary, NC
Private training and consulting in Rapid Software Testing for a corporate client.
July 16-18, 2012
San José, California, USA
Presenting "Critical Thinking for Testers" at the CAST 2012 conference.
August 21-30, 2012
Beijing, China
Training and consulting in exploratory testing for a corporate client.
September 10-12, 2012
London, UK
A public class of Rapid Software Testing, organized by ElectroMind.
September 24-28, 2012
Copenhagen, Denmark
A public class of Rapid Software Testing, organized by PrettyGoodTesting.
September 24-28, 2012
Copenhagen, Denmark
A public class of Rapid Software Testing, organized by PrettyGoodTesting.
October 1-4, 2012
Anaheim, California
The STAR West Testing conference.
October 9-11, 2012
Toronto, Ontario
A public offering of Rapid Software Testing, organized by the Toronto Association of System and Software Quality.
November 5-8, 2012
Amsterdam, Netherlands
A tutorial and track session at EuroSTAR 2012.
December 3-7, 2012
Oslo, Norway
A public offering of Rapid Software Testing.
I don’t know if you would agree with this description of a bug that matters to me. Let me try to frame it.
When I browse through your blog i.e., Developsense blog,I am interested in going through old posts of yours. When I clicked on ‘Jan 2005′ link under ‘Monthly Blog Archives’ (http://www.developsense.com/blog/2005/01/i-love-good-bug-on-qa-site) I found the image of the ‘QA Links bug’ overlapping the text in ‘Let’s Meet’ Section.
As this is inconsistent with other blog posts of the same site (www.developsense.com/blog), I apply the ‘inconsistent with the product’ heuristic and request you to fix this bug.
Michael replies: Excellent bug report. I observed the problem in a slightly different way than you did: under my version of Firefox, the graphic didn’t overlap the text. The graphic didn’t appear at all! Thank you for drawing my attention to it.
In terms of framing, there are a couple of points that I’d like to raise.
Test framing isn’t about requesting that someone fixes the bug. Who are you to tell me to fix a bug? (That’s a rhetorical flourish—in fact, you’re a trusted and respected colleague and friend. Yet…) As testers, we must be very careful about asking programmers outright to fix bugs. There are exceptions, such as testability problems, where we might start by asking informally and nicely. Most of the time, though, it’s up to the business and the product owner and the development manager to ask programmers to fix bugs. The good news is that test framing pretty removes the issue of making a request, and replaces it with the notion of logical arguments for why someone might (or might not) perceive a threat to the value of the product. So…
IF the intention of the blog post is to illustrate a problem in some other site
AND IF the illustration has problems of its own
SUCH THAT problems threatens the image of the blogger
IN ACCORDANCE WITH the consistency-with-image oracle heuristic
AND the consistency-with-product heuristic is applied to the otherwise unimpeachable quality of the site (*ahem*, *shuffle*)
AND there is a problem in which the graphic doesn’t appear
OR tramples on the right column threatens the value of the site
THEREFORE the value of the site or the reputation of the blogger is threatened
(UNLESS the blog post is so old that no one is reading it
EXCEPT someone must have been reading it
ELSE he wouldn’t have pointed out the problem).
Even though it comes without a specific request, the conclusion that there is a threat to value leaves the ball in the court of the programmer and the product owner. Which, I argue, is where it should be. From that, they can weigh all of the other potential threats to value, and make informed decisions about their priorities.
Again, tracing that whole line of connections isn’t something that you’d want to do with every test; you’d drive yourself and your client crazy. To defend our credibility, though, I’d argue it’s important for us to be able to do it for every test.