Mise en ligne : 24 juin 2003
par km
Description :
Les outils de tests que l’on trouve sur le marché sont divers et variés, tant par leur approche que leur technicité. Cependant, s’il est un point commun, c’est bien la méthode utilisable avec l’outil. Livré à lui même, l’outil ne pourra faire que ce qu’on lui demandera. Encadré par des informaticiens, l’outil ne sera jamais utilisable que par eux. Cette analyse est un retour d’expérience avec l’outil QARun de Compuware et pourrait sans doute être reprise en partie avec d’autres outils du marché
Problématique :
Les tests sont dans certains domaines du test à part entière coté utilisateur, et nous resterons de ce coté de la barrière, coté Maîtrise d’ouvrage.
L’emploi d’un outil est certes très utile, il n’en demeure pas moins qu’utilisé un outil coté MOA nécessite des compétences dans l’outil et qu’un savoir faire soit transmis aux utilisateurs pour qu’au terme du projet ceux ci deviennent autonomes. Comment peut-on faire alors pour que les équipes de test, notamment les utilisateurs puissent s’approprier l’outil sans devoir eux même devenir des informaticiens.
Une méthode est nécessaire, elle sera le lien, l’interface entre les utilisateurs et l’outil.
Dossier :
SPECTRE DES TESTS :
Les test vont concerner la non régression, ainsi que la découverte d’anomalie (processus heuristique)
LES BESOINS COTE MOA :
Heuristique : Les utilisateurs ont spécifié dans des scénario de tests les règles de gestion qu’ils vont tester. Cela consiste à indiquer que telle règle de gestion doit donner tel comportement applicatif et que telle donnée en entrée donnera tel résultat. La différence obtenue entre les deux résultats constituant une anomalie.
Non régression : Les utilisateurs ont joué un scénario et obtenu un résultat correct. Ce scénario sera rejoué lors d’une prochaine livraison applicative et devra donner les mêmes résultats.
LES OUTILS :
Utilisation native de l’outil : Il s’agit d’utiliser l’outil tel qu’il se présente, c’est à dire dans ses fonctions. Avec QARun, les utilisateurs vont "enregistrer" des saisies applicatives et constituer des scripts, qu’il sera possible de rejouer, à l’infini.
Ce mode pose un certain nombre de limites.
Les limites
- Le mode enregistrement fige les comportements. Ainsi lors d’une création de tiers, tout se passe normalement, l’outil a figé le comportement et de l’utilisateur et du système. Lors du rejoue du scénario de création de tiers, le système peut se comporter différemment, si par exemple une règle de gestion limite la création de tiers déjà existant et demande a l’utilisateur de valider cette saisie de doublon. Le script de création n’a pas "prévu" cette situation lors de l’enregistrement, car elle n’est pas apparue, alors. Il faut la prendre en compte, a posteriori.
- Le mode enregistrement laisse le libre choix à l’utilisateur de saisir les champs qui l’intéressent pour le cas qu’il a à tester, il va renseigner certains champs, d’autres pas. Le script est devenu figé par rapport au données. Reprendre ce script pour modifier les données avec un copier/coller par exemple, ne garantit pas qu’ensuite le script fonctionne du premier coup.
- Le mode enregistrement laisse le libre choix à l’utilisateur de naviguer dans l’application tel qu’il le souhaite, pour le cas qu’il a à tester. Reprendre ensuite le même script pour une navigation non strictement identique ne peut se faire sans modification du script. Il s’avère à l’usage qu’il est plus rapide de re-enregistrer un nouveau script que d’en adapter un déjà existant.
- La multiplication des scripts pour une transaction donnée est obtenue rapidement dés lors que les utilisateurs ne travaillent pas de la même manière et ont des comportement différents face à l’application, face à leur scénarios. Cette multiplication fait que l’évolution des scripts est ensuite difficile à faire. A transaction identique les scripts ne vont pas se ressembler, ni pour les données, ni même pour la navigation. Faire évoluer des scripts se fait alors au cas par cas.
Utilisation encadrée de l’outil
Il s’agit ici de corriger les défauts naturels de l’outil avec certains aménagements.
- Séparer les données, des traitements : il s’agit de sortir les données du script, pour rendre le script indépendant des données, et pouvoir modifier les données, sans avoir de modification à apporter au script.
- Rendre générique la navigation : il s’agit de procéder à un enregistrement universel de navigation qui passe, pour une transaction donnée, dans tous les champs de toutes les grilles et puisse traiter tous les cas.
- Constituer un script modèle pour une transaction donnée, et marier chaque script avec autant de jeu de données que l’utilisateur le souhaite. En cas d’évolution de l’application, un seul script est à modifier, le script modèle, et tous les jeux de données, mais c’est là l’intérêt, c’est la même modification qu’il faut apporter aux jeux de données de la transaction. La modification étant répétitive, elle peut dés lors être industrialisée.
METHODOLOGIE :
Plusieurs méthodologies peuvent être envisagées
Externalisation des données
Externalisation des données et des traitements.
Etant plus complète, c’est cette dernière qui sera présentée ici.
Il s’agit de créer une interface entre l’utilisateur et l’outil.
L’utilisateur n’enregistrera plus de script dans QARun, mais renseignera les données et la navigation de son scénario de test dans un document de type feuille de données. La feuille de données contiendra la navigation exhaustive de la transaction.
- Les ressources en présence : un utilisateur et un informaticien
- Constitution de la feuille de données : Il s’agit de procéder pour l’utilisateur à un premier enregistrement de la transaction en respectant quelques règles : passer sur tous les champs proposés par l’application pour la transaction, enchaîner tous les écrans ou grilles de saisie. Le script est alors exporté vers la feuille de données pour permettre d’isoler dans une colonne les données. Un second enregistrement est alors fait pour enrichir la navigation avec les cas que le premier enregistrement n’avait pu réaliser : Cas ou il y a un choix applicatif : exemple la création d’un tiers personne physique s’enchaîne avec tel écran alors que la création d’un tiers personne morale s’enchaîne avec tel autre écran.
En phase finale nous avons une feuille de données contenant tous les cas fonctionnels possibles d’une part et d’autres part une colonne contenant les données.
- Mise en forme de la feuille de données : La feuille de données doit alors être mise en forme avec de la programmation pour constituer en fin de travail un document de travail permettant à l’utilisateur de renseigner les données. Chaque ligne correspondant à un champs de saisie, ou une action applicative (partie de navigation par exemple tel que passer au champs suivant). Une programmation permettra de travailler avec des variables ou d’inclure des appels à des fonctions QARun déjà écrites sous forme de briques autonomes (traitant le cas ou il faut éventuellement répondre à des messages par exemple).Cette partie de mise en forme doit se faire en binôme informaticien et utilisateur, l’utilisateur indiquant les différents cas fonctionnels à l’informaticien qui programmera ces "intersections". La feuille de données représente alors un modèle. La colonne de données représente le jeu de données et peut être sauvegardée séparément
- Emploi : l’utilisateur doit uniquement renseigner les données qu’il désire ainsi que la navigation.
Une colonne regroupant la navigation et les données et alors exportée vers QARun et représente le script pour une transaction donnée.
- Evolution applicative : en cas d’évolution de l’application il s’agit, par transaction concernée, de reprendre la feuille de données du modèle de script et d’y insérer dans les colonnes adjacentes tous les jeux de données. Les nouvelles navigations ou champs sont alors répercutés au niveau de la feuille et sera appliquée par le jeu des colonnes à tous les jeux de données en une seule fois. Ces colonnes de données peuvent alors être re-sauvegardées séparément. Il n’est pas utile de conserver les scripts QARun, puisque par le jeu de copier/coller entre la feuille de données et QARun, il est possible de re-générer des scripts QARun
Voir d’autres infos dans la FAQ Tests