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

Network, what network? That’s the mindset change you go through with the new breed of Web services.

Forget that you’re doing HTTP requests to a service running in Project Zero. If you want to call it from a command line you do this:

wget http://<ipaddress>:8080/services/app.groovy

You then realize that this service is available to anyone and from anywhere (assuming your pc is on a network), and you can run it from a command line, application code, or even a browser. Sweet.

Nadolig Llawen!

Following on from Jon’s previous post on testing quotes:

“The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong, it usually turns out to be impossible to get at or repair.” – Douglas Adams

“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” – Rich Cook

Merry Christmas to anyone who’s actually reading this, and even the people who aren’t.

After weeks of bullying from my pod mate Russell, followed by a great  two pronged sales job from Scott and Dan, I thought I should at least have a look at the new version  of Ubuntu.

So armed with Russ’ 8.10 CD I gave it a whirl, booting from the CD without installing it properly. I tried it first on my old T42 Thinkpad and it was up and running without any intervention. OK, I’m partially impressed.

Now the real test, would it cope with my 5 year old Evesham desktop?

Simple – it went on a treat, recognised all the bits (external harddrive, wired internet) – I’m now very impressed.

Plan is to buy a Mac in the new year and then turn the Windows box into Ubuntu. My daughter is not impressed as Linux doesn’t have MSN (at least that’s what I’m telling her – and will keep it like that as I think MSN has been responsible for 90% of the viruses on our box)

So count me as a new Ubuntu fan…..

Happy Christmas to both our reader. See you all again in 2009

In my previous post, I mentioned I’ve started writing some scripts in Groovy. All was well until I wanted to persist data between tasks using JSON. The plan is to have a cron job that extracts data from a source and encodes it in a JSON file. I’ll then have a Project Zero application providing a service which when invoked would load the JSON data and return a summary of the data.

The good news… Project Zero has excellent built in JSON support through the zero.json.Json.decode and zero.json.Json.encode methods – which are amazing powerful and simple.

The bad news… When it comes to command line Groovy from groovy.codehaus.org, there doesn’t appear to be any built in support – bah!

So, using Groovy’s ability to use work with standard Java classes I trawled around for a Java JSON implementation. There’s a bunch listed on the www.json.org page, but having looked at a few none of them appear to be as simple as the Project Zero version.

The one that stood out was json-lib.sourceforge.net, but the number of dependencies it has on jars that have to be downloaded from external projects is mind boggling.

I tried importing the Project Zero jar files into my project to see if I could use the libraries they supply. But I soon discovered that it relies heavily on a running Project Zero environment. So no luck there either.

Surely it can’t be this difficult to have some simple JSON utility functions in Groovy. Right now I’m contemplating writing my own.

I’ve just been reading Mike Cohn’s ‘User Stories Applied’ for agile software development.  Excellent book – well worth a read and it’s helped me clarify my understanding of what user stories are, how to use them and how they relate to use cases.

I’ve pulled out some sound-bites that I liked:

“Story cards are the reminder to talk!”

“Just because users have the problem does not mean they are uniquely qualified to propose its solution”

Also liked his analogy for gathering requirements, where he suggests its like fishing with nets. We start with a net with big holes so we only catch the really big requirements, then over time the holes in the net get smaller. Traditional requirement gathering uses a very fine mesh net that attempts to catch everything first time round. Usually sinking the boat (I made up that bit – hope you don’t mind Mike).

I’d recommend this book to anyone involved in agile projects. There’s some good stuff in there.

Now I know you’re going to say ‘Jon, you haven’t mentioned anything about test in this post!’. Well don’t panic, I’m going to do a seperate post on my thoughts around how it releates to testing, especially system test.

Here’s a tag cloud (created by Wordle) of Wikipedia’s article on software testing:

I removed the words “software” and “testing”, as they swamped the picture.  The results are mostly what I guess I expected, though “agile” doesn’t appear very often.

How often have you heard, “We have to fix the low severity defects now, or they will never get fixed!” – even when you know some high priority core functionality is still not working?

Stepping back, fixing low severity defects may not seem in line with the agile approach, when your backlog is tackled in priority order.  However, I like to think of defects as like droplets of oil: they aggregate, and collectively they can form a much bigger droplet and a more serious problem. This seems particularly true of consumability defects.

In this case, resolving low severity defects collectively is indeed a high priority task. But there are challenges:

• How can we track this aggregation – and hence prioritise defect resolution? Informally, through impact on user stories? Or through modifying defect tracking tools to recognise that defects are not necessarily isolated issues, but instead can mutually reinforce?
• Is it an “all or nothing” approach to resolving the aggregated defects, or should you pick off individual ones to shunt the overall problem back down the priority stack?
• Finally, I have interchanged “severity” and “priority” in this post. Purists will argue these are separate attributes for a defect – but I think this post demonstrates how they can be strongly correlated.

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…)

I went to a presentation given by Graham Spittle today, and he used the analogy that watching salesmen was a lot like watching five-year-olds playing football – they all run to where the action currently is, instead of staying where they might be needed very shortly.  I like this analogy, and was thinking how it applied to software development teams.  You could say that the developers are the strikers, and the testers are the defenders.  Most of the time, it might be useful for everyone to stick to their positions, and not just run where the ball is.  Sometimes, however, you need everybody in the same half, because a.) you really need a goal; or b.) you really need to stop one.  It’s all one team though, and its a given that you also need midfielders who do a bit of both things.

Other sporting analogies will be welcomed.  Hit the comments (out of the park; for six; etc.)