The blog post this is written about can be found here.

I chose this blog post because it directly relates to the material we learned on equivalence class testing and our assignment based around it, and because it led me to a deeper understanding of what equivalence class testing is and the ways it can be applied more broadly. In it, the blog’s writer takes apart the Wikipedia article on equivalence class partitioning from a professional tester’s perspective.

The blogger defines an equivalence class as a set of things that have some quality in common that makes them more or less equally able to reveal a certain kind of bug, if it were present in the code. He writes that equivalence classes are not necessarily limited to classes of input data, even though common definitions of the concept characterize it that way. Instead, equivalence class partitioning can apply to anything you might be thinking of doing which has variations that could influence the outcome of a test.

The blogger takes issue with the Wikipedia article saying the technique is meant to reduce the number of test cases, since (as I learned earlier) the number of test cases tells you nothing. He writes that instead, equivalence class partitioning is a method that reduces test effort; and this is only a side effect of focusing test effort, which is accomplished by making educated guesses about where the bigger bugs are most likely to be. He stresses that the technique is based heavily on our mental model of a piece of software and that it’s a fallible method of testing.

I found it particularly useful when he used the real-life scenario of pushing against a door to try to open it as an example. If we push against one part of a door and it won’t move, we won’t try pushing every other spot on the door, because we intuitively understand that most places you can push on a door are more or less equivalent. Pushing once was enough discover it was jammed, and we feel confident in assuming that pushing elsewhere within the set of door spots you can push will have the same result. This thought process is the same as the one used in equivalence class testing.

Having read this post, I will make sure to have a good understanding how a piece of code is meant to work before I set about trying to determine the equivalence classes for it, and I’ll keep in mind that the concept of equivalence class partitioning can be used with things other than inputs.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s