Leadership dans les tests : outils de test

• Outils de collaboration : ils permettent de recueillir les idées et les exigences, de communiquer au sein de l’équipe et offrent une certaine intégration avec les processus automatisés, parfois au moyen de robots.
• Outils de test : un large éventail d’outils prenant en charge la gestion des données de test, la conception des tests, les cadres de tests unitaires, l’exécution des tests fonctionnels, les tests de performance et de charge, les tests statiques, la conception des tests, la gestion du processus de test, les cas de test, la journalisation et la génération de rapports de test.
• Outils DevOps ou de gestion de l’infrastructure : ces outils prennent en charge la gestion des environnements et des plateformes, le déploiement à l’aide de l’infrastructure en tant que code et des technologies de conteneurs, ainsi que la journalisation, la surveillance et l’analyse en production.

The Tools Knowledge Base est un registre en ligne d’outils qui se distingue de la plupart des registres en ligne par l’étendue de son périmètre, qui couvre la collaboration, les tests et le DevOps. Plus de 1 700 outils sont répertoriés dans ces trois domaines. Les pages web des outils sont indexées et peuvent faire l’objet de recherches.

Le site agrège et indexe également plus de 300 blogueurs ; plus de 52 000 blogs sont aussi indexés et consultables. Nous avons fourni les URL des principales catégories d’outils ainsi que des raccourcis permettant d’effectuer des recherches dans ces catégories au sein des blogs.

Plus de 1 700 outils prennent en charge la collaboration, les tests et le DevOps.

Nous examinerons plus loin dans cet article les principales préoccupations liées à la gestion des tests et les éléments qui la soutiennent.

REJOIGNEZ LA COMMUNAUTÉ

Améliorez votre boîte de réception avec plus de conseils en leadership technologique pour livrer de meilleurs logiciels et systèmes.

Create Free Account

Have an account? Log In

Architecture des outils

Dans le graphique ci-dessous, nous avons identifié l’éventail des types d’outils utilisés par la plupart des équipes logicielles modernes. Nous avons séparé les outils qui tendent à être utilisés dans les environnements de développement, de test et de production. 

Ces outils reposent sur des outils d’infrastructure qui fournissent des plateformes, des machines virtuelles et des conteneurs pour héberger les environnements, ainsi que sur des outils qui effectuent des déploiements automatisés. Les outils utilisés pour gérer les déploiements et les mises en production sont appelés outils d’orchestration des mises en production et des pipelines. Les communications au sein de l’équipe, ainsi qu’avec de nombreux processus automatisés, sont gérées par des outils de collaboration ou de ChatOps.

Bien que l’évolution vers le DevOps stimule le développement et l’adoption d’outils destinés à soutenir le développement continu, presque tous ces outils sont utiles à n’importe quelle équipe de développement ou d’exploitation logicielle.

Il n’est pas nécessaire d’adopter une culture DevOps pour utiliser des outils « DevOps ».

Gestion des tests

Les outils de gestion des tests sont indispensables dans tous les projets d’envergure. Les projets agiles adoptent généralement un outil de gestion des incidents et, pour les tests, s’appuient en partie sur l’utilisation de récits et de scénarios métier afin de suivre les principaux exemples de tests, voire la totalité de ceux-ci. Les outils de gestion des tests couvrent un périmètre allant de solutions très simplistes, comme Microsoft Excel, à des produits complets de gestion du cycle de vie des applications (ALM).

En général, le périmètre des outils de gestion des tests couvre plusieurs domaines :

Modèle de couverture des tests : La plupart des outils de gestion des tests vous permettent de définir un ensemble d’exigences auxquelles associer des cas de test et/ou des vérifications dans les tests. Ces exigences peuvent parfois être hiérarchiques afin de refléter la table des matières d’un document. De plus en plus, d’autres modèles, comme les cas d’utilisation ou les flux de processus métier, peuvent être capturés. Des rapports de couverture du plan de test et de l’exécution sont généralement disponibles.

Gestion des cas de test : Les cas de test et leur contenu peuvent être gérés afin de fournir une trace documentée des tests. Le contenu des cas de test peut être préparé avant les tests ou constituer une trace des tests exécutés. Les cas de test peuvent être au format texte libre ou structurés en étapes avec les résultats attendus. L’importation de documents et d’images à associer aux tests ou aux étapes est courante.

