Tester mieux et plus vite, c’est possible ?

Définir une stratégie de test de régression adaptée aux risques

La validation d’une application en maintenance évolutive ou corrective représente des risques importants car ses régressions ont un impact immédiat. L’application étant déjà opérationnelle, utilisée par ses utilisateurs pour des processus de l’entreprise, des dysfonctionnements introduits à l’occasion d’une nouvelle version apparaissent vite et ont des effets importants.

Les tests logiciels de non-régression, ou de régression, visent à éliminer ces risques pour assurer la continuité du service une fois la nouvelle version en production. Mais pour les éliminer, le périmètre des tests à réaliser est souvent complexe à identifier. Généralement les entreprises sélectionnent dans leur référentiel de test (Quality Center, TestLink, Salome-TMF, Excel, …) un ensemble de test pour former une suite de tests de non-régression et les jouent systématiquement à chaque version.

Cependant, la part relative de ces tests de régression vis-à-vis de l’effort global de test est souvent importante et représente des coûts conséquents. En outre, ils ne prennent pas en compte les risques réels liés aux changements réalisés car ils visent toujours le même périmètre fonctionnel.

En disposant, d’une meilleure visibilité sur le contenu de chaque version à tester, des modifications réalisées et du périmètre des régressions possibles il est possible d’optimiser sa stratégie de validation logicielle avec 2 objectifs:

• Mieux couvrir les risques de régressions en orientant les efforts sur les domaines fonctionnels concernés.
• Optimiser ses efforts de test en évitant les tests non-pertinents.

Définir une bonne stratégie de test logiciel n’est pas simple

Lorsque l’on cherche à définir la bonne stratégie de test on est confronté à deux difficultés majeures: la dimension fonctionnelle de l’application qui peut-être conséquente et la “remise à zéro” des risques pour chaque nouvelle version voire pour chaque nouvelle livraison.

Chaque livraison peut cacher des régressions

A chaque nouvelle livraison est attaché un risque d’introduire de nouveaux bugs. Que cette livraison soit la 1ère d’une nouvelle version à valider ou la dernière de sa phase de validation censée ne contenir que des correctifs précis. Des études réalisées par IBM ou Caper Jones évaluent à 8% le nombre de bugs introduits par les changements réalisés durant les phases de test (liés aux bugs trouvés).

Ces tests impliquent la connaissance des modifications apportées entre chaque livraison ainsi que le périmètre d’impact de ces modifications. Si le module fonctionnel A est modifié, quels modules seront impactés par son changement ? Le module B ? C ? Tous les modules ? Bien évidemment connaître l’impact réel d’un changement n’est pas simple. La stratégie de test habituelle consiste alors à tout re-tester. Mais re-tester, ça prend du temps…

Cette option devient même impossible en fin de cycle de validation, car après la dernière livraison contenant les derniers correctifs il devient impossible de repasser tous les tests. Il est dans ce cas indispensable de cibler son effort de test selon les risques avec une stratégie de Risk Based Testing (RBT). Disposer d’une vision du périmètre des risques apporte des éléments factuels pour définir une telle stratégie et disposer des informations nécessaires pour décider du Go/NoGo final pour passer en production.

Lorsque les tests de non-régressions deviennent trop importants

Au fur et à mesure de sa vie une application tend à élargir son spectre fonctionnel et donc le nombre de tests nécessaires pour éliminer tous les risques de régressions. Ainsi le nombre de scénarios constituant la suite de tests de non-régression tend à augmenter pour ne laisser aucun risque de coté.

Si pour chaque nouvelle version il est nécessaire de rejouer l’ensemble de ces scénarios, l’équipe de test est souvent confrontée à un véritable défi avec un délai court pour les exécuter.

L’automatisation des tests apparaît comme la seule alternative possible en permettant de traiter les tests beaucoup plus vite. Mais de nombreuses applications ne regroupent pas les critères rendant ce choix économiquement viable ou efficace.

Enfin, sans connaître les zones les plus concernées par les risques de régression suite à des modifications, il est fréquent de passer une première période de tests sans erreurs, puis de finalement arriver, alors que les tests sont presque terminés, à une zone où les bugs sont concentrés. Il s’agit alors d’une grosse charge de travail en dernière minute. Pas facile…

Comment tester plus efficacement

Imaginez la stratégie de test que vous adopteriez si vous pouviez savoir exactement quelles parties de l’application ont été modifiées, quels modules fonctionnels sont impactés, où se situent les risques de régressions…

Cela revient à savoir quoi tester et dans quel ordre, tout en évitant les mauvaises surprises à la fin de votre période de test. Mieux que l’automatisation des tests donc, il devient possible de prioriser ses tests et d’éviter les tests déjà réalisés sur des fonctionnalités n’ayant pas été modifiés.

Cette nouvelle approche de l’application permet donc de ne pas repartir de zéro à chaque nouvelle phase de tests mais de s’appuyer sur le travail déjà réalisé. Tout test réalisé et validé n’est pas nécessairement remis en cause par une nouvelle livraison dont on ne connaît pas réellement les changements. Il devient donc possible de mieux tester, de “tester juste”, tout en réduisant son effort de test.

La plateforme Kalistick vous offre la possibilité de suivre l’évolution de l’application. Grâce à ce suivi, vous augmentez l’efficacité de vos tests tout en réduisant les risques de régressions !