Quand les TNR viennent ralentir vos mises en production.

Dans un schéma “classique” vous développez une application, une fonction, vous effectuez les tests fonctionnels et de non régression nécessaires et vous procédez à la mise en production de votre évolution. Ce schéma va pouvoir s’appliquer si le rythme des évolutions n’est pas trop soutenu et surtout si vos campagnes de tests sont suffisamment industrialisées. Car si ce n’est pas le cas vos tests de non régression viendront ralentir vos mises en production.

La genèse de l’histoire.

Il y a fort à parier que les premiers tests que vous avez mis en place remontent à la création de votre logiciel ou votre application. Après des mois, voire des années de développement et de tests exécutés manuellement, vous avez mis en production le fruit de votre travail !

Et, bien souvent, l’on constate que malgré tous les tests réalisés il subsiste encore des dysfonctionnements après la mise en production. Et, dans les faits, c’est presque inévitable. Pour s’en rendre compte, il faut prendre un peu de recul sur ce qu’il vient de se passer au cours des mois de développement et de tests.

Au démarrage du projet, vous avez fixé une date “butoir” de fin de projet qui correspond, bien souvent, à la mise en ligne du logiciel ou de l’application. À la suite de cela, les premiers développements commencent, les premiers tests aussi et les premières modifications également. La date étant encore suffisamment lointaine, vous prenez le temps nécessaire à la correction de toutes les erreurs de fonctionnement et continuez en ce sens : une phase de développement, une phase de tests, une phase de correctifs, une phase de tests. Une phase de développement …

Mais, au fur et à mesure de l’avancement du projet et la date “butoir” approchant (voire la nouvelle date butoir), les développements s’accélèrent, les tests aussi, les correctifs … tant est si bien que, à la fin, pour pouvoir mettre en production dans les délais impartis il aura fallu gagner du temps. Et dans 99% des cas, le temps a été gagné sur les tests :

• Soit en ne testant qu’une partie des dernières fonctions développées
• Soit en n’effectuant pas les tests après l’application des correctifs
• Soit en n’effectuant pas les tests de l’ensemble des fonctions développées

Ce processus itératif va se reproduire pour chaque nouvelle version que vous allez réaliser.

Inévitablement vous vous exposez à découvrir des régressions au fur et à mesure de l’utilisation de l’applicatif sur son environnement de production.

Quand le temps devient l’ennemi des tests.

Le problème c’est que pour conduire des tests qui couvrent l’ensemble du périmètre fonctionnel cela prend du temps, beaucoup, beaucoup de temps !

Pour mener à bien des tests il faut :

• Le minimum requis : tester la fonction sur un environnement “neutre” avec les bons jeux de données (voir notre article sur l’importance des jeux de données)
• Le bon élève : ne pas se contenter de tester « la nouvelle fonctionnalité » mais bien toute la couverture de tests pour vérifier s’il n’y a pas d’ « effet de bord » et de régression d’autres parties de votre logiciel.
• Le zéro défaut : tester sur les différents environnements de production : navigateurs (et différentes versions) ? Systèmes d’exploitation (et différentes versions) ? Tester la fonction sur les bons terminaux : ordinateur, tablette, smartphone(s)…

Sans toutes ces étapes et ces différentes configurations vous ne pourrez pas être sûr que la version mise en production est stable. Souvent, on occulte une grande partie de ces configurations en partant du principe que si cela marche pour une, il y a de grande chance que cela marche pour l’autre…et bien après 30 ans de retour d’expérience, on vous livre un secret : ce n’est jamais le cas !

Si vous ne pouvez pas vous permettre de prendre des risques au moment de la mise en production, vous prendrez le temps qu’il faut pour exécuter les tests. Se faisant il devient malheureusement inévitable, en fonction de votre patrimoine de tests, que votre phase  de tests de non régression viennent ralentir vos mises en production et vous vous retrouverez avec des développements en “file d’attente”.

Il y a fort à parier que l’on ne vienne vous reprocher des délais de mise en ligne trop long qui plus est si cela a un impact direct sur le business de votre entreprise.

Mais le problème reste le même. Si vous faites l’impasse sur la qualité des livrables, les utilisateurs s’éloigneront d’une version buguée.

Vous l’aurez compris, dans tous les cas c’est votre faute.   

Il faudra vous poser les bonnes questions pour pouvoir gagner du temps sans négliger la qualité des tests. La seule solution : l’automatisation de tout ou partie de vos tests de non régression.

Pour conclure.

Les tests de régression sont souvent les négligés des projets de développement. Et pour cause, le temps nécessaire à leur bonne conduite est souvent une difficulté que beaucoup contourne car, sans cela, les tests ralentissent les mises en production. Comme pour une assurance, ne pas en avoir n’a aucune conséquence jusqu’au jour où on en a besoin ! Gardez à l’esprit que selon la complexité des tests à mener ils représentent 35% des coûts de développement d’un logiciel et quasiment autant du temps total. Le seul moyen pour faire diminuer ces deux paramètres est d’automatiser vos tests.
N’hésitez pas à nous solliciter, on vous expliquera comment faire !