retest Reduces Risk
Although it is seldom to find actual and accurate data on this, some studies report that 79% of defects were introduced as regressions. The reason for this is simply that every change to one part of the software can in principle affect every other part of that software. And it is inherently hard for developers to foresee such side-effects—which are mostly unwanted.
Therefore, every part of the software should to be tested before every release. This is an enormous amount of effort (to say the least) and simply impossible in times of continuous delivery.
Because of the shortcomings of current GUI test automation tools, GUI tests are traditionally brittle, expensive to write, and time consuming to run, leading to the famous test pyramid.
Since retest implements a completely different approach compared to all other test automation tools, tests created with retest are easy to record (no programming involved) as well as very robust. With the aid of virtualization/containerization and vast amounts of cloud computing power, the assumptions of the test pyramid are no longer true per se.
retest Reduces Efforts
Traditional GUI test automation causes huge efforts in creation and maintenance of the tests. With the retest approach, test creation is way less effort, requires no programming, and the resulting tests are less brittle, less flaky, and also much easier to maintain. This greatly reduces the effort in comparison to traditional test automation, not to speak of manual regression testing.
retest Reduces Costs
All of the above mentioned advantages reduce the overall project costs. Not only the costs of testing and QA, but also the costs of software development. Software rot happens if developers forego sensible changes in fear of unforeseen side-effects. retest changes that because developers get faster feedback due to continuous testing and have much more trust in the tests, causing them to no longer fear side-effects.