Hiccupps

You can waste a lot of time on formatting. In The Power of Fancy Plain Text I said that I prefer plain text when possible and for a while I've been using Ascii Flow , a web-based tool, for making quick and dirty flowcharts and simple block diagrams that I can store in text documents too. Here's a bit of a chart  I made recently to plot out some test scenarios for a timing-related issue I was investigating and wanted to share on our wiki. The blocks represent actions occurring over time and their relationship to a some significant times and events. t1 t2 + + +---|-----------------------------|------> time | | | +----+ +----+ | +----+ E1 | | A | | B | | | C | | +----+ +----+ | +----+ | | +-----------------------------------------+ E9 | V ...

When you're testing you're observing, mapping, inspecting. Sometimes it's non-specific - you're exploring, trying to understand the size, shape, performance envelope, functionality, scope, stability, usability or other characteristics of an application. Sometimes it's very specific - you are implementing an attack vector that you think you can exploit to expose a bug. Sometimes it's neither of those things or a combination of those things. Whatever it is, it always involves looking and when I'm looking at a system I try to apply what I think of as peripheral testing  by analogy to  peripheral vision ,  the ability to see objects and movement outside of the direct line of vision . I have my main focus on the thing I'm interested in, but I permit and encourage part of my focus to wander briefly, just a little, but often, while I'm there. Let's say we're working in a GUI. I'll take a few seconds to hover over all the components in a d...

Give a man a fish and he'll be fed that day. Give a man a fishing rod and he'll be fed for a lifetime. On James Bach's Rapid Software Testing course , you are that man, but Bach is not tossing you a fish, nor even giving you a fishing rod, instead he's swinging open the doors of his huge angling arsenal, throwing his arms out wide, gesturing at you to take a good look at the contents and smiling broadly. Inside there's stuff you recognise - poles, rods, nets, lines, hooks, waders, harpoons, reels, bait trays - and stuff you don't - crazy-looking doodads with springs and dials, big hairy ovals, bags of green seeds, assorted heavy machinery and wispy bits of fuzz. Some might have been used only once, some might be go-to tools for every day. One wall is a posterboard covered with lists; lists of half-acronyms , lists of instructions and heuristics  as long as your arm, lists of reminders, mindmaps with lists and sub-lists and sub-sub-lists bursting out of...

Sheet Happens  identified a potential bug observed in passing on a supermarket price label. A perennial issue for testers coming across something (arguably inappropriate text) while actually looking for something else (toilet roll) is how to decide (a) whether it's an issue at all and (b) if it is, whether this observation is the complete problem, an instance of a more general problem or the tip of a problem iceberg poking out above the surface of the stormy software seas. Or something else altogether, ideally without an annoying alliterative analogy . Oh yes, (c) what risk to associate with it while (d) expending an appropriate level of effort in any investigation. And (e) without yet knowing how serious the problem is. In some cases it'll be obvious. Your word processing application crashed and all your data was lost when you tried to change the text colour? No further thought required. In other cases it's less obvious. You noticed that instances o...

Is it a bug when you're offered the chance to see something similar to nothing and, when you take it, nothing is displayed? Or is it a bug to be offering the chance in the first place? Image:  http://flic.kr/p/5WvWMF

You don't have to look very hard to find definitions of quality. Some of them aren't very good ( boom! boom! ) and one with a lot of currency runs along these lines:  Quality is value to some person (who matters) in this case quoted from James Bach's Rapid Software Testing slides.  Here's the price ticket for toilet roll I saw in the supermarket this morning. It adds a new dimension to the phrase spending a penny :  Is there a quality issue here? I'm not sure whether I matter much to Tesco and it's arguable whether any value was lost by the use of this unfortunate abbreviation - I still bought some toilet paper - but i f your customers are laughing at you rather than with you, there's probably a quality issue somewhere. Image: winnond / FreeDigitalPhotos.net

Purely by chance I encountered three takes on perfection in the space of a couple of days. "Perfection", Run DMC said , "is quite essential". A laudable aspiration but, as their later career showed handsomely, hard to achieve. Compromise has a lot of very persuasive arguments. "This software is bug-free. It is perfect", Fast Company said of the Space Shuttle's control system , "as perfect as human beings have achieved ... the last three versions of the program - each 420,000 lines long - had just one error each." Skipping over how they knew that there was just one error , and why they didn't fix it, NASA had obvious reasons to strive for perfection, including the need to certify "that the software will not endanger the shuttle" before launch. Their approach was to be meticulous in the meta-work that supports software production as well as the production itself. But they still had errors. "We test", Weinberg s...

We all like a bargain and, if there was such a thing, we'd tuck into the free lunches with gusto too. But bargains needs to be viewed with caution and free lunch is usually only about half right - it probably is lunch. Automated testing is often thought to be a bargain or a free lunch but even limited experience will have shown you that it's not something for nothing and not even always cheap, especially in terms of maintenance. You should think carefully about whether regression tests are appropriate , what you hope to achieve, how, using what resources and attempt some level of cost/benefit analysis (using whatever data, estimates, gut feeling you have available) before you start on an automation project to try to maximise its value. But existing infrastructure can have unexploited value . For example, it is sometimes possible to double up regression test suites and test something other than what was originally intended. In my company we have both a traditional sof...

I saw a blue being from another dimension clawing its way through the ceiling the other day. If only. The building I work in is being redecorated and on the way to the canteen  I noticed that the painters had covered a smoke detector with a rubber glove. You don't need to be a health and safety officer to realise that this is not standard policy and potentially risky. But, paint fumes can set off smoke detectors and there were plenty of people around and there are many other smoke detectors in the building and the lack of other detectors covered with gloves suggested that decorators would be likely to remove it when they'd moved further down the building so I decided to do nothing about it. A clear spec violation, but mitigated by other factors. A reasonable short-term solution to an acute issue, but on the way home I still walked that way and checked that it had gone. You'll sometimes hear testers described as pedantic  and it's true that the detail an...

My QA team operates as a horizontal resource across the company. As you'd expect we predominantly provide our services to the dev team and most often that's for production work, although we do research and prototype projects with them too. But other functions, including documentation, marketing, consulting, operations and IT need test input on a regular basis too. Depending on who's asking, what they're asking for, and the kind of project they're working on, we'll ask for different levels of specificity in the input they give us.  For example: a one-time, ad hoc project to gather some performance data from a trial server might require no more than an email confirming the test envelope and environment and an idea of the intent of the experiment a three-month R&D project which delivers scripts to a partner might have a brief description of the aims, the high-level requirements and any areas which were not addressed a brand new software feature would ...