Hiccupps

As good testers we obviously try to give our bug reports meaningful titles that encapsulate the kernel of the issue described in the ticket as clearly as possible. Occasionally we want to make the bug stand out from the background , keep an issue at the forefront of everbody's mind, emphasise the strength of feeling we have about some problem or just make a developer smile. One way to do this is to inject a bit of humour into the title and these are a few of my favourites from our bug tracker: We use "we" for "us" : product documentation is inconsistent in how it refers to the company Do you know who I am? : a login dialog both refers to a user by name and doesn't recognise them Hash clash in file-based cache : collisions in a hashing algorithm  Caret does not stick : the cursor in a text box disappears Decomplexicate the complicated message's message complicator : a routine for aggregating error messages combines unhelpful terminology in a ha...

Functional fixedness is a concept that describes how a person can be restricted in their view of an object or problem. Or a piece of software. Essentially, if you know or are told that something is expected to be used in a particular way, or if you've thought of one way to do something already, you can find it hard to think of alternatives. You're fixed in your view of some functionality. A classic experiment in the area is to try to  think of uses for a house brick . In our line of work, this can manifest in places such as spec reviews, in implementation, in test coverage, in fact pretty much anywhere you may want to generate a set of ideas for a topic or area you already have some familiarity with. That last phrase is important. In a recent episode of  Horizon , Simone Ritter described how it's possible to boost creativity by putting the thinker into a scenario that violates usual practice or thought process. In her experiments, something as trivial as making a sa...

My interpretation of a tester's remit is a broad one. My view of where a tester should look for ways to improve the product is wide. The software itself is key but even within software we shouldn't limit ourselves to functional testing against specification or standards or convention; we should raise performance issues, usability issues, style issues, language errors... We can request changes to the way the product behaves, to remove pieces of functionality that have lost their utility, to merge pieces of functionality that perform similar roles, to consider new functionality or utilise new or better libraries.. We can constructively criticise process or lack of process, suggest ideas for improving  the product for internal customers such as support, ways in which our support ticketing system could be more efficient, bottlenecks in the way we develop software, reasons that projects overrun, ideas about why bugs weren't found in testing... I could go on (and believe...

One of the joys of working in a team is the interactions with other people. As testers we are more often than not part of a team, even if sometimes that team is simply us and a developer (I stopped believing in the code fairy quite early on). One of the biggest time sinks of working in a team is the interactions with other people. I've written before about how I strive for conciseness, completeness, consistency, clarity and correctness in written communications and I try to do the same verbally too. If you can keep your meetings tight, people will thank you for it, will attend more often and contribute more effectively. Agendas help a lot. Benevolent dictatorship helps more. Not saying stuff for the sake of it, or repeating yourself or - worse - other people or - worse still - what other people said in the same meeting  helps a great deal. The 5 Cs for writing can and do apply to conversations but because I'm not typically delivering a lengthy monologue in those situa...

This is my gran's recipe for bread pudding. I wrote it down on a piece of green continuous printer paper  (back when that stuff was common) and I've made it countless times in the years since, as the greasy fingerprints, tea cup rings and splashes of dried pudding attest. It's lovely with a cuppa, robot mug optional. Ingredients 12oz stale bread 3oz currants 3oz raisins 4.5oz sugar nutmeg lemon rind 3oz margarine 1 egg cold tea  Instructions Soak the bread in the cold tea for a couple of hours. Squeeze out the excess tea. Mix all the ingredients well. Pour into a greased pie dish. Bake for 1-1.5 hrs at 180 C. I made it at the weekend with my 5-year-old daughter. As usual it wasn't quite the same as all the other bread puddings , but it was still clearly a bread pudding in both form and taste and, if the recipe is a user story or a spec, our implementation of it passed UAT with flying colours. But we didn't really follow the "spec" ...

We are similar in some ways and dissimilar in others. Even where we share characteristics, I will see things differently to you. Your take on reality is not the same as the next person. And they don't look at things in the way we do either. I was reminded of this while reading an article in the paper at the weekend : "In language," [the interviewee] says, "you think that a word is a thing. When you say stone , it's a stone, but when you know that it's piedra in Spanish, it means that language is not linked absolutely to reality." It was a lesson in life: consider the alternative. To the average monoglot, in this view, there probably is no alternative: the label and the object are intrinsically linked. To the average polyglot, there's a level of abstraction away from the object that gives some insight into commonalities and differences across the various frames of reference. You and your users see the same software. They probably experience i...

We use a mixture of approaches to testing at our place and in some circumstances this includes scripted cases which we manage in  Testopia , an extension for Bugzilla . Yesterday, because the action that failed so spectacularly was non-essential to me, I enjoyed Testopia's combination (pictured above; click for full size) of Z-axis violation, inappropriately large and inappropriate content wedged into a dialog, unexpected text box in the same dialog, likely lack of validation of the server's response, and the tasteful use of colour and font size to reinforce the nature of an internal error while at the same time obscuring potentially useful debug information by truncating it. This one is glaringly obvious, but it's as well to remember from time to time that the tools we use to test are themselves applications with their own bugs . How well have the external tools you use been tested? How extensive is the coverage of that supposedly standards-compliant open-source l...

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