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