This post was originally posted on https://hackernoon.com/
Early testing is one of the seven software testing principles, which implies that the testing process should start as early as possible.
In my experience, though, I often see this principle being neglected, and QA teams get to testing after the software product has already been developed. As a result, there is not enough time to cover all the functional and non-functional aspects of a product. This leads to the release of a product with errors that end users find sooner or later.
How to Prevent Critical Errors In a Digital Product?
My answer is not that complicated: you should involve in the product development all people who will be responsible for its quality in the future. Meaning, the QA team that is going to improve the quality of the product through various activities, should get to the working process as soon as possible.
Clearly, it all depends on the project, software product, and methodology the whole team uses to develop it. But since most of the teams prefer Agile in their work, QA processes should take place far before the digital product is done.
Software product testing without executing the code is called static testing. Quality assurance teams, as well as other people in charge of the product’s future, should perform the static testing practices at the starting phase of the project.
Why Early Testing Is Crucial for Your Product’s Quality, Cost and Safety
Early testing is similar to healthy lifestyle tips and tricks we have known for years. Drinking enough water and doing morning exercises are beneficial, but even talking about it is boring. Here, I want to give you a different perspective on why early testing is essential, which may motivate you to implement it right away.
Preventing design and code defects
Early testing is necessary to define inaccuracies, contradictions, mismatches, and redundant requirements. It helps prevent not only over-expenditure but also disastrous events, like the Therac-25 case. The case that truly shocked me.
Therac-25, a machine designed by the Canadian AECL, was supposed to deliver radiological treatment to cancer patients. Instead, it was actually gradually “burning” them to death. First complaints were not heard, as the company’s engineers claimed such inaccuracies in radiology settings were “impossible.”
The problem wasn’t solved even after the AECL did some bug fixing and returned the machines to hospitals. Later, experts proved that the primary cause was a general poor software design and close to atrocious development practices. Whatever wrong was with Therac-25, it could not have been solved after release or at the last development stages.