Le Leadership dans le Test : Outils de Test
Note de la rédaction : Bienvenue dans la série Leadership in Test du gourou du test logiciel et consultant Paul Gerrard. Cette série est conçue pour aider les testeurs ayant quelques années d'expérience — en particulier ceux travaillant en équipes agiles — à exceller dans leurs rôles de lead test ou de management.
Dans l'article précédent, nous avons examiné l'infrastructure du site et comment la tester. Dans cet article, je vais vous présenter la boîte à outils du testeur, comment choisir entre les solutions propriétaires et open source, ainsi qu'un petit exercice de sélection d’outil.
Inscrivez-vous à la newsletter The QA Lead pour être averti dès la publication des nouvelles parties de la série. Ces articles sont des extraits du cours Leadership In Test de Paul que nous recommandons vivement pour approfondir ce sujet et bien d'autres. Si vous vous inscrivez, utilisez notre code promo exclusif QALEADOFFER pour obtenir 60$ de réduction sur le prix complet du cours !
Les équipes logicielles qui s’auto-gèrent utilisent un plus grand éventail d’outils que jamais auparavant. Dans une équipe logicielle typique, il peut y avoir vingt, voire trente outils utilisés. Pour vous aider à naviguer parmi tout cela, dans cet article nous couvrirons :
- Outils pour les tests
- Architecture des outils
- Gestion des tests
- Conception des tests
- Propriétaire ou Open Source ?
- Exercice de sélection d’outils
Commençons par passer en revue les principaux types d’outils que vous utiliserez pour les tests.
Outils pour les tests
Il est pratique de répartir les outils pertinents aux tests en trois types :
Envie d'en avoir plus avec The CTO Club ?
Créez un compte gratuit pour terminer cet article et rejoindre une communauté de CTO et de leaders en ingénierie partageant des cadres pratiques, des outils et des conseils pour concevoir, déployer et faire évoluer des technologies alimentées par l'IA.
Have an account? Log In
- Outils de collaboration : ils permettent de centraliser les idées et exigences, de communiquer au sein de l’équipe avec une certaine intégration aux processus automatisés, parfois via des bots.
- Outils de test : un large spectre d’outils qui prennent en charge la gestion des données de test, la conception des tests, les frameworks de tests unitaires, l’exécution de tests fonctionnels, les tests de performance et de charge, les tests statiques, la conception des tests, la gestion du processus de test, des cas de test, la consignation et le reporting des tests.
- Outils DevOps ou de gestion d'infrastructure : ces outils facilitent la gestion des environnements et des plateformes, le déploiement avec l’infrastructure as code et les technologies de conteneurisation, ainsi que la journalisation, le monitoring et l’analytique en production.
The Tools Knowledge Base est un registre en ligne d’outils qui diffère de la plupart des registres en ligne en ce que la portée couvre la collaboration, les tests et DevOps. Il y a plus de 1700 outils dans ces trois domaines. Les pages web des outils sont indexées et peuvent être recherchées.
Le site agrège et indexe également plus de 300 blogueurs et plus de 52 000 blogs, qui sont aussi indexés et consultables. Nous avons fourni des liens vers les principales catégories d’outils et des raccourcis pour la recherche dans ces catégories de blogs.
Il existe plus de 1700 outils prenant en charge la collaboration, les tests et DevOps.
Nous aborderons les plus grandes préoccupations concernant la gestion des tests et les éléments qui la favorisent, plus loin dans cet article.
Architecture des outils
Dans le schéma ci-dessous, nous avons identifié la gamme de types d’outils que la plupart des équipes de développement utilisent aujourd’hui. Nous avons distingué les outils habituellement employés pour le développement, les tests et les environnements 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 des outils effectuant des déploiements automatisés. Les outils utilisés pour gérer les déploiements et releases sont appelés outils d’orchestration des releases et pipelines. Les communications au sein de l’équipe, tout comme avec la plupart des processus automatisés, sont gérées par des outils de collaboration ou ChatOps.
Bien que l’approche DevOps favorise le développement et l’adoption d’outils soutenant le développement en continu, la quasi-totalité de ces outils est utile à toute équipe de développement logiciel ou d’opérations.
Il n’est pas nécessaire d’avoir une culture DevOps pour utiliser des outils dits « 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 ce qui est des tests, s'appuient parfois sur l'utilisation de stories métiers et de scénarios pour suivre les exemples clés, voire tous les tests. Les outils de gestion des tests varient en portée, des plus simples, comme Microsoft Excel, à des produits de Gestion du Cycle de Vie Applicatif (ALM) complets.
De manière générale, la portée des outils de gestion des tests couvre plusieurs domaines :
Modèle de couverture des tests : La plupart des outils de gestion des tests permettent de définir un ensemble d'exigences contre lesquelles associer des cas de test et/ou des vérifications dans les tests. Ces exigences peuvent parfois avoir une structure hiérarchique afin de refléter une table des matières documentaire. De plus en plus, d'autres modèles, tels que des cas d'utilisation ou des flux de processus métier, peuvent être capturés. Des rapports sur la couverture des plans 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 un enregistrement documenté des tests. Le contenu des cas de test peut être préparé avant la phase de test ou servir d'historique des tests exécutés. Les cas de test peuvent être rédigés en texte libre ou structurés en étapes avec des 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 organisés dans une hiérarchie ou étiquetés pour offrir une structure plus dynamique. Des membres de l'équipe de test peuvent se voir attribuer des tests. Les durées prévues des tests peuvent permettre de publier un planning synchronisé des tests à exécuter au sein de l'équipe. Des sous-ensembles de tests peuvent être sélectionnés afin d'assurer la couverture des exigences, de tester des fonctionnalités spécifiques ou de relancer des batteries de tests de régression. Les tests indiqués comme non encore exécutés, bloqués, échoués ou avec un autre statut peuvent aussi être sélectionnés pour exécution.
Exécution et journalisation des tests : Au fur et à mesure de l'exécution des tests par l'équipe, le statut des tests est enregistré. Tous les tests exécutés doivent comporter l'identité du testeur ainsi que la date/heure et la durée. Les tests réussis peuvent avoir simplement un statut de réussite. Les tests échoués, bloqués ou ayant donné des résultats anormaux peuvent être assortis d'une capture d'écran, de résultats de test, et d'un rapport d'incident associé. De nombreux outils proposent des intégrations avec des outils d'exécution des tests qui gèrent et exécutent les tests, enregistrent les résultats, et peuvent même générer des brouillons de rapports d'incident.
Gestion des incidents : Les échecs de tests sont consignés dans le journal d'exécution. Ceux-ci nécessitent généralement une investigation plus approfondie, avec débogage et correction si l'échec est dû à un bug. Les échecs nécessitant une investigation sont généralement enregistrés via des rapports d'incident, d'observation ou de bug. Les rapports d'incident peuvent contenir une grande quantité d'informations de soutien. Habituellement, les incidents sont associés à un type, un objet testé, une priorité et une sévérité. Certaines entreprises enregistrent une grande quantité d'informations et les associent à un processus de gestion des incidents sophistiqué.
Rapports : Rapports et analyses des données issues de toutes les fonctionnalités ci-dessus selon les besoins. La variété des rapports s'étend de la couverture prévue vs réelle, le statut des rapports d'incident pour suivre les investigations en cours, les corrections et les re-tests, des analyses du délai de résolution selon les types de défaillance, par fonctionnalité, sévérité, urgence, etc.
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 d'acceptation, les modèles typiques sont les documents d'exigences, les cas d'utilisation, les organigrammes ou les diagrammes de flux par couloir. Des modèles plus techniques comme les modèles d'états, les diagrammes de collaboration, les diagrammes de séquence, etc., fournissent également une base solide pour la conception des tests.
Dans de nombreux projets, les modèles servent à capturer les exigences ou les conceptions de haut niveau. Lorsqu'ils sont mis à disposition des testeurs, ils peuvent être utilisés pour tracer des chemins afin d’identifier les éléments à couvrir directement à partir du modèle. Si de tels modèles ne sont pas disponibles, il est souvent utile que l’équipe de test les crée, par exemple sous forme de diagrammes de processus ou de flux par couloir. Ceux-ci facilitent les échanges avec les parties prenantes, notamment concernant l'approche de couverture.
Dans le domaine propriétaire, des outils émergent permettant de capturer des modèles tels que des organigrammes et de générer des cas de test en suivant des trajets selon un objectif de couverture, par exemple tous les liens, tous les processus, toutes les issues de décision, toutes les paires et tous les parcours. Ces outils peuvent être associés à des outils de gestion et de génération de données de test pour produire des combinaisons de données à utiliser lors de tests manuels ou automatisés.
Il existe aussi des outils qui permettent la modélisation directement dans les outils d'exécution des tests. Par exemple, ces outils permettent au développeur de test de référencer tous les champs d’une page web, de créer des liens pour ‘connecter’ ces champs, et de créer un modèle de navigation pour la page – le tout de façon graphique.
Le modèle est ensuite utilisé pour créer des routes de navigation afin d’élaborer une suite de tests qui répond à certains critères de couverture – de la même façon que les outils de modélisation ci-dessus. Ces outils d’exécution peuvent générer automatiquement des parcours de test à partir de critères choisis, ou les produire de manière aléatoire, et également produire des rapports de couverture à partir de ces modèles.
C'est un domaine actuellement en pleine évolution – surveillez l’émergence d’outils de modélisation qui prennent en charge la conception et la génération de tests, et d’outils d’exécution qui permettent la modélisation du système testé ainsi que la sélection et le reporting automatisés des chemins de test.
Propriétaire ou Open Source ?
Au cours des vingt dernières années, l'utilisation de 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 serveurs associés de Microsoft, ainsi que la perception générale que Linux/Unix est plus fiable et plus sécurisé que Windows, font que, dans de nombreux environnements, Linux/Unix est le système d’exploitation de choix pour les serveurs.
Bien que l'article discute des avantages et inconvénients des outils open source et propriétaires, si vous recherchez spécifiquement des solutions qui s'intègrent bien avec 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) montrent la popularité relative des systèmes d'exploitation et des produits serveurs Web. Environ 85 % des sites utilisent les serveurs Web open source les plus connus, Apache et Nginx.
La popularité de ces produits FOSS d'infrastructure prouve que l'open source peut être aussi fiable, voire plus, que les produits propriétaires.
Pour une équipe logicielle ayant besoin de vingt ou trente outils 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 quelques critères à considérer lors du choix du type d’outil.
| Propriétaire | FOSS | |
| Disponibilité | Des outils sont disponibles pour chaque domaine. | Certains domaines, en particulier les outils de développement et d'infrastructure, sont mieux couverts que d'autres. |
| Coût d’achat | Souvent cher, en particulier pour les produits « entreprise ». | Gratuit ou licence communautaire à coût nul. Il existe parfois des licences commerciales pour les versions entreprise ou hébergées. |
| Documentation | Généralement très bonne. | Variable. Parfois excellente, parfois inexistante, et tout l'entre-deux. Souvent rédigée par des programmeurs pour des programmeurs, donc moins accessible que la documentation commerciale. |
| Support technique | Très bon, mais payant. | Variable. Certains auteurs d’outils offrent un excellent support et peuvent même ajouter des fonctionnalités sur demande. De nombreux outils possèdent des forums en ligne – mais ceux-ci peuvent être très techniques. D’autres outils sont peu ou mal supportés. |
| Fiabilité/qualité | Généralement très bonne. | Variable. Les produits avec de nombreux utilisateurs, langues, grandes équipes de support ont tendance à être excellents. Certains outils développés par des individus, avec peu de contributeurs et d’utilisateurs, peuvent être instables. |
| Richesse fonctionnelle | Les fonctionnalités suivent généralement la feuille de route publiée du produit et sont souvent complètes. | Les produits évoluent en fonction de la demande des utilisateurs et de la taille de l'équipe de contributeurs. Les contributeurs ajoutent surtout les fonctionnalités dont ils ont besoin, plutôt que sur la base de sondages clients par exemple. |
| Fréquence des mises à jour/correctifs | Les principales versions sont généralement espacées de plusieurs mois, parfois d’années. Mises à jour de correctifs régulières. Les avertissements et notes de version sont généralement très détaillés. | Variable. Les grandes solutions d’infrastructure suivent le même rythme que les produits propriétaires. Les outils plus petits ou moins populaires publient plus souvent. Peu ou pas d’avertissement, notes de versions rares, et parfois perte de compatibilité ascendante. |
Les produits FOSS peuvent être moins chers à obtenir, mais d’autres coûts et responsabilités peuvent s’avérer significatifs. Le facteur décisif entre les deux repose généralement sur la culture de votre organisation, votre tolérance au risque et vos capacités techniques.
Lorsque vous achetez des produits propriétaires et des contrats de support, les risques liés à l’incompatibilité (avec d’autres produits), à la fiabilité, à la facilité d’utilisation et au support technique attentif sont généralement faibles, même si parfois coûteux.
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 entendu, une période d’essai est facile à mettre en place et vous pouvez essayer autant d’outils que vous le souhaitez, mais il vous faudra étudier pleinement les capacités des outils.
Une ergonomie moindre et une incompatibilité avec vos outils existants peuvent poser problème, ce qui vous obligera peut-être à développer des logiciels d’interface, des plug-ins, ou des utilitaires de reporting ou d’import/export de données.
Il vous faudra également former votre équipe et vous-même pour atteindre une bonne maîtrise, et en général assurer vous-même le support logiciel. Cependant, votre équipe aura une connaissance plus approfondie du fonctionnement de l’outil et sera largement autonome.
Un outil FOSS pourrait vous aider à acquérir de l’expérience sur un nouveau type d’outil à moindre coût. Avec cette expérience, vous serez mieux placé pour choisir un outil propriétaire sur le long terme.
Un exercice de sélection d’outil
Si vous cherchez un outil de gestion des tests pour accompagner votre projet actuel ou un projet/applications récents et familiers. Sur la base des domaines fonctionnels mentionnés précédemment concernant les outils de gestion de tests, dressez une liste de 15 à 20 fonctionnalités qui sont soit :
- Obligatoires
- Souhaitables
Cela peut inclure des fonctionnalités, des intégrations, un accent sur la convivialité, le support ou une grande base d’utilisateurs ou encore des forums FAQ en ligne. Si vous avez déjà un outil en place, ne le choisissez pas.
À partir du texte de vos besoins, recherchez dans la base de connaissances outils (« Base de connaissances des outils ») trois outils (incluant un produit propriétaire et un FOSS) qui semblent correspondre à vos attentes. À l’aide des descriptifs de fonctionnalités des outils, créez un tableau comparatif des trois produits. Ajoutez une quatrième colonne pour l’outil que vous utilisez actuellement – à titre de comparaison.
- Comment les outils se comparent-ils en termes de fonctionnalités ?
- Quelles fonctionnalités manquent au(x) outil(s) FOSS, en comparaison des outils propriétaires ?
- Combien d’outils existent qui répondent globalement à vos besoins ?
- Combien de temps pensez-vous devoir consacrer à la recherche d’outils pour établir une présélection de, disons, trois ?
Inscrivez-vous à la newsletter The QA Lead pour être informé de la publication des nouveaux volets de la série. Ces articles sont des extraits du cours Leadership In Test de Paul — hautement recommandé pour ceux qui souhaitent approfondir ce sujet et d’autres thèmes. Si vous vous inscrivez, utilisez notre code promo exclusif QALEADOFFER pour bénéficier de 60 $ de réduction sur le prix complet du cours !
Apprenez des autres testeurs en écoutant nos podcasts ou en consultant nos blogs. Voici un article dont nous pensons qu’il vous sera particulièrement utile : COMMENT MES COMPÉTENCES EN TEST M’ONT FAIT DEVENIR UN(e) MEILLEUR(E) DÉVELOPPEUR(EUSE) AUTOMATISATION
