TNR pour assurer la qualité de la première version de votre logiciel

Publié le : 1 janvier 2024

Le test de non régression informatique, à ne pas confondre avec les tests fonctionnels ou unitaires, permettent d’identifier la régression d’une application entre une version n et une version n-1. Cela implique donc une version n-1.

Or, lors du développement de la première version d’un logiciel, il n’y a pas de version en production, donc de version n-1. Mais, pour les logiciels nécessitant des développements de plusieurs mois, voire années, il se crée implicitement un patrimoine de fonctionnalités.

C’est ce patrimoine, qui s’enrichit au fur et à mesure, qu’il faut valider par une campagne de test de non régression informatique. Le test de non régression informatique est le garant de la qualité de la première version de votre logiciel !

« Dette de régression » des projets informatiques.

Les projets informatiques sont discrédités par des régressions, au fil des développements. Les effets de bords sont fréquents et le temps passé pour identifier l’origine de la régression est considérable.

Dans la majorité des cas les régressions sont identifiées bien après leur apparition en production, souvent par les utilisateurs et, dans le même temps, le projet a continué de s’enrichir en fonctionnalités.

On se retrouve avec une « dette de régression » dont il est impossible de sortir. On est alors dans l’obligation de réaliser les mises en production quasi tous les jours. Les mises en production qui, en fait, ne sont que des Fixs.

Conséquence : la qualité de la première version de votre livrable est au mieux médiocre, au pire catastrophique.

Tests de non régression pour assurer la qualité au fil des versions.

Si les marketeurs ont le droit à leur “Time to Market”, les projets informatiques ont un “Time to TNR”. C’est ce timing de mise en place pour une campagne de test de non régression informatique qui permet d’assurer la qualité de votre développement. Ces tests ne viennent pas remplacer les tests unitaires ou les tests d’intégration, mais bien compléter vos tests.

Le test de non régression informatique est à initier lorsque le “tronc commun” du développement est en place et fonctionnel. Par exemple nommons la version DEV1.0, la version qui inclut les fonctions de création d’utilisateurs, de juridiction des droits d’accès, de login. Bien entendu, en ayant réalisé les tests unitaires, puis les tests d’intégration.

Lorsque tout est conforme, il faut alors qu’il le reste tout au long du projet. Lorsque la version DEV2.0, incluant pour exemple la fonction commande, est conforme, il est impératif de réaliser un test de non régression informatique sur les fonctions qui étaient disponibles dès la version DEV1.0.

Pour ce faire il faut avoir créé des scénarios qui permettent de vérifier que les fonctions de création d’utilisateurs, de juridiction des droits d’accès et de login sont opérationnelles dans la version DEV2.0 comme elles l’étaient dans la version DEV1.0.

On en profitera pour enrichir le patrimoine de test de non régression informatique avec les nouvelles fonctionnalités (dans notre exemple la fonction « commande ») pour, là aussi, en vérifier la qualité au fur et à mesure des versions.

Modèle inapplicable aux projets de développement court.

Le test de non régression informatique ne trouvera pas sa place lors de phases de développement court. Mettre en œuvre des TNR n’a aucun sens si la durée de vie de l’application ou le délai nécessaire pour la réaliser sont trop courts. En effet il n’y aurait aucune rentabilité.

En étant méthodique et en mettant en place l’organisation adéquate, il est possible de mettre en œuvre une campagne de test de non régression informatique tout au long du développement, quand bien même il n’y ait pas encore de version en production.

C’est la meilleure solution pour sortir une première version la plus qualitative possible et ainsi satisfaire pleinement les utilisateurs. Avec CloudNetCare, vous faites par ailleurs le choix d’un outil d’automatisation pour vous assurer de la satisfaction de vos utilisateurs en toutes circonstances.

Ayez toujours à l’esprit l’adage d’Henri Jeanson : « la première impression est toujours la bonne, surtout quand elle est mauvaise ».

Comment identifier le moment où la couverture d’une campagne de non régression est suffisante ?

