The premise of QA is that it is risky not to implement it: Quality Assurance (QA) entails a series of planned, consistent activities to meet the quality requirements for the product. Developers sustain the first negative impact of skipping this stage of the development process. The mistakes they make will very likely affect the end-user in a repeated fashion. The more mistakes they make, the worse it will be. It will result in a bad overall experience, a decrease in revenues, and the loss of the company’s reputation and credibility.

A brief cost-benefit analysis can lead to a definitive conclusion: it is more economical to invest in QA than to lose clients because of poor product quality. Viewed from another angle, mistakes carry a cost. The cost will be less if it is paid early on and in an organized manner.

An analysis carried out by CrossTalk at The Journal of Defense Software Engineering indicates that it may take up to 150 times longer to correct a mistake in the production stage than in the requirements and design stages. In terms of money, for every monetary unit the mistake costs in the early stages, you have to calculate between 60 and 100 monetary units for every product that has already gone live.

The frequent belief is that the developer can run the tests, and that will be enough to ensure quality. Reality shows that the person in charge of programming conducts tests known as the “Happy Road”, always within the development environment. This means that the programmer conducts tests to check that functionalities respond as expected. The quality expert goes far beyond that: he or she will try to stress the system, to “destroy” it, to explore every alternative, to think of all the roads the end-user may take, even the most extravagant options. The intention is to test the system in an environment closer to that of actual production. True quality is the result of a thorough search.

Quality from the Early Stages

How do we make the right investment in QA? The most recommended option is to contemplate QA starting during the early stages of the project. The tester in charge of ensuring quality must contact the client during the requirements stage. He or she must understand the business and, when the time comes to issue recommendations, the tester should view the project from the clients’ perspective. Even if it is important that the quality expert be knowledgeable about programming, it is essential that he or she fully understands the business’ logic.

Skills in terms of automation can also be very useful, particularly in projects that are critical for the business, when the number of cases to be tested is high (which slows down or hampers manual testing), or when releases are very frequent.

The automation of QA tests is fundamental when a very big fault in the code is found just a few days before the project goes live, requiring a very speedy debugging.

Specific skills may be required by the project itself (e.g., mobility).

The following step is the size of the QA team. If the project is bigger, the team of QA experts will need to be larger. A frequent misconception is believing that one tester can guarantee product quality, irrespective of the product scope and the frequency of releases. This is how bottlenecks are created before going live, since the person in charge of testing cannot keep up with the work, and projects are delayed. Again, a bad investment creates higher costs.

The Importance of Communication

The relationship between the person responsible for QA and the rest of the team –development, user experience and business analysts– is a key element. One-on-one communication takes place when different elements are discussed from a technical, design or integration viewpoint, making it difficult to run the tests. This avoids any possible surprises.  The tester will not suddenly find something the developer has left unresolved, but will even understand the potential obstacles the project might stumble upon.

Anyway, it is still quite common to act in a reactive manner: in the early stages of the project, a client may consider that the company does not have sufficient resources. On the other hand, even though an explanation of the inherent risks of not investing in QA has been given to the client, the client decides not to do it. Later on, when the project is well underway and bugs are threatening its success, the client reverts to the initial decision. That is why at Making Sense, as technology allies to our clients, we seek to raise awareness and educate about the importance of incorporating QA as a natural element in every project. It is better to avoid the need to remedy a problem.

QA helps to rectify any probable errors in the software product. Ironically, referring to QA as an expense and not an investment is, in itself, the first error one can make in the project.