Les outils les plus utilisés par les équipes QA

Les activités QA et de test sont menées selon un processus. Ce processus peut être plus ou moins mature, plus ou moins formalisé, plus ou moins respecté, mais dans tous les cas, il y a un processus ! Le processus est généralement soutenu par un ensemble d’outils.

L’objectif de cet article est de clarifier le rôle des différents outils couramment utilisés par les équipes d’assurance qualité dans le processus de test.

Pendant des années, il a été le principal et unique outil professionnel des équipes d’assurance qualité et de test. Un seul produit dominait complètement le marché : Mercury Test Director rebaptisé HP Quality Center rebaptisé ALM ! Aujourd’hui, l’offre sur le marché des outils de gestion des tests est beaucoup plus large, avec des outils tels que Azure Test Plans de Microsoft, Octane d’OpenText, Qtest de Tricentis, Testrail et XRay d’Idera, Zephyr de Smartbear et bien d’autres encore. Des acteurs locaux comme Acqua, Refertest, Squash, Testbench, Xstudio, etc. sont également entrés en scène.

Un outil de gestion des tests a deux fonctions principales :

référentiel de tests avec gestion du cycle de vie des tests :
> l’organisation et la gestion des campagnes d’exécution des tests

De nombreux outils de gestion des tests proposent également 2 fonctions supplémentaires et sont alors appelés outils ALM (ex : Helix by Perforce, Polarion, etc.) :

