Test cases and test clusters - partition inputs to save your time

Imagine that you have just finished writing your new cool feature. Now, what is the simplest check whether the code really does what it is supposed to? Run it through simple inputs and check whether outcome matches? Great technique. It has a limitation though - it checks it against this specific case (please see my last entry on that as well). How can we extend that and test whole classes of inputs? Well, there is this simple and elegant technique, which is called equivalence partitioning which seems to be exactly about that.

So what's the idea? We divide our input vectors based on the outcome they are producing (different inputs go through different paths etc) and then work on the representatives and assume that the rest of the inputs from the specific domain will behave similarly. So for example if we play with function, which calculates absolute number we have two partitions - positive numbers and negative numbers and we need to test at least one of each to check whether our function works.

Given that partitions are defined correctly (outcomes are similar on any two given inputs from the cluster) and completely (all inputs are in clusters) we have very powerful tool for software testing in an easy way. We found out how to reduce number of tests to be applied to the minimum and still test all possible test scenarios. Nice job.

Unfortunately, in life, if the problem just got much simpler it usually means you delegated it somewhere else.

The task of figuring out partitions is now the place where we will be spending our time. It's not trivial (or more like very very far from trivial) to figure out what are those clusters and what are their boundaries - but it's still a very effective way to move from chaotic to structured testing.

How you can do it - analyzing your code most likely - you can calculate sets of equations and reducing it by fixing some of the unknowns as problem becomes too complex quickly (top-down approach) or just run test case through the debugger and build on it when stepping through decision points (bottom-up). Or any approach in between really.

And one last note - as always - interesting things happen near or on the boundaries - there is a new life promise there which make your inputs behave - well let's call it unexpectedly - make sure that you have your guards there.