Skip to main content


Showing posts from December, 2012

A Cross/Tick

Testing's just a matter of following the steps, they say. It's as binary as a no/yes or a fail/pass. Anyone can do it. That's obvious isn't it? Well, perhaps. But they'll still ask: why do bugs suddenly appear, every time you are near? It's close to the question Karen Carpenter posed and easier to answer: bugs appear because people write the software and manage the processes used to produce the software. And why when you're near and not others? Because, like all good testers, what you follow is your nose, and you know the importance of things like Notes, of your test ideas which you review regularly before, during and after testing Observations, constantly, of the AUT, the users, the developers, the test team, their interactions and assertions and ambguities and the rest Systematicity, for those times when rigour is important Havoc, for those times when you just need to provoke a reaction Interest, in the product, its use, the domain, the techno

Working on the Moon

Ever feel like you're being asked for the moon on a stick? Harrison Schmitt pretty much was. The geologist for the Apollo 17 moon landing in December 1972 was interviewed recently for the BBC World Service on the 40th anniversary of the mission. I loved the interview, and I particularly enjoyed the parallels between working on the moon and testing on Earth. Although obviously the moon has less gravity and no oxygen. And it's much further to the vending machine from there. Here's a couple of extracts. On the perennial square-circling problem: You never have enough time ... The pressure I felt as a professional field geologist on the moon was that of getting as much good information as I possibly could knowing that almost certainly, at least in the foreseeable future, I would not get to go back to that field area ... On the other hand there was a professional joy of moving to each new station and having the challenge of deciding what was the most productive thing one c

The Riddle of Testing

It's frustrating when you receive materials into test that are quickly found to be unfit for purpose. Frustrating and wasteful of the time of everybody concerned. Frustrating, wasteful of time and almost certainly destined to cause bad feeling somewhere along the line. Frustrating, wasteful of time, destined to cause bad feeling and, well, I'm sure you can fill in the rest from your own experience. The Riddle of Testing is not why does this keep happening?  (although that could easily be the Second Riddle of Testing  and its answers are many and varied). No, the Riddle of Testing is a  coarse filter you knocked up quickly out of old chicken wire and a crate last time around, and you keep in your shed . You'll surely have a few of them, in different shapes and sizes, and when new material arrives you chuck it into one and shake it - sometimes by hand but sometimes you'll have jury-rigged an old motor to wobble the thing for you. If there's any lumps left on t

Setting the Quality

It was a sentence that came without much conscious thought at the end of another post  that's had me thinking - yeah, consciously - for a couple of weeks. While I was reflecting on my own view of and reaction to the quality of some stuff I'd bought, and which had failed, and trying to project this onto my day job, I asked: What qualities constitute quality for [the people concerned]? At its core this was simply restating Weinberg's elegant and efficient definition of quality as value to some person - often extended to some person that matters - but I found myself going back to the phrase, chewing it over and wondering whether the idea of breaking out the singular value into the plural qualities was a useful addition: Quality is the qualities that provide value to some person. After consideration, I think that what I like about it is that it draws out explicitly the point that the quality of a piece of software is intrinsically made up of a set of its, usually