Test planning, so you want more time!

If you’ve been involved in test planning you’ve no doubt encountered the questions, “Can you do it in less time?, What if you did test like this, is there a quicker way? what if we get some of the business to do all the testing for you?”

There are more questions like these as well, they all tell us something about the questioner, about how they are thinking, what matters to them, and they give you options to talk to them about. Testing can normally be done quicker, it’s just a question of do you want the risk that is associated with doing so?

So we are near the end of a change of software in part of the warehouse, there’s loads of config, some development, and a tonne of business understanding to gain. This is the second time we’ve tried this, the first time the business wasn’t at all happy with the config, so it was back to the drawing board for the project team. So now we are near the end and there won’t be a third chance so it has to go in, and be right. I haven’t been on this project, as you may have read in other posts my focus has been on the ERP we are putting in. However they are near the end and are worried it’s not going to happen, so I’ve been moved back to this one and basically asked to make the testing fit in the short time that is left. It’s all driven by the overall project budget, basically getting more money is going to be hard, so I have to look at what’s left and work out what not to do.

It’s all about risk here, the work is largely split into to pieces, the interface work, moving data via a bus between the new system and existing systems, and the new warehouse system itself. The interfaces have to work, but we control most of how the data arrives, so we can do a reasonable job on that without having to do to deep a piece of testing, and the warehouse system has had people all over it for months, there are in fact a group currently signing off business processes and user stories against what the set up in the system is, so they will have a good chance of seeing if the basic flows don’t work. So my sales pitch is more focus on the interfaces, less on the new piece. The focus of testing on the new warehouse piece would be the edge cases that the team signing off the basic flows are unlikely to go near.

Yes the state of what’s going on is far from ideal, but it rarely is, so we work with what we have, I’m often reminded of the scene in 13th warrior where they are on the boat and the northmen are laughing at the storm, show no fear, laugh at danger. There’s no point bemoaning the state it’s all in, get on and do what you can, make it work as best you can with the time and resources you have, flag risks if they are too much for the business to bare they will say. Your job is to let them know what these are and do the best you can to help get the project past the go live.

 

 

Long Chain Bugs

We’ve all seen them, your testing away, and something odd happens, application crash, unusual error message. you look back at what you were up to, retracing your steps waiting to see the same behaviour repeated, yet nothing shows, you end up digging around into system state, other applications that were running as well, other people who were in the environment as well, sometimes we can work it all out, a lot of the time, at least I, can’t. Well as I found out recently at a medical appointment I attended with my other half, it would seem that the medical community has long chain errors as well.

My partner has Lyme, she’s been very unwell with it for a number of years, and we recently had the chance to talk to a top-flight consultant about her condition. What they explained was Lyme Borreliosis Complex (LBC), as they have dubbed it, is a complex condition that has only in part to do with a single event. The system state also needs to have a variety of conditions meet for that bite to then cascade into the horrible condition that LBC is. They are not sure what the precise conditions need to be, they believe its a combination of genetics, familiar health, and environmental.

At, this point I had to try very hard not to hijack the appointment and start talking with them about how they are researching this and have they seen the very cool ted talk about a multi-disciplinary team that tackles big challenges that have eluded specialists.

It has made me think about how people who have practised testing, understand the mindset required to untangle these complex scenarios could have incredibly interesting and fulfilling jobs if we could convince other communities of the value and benefit we could bring.

Have any of you had the chance to bring your testing skill set to unexpected places?