la gestion des défauts
> la gestion des exigences pour permettre une traçabilité entre les exigences et les tests (quelle(s) exigence(s) un test couvre-t-il ? Quel(s) test(s) couvre(nt) une exigence

Les outils de gestion des tests et d’ALM prennent donc en charge de nombreuses tâches du processus de test, mais pas toutes. En particulier, ils ne supportent pas l’exécution automatique des tests et évidemment, ils ne supportent pas la conception des tests. C’est pourquoi tous nos clients utilisent YEST en même temps qu’un outil de gestion des tests.

Certains secteurs fortement réglementés, tels que les sciences de la vie et médicales, l’aérospatiale, la défense… et d’autres industries développant des logiciels hautement critiques, mettent en œuvre des stratégies sophistiquées en ingénierie des exigences qui exigent plus de fonctionnalités que ce que les outils de gestion des tests courants peuvent offrir. Parmi les outils populaires d’ingénierie des exigences, on trouve Jama Connect, IBM Rational Doors et Rhapsody, etc.

En plus de la gestion des exigences, ces outils prennent en charge les autres activités d’ingénierie des exigences telles que l’élicitation, l’analyse, la documentation… Ces tâches peuvent être effectuées à l’aide de représentations graphiques et de modèles.

Définir précisément les services et performances attendus du logiciel en développement est d’une grande importance pour l’assurance qualité. Cependant, écrire de bonnes exigences est difficile, chronophage et est considéré comme difficilement compatible avec les sprints agiles. Dans les contextes agiles, les tests peuvent opportunément compléter les exigences et constituer une partie importante de la DoD (Definition of Done). C’est précisément le but des approches de développement piloté par les tests (TDD) et de leurs variantes telles que le développement piloté par les tests d’acceptation (ATDD) et le développement piloté par les comportements (BDD).

Les workflows graphiques de YEST s’intègrent parfaitement dans ces approches agiles, notamment l’ATDD. En effet, ces workflows représentent une première implémentation des exigences, développée collectivement par les représentants métier (BA et/ou PO), les testeurs et les développeurs. Les agilistes désignent cette première implémentation de test par l’expression « spécifications par l’exemple ». Cependant, cette première implémentation de test qui complète les exigences est également extrêmement précieuse dans des contextes non agiles.

Avec la popularité croissante des pratiques de développement agile, le besoin d’accélérer les cycles de développement a conduit la plupart des organisations QA à adopter l’exécution automatique des tests. L’exécution automatique des tests est couramment appelée « automatisation des tests », comme si le test se résumait simplement à l’exécution et que d’autres tâches de test ne pouvaient pas être automatisées également.

Fondamentalement, un outil d’exécution automatique des tests est un robot qui commande l’exécution de séquences scriptées sur l’application logicielle. L’offre de tels outils sur le marché est abondante.

Parfois, les ingénieurs en automatisation des tests se voient confier les tests manuels à automatiser. Par conséquent, le défi de l’exécution automatique des tests réside dans la tâche de codage et la maintenance de ce code. C’est là que les frameworks d’automatisation des tests entrent en jeu lorsqu’ils ne font pas partie de l’outil lui-même. Ils proposent des accélérateurs et des composants réutilisables. Les frameworks populaires incluent les frameworks basés sur des mots-clés et/ou des données.

Récemment, nous avons également assisté à l’émergence d’outils d’automatisation proposant un framework graphique tel que Eggplant ou Leapwork. Ces représentations graphiques servent un objectif technique, et non pas un objectif de conception de test fonctionnel. Ce sont des représentations graphiques de bas niveau, parfois jusqu’au clic, généralement assez éloignées de la logique métier. C’est pourquoi ces outils d’automatisation de test basés sur des graphiques ne peuvent en aucun cas remplacer une solution de conception de test comme YEST.

Avoir les données de test requises à temps est un défi de taille pour les équipes QA. Les outils de gestion des données de test tels que Delphix, Informatica, Oracle Enterprise Manager… sont conçus pour relever ce défi. Ils peuvent généralement effectuer des tâches telles que la création de données, l’anonymisation des données, la création de fausses données, l’organisation des données…

Ce qu’ils ne font pas, cependant, c’est minimiser le nombre de tests avec des combinaisons de données optimisées. Prenons l’exemple d’une plateforme d’achat de billets de train : vos tests devront être exécutés avec tous les types de voyages possibles (aller simple ou aller-retour), direct ou avec des correspondances, toutes les catégories de clients (bébé, jeune, étudiant, adulte, senior), 1ère classe ou 2ème classe, tarif avec carte de membre ou tarif standard, etc. Des techniques d’optimisation des données existent (pair wise, n wise, etc.) et quelques outils sont disponibles pour implémenter ces techniques (Inductive Pairwiser, Hexawise…). YEST offre un service d’optimisation des combinaisons de données en tant que fonctionnalité native parmi de nombreux autres accélérateurs de conception de test.

Concevoir des cas de tests qui réduisent au maximum les risques et répondent réellement aux défis business est une tâche cruciale et complexe. Cruciale, car elle est la source de la qualité des tests et justifie ou non l’effort ultérieur dans l’exécution des tests. En effet, quel est l’intérêt d’exécuter et d’automatiser des cas de tests s’ils ne sont pas « smart » et pertinents du point de vue business ? Complexes, car cela nécessite une bonne compréhension des spécifications et des exigences, de la discipline et de l’organisation, des compétences collaboratives et de communication, une vision métier et des capacités techniques en test, ainsi que de la créativité. Et pourtant, aucune des catégories d’outils présentées ci-dessus ne soutient réellement la conception de tests et n’aide à appliquer les techniques de conception de tests.

Vous devrez donc envisager des outils de test à base de modélisation. C’est une solution de conception de tests qui consiste à développer un modèle du comportement attendu de l’application à tester et à laisser un outil générer automatiquement les tests à partir de ce modèle. Le modèle est la seule source de vérité et est généralement graphique, utilisant des notations telles que UML ou BPMN. Le MBT existe depuis plus de 20 ans et plusieurs outils sont disponibles depuis : GraphWalker, MaTeLo par AllforTec, MBTsuite par Sepp-Med, Conformiq, entre autres. Cependant, ces outils n’ont pas eu la percée attendue pour 2 raisons principales :

Avec YEST, Smartesting a revisité et revitalisé l’approche MBT et a adressé les 2 défis mentionnés ci-dessus. Les représentations graphiques de Yest sont faciles à développer car elles représentent des scénarios de test au niveau métier. En tant que telles, elles sont une première étape vers la production de cas de tests exécutables. YEST génère également des tests automatiquement, mais les tests générés peuvent être ajustés manuellement sans modifier la représentation graphique. En conséquence, YEST offre le meilleur des deux mondes : le support d’une approche rigoureuse de conception de tests, le pouvoir collaboratif des représentations visuelles, et la production super-efficace de cas de tests intelligents.