Skip to main content

Posts

Showing posts from March, 2012

Going with the Flow

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

Corner (of the Eye) Cases

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

Lessons Learned in Rapid Software Testing

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

To Bug or not to Bug?

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 of some object in