Planification de l’exécution des tests : Les tests peuvent être structurés selon une hiérarchie ou étiquetés afin de fournir une structure plus dynamique. Des tests peuvent être attribués aux membres de l’équipe de test. Les durées prévues des tests peuvent être utilisées pour publier un calendrier synchronisé des tests à exécuter par l’équipe. Des sous-ensembles de tests peuvent être sélectionnés pour couvrir les exigences, vérifier certaines fonctionnalités et réexécuter des ensembles de tests de régression. Les tests enregistrés comme non exécutés, bloqués, échoués ou associés à un autre statut peuvent également être sélectionnés pour être exécutés.

Exécution et journalisation des tests : À mesure que les tests sont exécutés par l’équipe, leur statut est enregistré. Pour chaque test exécuté, l’identité du testeur, la date et l’heure ainsi que la durée sont indiquées. Les tests réussis peuvent recevoir un simple statut de réussite. Les résultats de tests échoués, bloqués ou anormaux peuvent être accompagnés de captures d’écran, de résultats de test et d’un rapport d’incident. De nombreux outils proposent des connexions avec des outils d’exécution des tests qui gèrent et exécutent les tests, enregistrent les résultats et créent même des rapports d’incident préliminaires.

Gestion des incidents : Les échecs de test sont enregistrés dans le journal d’exécution. Ils nécessitent généralement une investigation plus approfondie, avec débogage et correction lorsqu’un échec est causé par un bogue. Les échecs nécessitant une investigation sont généralement consignés au moyen de rapports d’incident, d’observation ou de bogue. Les rapports d’incident peuvent contenir une grande quantité d’informations complémentaires. En général, les incidents sont associés à un type, à un objet testé, à une priorité et à une gravité. Certaines entreprises consignent une quantité considérable d’informations et l’associent à un processus sophistiqué de gestion des incidents.

Rapports : Rapports et analyses des données issues de toutes les fonctionnalités précédentes, selon les besoins. La gamme de rapports va de la couverture des tests prévue par rapport à la couverture réelle au statut des rapports d’incident permettant de suivre les investigations, corrections et nouveaux tests en attente, en passant par l’analyse du délai de correction pour différents types d’échecs, par fonctionnalité, gravité et urgence, entre autres.

L’outil de gestion des tests le plus populaire au monde reste Microsoft Excel.

Conception des tests

La conception des tests repose sur des modèles. Dans le cas des tests système et des tests d’acceptation, les modèles courants sont les documents d’exigences, les cas d’utilisation, les organigrammes ou les diagrammes à couloirs. Des modèles plus techniques, tels que les modèles d’état, les diagrammes de collaboration, les diagrammes de séquence, etc., constituent également une base solide pour la conception des tests.

Dans de nombreux projets, les modèles servent à recueillir les exigences ou les conceptions de haut niveau. Lorsqu’ils sont mis à la disposition des testeurs, ceux-ci peuvent être utilisés pour suivre les chemins et sélectionner directement les éléments de couverture dans le modèle. Si de tels modèles ne sont pas disponibles, il est souvent utile que l’équipe de test recueille, par exemple, des organigrammes de processus ou des diagrammes à couloirs. Ceux-ci aident les testeurs à avoir des discussions plus pertinentes avec les parties prenantes, notamment en ce qui concerne l’approche de couverture.

Dans le domaine des outils propriétaires, des solutions émergent pour permettre de capturer des modèles tels que des organigrammes et de les utiliser afin de générer des cas de test en suivant des chemins conformément à une cible de couverture donnée, par exemple tous les liens, tous les processus, tous les résultats de décision, toutes les paires ou tous les chemins. Ces outils peuvent être associés à des outils de gestion et de génération des données de test afin de générer des combinaisons de données de test destinées aux tests manuels ou automatisés.

Il existe également des outils qui permettent de réaliser la modélisation dans les outils d’exécution des tests. Par exemple, ces outils permettent au concepteur de tests de capturer tous les champs d’une page web, de créer des liens pour « relier » les champs entre eux et de créer un modèle de navigation pour la page, le tout sous forme graphique.

