Hiccupps

Around the time that the  Social Tester  was publishing his  36 Days of Web Testing  e-book I happened to be looking at some cross-browser issues. For reasons that I no longer recall - hey, it was exploratory  and that means you don't need to know what you're doing or why, right ? - I surfed over to Google's shopping site to find a surprisingly frank assessment of the state of internet consumerism, courtesy of IE6's text zoom, above. As Voltaire said : the progress of rivers to the ocean is not so rapid as that of man to error. Which keeps us in a job, at least.

When I put my slippers in the wash the other night I didn't anticipate that I would need to spend the best part of an hour cleaning what looked like sawdust out of the numerous crevices and crannies that make up the insides of our tumble dryer , and then throw the slippers away. But unexpected consequences are not today's concern. When the shower packed up I thought it'd be easy to replace. I should have known by that point that the previous owners of our house never did anything with future maintenance in mind. But maintainability is not today's concern. When I chose a cheap bathroom appliance and bought budget footwear I knew I was taking a calculated risk. Immediate savings, when made with open eyes, can be a positive option. However, low costs today can also mean increased costs tomorrow, and those costs, and customer reaction to them, might not be predictable. Which is today's concern. I bought the shower because the it was the only one I could...

We all do it. We find an issue in passing and report it quickly and it gets triaged and it's P3 and no-one dies and that's that. We've all done it. We've found an issue in passing and reported it quickly and it got triaged and it was P3 and no-one died and that was that. Until the underlying problem, of which we'd only observed a relatively benign symptom, burst out somewhere else in the product and turned out to be P1 critical. Late in the project, natch. We all know it. We can't test everything, even if we wanted to. But we're naturally cautious and we'd always prefer to, when we see the P3 in passing, wonder whether there's a cheap check to give some confirmation of our assessment. And if there is, we can use our testing instinct to decide whether to run it. We all know it doesn't work like this every time: on a system I was looking at once, I noticed that a particular account was being rejected on login. The cause of the rejection w...

The other day, a developer of my acquaintance said "well, a click is just a click." To be fair, in that discussion in that context in the limited way in which he meant it in the environment under consideration for the purpose we had in mind on that particular occasion he was probably sufficiently close to something not too objectionable that I didn't bother to raise a red flag. Didn't bother and (a) by the time I'd thought all that the conversation had moved on and, more importantly, (b) I've been around long enough and burned myself enough times that I've finally realised that nobody likes a smart-arse . Me included. Especially when I realise it's me. (Have the same problem? Let it all out in a blog !) But the notion stuck with me: is a mouse click ever really just a click ? If we consider a mouse click to be an atomic action then a single click exists as an entity in its own right and distinct from other clicks. Distinct, yes, but it cou...

If you can keep your head when all about you customers and colleagues are losing theirs and blaming it on you then, with apologies to Kipling, you'll stand a decent chance of being comfortable in tech support. I often think about the crossover between support and test and I've recruited people with support experience to work as testers more than once. I've also  noted before that I have my test team watch all support traffic and it's common in many companies for testers to be brought in for advice and to test fixes for issues that start as support tickets. But being the owner of a hard-to-reproduce high-value support issue, without a buffer between you and the customer who is experiencing the pain, being the one responsible for working out what the issue is and identifying a workaround adds piquancy and urgency and pressure to the diagnostic task. This kind of thing is often more constrained than the average test mission. In this scenario you know that there...

The older I get the miser I become. By which I mean that I more jealously guard the resource that I have and do my best to avoid spending it where I don't want or need to. Amongst my pet peeves (and I've collected a lot over the years) is the way in which unresolved upstream decision points can impact downstream. That's not to say I think all choices have to be made instantly (although there is theory on efficient decision-making e.g.  satisficing ) but I do think that clarity is imperative. When I'm waiting for a decision to license some further action on my part I don't want to have to expend energy and resources keeping possible options - and their dependencies - open, keeping resource on hold ready for an always impending decision - and perhaps compromising my other missions - and remembering to look up periodically to see whether the decision has arrived. When I'm waiting for a decision, I want the decision maker to be open about (a) what the chose...

There are times when getting a stakeholder to agree that there's a problem is not easy. Then there are times where, having found a stakeholder who accepts the existence of an issue, you have difficulty persuading them that it's important to find a solution to it now.  And then there are those times when, having found a sponsor who both recognises and wants to relieve the particular headache you've identified, they can't get past some narrow view of it - either in terms of the problem space or the complexity of the necessary solution or both - and you end up with incomplete fixes that might focus on a particular case or which will fail in logic for some subset of cases and perhaps even compromise the integrity of the implementation to boot. Limited-overs cricket found itself in this position a few years ago. In this format of cricket the two teams each bat for one innings to try to score runs given a set number of balls bowled to them and within a set number of wic...

Now and then I have days where I seem to be a mistake magnet. When I seem to be tripping over issues while getting repro for the unexpected behaviours observed during diagnosis of side-effect of a problem I wasn't even trying to provoke. Days where, when I close my eyes for a minute, I'm suddenly in the back of an open-top limousine cruising down Defect Drive with bug reports showering me like ticker tape. On those days, it's tempting to think about some rose-tinted previous release where "everything" "worked" or the requirements weren't attached to a bungee rope or the interested parties had a common lexicon or the team wasn't spelled tiiiiim or whatever. But that's just a waste of time and mental energy, and likely to lead to ennui and sourness. (OK, extra ennui and sourness.) When I find myself at the top of that slippery slope, I remember the wise words of Mark E. Smith in It's A Curse : "Balti and Vimto and Spangles ...

Gut instinct. If you're a working tester you probably use it, oooh, roughly, I'd say, well, on average, y'know, in a manner of speaking, perhaps, erm, just about all the time . Feel, or the intuition bred of experience, is rolled into everything you do. In every decision you make, it's playing a part. Every time you speculatively poke the system this way or that, or don't poke it, or poke it twice quickly, or with a series of sticks with lengths in powers of two, or with a null stick, or a log, a twig, a stake or a  bâton , every one of those, and pretty much everything else, in some way, involves your gut. Which is why you'd better feed it. And what does it like to eat?  Data . Data: gather some, test some, generate some, analyse some, learn some.Yum, yum. Image:  http://flic.kr/p/4Lxvsg .  With thanks to  The Social Tester . 

The Dev Manager has a phrase that he uses from time to time when he wants to take some shaky code, perhaps lashed together for speed or an acute need, or prototyped as a script, or created as a demo, and bring it into the product. Let's make an honest woman out of that, he'll say. The novelty of the unexpected anthropomorphism with a side of sexism soon wears off, although some of those kinds of projects can feel a lot like organising a wedding - expense, stress, unrealistic expectations, Mothers-in-law. (Go on, tell me you've never had a Ma-in-law on your project.) What I've taken from it is the idea that I should always consider coding my quick-and-dirty investigative scripts with a view to making them part of a regression suite later. I don't go that way every time. For instance, when I know it's a stricly one-shot deal like processing log files to diagnose an issue, I'll use whatever is fastest. And when I can get what I need inside an existin...