On en est tous convaincus, la perpétuelle quête de l’amélioration de la qualité des livrables passe par des tests, des tests et toujours des tests de non régression. Pour toutes les équipes informatiques, lors des mises en production, il y a un moment où la question se pose : quand peut-on arrêter de travailler à l’amélioration du patrimoine de test ?

Pour répondre à cette question, vous devez mesurer la qualité de vos livrables en vous basant sur des KPI pertinents. La satisfaction client et la fréquence de mises en production sont deux indicateurs à prendre en compte avant d’arrêter d’enrichir le patrimoine de test.

Satisfaction client au cœur de la stratégie de test de non régression informatique

Le premier indicateur de mesure est caché derrière l’idée d’amélioration de la qualité des livrables. On cherche à l’améliorer pour qui ?

Pour qui : User First ! C’est l’utilisateur de votre application, logiciel, progiciel ou site internet qui est le leitmotiv de toute la démarche de construction d’un test de non régression informatique. La satisfaction client est donc un paramètre essentiel à prendre en compte et doit être un outil de mesure de la pertinence du niveau de couverture de vos tests.

À vous de mettre en place les processus de collecte de ces informations : enquêtes de satisfaction clients, retour du service support, analyse des commentaires sur les réseaux sociaux. En fonction du pourcentage de satisfaction obtenu, sur l’utilisation des fonctionnalités de votre site et de son évolution dans le temps, vous pouvez identifier les moments ou la couverture est suffisante ou s’il faut, à nouveau, l’enrichir.

Toutefois, on ne peut pas être catégorique et se dire : il n’y a plus de retour négatif, on arrête la couverture. Cela va dépendre de la typologie de votre site ou logiciel et de sa fréquence de mise à jour. Dans le cas où les releases de nouvelles versions sont rares on peut estimer que lorsqu’il n’y a plus de retours négatifs on peut arrêter d’enrichir la couverture de test car la satisfaction client est le meilleur jalon de la pertinence de votre couverture de test.

Fréquence des mises en production en juge de paix

A contrario, un éditeur de logiciel ou un site e-commerce avec des mises en production plus fréquentes, mensuelles voire bimensuelles, ne peuvent se « contenter » des retours clients, quand bien même ils sont très positifs.

Le temps que l’information vous remonte et qu’elle soit traitée il y a de fortes chances que la version en production ait déjà évolué. Une MEP non évaluée par le client a déjà été remplacée par une mise en production n+1 ou n+2. Cette fréquence de mise à jour impose de plus d’enrichir en continu la couverture de la campagne de testing, pour couvrir les nouvelles fonctionnalités. Ce n’est qu’à ce prix que l’on peut maintenir une couverture logicielle suffisante.

Si vos MEP sont hebdomadaires voire quotidiennes, sans porter de jugement, avant d’imaginer réaliser des tests de non régression à chaque MEP, ce qui est quasiment impossible, il est bon de réorganiser les développements. Une fréquence aussi élevée cache souvent non des mises en production « fonctionnelles » mais des fixs, dû à pléthores de bugs qui sont passés en production.

Pour simplifier nous avons deux cas de figure :

• Des fréquences de mises en production “rares” (6 mois, un an ou plus) : la satisfaction client est un marqueur idéal d’une couverture par test de non régression informatique suffisante.
• Des mises en production continues (mensuelle, bimensuelle) : il faut enrichir en permanence la couverture du testing.

Pour conclure.

Il n’y a pas de règle pour déterminer si on teste suffisamment ou non. La satisfaction client est LE critère à prendre en compte et quasi universel. Si vous n’avez que des retours positifs de vos utilisateurs sur l’utilisation de votre site, il y a fort à parier que votre couverture de test est suffisante pour arrêter d’améliorer la couverture de vos tests.

Cependant, avant d’arrêter d’enrichir la couverture de test, pensez toujours à prendre en compte les fréquences de vos mises à jour. Plus les releases de nouvelles versions sont rares, plus vous pouvez être sûr qu’en absence de retours négatifs la décision d’arrêter de faire évoluer la couverture de test est plus que justifiée.