Skip to main content


Showing posts from January, 2013

Context Driven Answering

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

Breakfast Epiphanies

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

Further Reading

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

Happy New Fear

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: