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, formalisé, respecté, mais dans tous les cas, il y a un processus ! Le processus est généralement soutenu par un ensemble d’outils.

Cet article vise à 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. On retrouve 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 : l’organisation et la gestion des campagnes d’exécution des tests.

De nombreux outils de gestion des tests proposent, 2 fonctions supplémentaires, appelés outils ALM (ex : Helix by Perforce, Polarion, etc.). On parle de la gestion des défauts et de la gestion des exigences, permettant une traçabilité entre les exigences et les tests.

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, mettent en œuvre des stratégies sophistiquées en ingénierie des exigences. D’autres industries développant des logiciels hautement critiques mettent également en œuvre ces stratégies. Ces stratégies 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). Le développement piloté par les tests d’acceptation (ATDD) et le développement piloté par les comportements (BDD) sont des variantes de ces approches.

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. Elle est 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.

Les pratiques de développement agile sont de plus en plus populaires. Le besoin d’accélérer les cycles de développement a conduit la plupart des équipes QA à adopter l’exécution automatique des tests. On appelle couramment l’exécution automatique des tests « automatisation des tests ». Cela donne l’impression que le test se résume simplement à l’exécution. D’autres tâches de test ne peuvent 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 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 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, 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. Vous devrez exécuter vos tests avec tous les types de voyages possibles, directs ou avec des correspondances, pour toutes les catégories de clients, en 1ère classe ou 2ème classe, avec tarif carte de membre ou tarif standard, etc.

Des techniques d’optimisation des données existent (pair wise, n wise, etc.). 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. Il propose également 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 ?
Ces tâches sont complexes, car elles nécessitent une bonne compréhension des spécifications et des exigences. Elles demandent également 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é. Pourtant, aucune des catégories d’outils présentées ci-dessus ne soutient réellement la conception de tests. De plus, elles n’aident pas à 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 :
– La modélisation du comportement attendu de l’application en cours de test est perçue comme un investissement lourd et est un défi de taille pour la plupart des testeurs.
– Le réglage fin des cas de tests est fastidieux car cela implique de modifier le modèle et d’anticiper le comportement des algorithmes de génération de tests.

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 vous pouvez ajuster manuellement les tests générés sans modifier la représentation graphique

En conséquence, YEST offre le meilleur des deux mondes. Il supporte une approche rigoureuse de conception de tests. Il offre également le pouvoir collaboratif des représentations visuelles. Enfin, il permet la production efficace de cas de tests intelligents.