Let´s talk about Testing

Frequently, and especially in social networks and technology forums, I come across essays on the principles of the methodology of testing.

Among the different approaches, there are those who strongly defend manual testing against automatic tests, and then I also find many who throw away human testing to leave everything in the hands of the automated tests.

When I find one of these advocates who would leave the quality tests in the hands of computer programs and dispense with the human point of view, I remember the image of a man with a shaved head, extravagant sunglasses and leather clothes sitting in an armchair and saying: “We do not know who gave the first blow, them or us. But we know that we destroyed the sky.”

This is how Lawrence Fishburne, playing the role of Morpheus in the movie The Matrix, described the moment when humans destroyed the sky to try to end the sun as an energy source that fed the machines; great villains of that uncertain future that the 1999 film gave us.

My intention in this article is to share my experiences over more than five years in the world of Quality Assurance, from environments as varying as a call centre to a security company and, above all, what I’ve learned in a few months at EmpathyBroker with its diverse array of leading eCommerce clients.

First of all, we must bear in mind that it’s impossible to ensure 100% that a product or piece of software has no flaws. Yes, we can develop a test plan as exhaustive as you can imagine and execute it to the letter, we can reach the end and obtain an outstanding level of excellence but that does not mean that when it goes to market the end users won’t find, say, five errors on the first day.

While developing testing plans we’ve all probably thought that nobody will try to execute the same option 200 times in a row to see what happens … right? Well in my experience there are people out there who have a lot of free time!!

On the other hand though, it’s just not viable to test absolutely all of the possible variants of a system, with this I am referring to the software testing. In just a few rare cases the software will have a limited number of options but usually once we combine these with languages ​​- countries — visualization devices, this process can take years.

There is, however, a very important point that all QA Testers should implement, or at least fight for, and that’s the fact that the quality area must be part of the product or software from the very beginning. We should not limit ourselves to checking and reporting errors to give our OK once a product has been developed, but we should participate from the birth of that product. Intervening from the beginning of its lifecycle, anticipating possible failures before they happen will in turn enable the testing work to be more effective as well as rewarding; we’ll feel like “parents of the creature.”

Another important issue that we’ve heard for years in the business world is “getting out of the comfort zone.” It’s inevitable that after a few years of executing test plans in different elements of or versions of software, we believe that we have created the definitive test plan. So, we have the conviction that once we complete that plan there will be nothing left to check, nothing more we need to try … but this simply isn’t the case. Even a tried and tested method will always have weak points, especially if it is something that we have not created expressly for that product or piece of software. That’s why I strongly defend a new test plan for each different type of testing.

Obviously, it’s not the same to test a fire detector as the search engine of a fashion website; they have nothing in common and therefore the test path for each also needs to be unrelated. The same thing happens if we compare a fire detector with a motion detector. And in the same way if we compare the search engine of a clothing store with the search engine of a spare parts store… We need to plan tests for each of these different environments, well, differently.

Finally, I want to raise an argument in favour of combining manual with automatic tests. While I can’t say that it won’t happen in the future, today a computer program is not able to check if a result makes sense. That’s why we can’t leave manual testing to one side. What’s more a human being will never be able to analyze millions of data sets and combinations in a few minutes, so in turn we also can’t do without the automatic tests.

The key is therefore to combine both processes to obtain the best results.

Why should we choose between the red or blue pill, if we can take both?

Why should we destroy the sky, if the sun benefits all of us?