Strides Interactive

There aren’t such thing as a Free Lunch! Part #1Filed Under: Weekly Tuesday Dose of goodness

Hi all,

In this article, we’ll talk about certain lazy traits of certain people who simply doesn’t know that there’s a price for everything.

To size it up, I’m just going to talk about such traits that occur in Software Development and Software Testing.

So how does this group of people think that there’s such a thing as a free lunch? Read on…

Introduction

There’ll always be this group of people who take things too far when claiming that they’re simply taking the path of least resistance. How is it so?

Now let’s talk about taking the path of least resistance. Let’s take it to an example of a platoon of soldiers moving through a jungle. In an army operation, it’s not possible to walk on tracks lest they’ll be spotted the enemy easily. The next constraint would be, there shouldn’t be too much bashing taking place, or else the enemy can hear the sounds of their parangs bashing through the thick vegetation.

Therefore, the path of least resistance is to skirt around extremely thick vegetation and bash only when needed. It doesn’t mean anything lesser than that! That means, the soldiers will still need to walk and bash whenever appropriate in order to navigate through the vegetation.

Anything less would mean that the phase is used nothing more than as an excuse to evade the work required!

Scenarios

So let’s get to the point. How does this relate to software development? Let’s begin with a few scenarios.

Scenario 1 : Testing tools are treated as an Oracle-like capable of understanding code logic automatically.

This is relatively common in software quality and testing. Some people feels that tools are nothing but to serve as a check list for ticks to certify a piece of software to a certain level of quality.

While this is usually true in terms of coding standards and language standards; it doesn’t mean that the tester needn’t know the logic of the code.

In testing, there’re many test methodologies that require different areas of understanding, but most of them requires the tester to understand the code they’re testing. One of such methodologies is known as Unit Testing with Test Coverage.

Within Test Coverage, there’re several types of coverage. One of the most significant coverage metric would be MC/DC (Modified Condition/Decision Coverage). Its purpose is to make sure that all possible combinations of a condition branch is being tested. A truth table typically represents the exhausive combinations of all the tests required.

Let’s take a look:

if( a < 0 && b > 2) { }

to test, a 1st truth table would be:

Since it’s a && condition, the 2nd condition onwards is to be considered lightly. How so?

If the first condition is false, under the order of evaluation the condition is evaluated as false immediately without the need to evaluate the other sub conditions.

So we can effectively merge F,F and F,T into a single F, X test  case where X stands for whatever.

Guess what? Tools can easily tell you which part of the truth table is tested or yet to be tested. But the tool will not understand what each predicate represents.  a > 0 is a simple condition, but what if it’s a function call? How do I know what are the parameters that triggers a true and what are the others that trigger a false?

As a developer I’d know. But as a tool, how on EARTH will the automated tool ever know? Therefore, there’s and will always be a need for people to work for results. Don’t expect a tool to automate and work out these results for you. If that’s the case, these redundant people would be out of job in the first place.

Now, that’s quite a mouthful for today. I’m just going to cut it short today and talk more on other scenarios next week.

Regards,
Jeremy

To Be Continued….