Hiccupps

To the context-driven tester there are no best practices, merely practices to be applied in contexts where they are appropriate on missions to which they contribute. Context-driven  is differentiated from context-aware and other similar-sounding terms by virtue of the total freedom it gives to (and requires of) the tester to approach each situation afresh, driving the choice of practice from the context and not vice versa. That's not to say that expertise and experience can't play a part - we'd hope that knowledge of the range of practices that could be applied will mean a more productive selection - merely that the organisation, strategy, reporting and so on of the project is considered part of the project and not a predetermined factor. All options being open, and context being the ultimate arbiter of the value of an activity to a project, it's interesting to wonder whether there is anything that is indisputably never appropriate. Perhaps burning our test mat...

It's a non-stop adrenalin headrush, my day. Meetings, test plans, reports, estimates, scheduling, reviews, interviews, kicking Dev, occasionally getting to do a bit of testing and, oh yes, condiments. Piccalilli is how this one started. I had it on my sandwiches and so we got talking and about spices and pickles and curried fish and later onto Indian food for breakfast. At which point I remembered how, as a young man, I'd had my parochial view of the opening meal of the day exploded on my first visit to the States by a friend I was staying with suggesting we get dim sum for breakfast. Dim sum for breakfast? Was that even a thing? Could you really eat Chinese food in the morning? No, but really ? Really really ? It appeared you could. And we did. And suddenly there was a world of opportunity beyond toast, fry-up, cereals, and a mug of strong tea. And it was available to me at the cost of merely opening my eyes and mind. How much of what we do do we do just because that...

Oh yes, this test manager knows how to make his team have fun  and my annual Christmas event has become legendary for the enjoyment level of its participants. Not least because I haven't yet repeated the cake testing task of that very first year. And if you'd like to join in the good times, here's the most recent instalment. After reading the latest management BS (that's Brilliant Science, y'know) book the QA manager mailed round the following to the product development team, convinced that in doing so he'd be making informed staff happy staff. He was also secretly beginning to use the third person to refer to himself in order to increase their level of respect for the QA manager. (That's psychology, that is.) The Dev Manager and QA Manager watched the team progress with Bugzilla statistics by using the XML API biweekly. They should be against bug fix data which does not provide quality insight.  Unfortunately, the QA manager hasn't spotted that ...

The Dev Manager has just sent round a rough timetable for a couple of upcoming projects. In it, for the first time, he's labelled two major phases as Dev-led and QA-led.  Now, I like to give some rein to my subconscious, to not necessarily put first impressions last and to let reflex guide reflection as much as the next tester. But when my initial reading is of two unsavoury-sounding blocks of time in which it's predicted that the software will be devilled and we'll discover that the team quailed , I start to get scared. Freeing your mind  to find those test ideas is fine, but when it, unbidden, throws you suggestions like these you should look carefully at your starting  mindset . Which is why I'm resolving not to eat an entire box of chocolates before trying to catch up on email from home in the holidays. For 12 months, at least. Happy New Year. Image:  http://flic.kr/p/65ZcHW

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

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

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

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

Short arms and deep pockets, that's me. Not that I'm a total skinflint (although I'll admit to thrifty) but I do like to try to get good value out everything that I do. Sometimes this can be planned and sometimes I get it by exploiting existing resource. With test automation, one way to get value is to write code that can do double duty - as a surgical tool , crafting data and scenarios for those very specific checks, and by simply multiplying it up, as a long stick to whack the application with. For example, I might think about writing test code to run these ways, as a second-order priority: parallel: Look to run multiple instances of the tests in parallel without them interfering with one another. Write data to unique locations per instance of the test to ensure this. Check that any data that the suites are dependent on is not altered in the execution of the suite. serial: Look to run the same suite multiple times against the same application in series, perhaps ...

You're reading a blog about testing (cheers!) I read them too, and in addition I try to find cheap ways to expose myself to material outside of the area as well. I'm looking for easy routes into content I might be interested in, that might be relevant to me or the technology I use or that my company develops, teach me something, provide a useful resource, make a connection, spark a new thought or sometimes just make me chuckle. An efficient and productive way to do this, for me, has been to find a few trusted guides, guides that report regularly, with reliable quality and the breadth that I'm looking for, who consistently point me at content I wouldn't otherwise have come across. Here's a couple: If I only read one blog in a day, it'll be Four Short Links . One of the posts this week led me to Ray Dallo's Principles  (PDF)  in which he enumerates a couple of hundred rules that he applies to life and, particularly, management. These are extracted from ...