Developing software in Agile mode requires delivering value to customers on a regular basis, in sprint of one month, two weeks or even one week. It is therefore essential to implement a well-tested software validation policy, otherwise your efforts will be reduced to nothing by the presence of numerous bugs.
Indeed, if you want to deliver new features on a software, testing these new features is not enough because a software modification can also impact previously delivered functions. In this case, it is also necessary to replay a set of so-called "non-regression" tests on the existing functions, the number of which can quickly increase as you deliver new versions.
There are several possibilities for validating a software product quickly and with limited effort. Each of them involves a certain level of risk that you have to assume: you can achieve infinite quality with infinite resources !
Impact analysis of software code changes
The impact analysis of code modifications consists in evaluating all the tests to be replayed according to the modified code.
When properly mastered, this technique can drastically reduce the validation plan.
A good coordination is necessary between the development teams and the testers to ensure that nothing is left out. This technique even makes it possible to consider in advance and limit the modifications that will be made, so as to deliver more quickly, while performing a code refactoring for example.
How to partially validate software features
You can organize your sprints and deliveries into minor and major releases so that only a priority subset of your non-regression tests is performed during the delivery of minor releases.
A well-mastered Pareto rule will allow you to identify 20% of your tests that will validate 80% of the functionalities, and you will be able to focus on testing the new features.
A good agreement with your client will allow you to use minor versions only to present and validate a working principle or a UX Design proposal, but certainly not to deploy in production.
To prepare for the next major release without wasting too much time validating it, you can start doing your global non-regression incrementally as you produce the previous minor releases, using the impact analysis of each of the minor releases to determine the replay order of your global regression.
This method is risky in that you do not perform your non-regression on the final release, but it can limit the test plans to be replayed once the major release is developed. To implement this technique, it is preferable to organize your minor sprints from the most impactful (big low-level refacto for example) to the least impactful (finalization of GUIs) in order to limit the breakage on the last minor sprints.
And this method does not allow you to set up a continuous and smooth validation process as it still requires a stabilization phase for your major version.
How to automate software features validation
The interest of implementing automated validation when doing Agile is obvious: if the production cost of an automated test is generally more expensive than simply replaying it manually, automated validation starts to be profitable from a certain number of validated and delivered versions.
It allows you to deliver your software at any time: all you need to do is replay your automated test plan (and possibly some manual tests that you were unable to automate), which is faster than a completely manual test plan.
However, the implementation of automated validation suffers from two major problems: testers generally do not have the computer development skills : testeurs generally do not have some coding skills required to use the tools on the market, and the robustness of the generated tests is often lacking and requires significant maintenance.
It is with the aim of addressing these two points that we created Agilitest: Continuous Functional Testing is now a reality with Agilitest, discover our test automation solution.
.png)
