Test Planning – What Makes A Good Plan?

Today I want to talk about test planning, and planning in general. Here’s a question for you: Have you ever finished testing? I mean, really finished?

I never had that experience. I did have time run out, though, while testing.

We always end up running out of time. It doesn’t matter what our plans are. It makes sense then, to make the best of that time. That requires some planning.

Now, for planning, as with everything else, everyone has their own way that works (or doesn’t) for them. We keep looking for better ways to do that.

Planning is not simple, you have to bring a lot into the process. Some organizations build whole processes to do it correctly.

Test Planning? Correctly?

What does “correctly” mean? From the end-result -when would we consider planning “successful”?

One way to look at it, is checking the execution against the plan. That requires an execution, though. So we’ll know if our plan was good, only after it’s been implemented.

Which would be easy to do. Unless there were changes on the way.
And there are always changes.

While we’re testing, we learn stuff we didn’t know, or assumed differently when building the plan. And if we find out something important, that wasn’t in the plan, following the original planned steps doesn’t make sense, right? So what happens when we compare the execution vs the plan?

If we didn’t think about something during the planning, is it a failure? Can we assume the next time, we will think of everything upfront?

Shades of failure

Let’s say there’s a deadline. Our plan assumes we’re going to test all major components of the product, but we end up testing less than we planned, before the deadline is up. Yet, we still release on time.

Is that a failure of the plan? Or of our test planning process?
Does it really matter at this point?

“Ah”, you say, “We want to improve the next time we plan, so we don’t get into this situation again. How can we do it better next time?”

But what can we improve, that will make it work the next time?

I’ve been through a whole lot of planning sessions, all kinds. Plans never survive when they meet reality. That’s just a fact of life.

So the next conclusion we can come to, is that we don’t need a full plan. It would be a big waste. We need something that is light-weight and good enough.

Good enough test planning

In fact, what we really need is a starting point. A good starting point includes:

1. The content – what we’re going to focus on (main features, workflows) in our test plan
2. The effort – how we’re going to do it
3. The skills – what we need to know going in
4. The setup – what we need in order to start testing

Notice, that all these are what we identify as needed for starting out. That’s the starting point. Things will change as we go. But starting out, it’s what everyone in the project – developers, testers, devops, managers – needs to be aware of, and agree on.

Otherwise the plan, and worse – the execution, is doomed from the start.

It looks like it will work for big releases. It’s true, but it works with smaller releases, like a 1-week sprint. I’ll be going into more details of both high-level planning, and test scenario planning in the next posts.

If you want to know more about testing, check out my “API Testing with Postman” workshop. Planning discussion included.