Testing your software like building a house

Often, software testing is compared with building a house. This analogy is often used in explaining test methods. We are tending to mention that a foundation is important to start with. Requirements are needed on front as it cost more time and money to adapt the house during the construction phase.

Mostly, a house is fulfilling the same basic needs all over the worlds. Give shelter, security and some privacy. If we are asked to draw a house in a few minutes we all create similar houses with the same basic attributes like: walls, door, window(s) and roof. So in theory we have the same perception what a house is. And perhaps also what it is used for.

Only when we take a look at the actual build houses all over the world we see immediately differences. Below are some pictures of houses from all over the world:




These houses don't look in detail the same to each other, though some raw similarities they have.

If we keep comparing the analogy of building a house with software testing, then we should admit that we also are building different houses no matter what method we are using. The pictures above are from several places with huge distances taken over the world. (The Netherlands, Austria, USA, some place in Africa, Kenia)

I think this gives a risk when off shoring software testing to other countries. The perception of software testing is different as the culture is different.

You also will see some differences when you just cross your borders. In The Netherlands the have other construction rules then in Belgium or Germany. Imagine that crossing borders is the same as just stepping out of your office and look at your neighbors. They do things differently. So outsourcing software testing might result in different deliverables.

There is some other "hidden" similarity in building a house and software development which might lead in differences of deliverables. In some countries they plan the whole construction phase in detail and continue according plan. This can be compared to a waterfall approach. In other countries, they ship all the needed materials and start building a house, during the construction they check if they need more or other materials. Perhaps this is more like an Agile approach.

If our basic goal of software testing is the same all over the world: "deliver acceptable quality within time and budget" we should also define the sub goals. And keep monitoring them. To do this we have to be aware about the impact of culture, internal and external rules on software testing and define how to communicate with each other. We might create some kind of map/dashboard which gives an overview of our environment and provide us information to identify risks and conditions. For this, perhaps my idea about Open System Thinking and Software Testing can provide a guideline.

For structuring communication, Paul Gerrard tried to give some direction defining Test Axioms - second attempt.

Still I think we have another challenge left. What I see in a lot of articles, books and projects is that testers keep sticking to one method or one level of communicating. If they speak about testing, they dive into one development method and how testing should be embedded in that method. Others keep diving in test techniques. And some are expressing their test method/approach. And they try to change the world around software testing by laying up conditions towards others like: requirements should be written in this language, development should be ready at this time, and documentation should be delivered in this form containing this and that information and so on. So at least their process is under control. In this situation setting up a solid test process is becoming a goal instead of deliverance of software.

I think we should use our knowledge and adapt it to the situation we are in to and not force the situation to change so at least we can do our work correct. We need a wider thinking and approach. Perhaps this might be some task for test managers and test coordinators.

Of course as testers we should give some direction and explain what we expect to get to perform our task. And we also should be able to learn from previous results and adapt to newer situation. Only improving the test process should not be come a more important goal instead of software deliverance. The way the process is defined should also fit in the organization policy and we should not try to change that policy. First we should try to adapt our way of testing to it.

Perhaps we should have a bit of influence how the house should be build, only we should not be leading. If we are able to construct a house which has the same raw drawing, no matter where we are or who we are, we might be able to approach software testing as a living organism also. Software testing methods can be used to define the outside color of the house and the inside architecture.