Auteur : Pick
-------------------

Nous allons détailler les problèmes les plus courants rencontrés lors de tests IHM, Fonctionnels, de Configuration et d’Installation.

1.    Tests IHM :
Présentation visuelle :
Tester une interface n’est pas une tâche simple. En effet, l’aspect intuitif des interfaces cache des mécanismes complexes, souvent liées à l’environnement d’exploitation. On peut cependant dégager un certain nombre de types de tests caractéristiques qui auront pour objectif de vérifier la présentation des informations.

1.1    Menus et mnémoniques :
Tester les menus consiste à vérifier :
    qu’ils pointent vers les bonnes fenêtres ;
    qu’ils sont bien grisés s’ils doivent l’être. En particulier, si des droits d’usage sont définis, on vérifiera qu’ils sont correctement réalisés ;
    que les boutons ont bien un équivalent menu. En effet, les chartes graphiques, Windows en particulier, exigent que chaque bouton dans une fenêtre, et chaque icône, ait un équivalent dans le menu ;
    que, s’ils sont définis, les mnémoniques servent à accéder aux fonctions principales de l’application par des raccourcis clavier. Les utilisateurs les apprécient : ils doivent donc être testés ;
    que leur emplacement est correct.

1.2    Paramètres d’affichage :
Chaque fenêtre s’affiche dans un contexte particulier. Par exemple, elle peut afficher en mode plein écran ou sous forme d’une icône. Les couleurs des fenêtres doivent aussi être respectées. Certaines applications nécessitent un respect strict des paramètres d’affichage, car ils conditionnent l’accès aux boutons et aux autres objets. On testera aussi le comportement des fenêtres si on modifie leur contexte. Exemple : on vérifiera si les objets changent de taille si on modifie la taille de la fenêtre.

1.3    Propriétés des fenêtres :
Comme tout objet, les fenêtres ont leurs propriétés propres comme le libellé, les boutons d’affichage - réduction, agrandissement et mise en icône -, la présence d’ascenseurs, etc. On vérifiera par exemple si ces propriétés restent cohérentes en cas d’agrandissement ou de transformation de la fenêtre.

1.4    Barres d’icônes :
Les applications graphiques font appel de plus en plus aux barres d’icônes paramétrables, et que l’on peut afficher sur demande. Il est nécessaire de vérifier qu’elles s’affichent correctement lors du lancement de l’application et qu’elles exécutent correctement les fonctions qui y sont rattachées. Dans certains cas, l’usage des barres d’icônes peut prêter à confusion, car leur équivalent dans le menu n’exécute pas la même fonction.

1.5    Résolutions d’écrans :
Des surprises désagréables peuvent se produire lorsqu’on change de résolution de l’écran d’affichage. Certaines applications, n’ayant pas pris en compte le fonctionnement avec des résolutions différentes, provoquent des aberrations d’affichage : des boutons disparaissent de l’écran, des libellés de champs sont tronqués, etc. Les tests d’intégration doivent nécessairement effectuer ces vérifications.

1.6    Effets de bord :
Des problèmes d’affichage peuvent surgir lorsqu’on affiche une information comprenant une partie variable comme le nom d’une personne ou un identifiant : soit le libellé est tronqué, soit il déborde lorsqu’on choisit un nom ou identifiant long.

1.7    Changement d’environnement d’exploitation :
Le fait de changer d’environnement d’exploitation peut créer des problèmes d’affichage. Comme la compatibilité entre les environnements n’est jamais assurée à 100%, on découvre vite leur influence sur les applications.

1.8    Tests de navigation :
La navigation consiste à se déplacer entre deux écrans ou à l’intérieur d’un écran. Bien que naturelle, la navigation est un processus complexe qui pose beaucoup de problèmes aux testeurs, surtout dans les environnements graphiques. Les possibilités offertes par les systèmes d’exploitation de type Windows permettent aux utilisateurs d’exécuter des actions inattendues pouvant provoquer des dysfonctionnements graves.
Les tests de navigation se classent en deux catégories :
1.     navigation entre deux écrans.
2.     navigation à l’intérieur d’un écran.
Cette distinction a pour but de différencier les problèmes, car la navigation à l’intérieur d’un écran est liée aux déplacements par tabulation ou aux touches de raccourci alors que la navigation inter-écrans dépend essentiellement des spécifications fonctionnelles.

1.9    Moyens de navigation :
Il faut nécessairement utiliser l’un des moyens de navigation suivants : touches de clavier ou clic de souris sur des boutons de l’application, ou sur les menus. Chaque fois qu’on change d’écran, on utilise un « moyen » de navigation. Les environnements graphiques ont considérablement développé leur usage, et leur importance n’est plus à démontrer.
Les moyens de navigation les plus utilisées sont les suivants :
    touche « Entrée »,
    menus,
    barres d’icônes,
    boutons de l’application,
    bouton droit de la souris,
    touches de fonction,
    déplacer - lâcher (drag and drop).
Dans les applications, une même action peut s’effectuer par plusieurs moyens, et leur effet n’est pas toujours identique : il faut donc les tester tous.

1.10    Déplacements dans l’écran :
Tous les objets doivent être accessibles à partir du clavier, parce qu’on doit pouvoir continuer à utiliser l’application en mode dégradé si la souris tombe en panne.
Plusieurs méthodes existent pour faciliter l’accès aux objets de l’application par le clavier. Les plus courantes sont :
1) La tabulation : on utilise la touche « Tab » pour accéder à l’objet suivant dans l’écran, et les touches « Crtl - Tab » pour accéder à l’objet précédent.
Plusieurs problèmes spécifiques aux tests se posent pour valider la tabulation :
    Les objets ne sont pas affichés dans l’ordre de tabulation. Par exemple, si on doit saisir le nom, le prénom et l’adresse et que celle-ci apparaît avant le prénom, l’utilisateur ne peut pas effectuer correctement et efficacement cette saisie. Une autre perturbation est liée à l’ajout d’objets dans les écrans qui peut perturber l’ordre de tabulation préétabli ce qui provoque également une désorganisation de l’ordre des champs de saisie. Ces changements provoquent souvent des régressions dans les applications.
    La touche « Tab » pointe vers un objet invisible, ou vers un objet composite de type Applet Java, ActiveX ou Datawindow dans l’environnement Powerbuilder. Dans ce cas, la gestion des touches de tabulation devient problématique et elle doit s’intégrer dans une gestion plus large dépendant des spécificités des objets. On perd en effet le contrôle du déplacement par tabulation puisque l’objet composite est géré de manière autonome.

2) Les touches de raccourci : Ces touches permettent l’accès rapide aux fonctions les plus usuelles. Elles contiennent en général les touches « Ctrl » ou « Alt ». Le test des touches de raccourci consiste à vérifier qu’elles sont correctement réalisées, qu’il n’en manque pas, et qu’elles ne perturbent pas le fonctionnement normal de l’application.
L’usage des outils facilite ces tests, car ils sont capables de reconnaître automatiquement les propriétés des objets à l’intérieur d’une fenêtre.

1.11    Options par défaut :
Lorsqu’une page apparaît  à l’écran, le programmeur a défini des options par défaut permettant à l’utilisateur de se servir d’un environnement de travail adéquat. En particulier, il pourra appuyer sur la touche « Entrée » ou sur la touche « Echap » dès que la fenêtre apparaît. Ces touches reflètent les objets définis comme ayant la propriété « Default », car ils sont actifs dès l’affichage. Il est important de tester le comportement de ces options par défaut puisque l’utilisateur peut les utiliser dès l’affichage d’une fenêtre et, si elles ne sont pas correctement programmées, elles peuvent perturber l’application.

En conclusion, on retiendra que les tests IHM représentent une catégorie importante de tests génériques - à appliquer sur tous les écrans - et qu’ils doivent être réalisés avec la plus grande minutie.

2.    Tests Fonctionnels :
Ces tests ont pour but de vérifier qu’il n’y a pas d’anomalies dans les fonctions réalisées par l’application. Par essence, ces tests sont spécifiques, car ils sont basés sur les spécifications fonctionnelles et techniques, mais on peut dégager un certain nombre de tests fonctionnels récurrents qu’il faudra réaliser dans tous les cas.

2.1    Champs obligatoires :
Les champs obligatoires sont des champs qui doivent contenir une valeur pour qu’une fonction soit validée. En général, ces champs sont affichés différemment des autres champs : la couleur est différente ou le cadre est renforcé. Deux cas de figure peuvent se produire lors de l’exécution :
1.     On valide la fonction sans remplir le champ et on vérifie que le message d’erreur adéquat s’affiche. On reproduit ce mécanisme pour tous les champs afin de vérifier qu’ils sont tous signalés de la même manière.
2.     La fonction de validation est grisée. Dans ce cas, on vérifiera qu’elle redeviendra active lorsque tous les champs obligatoire auront été remplis.

