Today’s software tests are getting more and more expensive with the same results they had earlier. So how to replace useless expanses with quality testing? There are dozens of theories and methodologies of achieving such a goal and now we have a new and shiny one in front of us. Let’s give it a try. Reducing the cost of software testing? That’s where DOT steps in.
Why depth? It comes from a different term – the depth of field which is used in photography. Thus after a few adjustments we have the definition from the description: the distance between the nearest and the furthest of software components involved.
Let’s start with what we’ve met by the “component”. In this perspective a component is a rational entity that is capable of performing a tiny feature of the whole system. Its size would be individual for each and every system.
Now, that we are clear with definitions let’s get to examples. Or decreasing the effort spent on software testing and, of course, it’s cost. Let’s take a nice little quote web app you are developing. It has some rules of its own and if the data is inputted correctly by the user he gets a proper price. So what will your fellow user see through the black box? Pretty much nothing except for some things he’ll be certain of, due to the fact all such apps have something in common. But when the box is open there are lots of layers like Java chattering with the server, controllers and validators, the business rules, the pricing calculator, the data storage. How much more fascinating, right?
And what is the app’s most important part? The calculator, of course. But now that we see it smiling to us from the open black box it will still take us time to get there through all the Java and rules and stuff.
Or you can just DOT it, because you see the calculator, all that is relating to it and you can focus on that. It will definitely save some time and money, yet I have a question to my favorite readers:
Does everyone agree with this DOT method, is it worth it and why, or why not?