… c’est quoi les tests ?

27 09 2008
Sensibilisation à la recette
Il s’agit ici de présenter de manière synthétique et rapide ce que sont les tests et pourquoi tester. Je commencerai par la définition de « génie logiciel ».

Définitions : Génie logiciel

Le Génie Logiciel ou GL est un domaine relativement récent : la première conférence sur le thème du GL eut lieu en 1969 lors de la conférence de l’OTAN. D’ailleurs la citation suivante en est extraite : « Le génie logiciel est l’élaboration et l’utilisation de principes de génie permettant de produire économiquement des logiciels fiables, et qui fonctionnent de façon efficace sur des machines réelle » : Naur & Randell (eds), Software Engineering : A Report on a Conference sponsored by NATO Science Committee, NATO, 1969.

Donc, le génie logiciel touche au cycle de vie des logiciels. Toutes les phases de la création d’un logiciel y sont enseignées : l’analyse du besoin, l’élaboration des spécifications (fonctionnelle et technique), le développement, la phase de test et finalement la maintenance. La prise en compte des tests suivant une méthodologie (artisanale certes) et la qualité des logiciels ont débuté à cette époque.

Quelques définitions :

  •  » Application pratique de la connaissance scientifique dans la conception et l’élaboration de programmes informatiques et de la documentation associée nécessaire pour les développer, les mettre en œuvre et les maintenir » (B. W. Boehm, 1976),
  • « Ensemble des activités de conception et de mise en œuvre des produits et des procédures tendant à rationaliser la production du logiciel et son suivi » (Arrêté ministériel du 30-12-83).

Définitions : Qualité / tests

La qualité d’un logiciel est son aptitude à satisfaire les besoins (exprimés ou potentiels) des utilisateurs (Martin, J.P., 1987).

Le développement logiciel est une activité humaine qui introduit des défauts à toutes les étapes du processus et notamment lors des activités de tests et vérification, les défauts se propagent, produisent d’autres défauts et sont livrés aux clients. Le développement logiciel devient aussi une activité massivement collective et implique des problématiques complexes comme le partage de tâches qui nécessite un ajustement entre les différentes personnes et points de vue ou bien la compression des délais et l’imperfection de la communication, l’éloignement géographique ne permettent pas l’ajustement, la probabilité d’introduction des défauts augmente. (Bug Mars explorer : pas le même système de mesure).

L’élaboration du logiciel est une activité itérative et la communication écrite joue un grand rôle, mais la taille et le nombre des documents ne permet pas une maîtrise individuelle. La désynchronisation de la mise à jour des documents de référence par rapports aux décisions peut générer des anomalies, de même que le manque de synchronisation est source de nombreuses erreurs notamment aux niveaux des interfaces. Enfin, les revues et les tests sont des moyens de resynchronisation des références.

Les facteurs aggravants sont la taille et la complexité grandissante des applications, la taille des équipes. Mais aussi, un changement des technologies et la pression des délais ou bien la répartition géographique avec des équipes réparties sur divers continents. Et par conséquent un choc de culture et de langue.

Comme on peut le voir le développement logiciel est complexe et peut générer à toutes les étapes des anomalies.

(illustration à venir)

L’illustration ci-dessus est un exemple de progression du taux d’erreurs (en production) pour 1000 lignes de code développées. Plus le nombre de ligne augmente, plus les erreurs sont nombreuses.

Quelques sources :

  • un programmeur expérimenté injecte 1 défaut chaque 10 lignes de code soit 100 défauts par KLOC (kilo line of code),
  • après intégration et validation, il reste 5 à 10 défauts par KLOC (Source : Bugs or defects Watts S. Humphrey SEI interactive, March 1999).
La vérification du logiciel a pour but de démontrer que les produits logiciels issus d’une phase du cycle de développement sont conformes aux spécifications (incluant les exigences légales et réglementaires) établies lors des phases précédentes.
Elle a également pour but de détecter et de rendre compte des fautes qui peuvent avoir été introduites au cours des phases précédant la vérification.

