vous propose un article de l'expert Ed. Yourdon, à lire et à relire!

Comme tout ce qui concerne l'An 2000, la réussite des tests est plus une question d'organisation qu'une question de technique.

Environ 50% du budget, des ressources et du temps sera dépensé en tests. Ainsi l'organisation qui s'est lancée en 1997 avec une cartographie, un inventaire et une étude d'impact des programmes contenant des dates sensibles constatera que 12 mois d'effort ont permis d'accomplir seulement 5% de la tâche globale de correction An 2000.

Le rythme s'accélère cette année au fur et à mesure que les organisations accroissent le personnel nécessaire pour la phase de mise en œuvre. Mais cela ne les amènera qu'à mi-chemin, et s'étalera encore jusque pendant les premiers mois de 1999. Ainsi, la moitié du travail à réaliser sera comprimée en 12 mois ou moins pendant l'année 1999. Et sans une planification et une organisation soignée, les chances de réussite en sont très faibles.

Bien sûr, cela dépend de ce qu'on appelle réussite. Quelques chefs de projets An 2000 pourront dire :"Nous sommes le 31 décembre 1999, donc nous devons avoir fini nos tests. Par conséquent je déclare que nous avons réussi!" C'est une question classique pour tout projet logiciel: Comment savez vous quand vous avez fait suffisamment de tests? Hélas, une réponse habituelle est: "Nous avons fait suffisamment de tests quand nous n'avons plus le temps d'en faire!". Une version moins cynique est :"Nous avons assez testé quand nous avons passé plusieurs jours sans trouver d'anomalies".

La définition appropriée de la réussite implique la notion de couverture:" Nous avons fait assez de tests quand nous pouvons montrer que nos tests ont fait fonctionner X% des instructions ou X% des chemins logiques de notre programme". Il existe plusieurs outils dans le commerce qui fournissent une analyse de la couverture; la technologie est bien développée, mais la pratique ne l'est pas. Si vous voulez réussir vos tests de l'an 2000 en 1999, assurez vous d'avoir choisi et installé des outils de couverture des tests en 1998, et que votre équipe de projet sait les utiliser.

Pendant que vous y êtes, achetez aussi des outils de test de non-régression, installez-les et assurez-vous que vos gens savent les utiliser. Vous en avez besoin parce que les essais de correction des anomalies pour l'An 2000 vont introduire de nouvelles anomalies à d'autres endroits du logiciel. Un test de non-régression vérifie le logiciel avant et après un changement, non seulement pour voir si les changements fonctionnent, mais également pour vérifier si une autre partie du logiciel n'est pas cassée à cause de la modification.

Nous nous cachons souvent le risque lié au phénomène dit " d'une simple modification d'une ligne" dans les projets de maintenance, bien que les histoires abondent des désastres gigantesques résultant de cette pratique. Avec l'An 2000, c'est une pratique absolument inacceptable à cause de la dimension des modifications de logiciels nécessaires. Pour une grande entreprise typique, 80% des applications de gestion sont concernées par les dates et par conséquent doivent être corrigées. Et l'effort de correction entraînera la modification de 5% du code.

Pendant qu'ils y sont les programmeurs seront tentés de corriger quelques autres anomalies qu'ils découvriront dans le vieux système en même temps qu'ils chercheront à éliminer du "code mort", qui se révélera ou pas être vraiment mort.

 D'après le gourou des métriques, Capers Jones, environ 7% des modifications de code dans les projets An 2000 introduisent de nouvelles anomalies. Et quand on considère que le portefeuille d'une entreprise contient 200 à 300 millions de lignes de code, cela signifie que de très nombreuses anomalies sont rajoutées.

Sans un test de non-régression capable d'apporter une comparaison entre avant et après, l'équipe de projet ne saura pas si tout ce qui était correct continue à l'être. L'administration américaine des impôts a déjà reconnu avoir supporté une telle expérience dans son projet An 2000, lorsque 1000 contribuables innocents ont reçu par erreur une note de rappel pour paiement tardif. Plus intéressante est l'expérience d'une firme de courtage de Wall Street qui par une erreur innocente dans son projet An 2000 a effectué un dépôt de 19 millions de Dollars sur le compte de chacun de ses clients.

Finalement, les chefs de projets An 2000 doivent mettre en œuvre une forme assez peu familière de tests dès maintenant: le test de la base. Si ce concept de test de la base ne vous est pas familier, pensez y de cette manière: Si vous avez un système ancien stable fonctionnant en production, alors l'objectif de votre effort An 2000 est de reproduire son comportement actuel avec une version du système compatible avec l'an 2000.

Mais qu'est-ce que cela signifie? Nous ne pouvons pas simplement déclarer, "Le système actuel fonctionne, et nous souhaitons que la nouvelle version aussi fonctionne, quand nous ferons les corrections pour l'an 2000." A l'inverse, nous devons dire : "Nous avons un million de cas de tests, qui représentent une couverture à 98% des chemins logiques de la version actuelle du système, et voici quel est le résultat de ces cas de tests. Après avoir fini de faire les modifications An 2000, nous devrons exécuter le même million de cas de tests pour vérifier que nous obtenons les mêmes résultats (logiques). C'est ainsi que nous saurons que le système continue de fonctionner correctement".

Est-ce si simple? Considérons le fait que le système "stable" actuel contient très certainement des anomalies. Certaines sont connues et pas corrigées, tandis que d'autres sont potentielles et inconnues. Si vous vous occupez de 200 à 300 millions de lignes de code, alors la gestion des vérifications et de la configuration est d'une importance essentielle. Et cela signifie, à peu d'exceptions près, que l'effort An 2000 doit tendre à reproduire le comportement anormal du système actuel. Et cela signifie également que si vous avez commencé à corriger vos applications sans avoir engagé un test de la base, vous ne maîtrisez sans doute déjà plus votre projet.

Et ceci ne traite qu'une petite partie du sujet, bien entendu, et de nombreux excellents fournisseurs de tests sont à votre disposition pour vous aider. Mais ne les appelez pas, et ne commencez pas à établir vos plans, en 1999. Même si vous pensez que l'activité principale pour 1998 est la mise en œuvre des corrections, vous devez commencer à établir vos plans pour les tests de l'An 2000 dès maintenant.

__________________________________________________________________________________________

© Computerworld - March 16, 1998 . Ed Yourdon est un expert et un conférencier mondialement reconnu pour tout ce qui concerne le développement d'applications. Il dirige le "Year 2000 Advisory Service" du Cutter Consortium à Arlington, Mass. (USA). Son dernier ouvrages est "Time Bomb 2000". Il peut être joint par Email à Ed@yourdon.com.

Traduction française : ADAR Sarl

Pour les dernières informations sur les problèmes An 2000, allez sur les pages An 2000 du site de Computerworld:

HOME | A PROPOS | PRESSE | PRODUITS | SERVICES | CONTACTS
DOWNLOADS | SAP R/3 | QUALITE | EMPLOIS | La suite SAP R/3 | PRESENTATIONS