Blog: I love a good bug on a QA site.

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.

Want to know more? Learn about upcoming Rapid Software Testing classes here.

One response to “I love a good bug on a QA site.”

  1. 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’ (https://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.

Leave a Reply

Your email address will not be published. Required fields are marked *