I seem to have amassed quite a lot of personal data; digital photographs, music, manuals and course-work all adds up to a few GB. Obviously, being fond of computing, I have implemented some mind bogglingly complex – albeit sporadic – backup strategies that I don’t really understand anymore. If a key piece of hardware were to fail I’d loose it all. As good an excuse as any then for a gadget impulse buy: a Network Attached Storage (NAS) device would save the day, so I bought one last weekend.

The problems started shortly after I switched it on.  I planned to use the device for backup purposes and to support sharing of data between systems, but I had not really thought this through. The device has a single ‘large’ disk, so no complex redundancy or performance configurations to worry about, how hard can it be?

My first plan was simple – mount the drive and start copying data. The drawbacks emerged pretty quickly;  many of the data structures are ‘live’ and subject to change.  Relying on manual inspection to identify updates is not really going to scale. Thankfully, the device manufacturer was one step ahead and had kindly bundled some software. Sadly, my PC, the software and I could not get along, the PC eventually got so upset that I sent it to the naughty step to reflect on its behaviour. OK, I need way of pairing file structures and establishing a relation so that changes would be synchronized from the live ‘master’ to backup ‘slave’ structures. At this point I remembered Jon mentioning SyncToy, which seems to address my needs. Any other tools or strategies worth reviewing?

The plan has been approved and the team is fully committed, great stuff! Hang on a minute, what if… How about… hmm, I need another test! While I’m at it, it would be good to tidy up a few loose ends and address a few concerns. I’ll fetch my cape, it’s time for some Hero Testing; it can only make things better.

Jon first introduced me to the term ‘Hero Testing’ and to some of the challenges this ‘I can do it quick & cheap’ approach may bring. For example:

• Employ different process
• Compromise test repeatability (manual v automated test execution)
• Lead to conflicting priorities
• Undermine the value of ‘core’ testing already in plan

If this stuff is important, shouldn’t it be evaluated, prioritized, owned and managed by the team from *their* backlog? Maybe this is what a true Testing Hero would do. Shame, I thought I made the cape look good.

Over the last few days, Ben and I (this is a joint post) have been trying to reach agreement on our understanding of risk. Ultimately we want to identify some new and effective methods to articulate the risks we may identify. The discussions were held at lunchtime, and OK, things got a bit silly. Nevertheless, we think there is a lesson to be learned somewhere in the example below. As such, please do add a comment if you can find one… We’ve also submitted this as an idea to the BBC’s Genius programme.

Objective: Introduce consolidated risk gauge to simplify the (human : machine) interface. The merits of a such a device are illustrated in the motor-car example below.

Modern cars have a bewildering array of dials and warning lights on a dashboard – but are they really necessary?

Consider just one of these dials: the speedometer. Does a driver really care what his absolute speed, based on centuries old units and the period of the Earth’s orbit around the sun, is? The answer is no: a driver simply wishes to know he will get to his destination without incident: be it crashing, getting a speeding ticket or missing his appointment.

It is therefore proposed that the speedometer is replaced by a risk dial – which interprets prevailing driving conditions, speed limits and navigation plans – e.g., using existing GPS technology – to calculate a risk metric. For example, if the driver exceeds a speed limit on a road, the risk gauge will go up, as speeding tickets are more likely. The driver can then elect to change his driving style to reduce this risk.

This proposal can be extended further. Consider the fuel gauge. The driver does not care about how much is in the tank per se – he simply wishes to understand the risk of running out of fuel on his journey. This dial could therefore be replaced too, by one measuring this risk. Note that the speedometer and fuel gauges have been simplified to share a common unit – one of risk – and hence can share the same gauge! By extension of the same argument, all dials and warning lights can be incorporated into one single dial of “consolidated risk” – thus addressing the complexity of modern car dashboards.

Missed a car service? Risk increases. Parked in a dodgy area? Risk increases. Such a metric would help encourage drivers to minimise risk, and even find alternate transport methods. This conveniently brings the proposal onto its zenith: consider how much more pleasant and minimalist a Jumbo Jet’s cockpit would be if there was just a single risk gauge.

I bought my wife a Nintendo DS for Christmas along with Dr. Kawashima’s Brain Training software. Since then, we have been competing to get our ‘brain ages’ as low as possible. Last night I was on a roll; I achieved a new player record in the Stroop test and personal bests for the word memory and connect maze tests. Having completed the three exercises, the software announced it was calculating my new brain age. For those unfamiliar with the software, a ‘brain age’ score of 20 is the best possible score.

After an impressive effort on my part, imagine my disappointment when I was informed my new ‘brain age’ was calculated to be 78 – more than double what it was before I started. What an outrage! I could not understand what I had done wrong, maybe I pressed some buttons while the system was calculating which had somehow affected the result. Either way, I was sure I was looking at a defect, and one I would not be able to recreate easily. While my wife saw the funny side, I was still trying to make sense of the situation. I clicked ‘next’ to get back to the system’s main menu page – at this point the system appears to persist the result and also presents some helpful tips, apparently I may have been tired when I did the tests which may explain my low score. Grrr!. Final step; I clicked OK to acknowledge completion of the test, but hang on a minute – there are some extra panels and I’m informed that there may have been a problem with the original calculation, my real score is in fact 23. At this point the animated character on the top screen (who I presume to be Dr Kawashima) is laughing as he tells me he had made a joke! As a tester, this is the first time software has made fun of me intentionally, I wonder if it will be the last?

