I get perverse joy in finding bugs on testing and QA-related sites. Here’s one from QAForums. Apparently none of the 106,000 members has noticed the bug, or if they’ve reported it, nothing’s been done.
Note that, not only is the “grand_total Quality Assurance Links” tag unknown, but the word “unknown” is spelled wrong.
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.
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.
January 16-18, 2012
Helsinki, Finland
Rapid Software Testing: a three-day public class, organized by Altom. Information is here; registration here.
January 27-29, 2012
Melbourne, Florida
Workshop on Teaching Software Testing
January 30-February 3, 2012
Palm Bay, Florida
Writing work with Cem Kaner and Becky Fiedler.
February 12-18, 2012
Orcas Island, Washington
In-person development work on the Rapid Software Testing class with James Bach.
March 8-14, 2012
Utrecht, Netherlands
Pencilled-in engagement teaching Rapid and exploratory approaches with a corporate client.
March 15-16, 2012
Munich, Germany
Two days of presentation and particpation in an in-house testing conference for a corporate client.
March 26-29, 2012
Halifax, Nova Scotia, Canada
A three-day Rapid Testing class in-house for a corporate client, with a free fourth day based on the client's agenda.
April 10-12, 2012
Oslo, Norway
A public offering of Rapid Software Testing.
April 13, 2012
Oslo, Norway
Work for a corporate client.
April 16-19, 2012
Orlando, Florida
A tutorial and a keynote at the STAR East conference.
April 25, 2012
Toronto, Ontario, Canada
Corporate in-house training and consulting.
April 30-May 2, 2012
London, UK
Rapid Software Testing public class organized by Electromind. Register here.
May 3-4, 2012
London, UK
The UK's first public offering of Rapid Software Test Management, again organized by Electromind. Register here.
May 7, 2012
Stockholm, Sweden
I'll be presenting the first keynote and a half-day tutorial at the inaugural Let's Test Conference in Sweden. Alas, I'll only be able to stay the first day of the conference, which runs from May 7 through May 9, 2012.
May 8-11, 2012
Trondheiim & Brønnøysund, Norway
The Norwegian Testing Cruise. So far as we know, this will be the the first boat-based and northernmost testing conference in history.
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
Participating in the CAST conference.
September 10-12, 2012
London, UK
A public class of Rapid Software Testing, organized by ElectroMind.
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.