Les outils du Test

Le livrable majeur de toute activité de test, informatique ou non, est la trace : qu’a-t-on testé, quels sont les termes des tests effectués, quels en sont les résultats et ces résultats sont-ils conformes aux attentes ?

Toute activité de test incapable de produire de telles traces se trouvera dans l’impossibilité de certifier un quelconque niveau de qualité de l’objet testé.

Obtenir ces traces est le fruit d’un travail minutieux et répétitif, résultat de la collaboration de plusieurs niveaux de compétence, pour :

• élaborer et conserver les plans de test et les jeux de données associés,
• exécuter les scénarios de test et enregistrer les résultats obtenus ainsi que les conditions de leur exécution,
• déclarer les anomalies et en assurer le suivi,
• mesurer l’avancement et la couverture des tests effectués, ainsi que la qualité du produit testé pour aider à la décision sur les actions à prendre,
• restituer de façon détaillée et synthétique l’ensemble des actions effectuées pour certifier le niveau de qualité atteint.

L’enjeu est ici de disposer d’un référentiel d’informations propre à faciliter les opérations, conserver la trace des différentes actions, gérer les liens entre les différents types de traces, favoriser leur lisibilité, et homogénéiser la pratique des différents acteurs du projet.

Depuis le milieu des années 1990, de nombreuses solutions ont été élaborées et améliorées pour outiller ces activités, guide « naturel » pour l’élaboration et la mise en œuvre des plans de test, ainsi qu’un moyen de leur conservation pour réutilisation au fil des versions successives des applications. La plupart de ces solutions permettent un travail collaboratif par un partage contrôlé de l’ensemble des éléments gérés entre les différents profils concernés. Ce partage favorise l’indispensable cohérence d’ensemble des activités de test.

D’autres outils, à vocation plus technique, ont été conçus pour automatiser l’exécution de séquences de test, l’enregistrement des résultats, ou simuler l’action de très nombreux utilisateurs simultanés, pour des besoins plus spécifiques, tels que les tests de non-régression ou les tests de performance.

Enfin, des solutions techniques sont également disponibles pour automatiser la génération de données permettant à la fois de maîtriser les conditions initiales des environnements de test et celles de l’exécution, manuelle ou automatisée, des scénarios prévus.

Un recours avisé à ces différentes solutions permet d’augmenter significativement la productivité des équipes de test, ainsi que la qualité du travail de test lui-même, et assure la cohérence d’ensemble des différentes activités sur l’ensemble du projet.

Test manuel ou test automatisé ?

L’élaboration d’un plan de test, qui consiste à concevoir les cas et scénarios de test à partir de cas d’utilisation de l’application, ne saurait être automatisée. Cette activité sera néanmoins plus ou moins aisée selon l’outillage utilisé.

En revanche, l’exécution des tests peut être effectuée manuellement par un testeur ou automatiquement par un dispositif capable d’exécuter les scénarios de test et d’en enregistrer les résultats, dans l’ordre imposé par le plan.

Le recours à une exécution automatisée des tests se justifie principalement dans les cas suivants :

• les tests de non-régression, qui nécessitent de rejouer de nombreuses fois des séquences de test pouvant porter sur un périmètre important, dès qu’une modification est intervenue sur un composant,
• les tests de performance, où l’on doit simuler la sollicitation de l’application par de très nombreux utilisateurs simultanés.
• dans le cas d’applications Web, les tests de compatibilité des navigateurs et de leurs nombreuses versions, par un rejeu automatisé des mêmes scénarios dans plusieurs contextes de navigation techniquement différents.

L’automatisation réduit le coût d’exécution des tests, permet de nombreux rejeux sans surcoût majeur et garantit une exécution à l’identique des séquences de test. En revanche, le coût d’élaboration des séquences de tests automatisés est souvent très important et requiert des compétences techniques spécifiques et rares.

Outiller le test manuel améliore la productivité des équipes et la qualité des tests

Les outils de gestion des plans de test permettent tout à la fois la structuration et l’élaboration du plan de test en cas et scénarios de test, l’exécution des scénarios de test avec enregistrement des résultats, la déclaration des anomalies détectées, ainsi que la gestion et le suivi de leur cycle de vie.

En amont du plan de test, la plupart de ces outils intègrent désormais une gestion des exigences comprenant leur définition, leur niveau de priorité de test, le lien entre les exigences et les cas et/ou les scénarios de test. Ce lien très important permet de connaître à tout moment le degré de couverture et de qualité des exigences vérifiées, pendant et après l’étape d’exécution des tests.