Le modèle est ensuite utilisé pour créer des chemins de navigation et constituer une suite de tests répondant à certains critères de couverture, comme avec les outils de modélisation précédents. Ces outils d’exécution peuvent créer des chemins de test automatisés à l’aide de critères sélectionnés ou les générer de manière aléatoire, et également rendre compte de la couverture par rapport à ces modèles.

Il s’agit actuellement d’un domaine dynamique : surveillez les outils de modélisation prenant en charge la conception et la génération des tests, ainsi que les outils d’exécution prenant en charge la modélisation du système sous test, la sélection automatisée des chemins de test et la création de rapports.

More Articles

• 9 types de tests logiciels en ingénierie logicielle
• 5 types de tests de performance + meilleurs outils
• Tendances des tests logiciels : dernières technologies QA, statistiques et données

Propriétaire ou à code source ouvert ?

Au cours des vingt dernières années, l’utilisation de produits logiciels libres et open source (FOSS), en particulier pour faire fonctionner l’infrastructure, s’est largement répandue. Le coût des licences de systèmes d’exploitation et des logiciels de serveur web associés de Microsoft, ainsi que l’idée généralement admise que Linux/Unix est plus fiable et plus sécurisé que Windows, signifient que, dans de nombreux environnements, Linux/Unix est le système d’exploitation privilégié pour les serveurs. 

Bien que cet article examine les avantages et les inconvénients des outils open source et propriétaires, si vous recherchez spécifiquement des solutions qui s’intègrent bien à Jira, notre guide complet sur les outils de gestion des tests spécifiques à Jira peut vous aider à prendre une décision éclairée.

Les deux tableaux ci-dessous (mis à jour quotidiennement sur w3techs.com) présentent la popularité relative des systèmes d’exploitation et des produits de serveur web. Environ 85 % des sites utilisent les produits de serveur web open source les plus connus, Apache et Nginx.

La popularité de ces produits d’infrastructure FOSS prouve que l’open source peut être tout aussi fiable, voire plus fiable, que les produits propriétaires.

Pour une équipe logicielle qui a besoin de vingt ou trente outils logiciels pour soutenir ses activités, il existe des outils FOSS et propriétaires fiables et fonctionnels pour chaque tâche. Comment choisir entre un produit propriétaire et un produit FOSS ?

Le tableau ci-dessous résume certains des éléments à prendre en compte lors de la sélection d’un type d’outil.

	Propriétaire	FOSS
Disponibilité	Des outils sont disponibles pour tous les domaines.	Certains domaines, notamment les outils de développement et d’infrastructure, sont mieux pris en charge que d’autres.
Coût d’achat	Souvent élevé, en particulier pour les produits « d’entreprise ».	Gratuit, ou licence d’utilisation communautaire sans coût. Des licences commerciales peuvent exister pour les versions d’entreprise ou hébergées.
Documentation	Généralement très bonne.	Variable. Parfois excellente, parfois inexistante, avec toutes les situations intermédiaires. Elle est souvent rédigée par des programmeurs pour des programmeurs, et donc moins exploitable que la documentation commerciale.
Assistance technique	Très bonne, moyennant paiement.	Variable. Certains auteurs d’outils fournissent une excellente assistance et ajoutent même des fonctionnalités sur demande. De nombreux outils disposent de forums en ligne – mais ceux-ci peuvent être très techniques. D’autres outils sont mal pris en charge.
Fiabilité/qualité	Généralement très bonne.	Variable. Les produits comptant de nombreux utilisateurs, prenant en charge plusieurs environnements régionaux et disposant de grandes équipes d’assistance ont tendance à être excellents. Certains outils écrits par des personnes seules, avec peu de contributeurs et peu d’utilisateurs, peuvent être instables.
Richesse des fonctionnalités	Les ensembles de fonctionnalités suivent généralement les feuilles de route publiées des produits et sont habituellement complets.	Les produits ont tendance à évoluer en fonction de la demande des utilisateurs et de la taille de l’équipe de contributeurs. Les contributeurs ont tendance à ajouter les fonctionnalités dont ils ont besoin plutôt qu’à se baser, par exemple, sur des enquêtes auprès des clients.
Fréquence des versions et des correctifs	Les versions majeures sont généralement espacées de plusieurs mois, voire de plusieurs années. Des versions correctives sont publiées régulièrement. Les avertissements et les notes de version sont généralement de très bonne qualité.	Variable. Les versions majeures des grands produits d’infrastructure sont publiées selon un rythme similaire à celui des produits propriétaires. Les produits plus petits et moins populaires ont tendance à être publiés plus fréquemment. Les avertissements sont rares ou inexistants, les notes de version sont médiocres et la compatibilité ascendante peut occasionnellement être rompue.

