Thursday, 30 July 2009

A practical example of lean principles

My hobby is sport climbing and myself and a friend spend a couple of hours a week down at our local climbing gym climbing sport routes. Now we are both reasonably fit men, well into the age that professional sportsmen are described as 'veteran' but nevertheless not in bad shape. We are also competent climbers, by no means excellent but we can generally climb a 6B grade if we push ourselves. While at the centre I often watch the better climbers to appreciate their technique and try to pick up some tips. It is not uncommon that these expert climbers that I find myself most in awe of are children and teenagers. They seem to effortlessly scale routes that my partner and myself wouldn't even consider attempting. Now I have the advantage of strength, I hope that I have more of the wisdom that comes with age, and I have certainly been climbing for longer, so how is it that these youngsters can make it look so easy? The answer is that they are leaner, both in their physique and their approach, which helps them to achieve their goal more efficiently than I can. It is possible to identify a number of factors for success in the sport that translate well into lessons for software development and testing:

Only apply effort that helps you to achieve your goal

My temptation when climbing, as with most men, is to 'brute force' with your arms. In this way I often apply excess energy which is lost on the wall, when a touch more finesse to apply the effort in a more focussed manner would achieve the same result using less energy. If we can identify the activities and actions that contribute specifically to achieving our goal and perform only these actions then we will achieve success more quickly and with resources to spare.

Only carry the weight that is needed to help you achieve your goal

Although not fat, I am bulky when compared to a 12 year old, and this excess weight can be a cause of drag. Similarly if we have bulky processes, excessive documentation to maintain and too much manual testing then this can limit our progress and use up valuable energy.

Do not fear committing yourself with just what you need to progress

One of the real skills in climbing is knowing how much of a purchase on the wall you need in order to perform a move. The mediocre climber such as myself will not trust in his ability to make a move with limited hand/foothold and so will waste energy finding unnecessary reassurance, when the better climber will move when they have just enough purchase to progress. Similarly a the development/test team can learn that it is possible to commit to work and progress without technical specifications, design documents and the like and just start with a one-line story and a plan to discuss it, then this will free us up to embrace agile/lean processes without the false reassurance that those documents provided.

I'm off down the climbing centre again on Thursday, and will hope to practise what I preach. As with all things, it is easy to talk about the best way of doing something, however whether I can apply these principles when I'm halfway up a wall and my legs have just started shaking like Elvis' is another matter ....

Sunday, 19 July 2009

A Sisyphean Task?

I thought that as my first foray into blogging I would elaborate on the title and purpose of my blog. If you are unfamiliar with Greek Myths, Sisyphus was a king who was punished with the task of rolling a boulder repeatedly up a hill only to watch it roll back down. A Sisyphean task is one that can be seen as repetitous and unavailing.

A somewhat depressing title for a blog, you may think, however for I think that many peoples' perception of the task of Software Testing is not too far removed from this. If we equate the height of the boulder to be the confidence in the piece of software under test (SUT) then the task of testing the software could very much be seen as a Sisyphean Task. We execute tests to push up the confidence in a piece of software, only for new functional and environmental changes to be introduced that cause this confidence to roll back down. We then have to push the boulder back up, negotiating all of the newly introduced obstacles whilst at the same time covering the old ground of existing functionality to ensure that no new problems have been introduced.

Where then, lies the appeal? If testing is truly a Sisyphean task then how can it appeal as a career to intelligent and creative minds? I think that the answer can lie in how the task is perceived. If we amend our viewpoint of Sisyphus' labour from a manual task to an engineering one, then the challenge becomes significantly more interesting. How can we speed up the process of moving the boulder up the hill? What solutions can we engineer to reduce the manual effort required to increase our confidence in the system. What are the most efficient ways of increasing confidence without the need for repeated effort? How can we ensure that these solutions are flexible enough to cope with the changing landscape in which they are required to work? It is in creating the most elegant, flexible and efficient solutions to performing the Sisyphean tasks that define the work of the softare tester that we find one of the most sastisfying challenges for the increasing number of creative minds that are choosing software testing as their area of expertise.