My running mate and myself went out, the other day, for a routine run. An early morning run, 10 km in a steady and not-too-fast pace. All was fine, and towards the last 2 km, my friend suggested that since we are ‘feeling great’, as he put it, it’s an opportunity to add 2-3 km to our run.

I wasn’t sure it’s a good idea – he was right that conditions were good (great weather, good track), and we were not yet that tired, and perhaps it is indeed an opportunity. But what about the bigger scheme of things? What about the next planned runs – will we feel it (physically) then, if we don’t stick with the training plans? And what about the time – do we have it, or will we be late for other duties, waiting for us that day?

This is of course the same with software testing projects, and testing cycles in particular. Let’s take schedules and time as an example.


Stick with the plan

You’ve planned your testing, so that the current cycle meets a certain schedule. This of course required you to select a group of tests, out of your full test repository, so that they cover the requirements for this cycle, while staying within the planned schedule.

To your surprise your cycle is done ahead of schedule.

I know that many are thinking now “no way this could ever happen”, but it does sometimes happen and we should know how to deal with it.
First write a memo-to-self to later examine how did this happen. Was the planning wrong, and what caused the gap (More testing could/should have been planned? less time needed to be asked for? Perhaps there was no need for all testers in this cycle? Etc.). A crucial investigation for future cycles.
Then, send a positive feedback to the dev guys. It might be that they did a great job this time, which just made it easier to test. And it’s always best to keep a positive vibe with the team.

And now get to the main issue on the table, as it’s time for other decisions.

Many would argue that it is best to simply stick with the original plan, hand off the results, allowing other groups to continue with their work, and enabling you to move to your next cycle or project.
This makes sense, and aligns with the there’s-no-time pressured environment most software projects are done at. It also matches many cases of an Agile flow, but not only. And yes, there’s sometimes a case of too much testing, when it’s better to just call it done.
But as good as it is as a first choice of decision, is it the only option? Can’t I take the unexpected time I got and use it differently?

Be flexible and use your resources wisely

The first thing to consider is – should there be more testing done, now that there’s spare time for it. Taking advantage of this available time, you can consider re-testing some of the tests, or maybe explore parts of the software that originally you didn’t plan to test.
It might be that handing your testing results earlier than scheduled won’t help anyhow – other groups aren’t ready for it, and it won’t help anyone. Perhaps the schedule seemed short and you were forced to leave out tests, ones you could not cover given the tight schedule. Well, time was now given…
Time is one of your resources. You should use it wisely, meaning that all things should be considered once a change in plans is introduced.



Each case separately

We’ve referred to Common sense in previous posts as one of the most important assets a tester, and a testing group manager, can hold. It can be considered a testing methodology, and it should be there for any decision, with anything related to a software testing project. Same here – use it when you encounter a plan that has gone “too well” and left you with unexpected resources, additional time or any other asset that can be used. If common sense is applied, your decision – whether sticking with the plan or flexing the plan into a new plan – will be a better decision.

Oh, and that run? We added 1 km and both of us were happy…