High-Level Test Planning – Constraints

Let’s continue our discussion of High-Level Test Planning. We’ve already discussed the content and what makes a good plan.

At this point, we seem to know what goes into the plan, as well as prioritization and accepted quality level. We still don’t know if everything will fit into the time slot we have.

Ok, most of the time, we know it won’t fit. But talking about content without context, doesn’t make sense. We need to consider more information. And some of it are constraints.

Or, in other words: Things we know now that will bite us later.

We usually think about constraints as outside of our control. But sometimes we can do something about them.

There can be many things that will impact our work, but at this point, since we’re discussing high-level planning, we’re talking about big ones. The ones that if we won’t consider, will derail our beautiful plan. For example…

Deadlines in Test Planning

Deadlines are important. Sometimes we can’t do anything about them. As much as we try, New year’s always comes at the same time. If that’s our deadline, no magic will help us.

But deadlines can also be arbitrary. Take for example – sprints. The reason sprints are time-boxed, is to focus us on the content of the sprint. It’s just like the process of content prioritization that we already discussed – within the time limit, we focus on the high priority items.

Yet sprint end-dates are arbitrary. Now, I’m not suggesting you start playing with sprint size. It usually serves its purpose. I suggest that understanding where deadlines come from is important to make decisions, and sometimes these deadlines can be moved.

For our discussion though, we’re talking deadlines you can’t move. These deadlines are constraints – we need to consider them in our plan and execution.

Next, there’s people’s availability. If people are going on the summer’s holiday, they won’t be testing. That’s a good thing, by the way. For them.

We may be able to do something about this, though. We may bring in other people to cover for them, or we can shift responsibilities around the team.

Note, that we can make decision about these constraints now, but more importantly, we’re discussing them. We are going to deal with them, but not now – it can be tomorrow, or maybe we can wait with that decision for a later date.

The important thing is that we thought about it, and now it’s floating in the office’s virtual air, nagging us.

What else? Oh yes!

You may think that’s only for certain projects. I worked on multiple instrument-operated software projects, and we didn’t have an instrument. It was a while until we got a prototype. We still needed to test our software, and the decision was to work with simulators.

Testing with the instrument, once we got it, required chemicals. And chemical preparation. While you don’t need to solve everything for our high-level test planning, it needs to be considered.

And other Test Planning Constraints…

But there are other things, less hardware related, that we need to consider. Setup data, new testing environments, things that we need and don’t have yet – we need to raise the issues.

We’ll start planning for them later . But we probably want the big costly, risky things considered up front.

The final things you want to consider are missing skills, and knowledge. You can identify those by completing the sentence “we don’t know how to…”.

If we don’t possess the knowledge, we’ll need to acquire it, practice it, get good at it, and then use it. That of course, takes time.

As bad as we are at estimating things that we DO know, the things that we don’t know are riskier, and usually spiral out of control. That’s why we want to at least consider them, make a note to make sure we can start working, or at least start planning for them.

Remember, the high-level plan is our starting point. We want to make sure we’ve at least marked the major things that we want to accomplish, and what will get in our way.

Once we have this plan, everyone is in agreement about the content and sees the constraints, we now have what we call Coherenece. Everyone working towards a known goal, understanding the guidelines, and have the big picture in mind.

We’ve just got rid of a lot of “but I thought…” discoveries down the line. Not all of them, but the big ones. And that contributes to testing the important stuff.

That’s just the start. We’ll tackle more of these things in upcoming posts, but this is how the process begins. Until then, check out the API Testing Workshop. We do some planning there too.