Leadership en Test : Outils de Test
Note de la rédaction : Bienvenue dans la série Leadership en Test animée par le 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 équipe agile—à exceller dans leurs rôles de chef de test et de management.
Dans l’article précédent, nous avons étudié 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 solutions propriétaires et open source, et un petit exercice de sélection d’outils.
Inscrivez-vous à la newsletter The QA Lead pour être prévenu·e de la publication des prochaines parties de la série. Ces articles sont des extraits du cours Leadership en Test de Paul, que nous vous recommandons fortement pour explorer ce sujet et d'autres plus en profondeur. 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 !
Les équipes logicielles qui s’auto-gèrent utilisent un éventail d’outils plus large que jamais. Il peut y avoir, dans une équipe type, vingt, voire trente outils utilisés en permanence. Pour vous aider à vous y retrouver, cet article couvrira :
- 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 examiner les principaux types d’outils que vous utiliserez pour les tests.
Outils pour les tests
Il est pratique de diviser les outils liés aux tests en trois types :
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
- Outils de collaboration : ils permettent de saisir les idées et les exigences, de faciliter la communication au sein de l’équipe avec parfois une intégration à des processus automatisés, voire des bots.
- Outils de test : un très large éventail d’outils pour la gestion des données de test, la conception de tests, les frameworks de tests unitaires, l’exécution de tests fonctionnels, les tests de performance et de charge, les tests statiques, la conception, la gestion du processus de test, les cas de test, la consignation et le reporting des tests.
- Outils DevOps ou de gestion d’infrastructure : ces outils gèrent l’administration des environnements et des plateformes, le déploiement via l’infrastructure as code et les containers, 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 des autres en couvrant la collaboration, les tests et le DevOps. On y trouve plus de 1700 outils répartis dans ces trois domaines. Les pages des outils sont indexées et il est possible de les rechercher.
Le site répertorie également plus de 300 blogueurs et plus de 52 000 articles de blog qui sont aussi indexés et consultables. Nous vous proposons des liens directs vers les principales catégories d’outils ainsi que des raccourcis permettant de rechercher ces catégories dans les blogs.
Il existe plus de 1700 outils dédiés à la collaboration, aux tests et au DevOps.
Nous étudierons plus loin dans cet article les principaux enjeux de la gestion des tests.
Architecture des outils
Le graphique ci-dessous présente le large éventail de types d’outils utilisés aujourd'hui par la plupart des équipes logicielles modernes. Nous avons distingué les outils utilisés en développement, en test et en production.
Ces outils reposent sur des outils d’infrastructure qui fournissent des plateformes, des machines virtuelles et des containers pour héberger les environnements, ainsi que des outils permettant les déploiements automatisés. Les outils utilisés pour gérer les déploiements et les livraisons sont appelés outils d’orchestration de release et de pipeline. La communication au sein de l’équipe, ainsi qu’avec de nombreux processus automatisés, est gérée par des outils de collaboration ou de ChatOps.
Bien que l’essor du DevOps favorise le développement et l’adoption d’outils destinés au développement continu, presque tous ces outils sont utiles à toute équipe de développement ou d'exploitation logicielle.
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 de grande envergure. Les projets agiles utilisent en général un outil de gestion des incidents et, en ce qui concerne les tests, s'appuient souvent sur l'utilisation d'histoires métier et de scénarios pour suivre des exemples clés, voire la totalité, des tests. Les outils de gestion des tests varient en termes d'étendue, allant de solutions très simples 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 permettent de définir un ensemble d'exigences contre lesquelles on associe des cas de test et/ou des vérifications dans les tests. Ces exigences peuvent parfois être hiérarchisées pour refléter une table des matières documentaire. De plus en plus, d'autres modèles tels que les cas d'utilisation ou les flux de processus métier peuvent être pris en compte. Des rapports de couverture du plan de test et d'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 constituer une trace documentaire 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 résultats attendus. Il est courant d'importer des documents et des images à associer aux tests ou aux étapes.
Planification de l'exécution des tests : Les tests peuvent être structurés hiérarchiquement ou étiquetés pour offrir une structure plus dynamique. Les membres de l'équipe de test peuvent se voir attribuer des tests. Les durées planifiées des tests peuvent être utilisées pour publier un calendrier synchronisé des tests à réaliser dans toute l'équipe. Des sous-ensembles de tests peuvent être sélectionnés pour atteindre la couverture des exigences, faire des essais ciblés, et relancer des suites de tests de régression. Les tests enregistrés comme non exécutés, bloqués, échoués ou avec un autre statut peuvent également être sélectionnés pour exécution.
Exécution et journalisation des tests : Lors de l'exécution des tests par l'équipe, leur statut est enregistré. Tout test exécuté aura le nom du testeur, la date/heure et la durée renseignés. Les tests réussis peuvent simplement recevoir un statut "réussi". Les résultats échoués, bloqués ou anormaux peuvent inclure des captures d'écran, les résultats correspondants, ainsi qu'un rapport d'incident associé. De nombreux outils offrent des liaisons avec des outils d’exécution de tests qui gèrent les tests, enregistrent les résultats, et créent même des projets de rapport d’incident.
Gestion des incidents : Les échecs de test sont consignés dans le journal d'exécution. Ceux-ci nécessitent généralement une investigation, avec des phases de débogage et de correction si l’échec est causé par un bug. Les échecs nécessitant une enquête sont habituellement enregistrés sous forme d’incident, d’observation ou de rapports de bugs. Les rapports d’incident peuvent recueillir de nombreuses informations complémentaires. En général, un incident reçoit un type, un objet testé, une priorité, et une sévérité. Certaines entreprises enregistrent une grande quantité d'informations et disposent de processus de gestion des incidents très sophistiqués.
Rapports : Rapports et analyses de données issues de l'ensemble des fonctionnalités ci-dessus, selon les besoins. L'éventail des rapports va de la couverture planifiée versus réelle, aux statuts des rapports d’incidents pour suivre les investigations en cours, la correction et la reprise des tests, l’analyse des temps de résolution selon les types d’échecs, par fonctionnalité, sévérité, urgence, etc.
L’outil de gestion de tests le plus utilisé au monde reste Microsoft Excel.
Conception des tests
La conception des tests repose sur des modèles. Pour les tests système et d’acceptation, les modèles courants sont des documents d'exigences, des cas d’utilisation, des organigrammes ou des diagrammes en couloirs. Des modèles plus techniques comme 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 sont utilisés pour définir les exigences ou les conceptions de haut niveau. Lorsqu’ils sont mis à disposition des testeurs, ils peuvent servir à tracer des parcours afin de couvrir directement les éléments de couverture à partir du modèle. Si ce type de modèle n’est pas disponible, il est souvent utile que l’équipe de test réalise par exemple des organigrammes de processus ou des diagrammes en couloirs. Cela aide les testeurs à avoir des échanges plus pertinents avec les parties prenantes, en particulier en ce qui concerne l’approche de couverture.
Dans le domaine propriétaire, des outils apparaissent qui permettent de capturer des modèles tels que des organigrammes et de les utiliser pour générer des cas de test en traçant les chemins selon un objectif de couverture donné, par exemple tous les liens, tous les processus, tous les résultats de décision, toutes les paires ou tous les parcours. Ces outils peuvent être connectés à des outils de gestion et de génération de données de test afin de produire des combinaisons de données pour des tests manuels ou automatisés.
Il existe également des outils permettant de réaliser la modélisation directement dans les outils d’exécution de tests. Par exemple, ces outils permettent au concepteur de tests de relever tous les champs présents sur une page web, de créer des liens entre les champs, et de construire un modèle de navigation pour la page – le tout sous forme graphique.
Le modèle est ensuite utilisé pour créer des parcours de navigation afin de concevoir une batterie de tests répondant à certains critères de couverture – exactement comme les outils de modélisation précités. Ces outils d’exécution peuvent générer automatiquement des parcours de test selon différents critères, ou les générer aléatoirement, et produire des rapports de couverture par rapport à ces modèles.
C’est actuellement un domaine en pleine évolution – soyez attentif aux outils de modélisation qui soutiennent la conception et la génération de tests, ainsi qu’aux solutions d'exécution qui intègrent la modélisation des systèmes à tester, la sélection automatisée des parcours et le reporting de couverture.
Propriétaire ou open source ?
Au cours des vingt dernières années, l'utilisation des logiciels libres et open source (FOSS), en particulier pour gérer les infrastructures, s'est largement répandue. Le coût des licences des systèmes d'exploitation et des logiciels associés de serveurs web de Microsoft, ainsi que la perception générale que Linux/Unix est plus fiable et sécurisé que Windows, font 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 inconvénients des outils open source et propriétaires, si vous recherchez spécifiquement des solutions bien intégrées à Jira, notre guide complet sur les outils de gestion de tests spécifiques à Jira peut vous aider à prendre une décision éclairée.
Les deux tableaux ci-dessous (mis à jour quotidiennement sur w3techs.com) illustrent la popularité respective des systèmes d'exploitation et des logiciels de serveurs web. Environ 85 % des sites fonctionnent avec les serveurs Web open source les plus connus, Apache et Nginx.
La popularité de ces produits d'infrastructure FOSS démontre 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 solutions FOSS et propriétaires fiables et fonctionnelles pour chaque usage. Comment choisir entre un produit propriétaire et un produit FOSS ?
Le tableau ci-dessous résume certains éléments à prendre en compte lors du choix du type d'outil.
| Propriétaire | FOSS | |
| Disponibilité | Des outils sont disponibles pour chaque domaine. | Certains domaines, en particulier le développement et les outils d'infrastructure, sont mieux soutenus que d'autres. |
| Coût d'achat | Souvent onéreux, en particulier pour les produits « entreprise ». | Gratuit ou licence communautaire à coût nul. Des licences commerciales peuvent exister pour les versions entreprise ou hébergées. |
| Documentation | Habituellement très bonne. | Variable. Parfois excellente, parfois inexistante et tout l'éventail entre les deux. Souvent écrite par des programmeurs pour des programmeurs, donc moins exploitable que la documentation commerciale. |
| Support technique | Très bon, mais payant. | Variable. Certains auteurs d'outils offrent un excellent support et ajoutent même des fonctionnalités sur demande. Beaucoup d'outils disposent de forums en ligne – mais peuvent être très techniques. D'autres outils sont peu soutenus. |
| Fiabilité/qualité | Habituellement très bonne. | Variable. Les produits avec de nombreux utilisateurs, localités, grandes équipes de support, ont tendance à être excellents. Certains outils développés par des individus, avec peu de contributeurs ou d'utilisateurs, peuvent être instables. |
| Richesse fonctionnelle | Les jeux de fonctionnalités suivent généralement les feuilles de route publiées et sont généralement complets. | Les produits évoluent souvent selon la demande des utilisateurs et la taille de l'équipe de contributeurs. Les contributeurs tendent à ajouter les fonctionnalités dont ils ont besoin plutôt que de se baser par exemple sur des enquêtes clients. |
| Fréquence de publication/mise à jour | Les principales versions sont espacées de plusieurs mois, voire années. Des patchs sont publiés régulièrement. Les avertissements et notes de mise à jour sont en général de très bonne qualité. | Variable. Les grands produits d'infrastructure publient leurs versions majeures comme les produits propriétaires. Les produits plus petits ou moins populaires ont tendance à sortir plus fréquemment. Peu ou pas d'avertissement, notes de version pauvres et perte de compatibilité ascendante à l'occasion. |
Les produits FOSS peuvent être moins coûteux à l’acquisition, mais d’autres charges et responsabilités peuvent être significatives. Le facteur décisif entre les deux dépend généralement d’un mélange de culture d’entreprise, d’appétence au risque et de capacité technique.
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 le support technique attentif sont généralement faibles, bien que parfois coûteux.
Avec les produits FOSS, il est généralement nécessaire de mener des recherches beaucoup plus approfondies avant de s'engager dans leur utilisation. Après tout, il n’y a pas de commercial à contacter et la documentation peut être simplement fonctionnelle plutôt qu'informative. Bien entendu, il est facile de configurer une période d’essai et vous pouvez tester autant d’outils que vous le souhaitez, mais il faudra procéder à une analyse plus approfondie des capacités de l’outil.
Une moins bonne ergonomie et des incompatibilités avec vos outils existants peuvent poser des problèmes, il peut donc être nécessaire d’écrire des logiciels d'interface ou des plug-ins ainsi que des outils de rapport ou d’import/export de données.
Il vous faudra aussi former votre équipe et vous-même pour prendre l’outil en main et assurer le support logiciel par vos propres moyens. Cependant, votre équipe acquerra une connaissance plus fine du fonctionnement de l’outil et sera globalement autonome.
Un outil FOSS pourrait vous aider à acquérir de l'expérience avec 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’outils
Si vous recherchez un outil de gestion des tests pour soutenir votre projet actuel ou un projet récent et familier, ainsi que l’application associée. Sur la base des domaines fonctionnels évoqués dans la discussion sur les outils de gestion des tests ci-dessus, faites une liste de 15 à 20 fonctionnalités qui sont soit :
- Obligatoires
- Souhaitables
Cela peut inclure des capacités fonctionnelles, des intégrations, un accent mis sur la facilité d’utilisation, un support, une large base d’utilisateurs ou des forums en ligne/FAQ. Si vous avez déjà un outil en place, n’utilisez pas celui-là.
En utilisant le texte de vos besoins, recherchez dans la base de connaissances des outils pour trouver trois outils (y compris un produit propriétaire et un produit FOSS) qui semblent répondre à vos exigences. À partir des descriptions des fonctionnalités des 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 – à titre de comparaison.
- Comment les outils se comparent-ils en termes de fonctionnalités ?
- Quelles fonctionnalités le ou les outils FOSS n’ont-ils pas, comparés aux outils propriétaires ?
- Combien d’outils existent qui répondent globalement à vos besoins ?
- D’après vous, combien de temps faudrait-il prévoir pour rechercher les outils et établir une présélection, disons de trois ?
Inscrivez-vous à la newsletter The QA Lead pour être averti lorsque les nouveaux volets de la série seront publiés. Ces articles sont des extraits du cours Leadership in Test de Paul— fortement recommandé pour ceux qui souhaitent approfondir ce sujet et d’autres. Si vous vous inscrivez, utilisez notre code promo exclusif QALEADOFFER pour profiter de 60 $ de réduction sur le prix total du cours !
Apprenez des autres testeurs en écoutant nos podcasts ou en consultant nos blogs. En voici un dont vous pourrez tirer de nombreux enseignements : COMMENT LES COMPÉTENCES EN TEST M’ONT FAIT DEVENIR UN MEILLEUR DÉVELOPPEUR AUTOMATISATION
