Leadership en Test : Documentation
Note de la rédaction : Bienvenue dans la série Leadership en Test du gourou et consultant en tests logiciels 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 chef de test et de gestionnaire.
Dans l’article précédent, nous avons décrit un manifeste du risque à l’intention des managers. Dans cet article, nous allons aborder la question classique : « Combien de tests sont suffisants ? » Révélation : cela dépend des parties prenantes.
Abonnez-vous à la newsletter The QA Lead pour être informé de la publication des nouveaux épisodes de cette série. Ces articles sont extraits du cours Leadership en Test de Paul, que nous vous recommandons vivement pour approfondir ce sujet et d'autres. Si vous vous inscrivez, utilisez notre code promo exclusif QALEADOFFER pour bénéficier d’une réduction de 60 $ sur le prix total du cours !
Quel que soit le projet, l’organisation ou la méthode, il y a toujours une place pour la documentation. Une bonne documentation est une bénédiction, offrant un historique utile de la démarche, du périmètre, des plans, des conceptions et des résultats d’analyse, de développement et d’activités de test.
Dans cet article, je vais aborder :
- La valeur de la documentation
- Les dangers des modèles et du copier-coller
- Types de documentation de test
- Conseils pour concevoir la documentation
C’est parti.
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
La valeur de la documentation
Dans les projets structurés, les documents sont généralement considérés comme des livrables à part entière. Dans les approches agiles ou en continu, la documentation peut être produite comme sous-produit, de valeur plus ou moins grande.
La rédaction de documents peut être l’activité principale de rédacteurs techniques professionnels mais, pour la plupart des praticiens, c’est une corvée — quelle que soit son utilité. Même si la rédaction de documents peut sembler ennuyeuse à certains, le vrai problème avec la documentation, c’est que dans de nombreux contextes, la plupart des documents ne servent à rien. Ils ont peu de valeur, sont obsolètes, inexacts — ou tout cela à la fois.
Chaque chef de test a déjà rédigé des stratégies de test que personne n’a lues ou approuvées. Les testeurs écrivent des tonnes de plans de test, de scripts et de rapports, et le seul contenu réellement utile pour les parties prenantes se résume aux synthèses d’une page au début ou à la fin.
Nous avons tous rédigé des documents dont nous savions qu’ils n’avaient que peu de valeur et que personne ne lirait.
Cela provient de problèmes courants liés à la documentation, que l’on rencontre dans les petits comme dans les grands projets. Pour chaque document que nous rédigeons, plusieurs questions doivent être posées :
- Quel type de document ? Une politique ou une stratégie, une approche ou un plan, une conception ou une mise en œuvre, ou encore un résultat et son interprétation ?
- Quel est l’objectif du document ?
- Quel contenu est nécessaire pour atteindre cet objectif ?
- Quelles sources d’informations sont nécessaires pour créer ce contenu ?
- Si le document doit évoluer dans le temps, comment sera-t-il maintenu ?
- Quel niveau de détail est requis ?
Les dangers des modèles et du copier-coller
Si votre projet exige un certain type de document, comme un plan de test système ou un registre des risques, il peut être tentant de trouver un modèle prêt à l’emploi pour ces documents (et beaucoup d’autres) sur Internet.
Certains modèles peuvent prétendre répondre à une norme ou à une convention, et avoir été téléchargés et utilisés des milliers de fois. Parfois, un modèle peut sembler correspondre exactement à votre besoin. Mais, comme nous allons le voir, même si la table des matières paraît complète, cela peut vous attirer des ennuis.
Il peut aussi arriver que vous, ou d’autres personnes de votre entreprise, ayez rédigé un document similaire pour un projet précédent. Vous pourriez être tenté de le copier, de le renommer, de changer les références à l’ancien projet et de modifier le contenu pour l’adapter.
Avertissement : D’après mon expérience en tant que relecteur indépendant, cette pratique est très courante et souvent source de vrais problèmes.
Premièrement, il est généralement évident qu'une copie/modification a été réalisée. Le langage utilisé dans le texte semble souvent déconnecté du projet et il y a des lacunes ainsi que du texte superflu partout. Pourquoi cela ?
Utiliser un modèle préformaté ou un document existant comme source comporte plusieurs risques :
- Le document semble complet, mais il peut inclure des sujets inappropriés et en exclure d'autres qui sont essentiels.
- Il fournit des titres de section, mais aucune indication sur le contenu approprié à chaque rubrique.
- Il peut contenir du texte qui semble réutilisable et qui est copié tel quel depuis un projet antérieur non lié, mais ce texte peut donner une mauvaise impression, ou être inexact ou incomplet.
L’utilisation de modèles pour obtenir des titres et une mise en page de base peut être utile, mais le principal problème des modèles est le suivant :
La tentation avec les modèles est de leur accorder une confiance excessive puis de rédiger des banalités dans les différentes sections. Après tout, on peut penser que le document sert à « cocher une case » et que personne ne le lira de toute façon. Le risque des modèles est que vous cessiez de réfléchir et produisiez un document ayant peu de valeur.
Types de documentation de test
Dans cette section, nous allons examiner les différentes formes de documentation de test et aborder certaines considérations concernant les projets structurés ou agiles/continus par rapport à l’approche classique en cascade.
L'ensemble principal des documents de test se répartit généralement dans les catégories suivantes :
- Politique et stratégie (parfois appelé Plan Directeur de Test)
- Définition des tests (également appelée spécification ou plan de tests, de manière confuse)
- Conception des tests
- Cas de test
- Procédures ou scripts de test
- Exécution des tests
- Calendrier
- Journal
- Rapport de test
La gamme ci-dessus de types de documents couvre la définition du processus de test, les activités clés de définition, d’exécution et de rapport.
Il existe plusieurs autres documents liés aux tests qui, dans des environnements plus bureaucratiques, incluraient la définition et la gestion de l’environnement de test, les procédures d’acceptation, les processus de gestion des incidents, etc. (nous traiterons la gestion des incidents dans un prochain article).
Une autre omission évidente dans la liste ci-dessus est un plan ou un calendrier global pour les activités de test. Un calendrier n'est pas réellement un document de test ; il s'agit d'une partie intégrante du plan global de projet pour un projet structuré (nous aborderons également la planification du calendrier dans un prochain article, alors restez attentif !).
Politique, stratégie, plan directeur de test
| But |
|
| Contenu |
|
| Sources |
|
| Maintenance |
|
Considérations Agile/Continues La stratégie de test pour des projets agiles utilisant Scrum, par exemple, sera probablement assez brève et composée de seulement quelques pages (si elle est même documentée). Le processus de test peut ne pas avoir de stades distincts, mais il est probable qu'il y ait une définition des tests à différents niveaux. Par exemple :
Le rôle du testeur pourrait être de tester de façon interactive les fonctionnalités au fur et à mesure qu’elles sont publiées par les développeurs, ou d’agir comme coach test auprès du reste de l’équipe. Comme pour l’utilisation d’outils et/ou TDD, la manière de travailler évolue au fil du temps et peut ne jamais être formalisée. | |
Définition des tests (conception, cas, procédures)
| But |
|
| Contenu |
|
| Sources |
|
| Maintenance |
|
Considérations Agile/Continues C’est dans la définition des tests que l’approche agile diffère le plus des projets structurés. Potentiellement, les testeurs qui se concentrent sur les fonctionnalités au fur et à mesure qu’elles sont livrées peuvent ne pas rédiger de documentation du tout. Cela est approprié s’il existe une politique ou une charte générale pour les tests de fonctionnalités, par exemple. Il y aura plus vraisemblablement une brève charte pour tester chaque fonctionnalité dans une session de test exploratoire. Une charte est comme un plan pour une courte période d’exploration. Elle identifie habituellement :
| |
Exécution des tests (Planification, Journal)
| Objectif |
|
| Contenu |
|
| Sources |
|
| Maintenance |
|
Considérations agiles/continues Si les projets agiles/continus ne s’engagent pas sur des documents de définition des tests, ils compensent en encourageant les testeurs à tenir de meilleurs journaux d’exécution des tests. Lorsque les tests sont effectués en sessions selon des chartes, le testeur est censé prendre de bonnes notes sur les tests qu’il exécute. Il existe peu d’outils dédiés au journal de test qui soient plus que de simples carnets de notes ; ainsi, beaucoup de testeurs utilisent des éditeurs de texte simples, des applications de prise de notes ou des carnets papier. Les journaux servent généralement à enregistrer toutes les activités et observations importantes pendant les sessions au fur et à mesure. Un journal typique de test exploratoire contiendra différents aspects tels que :
| |
Rapport de test
| Objectif |
|
| Contenu |
|
| Sources |
|
| Maintenance |
|
| Considérations Agile/Continues L’objectif d’un rapport de test dans un projet agile peut couvrir une seule itération ou un sprint, le test pour une livraison, ou une phase de test de niveau supérieur telle que l’intégration ou l’acceptation globale du système. Dans tous les cas, l’objectif reste inchangé. Une grande partie du contenu du rapport de test sera issue des outils ou des notes des testeurs. Le résumé narratif des résultats est rédigé par le responsable de test ou le testeur pour une phase de test de moindre ampleur. Comme souvent, le rapport sera probablement moins formel et il y aura sûrement moins de données brutes pouvant servir de base à des analyses sophistiquées. Il est certain que, lors des itérations, la progression au fil de l’itération – en termes de fonctionnalités ou d’histoires livrées, testées et approuvées par les utilisateurs – pourra être consignée dans un outil ou sur un tableau KanBan public. De cette façon, les parties prenantes sont tenues informées des progrès au fil de l’itération et la nécessité d’un rapport formel à la fin de la période de test s’atténue. La visibilité de la progression est une préoccupation majeure pour les équipes agiles. Grâce à des points quotidiens autour d’un tableau Scrum, par exemple, les membres de l’équipe partagent leur compréhension de la progression, se questionnent mutuellement et s’accordent en permanence sur la situation et les prochaines étapes. Ainsi, un rapport de test formel peut ne jamais être nécessaire, car l’équipe est toujours informée et à jour. Si les testeurs consignent des notes écrites de leurs activités de session, il n’existe alors pas de données exploitables pour générer des rapports automatisés. Les comptes-rendus de sessions et l’avancement peuvent donc être présentés de manière publique et visuelle. Cela exige une discipline élevée et de bonnes compétences de communication chez les testeurs. Le responsable ou manager de test devra alors fournir un rapport tout aussi informatif aux parties prenantes, basé sur des comptes-rendus oraux. | |
Quelques conseils
Le sujet de la documentation dans les projets est un sujet sensible aussi bien pour les testeurs que pour les autres membres de l’équipe.
La plupart des gens considèrent la rédaction de documentation comme une corvée.
Voici quelques éléments à garder à l’esprit lors de la conception de votre documentation.
- La documentation doit avoir un objectif et un public clairement définis. Si votre public n’a pas besoin de la documentation, il ne la lira pas. Si elle ne correspond pas à ses propres buts, il ne s’y impliquera pas.
- Il est généralement préférable de consigner l’activité au moment où vous l’effectuez, voire avant. Par exemple, la TDD (développement piloté par les tests) prévoit la création de tests avant de coder. Les journaux de session de test doivent être réalisés pendant la session, pas après coup.
- Les données essentielles à la traçabilité d’un aspect des tests peuvent être minimales. Par exemple, une note dans un carnet peut suffire au testeur mais sera difficilement analysable. Un simple journal texte enrichi d’un balisage pourrait être aussi rapide à saisir et analysable par un outil personnalisé.
- Les procédures de test ne sont pas forcément nécessaires si les testeurs connaissent bien le système à tester. Un objectif ou une charte de test peuvent suffire. Les cas de test préparés peuvent être documentés au minimum dans un simple tableau.
Pour finir
La nécessité est la mère de la documentation.
Si vous préparez une documentation exhaustive pour vos parties prenantes et qu’ils ne la lisent pas, c’est qu’ils n’y voient pas de valeur ajoutée.
Il vaut mieux présenter une feuille blanche à votre partie prenante et compléter ensemble les sujets qu’elle souhaite voir dans le document, puis travailler à partir de cette base. Peut-être demanderont-ils des pages de contenu, mais ce dont ils ont vraiment besoin est souvent bien plus simple. Continuez de demander : « Pourquoi veulent-ils cela ? »
Merci de votre lecture, retrouvez-nous la prochaine fois alors que nous retroussons nos manches et nous lançons dans un peu de planification de tests.
Inscrivez-vous à la newsletter The QA Lead pour être informé lorsque de nouvelles parties de la série sont publiées. 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 bénéficier de 60 $ de réduction sur le prix total du cours !