Les tests (ou recette) servent à détecter d’éventuels écarts entre le comportement attendu et le comportement observé au cours des tests, ce qui élimine un grand nombre de fautes présentes dans le logiciel.
Les tests permettent également de s’assurer du niveau de qualité d’une application.
Enfin ils permettent d’obtenir la confiance nécessaire avant l’utilisation opérationnelle (il faut cependant noter que le nombre de fautes détectées ne peut pas être considéré comme un critère de réussite des tests. Le retour d’expérience montre en effet qu’à complexité technique et industrielle constante, un grand nombre d’erreurs détectées par rapport à d’autres projets « de référence » peut seulement être interprété comme l’indicateur d’un logiciel contenant un très grand nombre de fautes et non comme l’atteinte d’un bon taux de détection des fautes présentes).

Il est donc très difficile d’avoir confiance en un logiciel ayant un grand nombre de fautes détectées par le test.
Il existe un risque pour le concepteur de faire définir par une même entité (individu, équipe), la spécification, la conception, la stratégie de tests et les cas de tests. Ce qui implique donc « qu’on ne peut être juge et partie ».
La signification de cette expression dans le milieu des tests exprime le fait qu’une équipe de développeurs n’est pas la plus à même d’assurer les développements d’une application et de la tester. Deux raisons au moins justifient le recours à un tiers pour tester un logiciel. La première raison est que le but des tests est d’exécuter un programme avec l’intention de trouver ses erreurs, ce qui constitue un processus mental non naturel pour son auteur, difficile à mener par une même entité.
La deuxième raison est que le programme peut donc contenir des erreurs dues à la non compréhension de l’implémentation ou des spécifications par le développeur. Dans ce cas, il est probable que celui-ci aura ces mêmes « non compréhensions » quand il testera son propre programme (mode commun de défaillance).

La correction des fautes logicielles peut injecter de nouvelles fautes et perturber des parties correctes déjà testées, mais aussi rendre active une partie du logiciel jusqu’alors inaccessible et donc révéler un grand nombre de nouvelles fautes, qui ne pouvaient être constatées avant cette correction.

Maintenant que disent les livres ?

« Le test n’est pas une science exacte. Il fait appel au bon sens autant qu’à la haute technologie » (Maurice Rozenberg – Tests Logiciel).

« Le test est l’exécution ou l’évaluation d’un système ou d’un composant, par des moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus » (version de l’IEEE).

« Le test est une technique de contrôle consistant à s’assurer au moyen de son exécution, que le comportement d’un programme est conforme à des données pré-établies » (selon AFCIQ).

Ces définitions officielles de ce que sont les tests sont toutes vraies mais sont également complémentaires. Chacune de ces définitions aborde un point spécifique des activités de qualification prenant place au sein d’un projet de qualification.

Maurice Rozenberg nous explique que le test doit allier savoir-faire et connaissance technologique. L’IEEE et l’AFCIQ abordent le sujet en posant comme fondamental que le test (outillé ou pas) est la mesure de l’écart entre les spécifications des utilisateurs (expressions des besoins ou équivalent) et les résultats obtenus.

En fait, la phase de test / qualification / recette est un projet à part entière au sein d’un projet global lié à une application (création, évolution, correction) qui prends sa place dans l’écosystème informatique d’une ou plusieurs entreprises. Pour ce faire nous devons prendre suffisamment de recul.

« Penser globalement et agir localement !»
Ce credo doit être en tête de tous les chefs de projet de qualification car penser que les tests ne débutent seulement qu’après les développements est déjà une grave erreur et hypothèque fortement la suite du projet de qualification.

Pour finir citons le Génie Logiciel : « Dire d’un logiciel qu’il est de qualité sous-entend qu’on puisse lui appliquer certains critères comme l’adéquation aux besoins, la fiabilité, l’efficacité et l’évolutivité. »

Dans la pratique, il s’agit de tester le logiciel suivant une méthodologie définie avec des outils et automates adéquats.

Le pendant de la qualité est la non-qualité. C’est ce qui sera abordé dans le prochain article.


Actions

Information

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s




%d blogueurs aiment cette page :