2.2    Tests aux limites :
Les tests aux limites ont pour objectif principal la vérification du comportement de l’application si on entre des données proches ou à l’extérieur des limites autorisées.
2.2.1    Champs numériques :
Ces tests, effectués lors des phases de test unitaires et repris en partie lors des tests fonctionnels, ont pour but de valider le comportement de l’application lorsqu’on entre des valeurs proches et, au-delà, des bornes pour chacun des champs. Ils sont souvent révélateurs d’une programmation instable, les programmeurs n’ayant peut-être pas prévu toutes les combinaisons avec ces valeurs extrêmes. Ainsi, dans un champ numérique N dont la valeur doit être comprise entre 1 et 10, toute valeur saisie sortant des critères doivent retourner un message d’erreur.
2.2.2    Bases de données :
Lorsqu’on utilise une application, on suppose qu’elle contient toujours des données. Or, il s’avère que, dans la réalité, l’accès à des tables vides ou à des champs vides crée de gros problèmes de fonctionnement, se manifestant souvent par des messages d’erreur incompréhensibles.
Les tests aux limites de bases de données nécessitent l’accès à des outils d’administration de ces bases et de peuplement de tables par des données préparées à l’avance. Il est nécessaire de définir des jeux d’essais dans lesquels on cherchera à lire des enregistrements de tables vides, ou d’écrire dans des tables des données contenant des champs vides.

2.3    Intégrité référentielle :
Les applications de type client-serveur créent en permanence des tables ou des requêtes à partir d’informations saisies par les utilisateurs. Ces nouvelles tables peuvent perturber l’intégrité référentielle des bases applicatives, surtout si les clés des champs indexés ne sont pas gérées correctement. Les tests d’intégrité référentielles sont exécutés à l’aide d’outils spécialisés pouvant analyser et afficher la structure d’une base de données.

2.4    Modes dégradés :
L’objectif de ces tests est de vérifier le comportement de l’application dans les conditions anormales ou accidentelles :
    la souris tombe en panne,
    le lecteur de disquette ou de CD ne fonctionne plus,
    le câble réseau est déconnecté,
    le serveur de données ne répond plus,
    la carte graphique fonctionne dans une résolution plus basse, etc.
Tous ces modes ont en commun le fait qu’ils créent des conditions défavorables par rapport à l’exploitation courante. Toute personne utilisant un PC a déjà rencontré ce genre de situation et elle aura apprécié le fait de pouvoir finir les tâches démarrées avant la panne.

2.5    Sécurité :
Les tests de sécurité consistent à valider :
    les profils utilisateurs,
    les fonctions accessibles pour chaque profil.

3.    Tests de configuration :
Les environnements d’exploitation se renouvellent tous les trois ans en moyenne. Le parc des ordinateurs change également très souvent. Les applications, reflets des besoins réels des utilisateurs, sont plus stables et doivent s’adapter à tous ces changements. Une accélération de ces changements est perceptible depuis l’avènement du standard Windows.
Avant d’étudier l’impact des environnements d’exploitation sur les tests, essayons d’énumérer les causes possibles de problèmes surgissant après un portage d’un environnement vers un autre. Pour la clarté de l’énoncé, nous resterons dans les environnements Windows :
    l’application a été développée en 16 bits et doit fonctionner en environnement 32 bits,
    les objets enfouis dans les écrans ne fonctionnent pas de manière identique,
    les DLL sont incompatibles,
    les drivers de périphériques changent,
    les vitesses de traitement sont différentes,
    les formats de fichiers ou de bases de données diffèrent,
    des fonctionnalités disparaissent,
    les interfaces ne sont pas gérées de la même manière, etc.

4.    Tests d’installation :
Ces tests ne sont pas toujours réalisés car l’installation est effectuée à l’aide d’un logiciel spécifique. Ils peuvent cependant mettre en évidence des incohérences liées aux plates-formes cibles, surtout en environnement réseau.

4.1    Installations ciblées 16 et 32 bits :
On rencontre de plus en plus d’applications compilées en 16 bits et en 32 bits par le même compilateur. Par défaut, chaque compilation est adaptée à un environnement spécifique. Il arrive cependant que l’on ait besoin d’installer une version 16 bits d’une application dans un environnement 32 bits. Il faudra alors tester si le programme d’installation permet cette combinaison.

4.2    Chemins interdits :
Les chemins définissent dans l’environnement windows les noms des supports de stockage des fichiers et des référentiels. Certains chemins peuvent poser des problèmes soit parce qu’ils provoqueront un dysfonctionnement de l’application, soit parce que les droits d’écriture sur le support sont réduits. Tous les cas de figure doivent être testés.

4.3    Droits d’utilisation des objets :
Le programme d’installation devra être testé avec pour objectif la validation d’une installation correcte des modules run-time.