It’s not only about testing!

“It’s impossible to run all these tests in the time we’ve got left!”

How many times have you said this phrase?
I know I’ve said it tens if not hundreds of times…
Looking back, I must have sounded like Star Trek’s Dr. McCoy with his:
“I’m a doctor, not a…”
Funny thing is that also looking back I think that about 80% of the times I said this phrase we were eventually able to release the project on time (or very close to it), either because we managed to run most of the tests we needed to run, or because (believe it or not!) we found a way to release the project without running all the tests we had planned…

Do you ALWAYS run all your planned tests?

Unless you are working for NASA, a life-sciences company, an aerospace firm or another type of “regulated industry” company the answer will surely be NO.
I bet that not only did you “not-run” some of the tests you had planned, but also that during the actual test execution phase you realized that you needed to run some additional tests you had not anticipated during the planning stages of your project.
And so the question is, should you feel bad about this?
I mean, if you look at it from a traditional “project planning” perspective you either don’t know how to plan your tests, or you are letting other managers bully you into taking exaggerated risks by not running important parts of your test plan, or both.

Or is there another alternative?

OK, I am being a little harsh here, but it is only to make a point
After all there might be a third option:  Maybe the truth is that your project is simply too dynamic, and at the rate things are constantly changing it is extremely hard (or plain out impossible) to plan all your tests up-front!
– If your projects are anything like mine, then I guess you were nodding your head as you read the last sentence. –

The Crystal Ball approach

A wise tester (please don’t ask me who, because I really don’t remember) once said:
“If I could provide the same information about the product by looking at a crystal ball, without running a single step, I would still be doing my job as a tester.”
To this I usually add, that not only would you be doing your job as a tester, you would be doing it more effectively
But what does this has to do with test planning or ever-changing projects?
It has everything to do with it!
Your job as a tester is not only about testing!
As the wise tester said, our objective is not to test but to provide information. Testing is only one of the tools we use (maybe the most powerful tool we possess) in order to gather the data.  But as with any tool, you need to use it correctly in order to meet your purpose.

If your projects change so should your test plans

Fighting project change is like fighting the Sun and the winds, a total waste of time and efforts.  In the best case you will seem like a grumpy tester, and in the worst case you will be the team buffoon that no one takes seriously anymore and who is constantly stating that they won’t be able to release the project on time…
If this is the case then instead of fighting change, plan for change.
There are a number of things you can do in order to cope with change as part of your test planning:
1. Make high-level plans and then low level plans
Instead of making very detailed and low level test plans for all your project (up to 6 or 9 months ahead of time), make high level plans and estimates.  Then, as the project progresses, take the most immediate tasks (2 to 4 weeks in front of you) and create lower level plans ONLY for these parts, taking into account the changes and actual status of your project.
2. Exercise mental flexibility
There are many definitions for mental flexibility, but in this context I mean the ability to cope with change and to react to it in a productive and constructive way.
Instead of getting mad at people who will come to you with new features and issues that will make you change your plans, take these changes as constraints that cannot be blame on anyone.  Then look at them as your challenges and solve them by thinking what is the best thing you can do based on this new reality facing your project.
3. Plan your tests as modular building blocks
I love Lego, whenever I want to build something there are always countless ways of arranging the small pieces.  If half way across my building I am missing a piece I can always improvise and still make something close to what I was aiming to do.
BTW, today I do this mostly with my son, but I still find myself something buildings things without even thinking about it as kind of a mental relaxation exercise.
But back to our changing projects :-), your approach to testing can be similar to building with Lego.  If you plan your tests as modular blocks that can be used in order to create scenarios and achieve different levels of coverage, then you should not have a problem shuffling these blocks in order to answer your current testing needs.  If an unforeseen change suddenly appears, then look in your virtual lego box and find the combination of tests that you can put together to supply answer this challenge.
Even if in practice it is more complicated that this (and it is a lot more complicated than this!) having modularity in your tests will provide you with much more flexibility and higher degrees of freedom to help cope with change.
4. Make it a habit to ask your stakeholders what information they need NOW
Back to our “crystal ball”, our job is to provide information (testing is only the empirical tool we use) and just like your project is constantly changing so will the information needs of your team change.
Make it a healthy habit to regularly ask your project stakeholders what information they require and what is important for them that you test in order to make their decisions.
Providing useless information can sometimes be even more annoying to them than not providing any information at all…

http://qablog.practitest.com/2013/09/its-not-only-about-testing/