Hiccupps

One of my favourite posts of all time, on one of my favourite blogs of all time, is Customer-Driven Knob  at Abakas . Its message: don't expose a control to the customer unless (a) it is motivated by a customer requirement rather than an implementation detail or flaw and (b) it is clear that the customer could make an informed choice about its use. The Dev Manager has been alerted to its existence on more than one occasion and this week he showed that he does occasionally listen to what I say by pointing me at Checkboxes that kill your product  by Alex Limi, who does Product Design Strategy at Mozilla . It starts: Firefox ships with many options that will render the browser unusable to most people, right in the main settings ui. and it ends What about the product that you are building? Is it time to take a fresh look at what kind of options you include?  I think we all know the answer to that. Image:  http://flic.kr/p/7bHKB7

A good report is knowledge shared clearly, correctly, comprehensively, consistently and concisely . As testers, we spend a lot of our time dealing with reports that lack some or all of those and it should be important to us professionally, and also in our selfish interests, to maximise the signal/noise ratio of our own writing. But it's easy to forget to think about it and even when reviewing reports before submission it's easy to not notice issues, given the full context of the situation is usually uppermost in the mind at the time. Here's a few of the common traps I've fallen (and fall) into: "In a meeting it was decided that we should ..." Meeting with who?  Were there alternatives, are there minutes to link to? "It all goes wrong", "It just doesn't work" In what way, what do you see, why is that unhelpful? "It is not possible to ..." Are you sure? Just what did you do to try to make it happen? "We observe A, ...

Flicking through a blog the other day, I was impressed by the author's insight, the breadth of material, his interest in the semantics, theory and practice of testing. I chuckled at the sense of humour and I adored the modesty and humility he displayed. And then I noticed that of the seven images I could see on the blog's front page three ( 1 , 2 , 3 ) were record sleeves. I was distracted by this, my train of thought moving away from the content and onto the relevance of my observation and speculation about the author's interests: is it significant that there are so many record sleeves here? Will I have a look at the archives to see what images were used there? Is this chap a record collector? Are these records personal favourites? Why is he using images on every post, anyway? What value do they add? What was this blog about, again? And then I remembered that it was my blog  and that I had started off scanning for typos. The signal I was giving out, from an aggr...

I messed up this week. And the week before. And the week before that, the one prior, most weeks last month, most months this year, most weeks in most months most years ... Basically all the time. And I do it on purpose because it puts me in a position to find bugs that I wouldn't otherwise come across. I'm not talking about deliberately entering junk content into applications, configurations, data and the like. I'm not talking about random clicking in a system under test or trying to engineer corner cases by artificially restricting disk space or RAM or some other resource or any other of those legitimate test vectors that benefit from experimenting with the available parameters. I'm talking about sympathetic testing - or even just plain usage - in an untidy way to try to increase my test coverage in passing. Here's some examples: If your application is in the cloud, maybe don't log out of it when you've finished your current task. Look for odd effe...

Since reading the  last issue of The Testing Planet  on leadership I seem to have come across more blogs than usual talking about how to be a great leader, manager, boss or whatever, for instance: Evaluate Character AND Performance 9 Leadership Tips Anyone Can Use Immediately 10 Things Really Amazing Bosses Do This is why you need to learn how to talk to developers I'm interested in improving as a manager, leader, boss and (especially) whatever and this kind of material can provide inspiration. I'm also keen on personal reflection and introspection as a way of identifying areas to work on and over the years I've come to realise that a couple of principles trump most other things for me: clear : I will do my best to be absolutely clear about what I think, what my response to any request is, what my motivation for any particular approach is, what I will commit to do (or not do) about some problem and so on. I will encourage and answer any question on any work-rel...

Rands recently wrote a great blog post on the way that companies project unrealistic expectations onto new employees, are disappointed when they don't achieve them and then then come to know the new hire further down the line. This trajectory is a familiar one and applies not just to employees but also to many aspects of software development including whole products and features within an application. When a feature description is still relatively broad, unexplored and underdeveloped it will naturally be understood in a variety of ways by different people. Equally naturally, the ways in which it is understood and the depth of the understanding will correspond largely to the particular interests of those people. The sharp end of those interests tend to be in issues that the idea can resolve and the feature can often look like Lilly the Pink  with respect to them. High-level apparent solutions to high-value problems inflate the attraction of the feature. As the feature move...

I had more or less the same conversation with  Michael Bolton and Pradeep Soundararajan recently and both started with a statement about tool use and automation: Pradeep : @testertested : I help testers re-think what they mean by automation. I help them see usage of any tool as automation @qahiccupps : any tool? A pen and paper is a testing tool.. @testertested: Yes, it does help you make notes, that you refer to for re-exploring the app. Do you see it that way? @qahiccupps: Yes, a tool but not automation which, for me, requires action w/o my participation. Another: I can use Excel manually (enter formula into every cell) or automated (macros). Tool != automation. @testertested: So, what about annotation pens and stuff ? @qahiccupps: Used directly it's manual. Without me (directly) controlling, automation. Not sure if we're missing each other's point? Michael : @michaelbolton : Test automation is any use of tools to support testing . @qahiccupps: pen and...

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