Hiccupps

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 ...