La plupart de ces outils proposent une organisation hiérarchisée des principaux composants du test (exigences, cas de test et scénarios), pour une meilleure lisibilité et une organisation optimale du travail des différents intervenants. De plus, ils sont généralement capables de gérer un nombre non limité de projets.

La gestion des jeux de données de test est souvent prise en compte et peut parfois faire appel à des données stockées dans des documents externes (format tableur).

La gestion des anomalies est toujours intégrée, soit comme fonctionnalité propre à l’outil, soit à l’aide de greffons (« plug-ins ») reliant l’outil à des solutions spécifiques de gestion des « tickets » d’incidents.

La visibilité sur l’avancement des tests, la couverture testée et la qualité des composants testés est assurée au travers d’états synthétiques et détaillés avec parfois une possibilité d’export de ces données vers des documents de type tableur. Ces états sont plus ou moins paramétrables, selon les outils.

Enfin, une fonctionnalité d’administration des utilisateurs et des groupes (profils) renforce l’organisation et la gestion des compétences au sein des projets de test, par une gestion fine des droits d’accès aux différents projets et composants de test de ces projets.

Tous ces outils proposent une interface appropriée pour la saisie / modification des composants du test, l’organisation des campagnes de test par enchaînement des scénarios et l’exécution des scénarios de test. Ils font appel à une gestion de base données (PostgreSql, Oracle, MS-SQL, MySql, etc.) pour mémoriser les composants du test ainsi que les résultats obtenus et gérer les liens entre niveaux de données.

Ils intègrent souvent des fonctionnalités d’import/export, que ce soit pour faciliter le transfert des projets entre outils ou pour des besoins spécifiques de reporting.

La richesse fonctionnelle portée par ces outils en fait de véritables plates-formes centralisées, référentiels dédiés à la gestion des projets de test informatique pour l’entreprise, offrant un cadre à l’harmonisation des pratiques. Leur capacité de mémorisation permet à la fois la réutilisation des plans de test tout au long de la vie de chaque application et la mise en évidence de l’évolution de la qualité des développements et du processus de test au fil du temps.

Leur utilisation ne requiert pas de maîtrise technique particulière : ils sont accessibles aussi bien aux équipes de maîtrise d’ouvrage que de maîtrise d’œuvre, sous réserve d’une formation à leur utilisation.

Automatiser la non-régression: un investissement à moyen-terme

Dès qu’une modification a lieu sur un composant applicatif, que ce soit à la suite de la correction d’une anomalie ou du fait d’une évolution de l’application, il est nécessaire de tester la non-régression des parties non modifiées. Pour cette raison, les campagnes de test sont organisées en itérations (en général 3) incluant successivement: test de conformité des composants livrés, test de conformité des corrections d’anomalies, test de non-régression des composants non-modifiés.

Le périmètre de non-régression étant souvent plus important que celui des corrections / évolutions, le rejeu manuel des tests de non-régression devient très vite coûteux. De plus, il est impossible de garantir une exécution manuelle rigoureusement identique du même scénario de test à deux moments différents.

Dans cette optique, l’existence d’outils permettant l’exécution automatique de séquences de test assure :

• un nombre illimité de rejeux rapides et sans surcoût significatif de tout ou partie du plan de test,
• une exécution de chaque rejeu dans des termes strictement identiques,
• une organisation assouplie par la possibilité d’exécuter les tests en dehors des tranches horaires habituelles.

Face à ces indiscutables avantages, le coût de traduction du plan de test en séquences automatisées est très important et dépasse bien souvent le gain obtenu par l’exécution automatisée de plusieurs rejeux :

• charge de travail supérieure pour exprimer les scénarios de tests en langage technique,
• obligation de vérifier la conformité de chaque scénario automatisé aux attentes du test correspondant,
• coût horaire augmenté par le recours à des techniciens spécialisés et rares.

En outre, chaque modification de l’application entraînera la révision des tests automatisés correspondants.

Investir dans une charge de travail d’automatisation (en plus de l’outil et de la formation) n’aura d’intérêt que si le nombre d’exécutions projetées est suffisamment important pour compenser le coût d’élaboration. Ceci est possible dès lors que l’on envisage la totalité du cycle de vie d’une application et pas seulement une seule version. On considère généralement que l’amortissement peut intervenir au bout de trois à cinq versions de l’application.

Depuis quelques années toutefois, cette contrainte de charge d’élaboration des séquences automatisées est en passe d’être levée, du fait de l’émergence de nouveaux outils faisant appel à des générateurs de code.
Le principe, très simplifié, en est le suivant:

• le plan de test est élaboré par du personnel non-spécialisé, à l’aide d’une interface ad hoc, et ses termes sont stockés sous forme de paramètres,
• les paramètres de chaque scénario sont traduits automatiquement en séquences techniques, dans le langage d’un automate choisi (génération du code),
• les séquences techniques sont exécutées par l’automate de test qui enregistre aussi les résultats,
• avec certains outils, les paramètres définissant les scénarios de test peuvent aussi être exportés vers un outil de gestion manuelle des tests. Le même plan de test servira à tester la conformité comme la non-régression.

Avec de tels outils, le coût d’automatisation devient abordable : élaboration du plan de test par des non-spécialistes, recours minimal à des spécialistes techniques, réutilisation et évolution du plan de test facilitées.

Certains de ces outils pourraient à terme permettre une exécution automatisée des tests de conformité et plus seulement celle des tests de non-régression.

Pas de test de performance sans un outillage spécialisé

Tester la performance d’une application ne consiste pas uniquement à vérifier que les exigences de délai de réponse sont satisfaites, mais surtout à vérifier le respect de ces exigences pour le nombre attendu d’utilisateurs simultanés (test de charge) et mesurer l’impact de différentes conditions de sollicitation sur le comportement de l’application (tests de performance, de montée en charge, de dégradation des performances, de stress, etc.).

Procéder à ces tests impose de simuler l’activité d’un nombre variable et potentiellement très élevé d’utilisateurs simultanés (jusqu’à plusieurs centaines de milliers en fonction des contraintes imposées à l’application).

A titre d’exemple, l’application qui permet à tous les contribuables français de déclarer leurs revenus doit pouvoir supporter une charge de plusieurs milliers d’utilisateurs simultanés (pic constaté de 100 000 par heure en 2016).

De telles simulations ne sont possibles qu’au travers d’outils spécialisés permettant a minima :

• l’enregistrement et le paramétrage de scénarios fonctionnels destinés à une exécution par un automate (« utilisateur virtuel »),
• l’exécution d’un même scénario avec des données distinctes par utilisateur virtuel (« variabilisation »),
• l’activation simultanée ou progressive de plusieurs utilisateurs virtuels, pour exécution d’un même scénario ou des scénarios différents, selon des organisations temporelles simples ou complexes,
• l’enregistrement des délais de réponse, détaillé par scénario, action et utilisateur.

La mise en œuvre de ces outils permet d’identifier les conditions de fragilisation du système testé en fonction du degré de sollicitation (nombre d’utilisateurs simultanés) et/ou des scénarios fonctionnels exécutés.

Associés à des « sondes » techniques branchées sur les composants techniques du système (réseau, serveurs, bases de données, etc.), ces outils aident également à identifier précisément les points de vulnérabilité du système en situation.

Sans cet outillage, il serait impossible de détecter, avant mise en production, des failles techniques non décelables dans la conception de l’application parce que liées aux limites de l’environnement technique de développement.

Le résultat des tests de performance permet de préciser les contraintes techniques de mise en œuvre et d’ajuster le dimensionnement de l’environnement en conséquence.

Les outils de la génération des données

Si les tests manuels peuvent souvent se contenter de jeux de données élaborés manuellement, les tests automatisés, notamment les tests de performance, nécessiteront plus souvent un outil générateur de données de test. En effet, par nature, ils donnent lieu à de très nombreuses exécutions simultanées des mêmes scénarios. Or, un même scénario, déroulé simultanément par de nombreux utilisateurs virtuels, nécessitera un jeu de valeurs distinct par occurrence d’exécution sous peine d’erreurs (ne serait-ce que pour les identifiants de connexion).

Le test de programmes « batch » (sans intervention humaine) appelés à traiter de grandes masses de données, peut poser de lourds problèmes de constitution de jeux de données de test volumineux.
Enfin, la préparation des environnements de test peut nécessiter des opérations complexes d’initialisation des bases de données.

Construire de tels jeux de données artisanalement peut avoir un coût élevé en main d’œuvre et être source d’erreurs pouvant conduire à des tests sans valeur suivis de coûteuses révisions des jeux de données.

A l’inverse, disposer d’un moyen de construire automatiquement ces jeux de données est un facteur de réduction drastique des coûts et de fiabilisation des données de test.

On peut bien sûr écrire des programmes spécifiquement destinés à ces opérations. Mais il faut alors investir dans leur test et dans leur maintenance.

On peut aussi recourir à des solutions de type ETL (Extract / Transform / Load), issues du monde du décisionnel, qui proposent des fonctionnalités puissantes de génération et de combinaison de données, une interface graphique de mise en œuvre, et la possibilité de lire et générer des données dans de très nombreux formats, notamment de bases de données, mais aussi tableur, XML, etc.