Les produits FOSS peuvent être moins coûteux à obtenir, mais les autres coûts et responsabilités peuvent être importants. Le facteur déterminant entre les deux est généralement un mélange de votre culture, de votre tolérance au risque et de vos capacités techniques.

Lorsque vous achetez des produits propriétaires et des contrats d’assistance, les risques liés à l’incompatibilité (avec d’autres produits), à la fiabilité, à la facilité d’utilisation et à une assistance technique attentive sont généralement faibles, même si ces solutions peuvent parfois être coûteuses.

Avec les produits FOSS, vous devez généralement effectuer des recherches beaucoup plus approfondies avant de vous engager à en utiliser un. Après tout, il n’y a pas de commercial à qui parler et la documentation peut être fonctionnelle plutôt qu’informative. Bien sûr, une période d’essai est facile à mettre en place et vous pouvez adopter autant d’outils que vous le souhaitez, mais vous devrez mener une étude plus complète des capacités de l’outil. 

Une facilité d’utilisation moindre et une incompatibilité avec vos outils existants peuvent poser des problèmes. Vous devrez donc peut-être écrire des logiciels d’interfaçage ou des extensions, ainsi que des utilitaires de création de rapports ou d’importation/exportation de données. 

Vous devrez également vous former et former votre équipe afin de la mettre à niveau, et assurer généralement vous-même l’assistance logicielle. Cependant, votre équipe aura une connaissance plus approfondie du fonctionnement de l’outil et sera largement autonome pour assurer sa propre assistance.

Un outil FOSS pourrait vous aider à acquérir de l’expérience avec un nouveau type d’outil à peu de frais. Grâce à cette expérience, vous serez mieux placé pour choisir un outil propriétaire à long terme.

Exercice de sélection d’un outil

Si vous recherchez un outil de gestion des tests pour prendre en charge votre projet et votre application actuels ou un projet et une application récents qui vous sont familiers. En vous basant sur les domaines fonctionnels abordés plus haut dans la discussion sur les outils de gestion des tests, dressez une liste de 15 à 20 fonctionnalités qui sont soit :

• Obligatoires
• Souhaitables

Cette liste peut inclure des fonctionnalités, des intégrations, un accent mis sur la facilité d’utilisation, l’assistance, une large base d’utilisateurs ou des forums/FAQ en ligne. Si vous avez déjà un outil en place, ne choisissez pas celui-là.

À l’aide du texte de vos exigences, effectuez une recherche dans la Base de connaissances sur les outils pour trouver trois outils (dont un produit propriétaire et un produit FOSS) qui semblent répondre à vos exigences. À l’aide des descriptions des fonctionnalités de ces outils, créez un tableau comparatif des fonctionnalités des trois produits. Ajoutez une quatrième colonne pour l’outil que vous utilisez réellement, à des fins de comparaison.

• Comment les outils se comparent-ils en matière de fonctionnalités ?
• Quelles fonctionnalités le ou les outils FOSS n’offrent-ils pas par rapport aux outils propriétaires ?
• Combien d’outils existent qui répondent globalement à vos exigences ?
• Combien de temps pensez-vous devoir consacrer à la recherche d’outils pour établir une liste restreinte d’environ trois outils ?

Inscrivez-vous à la newsletter de The QA Lead pour être informé de la mise en ligne des nouvelles parties de la série. Ces articles sont des extraits du cours Leadership dans les tests de Paul — vivement recommandé à ceux qui souhaitent approfondir ce sujet et d’autres thèmes. Si vous vous inscrivez, utilisez notre code promotionnel exclusif QALEADOFFER pour obtenir $60 de réduction sur le prix total du cours !

Apprenez auprès d’autres testeurs en écoutant nos podcasts ou en consultant nos blogs. En voici un dont nous pensons qu’il vous apprendra énormément : COMMENT MES COMPÉTENCES EN TEST M’ONT PERMIS DE DEVENIR UN MEILLEUR DÉVELOPPEUR EN AUTOMATISATION