Hiccupps

You can learn a lot from your kids, and not just how much you hate High School Musical 1, 2 and friggin' 3. I play a game with my daughters (Hazel aged 5, Emma aged 3) that we call Follow the Leader, dreamed up one rainy afternoon. It's like the traditional game except that you play it on paper: one person draws something and the others have to copy along. When the pictures are finished we line them up and see how they compare. Here's three of our efforts from one recent game. In order below, Emma was the leader, Hazel sat next to her and I was on the other side of the table (click to enlarge the images): Emma likes to work bottom-up, incrementally building the big picture and often jumping from detail to detail without giving much, if any, indication of how they interconnect and which are the most significant. This is fine for her - she's a late-binding kind of leader - but it makes it harder for the followers to be sure they're building up the right...

The joke was funny enough, but you've gotta love the punchline Twitter produced when I tried to add the tweet to my Favorites (click to enlarge): Image:  http://flic.kr/p/4ZSZPc

Musing on the recent call for articles on skills for The Testing Planet I got to thinking about the difference between skills and traits. The former is sometimes described as something learned and the latter as something innate. A quick web search throws up plenty of examples of this (e.g. 1 and 2 ) but that explanation is too glib for me, particularly the second of those articles which advises "If you’re having trouble separating skills and traits, think in terms of action verbs for skills, such as: training, implementing, leading, promoting, developing, presenting, organizing, planning". Questioning? I've ended up in software testing and (on the good days) I like to think that I've got skills appropriate to the role. With the benefit of confirmation bias hindsight I can think of things in my boyhood that suggest I've always been the kind of person my colleagues think I am. Weinberg, amongst other things , challenges himself and us to find at least thr...

One of the challenges of testing is coming up with new things to try. Sure, there are common software anti-patterns  to look for, and probably specific recurring kinds of issues in your particular product, that can form part of a test strategy. But, particularly as your application matures, you're more likely to find higher value problems with novelty than simple repetition. During a recent round of exploratory testing we spent some time brainstorming test ideas. As a driver for productivity, spontaneity and creativity we tried something we hadn't done before: a strict two minutes on each of the CRUSSPIC STMPL letters with every suggestion that was shouted out noted straight down on the whiteboard without discussion or elaboration. After a brief review and some aggregation and refinement, we generated a bunch of session charters which included some new general approaches. Here's a couple: tool-driven sessions: take a tool we'd never used but thought might be us...

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