Hiccupps

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

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