Two to three years ago I bought a GPS equipped PDA phone. At the time, I justified the extra cost (to myself) as it could do a great deal more than just navigate me from A to B… Until a couple of months ago, it’s been used almost exclusively to run navigation software. By today’s standards, it is quite a bulky device and a little low specification, nevertheless – and much to Ben’s amusement – I’ve been making a lot more use of it recently. So what changed?

Well quite a lot, mobile data has come down in price – my mobile network provider supplied an unlimited data pack to my line for a few extra pounds a month, and there has been a great deal of progress in software designed for mobile devices; for example, many Google applications are now available > http://www.google.com/mobile/ < In addition, a much greater awareness of mobile devices has meant that many more web sites are readable with lower screen resolutions, or have mobile-aware content variations. Naturally I’ve tested this site and on my device it’s readable

So as well as navigating me from A to B, I can check email, review products and even compare prices while out shopping. The integrated GPS means I can perform location specific searches, so no matter where I am, I can find the products or services that I might need (no need to worry about Pickled Onions ever again). I’m already thinking about cool new applications I’d like to see, many of which could be great fun to test.

Did you test <insert_non-obvious_scenario_description_here> ?

If I received a pound for every time I have been confronted with this sort of question; I would have been at least two pounds better off last week. As a tester, it is easy to become defensive when these sorts of questions come up. In some ways this is good, it means we are passionate about what we do. In other ways, it can distract from the question itself. If the answer does happen to be no, then we must respond quickly – as a team – with a plan. This all sounds very tactical, dynamic and, err, agile. So, where do these questions come from? Why did scenario X not seem obvious to start with?

Most importantly, what has any of this got to do with Pickled Onions?

As we enter the Christmas period, I know I am going to have forgotten to buy something at the supermarket. It’s unlikely to be a complete disaster as I have developed two potential strategies to mitigate the risk:

1. Go to the supermarket this week and buy at least one of every item they sell, just in case I need it.
2. Make a list of all the things I think I will need to survive for a couple of days while the shops may be closed, and purchase only these items from the supermarket.

After a little bit of thought, I am not really liking option one, it does not seem a proportional response to the issue. Option two seems a much better idea, in fact, I have already had a draft list buddy checked and am ready to execute. Is there a risk of me forgetting something though? Yep – the question really is what am I going to do if faced with this situation? I’ve decided to try and keep calm, assess the situation and work out how best to correct it (with the resources available). Sound familiar?

Just for luck, I am going to purposely forget the Pickled Onions – I know the local shop is open on Boxing Day and I’ve already checked that they sell them.

Merry Christmas

Agile is a hot topic and is having a major influence on how we all think about software, both as developers and as consumers. The idea of capability arriving in huge waves is set to become a thing of the past, as we adopt techniques to stream capability in line with consumer expectation. I see this transition in two parts:

• Embrace new software delivery models.
  From requirements and user stories to iteration commitments and user deliverables.
• Retain flexibility as a core software design concern.
  Smart design is essential to ensure there is an architectural framework to support iterative delivery.

So what does this mean? Well, we know a lot about these things independently, the exciting part is in putting the concepts together. This got me thinking; we’ve spoken a lot about testing within an agile delivery model, but maybe we should consider testing to determine how Agile the deliverable is. One approach is for the SVT team to put in a request for an additional user story, or story variation, and measure the resulting impact in some way. For example, number of additional story points, estimated delivery date, or impact to the backlog etc.

(more…)

Myself and a colleague visited the University of Southampton‘s School of Electronics and Computer Science today. We were invited as guest lecturers to deliver a presentation on Enterprise Software Testing to a group of Software Engineering MSc Students. I was really impressed with the questions and discussion points from the students. There was a great deal of interest in the testing discipline with real enthusiasm for Agile practices, as a strategy to deliver capability, and not just code.

Maybe testing really is the new development!

Test bucket x, the Regression Test bucket – sound familiar?

Seriously, I’ve always wondered where the term comes from. Is it just a collective noun for tests, or was there really a time when the software industry quantified tests by the bucket-load?

In true Balderdash & Piffle style: Does anyone have a reference for its first usage?

Many people are using services like Twitter to let each other know what they are doing.

In recent years, portable digital measurement devices for blood pressure, temperature and heart rate have become common in the home. At the other end of the scale, technology has revolutionized even highly complex examinations; I found this article from 2002 http://news.bbc.co.uk/1/hi/2319249.stm. Most of us are already carrying sophisticated mobile devices capable of short and long range connectivity. Surely it is only a matter of time before all these things become smaller, consume less power and combine to give us a more accurate view of how we are feeling?