English | EN Lack of quality: getting to the root of the problem
Dec 16, 2014
I have acne. I have had it for a few years now and I have tried an enormous amount of things to fix it: acne creams, face masks, facial exfoliant, etc.; I have followed several facial treatments recommended by my dermatologist; I have even taken different beauty treatments in beauty centers and spas and tried the most expensive moisturizers in the market. But, after spending lots of money, the problem persisted, because I was trying to fix it focusing on the symptoms and not attacking the root of the problem: my acne was a hormonal problem, so what I had to do was to deal with the cause of my hormonal imbalance. Now that I am attacking the underlying problem my skin is improving and the acne is slowly disappearing.
If we translate this to our field, we can say that, in most cases, defects are the acne of a software application and our common goal as testers is to detect those little spots and report them to the developers in order to correct them with an expensive facial cream. And this is the best scenario, because sometimes the spots are discovered by the user once the program is already in production and we need a luxurious moisturizer to fix them. What we are doing is papering over the cracks and not attacking the root of the problem: the lack of quality. Quality must be built from the beginning, not tested at the end.
That’s why quality must be the objective of all the people involved in software development and testing must start as soon as possible, since the goal of testing is not finding the spots, but to prevent getting those spots going to the source. This can be done embedding quality activities in all the phases throughout the software development lifecycle.
Therefore, just as the most expensive facial cream in the market is not the solution to hormonal acne, starting testing once the test object is delivered is not the solution to the lack of quality. We must attack the underlying problem and introduce quality in every step of the software development lifecycle.
About the author
