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

If you are familiar with the BBC’s Little Britain comedy series, you will have probably seen David Walliams performing a Mr Mann sketch. Mr Mann is a very demanding customer, he has ludicrously specific requirements and no ability to compromise. Much to the annoyance of shop keeper Roy, Mr Mann is prepared to simply ‘wait’ – presumably forever – until he gets what he wants.

As Software Engineers, the very nature of our job means that we work with very specific sets of requirements. As software testers we have a tendency to blend these together into complex test scenarios with the sorts of prerequisites and demands that would make even the likes of Mr Mann seem easy to please. Sadly, when we don’t get all the pieces we need in one go, the temptation to wait for the rest of them to arrive can become overwhelming.

It is important not to forget that each and every test scenario is designed for good reason and will no doubt reveal something fundamental about the item under test. However, we must keep this end goal in context. If we can’t proceed with Scenario S as is, we must challenge ourselves and re-examine our test tactics to keep things moving. This is vital if we are to keep lowering the risk to the parent project.

OK, so this approach won’t always pay off, it’s a bit like trying to avoid a traffic jam – sometimes you just can’t. It is also important that we don’t become engrossed with spinning-plates or distracted with investigating the trivial low-value areas.

Sometime ago I had a track driving lesson, the instructor told me “Whatever you’re doing, it isn’t working. Try something different – anything will do!”. He certainly had a way of emphasizing this message, and I didn’t much appreciate the feedback at the time, but maybe he had a valuable point?