Les offres de l’outillage du test – Quels critères de choix ?

Dans ce domaine, l’offre de solutions est abondante et sa présentation via les sites web de leurs promoteurs permet d’autant moins un choix aisé que la couverture du besoin fera rarement appel à un outil unique.

Comme toujours en matière de choix, il est préférable de se munir de critères le plus précis possibles et qui, avant même leur rôle d’aide dans la sélection des offres proposées, proposent une mise en évidence de la maturité de la vision que l’on se fait de l’activité du test informatique et des moyens envisagés pour la soutenir.

Nous avons dégagé quelques grandes classes de critères permettant la recherche de solutions et leur évaluation :

1. Modalités de mise en œuvre des tests : tests manuels ou tests automatisés.
   Pour les tests automatisés, scripts en langage technique et/ou formulation « à mots-clés » (avec génération du code),
2. Types de tests visés : fonctionnels, exploratoires, compatibilité, performance, etc.,
3. Fonctionnalités attendues : gestion complète du plan de test (cas, scénarios, campagnes de test), intégration des exigences et de leur lien aux scénarios de test, gestion des anomalies, reporting avancement et qualité, etc.,
4. Support des applications à tester : application web, applications mobiles, mainframe, etc.,
5. Technologie des applications testées : Windows, Mac, Unix, Linux, iOS, Android, etc.,
6. Organisation : gestion multi-projets, gestion des utilisateurs et des profils d’utilisation,
7. Inter-opérabilité des différentes solutions : échange de données, greffons, etc.
   Le cas de plus fréquemment rencontré d’inter-opérabilité est celui d’outils de gestion de tests manuels ne disposant pas d’une fonctionnalité de gestion des anomalies, mais pouvant communiquer avec un tel outil au travers de greffons,
8. Plate-forme technique des solutions : Windows, Mac, Unix, Linux, Saas (« Software as a Service »),
9. Coût des solutions et du support technique : offre du marché, offre « open source » et niveau de support.

On le comprend bien, présenter l’ensemble de l’offre, qui plus est sous une forme comparative, est hors de portée de ce document. Aussi nous limiterons-nous à fournir quelques repères représentatifs de notre pratique, dans le monde des offres commerciales et dans celui de l' »open-source ».

Dans l’offre commerciale on trouvera principalement :

• pour la gestion des tests manuels : Quality Center (HP), Rational Quality Manager (IBM), Test Manager (Microsoft). Certaines de ces solutions disposent de passerelles avec des solutions d’automatisation,
• pour l’automatisation des tests fonctionnels (non-régression), applications Web et mobiles :
  UFT (Unified Functional Testing – HP), Ranorex, SilkTest (Micro Focus), Tosca (Tricentis), KaliosTest (Kalios). La plupart de ces solutions intègrent le test de compatibilité (navigateurs),
  A noter la formule particulière de KaliosTest, qui permet la fabrication des plans de test automatisés sans recours au codage technique (le code des séquences techniques est généré à partir du plan de test),
• pour les tests de performance (applications Web et mobiles) : WebLoad (Radview), LoadRunner (HP), StormRunnerLoad (HP), NeoLoad (Neotys),
• certaines solutions, comme Tosca (Tricentis) facilitent la gestion des tests exploratoires, par nature peu structurés,
• pour la génération de jeux de données : Talend (Talend) et Pentaho (Pentaho Corp) permettent la génération de bases de données complètes à partir de multiples sources de données et à l’aide d’une interface graphique efficace. Talend propose une « community edition » très complète (Talend Open Studio),
• pour la gestion des anomalies : Jira (Atlassian). HP-Quality Center cf. (tests manuels) intègre la fonctionnalité.

L’offre « open source » couvre elle aussi une grande partie des besoins, avec des outils d’un niveau souvent équivalent à ceux de l’offre commerciale. Elle permet de se familiariser à un coût maîtrisé avec la problématique des tests outillés.

• pour la gestion des tests manuels : TestLink, SquashTest TM, RTMR,
• pour l’automatisation des tests fonctionnels (non-régression) : SquashTest TA, Selenium,
• pour les tests de performance (applications Web et mobiles) : JMeter (Apache),
• pour la gestion des anomalies : Bugzilla, Mantis.
  A noter que ces outils peuvent être reliés à l’aide de « plug-ins » à des outils tels que TestLink et SquashTest qui ne disposent pas d’une fonctionnalité propre de gestion des anomalies.

Certains outils de l’offre commerciale sont aussi disponibles en version gratuite (« community edition »), souvent au prix d’une limite dans les fonctionnalités offertes.