Automatisez des tests fonctionnels pour le web avec Cypress

Évitez le conflit et le jugement

Les parties prenantes, également appelées intervenants ou acteurs, désignent l'ensemble des individus, groupes ou entités qui sont directement ou indirectement impliqués dans votre projet. Elles peuvent avoir un intérêt, un rôle ou une influence sur les décisions prises et les résultats obtenus. La liste des parties prenantes peut être très spécifique à chaque projet et varier en fonction de l'industrie, de la portée du projet et du contexte. Elles jouent généralement un rôle essentiel dans la réussite et la réalisation des objectifs. L’identification et une gestion appropriées des parties prenantes sont donc essentielles pour garantir une communication fluide, une collaboration efficace et la réussite globale du projet en répondant aux besoins et aux attentes de tous.

Les parties prenantes peuvent être classées en deux catégories principales :

1. Parties prenantes internes :

• Équipe de projet : les membres directement impliqués dans la réalisation du projet, tels que les chefs de projet, les développeurs, les concepteurs, les testeurs, etc.

• Direction et gestionnaires : les dirigeants et les responsables qui prennent des décisions stratégiques et allouent des ressources au projet.

• Collaborateurs et employés : ceux qui contribuent de manière opérationnelle à la mise en œuvre du projet.

• Départements fonctionnels : les unités ou départements spécifiques (marketing, finances, RH, etc.) qui peuvent être impactés par le projet.

• Utilisateurs finaux : les personnes au sein de l’entreprise ou du groupe qui utiliseront le produit, le service ou le résultat final du projet.

2. Parties prenantes externes :

• Clients et utilisateurs : ceux qui achèteront ou utiliseront le produit ou le service résultant du projet.

• Fournisseurs et partenaires : les entités externes qui fournissent des ressources, des services ou des composants nécessaires au projet.

• Investisseurs et actionnaires : les personnes ou les groupes qui ont investi des capitaux dans l'entreprise ou le projet.

• Autorités réglementaires : les organismes gouvernementaux ou entités chargés de veiller à la conformité aux règlements et aux normes.

• Groupes de défense des consommateurs : les organisations qui représentent les intérêts des consommateurs et des utilisateurs finaux.

Une fois que les parties prenantes impliquées dans un projet ou une initiative ont été identifiées, il devient impératif de maintenir des relations harmonieuses et constructives entre elles. 

Cependant, il est important de reconnaître que la dynamique entre les parties prenantes peut être sujette à des défis potentiels, notamment lorsqu'il s'agit de gérer les retours d'informations critiques, tels que ceux issus des bilans de test. 

Lors d’un bilan de test, il est important d’éviter le conflit et le jugement. Cela peut s’avérer un terrain délicat sur lequel naviguer. Vous serez souvent perçu comme porteur de mauvaises nouvelles en rapportant des défauts, et vous pouvez involontairement susciter des tensions au sein des équipes de développement. Il est crucial de ne pas oublier que les développeurs sont des êtres humains sujets à l'erreur, et qu’ils ont le droit d’en faire. 

Dans cette optique, la communication des informations factuelles sur les problèmes découverts et l'analyse des risques associés exigent des compétences relationnelles de haut niveau. Vous devez adopter une approche empathique et délicate lorsque vous partagez les résultats des tests avec les différentes équipes et les différents interlocuteurs. L'objectif est de souligner que la détection de défauts vise à améliorer la qualité globale du produit plutôt que de mettre la faute sur certains individus.

Pour prévenir les conflits, il est essentiel de rappeler constamment l'objectif commun qui unit toutes les parties prenantes. En mettant en avant l'engagement collectif envers l'excellence et la satisfaction du client, les équipes sont plus enclines à dépasser les différences d'opinion et à travailler ensemble de manière constructive. La collaboration est la clé pour transformer les défis en opportunités d'apprentissage et d'amélioration.

Comprendre les sentiments et les perspectives des autres est également un élément crucial dans la prévention des conflits. Il est important de se mettre à la place de la personne qui a développé la fonctionnalité ou rédigé les spécifications, et de reconnaître les efforts qu'elle a déployés. En adoptant une attitude respectueuse et en montrant de l'empathie envers les défis rencontrés par chaque membre de l'équipe, il devient plus facile de maintenir un climat de compréhension mutuelle.

En résumé, éviter le conflit et le jugement dans un bilan de test pour les parties prenantes nécessite une approche équilibrée et sensible. Vous devez faire preuve d'empathie, de compétences relationnelles solides et d'une compréhension approfondie des émotions et des perspectives de vos collègues. En mettant en avant l'objectif commun, en favorisant la collaboration et en reconnaissant l'humanité derrière chaque erreur, il est possible de créer un environnement où les bilans de test deviennent des outils de croissance plutôt que des sources de conflit.

Rédigez des rapports d’incidents ou d’évolution

La rédaction de rapports d'incidents ou d'évolution joue un rôle crucial dans la gestion efficace de tout projet ou système. Ces rapports sont essentiels pour documenter et communiquer les problèmes, anomalies, améliorations ou évolutions identifiés lors du développement, des tests ou de l'utilisation. Ils assurent la transparence, la traçabilité et favorisent l'amélioration continue au sein de l'organisation.

Lorsqu'il s'agit de rédiger des rapports d'incidents, il est primordial de documenter avec précision tout problème ou dysfonctionnement rencontré. Ces rapports doivent contenir des informations telles que : 

• la description du problème ;

• les étapes pour le reproduire ; 

• la gravité de l'incident ;

• le contexte dans lequel il s'est produit ;

• tout autre élément pertinent. 

Avant de soumettre un rapport, assurez-vous de vérifier qu'aucun défaut similaire n'a déjà été rapporté en faisant une recherche des tickets ouverts, par exemple.

Pour faciliter la résolution rapide et efficace des incidents, il est recommandé d'utiliser un template de rapport d'incident. Le rapport doit contenir :

• le navigateur et la version du navigateur utilisés ;

• le système d'exploitation ;

• les étapes détaillées pour reproduire l'incident ;

• les résultats obtenus ainsi que vos attentes initiales ;

• le cas échéant, si l'incident implique une API, des notes pour aider les développeurs à comprendre le contexte.

Il est parfaitement approprié d'inclure des captures d'écran ou des vidéos dans votre rapport d'incident. Cela peut non seulement aider les équipes de développement à mieux comprendre le problème, mais aussi éviter des questions redondantes ou des retours vers l'équipe de testeurs.

Même si les tests ont été automatisés, la rédaction d'un rapport d'incident reste pertinente. Elle permet de vérifier ultérieurement que la régression a bien été résolue et peut contribuer à l'analyse des tendances à long terme.

En ce qui concerne les rapports d'évolution, ils ont pour objectif de présenter des idées d'amélioration, de nouvelles fonctionnalités ou des changements souhaités pour le projet ou le système. Assurez-vous de fournir une justification claire et détaillée pour chaque évolution proposée, en mettant en avant les avantages potentiels pour le projet ou l'entreprise.

En somme, la clarté, la précision et la concision sont les maîtres mots dans la rédaction de ces rapports. En documentant minutieusement les problèmes rencontrés et les suggestions d'amélioration, vous aidez à la gestion efficace du projet, à la prise de décisions éclairées, à la poursuite de l'amélioration continue ainsi qu’à la création d’un historique précieux pour analyser les tendances, identifier les points faibles et mettre en œuvre des solutions pertinentes. 

On peut aussi rédiger les rapports d’incidents et d’évolution à l’aide d’un gestionnaire de tickets, également connu sous les noms de système de suivi des problèmes ou de logiciel de suivi des incidents. Il s’agit d’outils conçus pour vous aider à gérer, suivre et résoudre efficacement les incidents, les demandes et les évolutions dans divers contextes, tels que la gestion de projets, le support client, le développement logiciel, et plus encore.

À titre d’exemple, on peut citer les gestionnaires de tickets suivants :

• Jira : Jira est l'un des outils les plus utilisés. Il propose des fonctionnalités de personnalisation avancées, des tableaux de bord et des rapports détaillés.

• Microsoft Azure DevOps : anciennement connu sous le nom de Visual Studio Team Services (VSTS), cet outil propose des fonctionnalités de suivi des tickets et de gestion de projet pour les équipes de développement logiciel.

Vous avez rédigé vos rapports, maintenant vous allez regrouper toutes les informations afin de rédiger le bilan de campagne.

Rédigez le bilan de campagne

Le bilan de campagne de test est un document qui rassemble les résultats, les observations, et les conclusions tirées des activités de test effectuées pendant une période déterminée ou pour un objectif spécifique. Ce bilan permet d'évaluer la qualité du produit ou du système testé, de prendre des décisions éclairées et de fournir des informations cruciales pour les parties prenantes du projet.

Votre bilan de campagne de test doit contenir les étapes ci-dessous. La majorité de ces étapes doivent vous être familières grâce à tout ce que vous avez vu dans ce cours :

1. Introduction à la campagne de test :

• Présentation du projet ou de la version du logiciel testée.

• Contexte de la campagne, y compris les objectifs de test et les critères de succès.

2. Plan de test initial :

• Description détaillée du plan de test établi en amont de la campagne.

• Énumération des scénarios de test, des cas de test et des environnements ciblés.

3. Exécution des tests :

• Résumé des activités d'exécution de test, manuelles et automatisées.

• Détails sur les outils de test utilisés, les configurations et les jeux de données.

4. Résultats des tests :

• Présentation des résultats bruts des tests, y compris les succès, les anomalies et les défauts.

• Utilisation de captures d'écran, de journaux de test et d'autres éléments visuels pour étayer les résultats.

5. Analyse des résultats :

• Analyse approfondie des résultats, en mettant l'accent sur les tendances et les performances notables.

• Comparaison des résultats aux attentes et aux objectifs de test fixés.

6. Enseignements tirés :

• Identification des principaux enseignements tirés de la campagne de test.

• Réflexion sur les aspects positifs et les domaines nécessitant des améliorations. 

7. Recommandations d'amélioration :

• Proposition de recommandations spécifiques pour optimiser les futurs processus de test.

• Suggestions d'améliorations techniques, méthodologiques ou organisationnelles.

8. Couverture et suivi des anomalies :

• Présentation de la couverture des anomalies, y compris leur statut (ouvertes, résolues, fermées).

• Explication des mesures prises pour résoudre les problèmes identifiés.

9. Performance des ressources de test :

• Évaluation de l'utilisation des ressources de test (temps, personnel, environnements).

• Identification des éventuelles contraintes ou éventuels défis rencontrés lors de la campagne.

10. Conclusion et leçons apprises :

• Résumé global des enseignements clés et des conclusions tirées.

• Présentation de l'impact global de la campagne de test sur la qualité du logiciel.

Présentez le bilan de campagne

Votre bilan fini, il est temps de communiquer à vos parties prenantes vos résultats. Pour cela, vous allez rédiger un document tel que présenté ci-dessus, et selon votre stratégie d’entreprise ou d’équipe. On peut tout simplement écrire un document PowerPoint ou Word par exemple.

L’important c’est de rédiger votre document et de l’envoyer sur le canal choisi par l’entreprise : e-mail, stockage sur le cloud, Teams…

À vous de jouer !

Rédigez un rapport d’incident avec l’analyse que vous en avez faite sur l’incohérence que vous avez trouvée dans le À vous de jouer précédent : le formulaire ne devrait pas s’envoyer quand le message est supérieur à 250 caractères.

Vous pouvez utiliser le rapport d’incident mentionné dans ce chapitre.

Consultez la suggestion de corrigé.

En résumé

• Il est important de connaître les personnes, groupes ou entités impliqués dans le projet ainsi que leurs rôles.

• Utilisez un langage positif sans jugement lors de la communication des résultats des tests, et prenez en considération les émotions et les perspectives de toutes les parties prenantes.

• Mettez en avant les objectifs partagés pour favoriser une compréhension mutuelle et encouragez la collaboration entre les parties prenantes pour résoudre les défis et trouver des solutions.

• Les rapports d'incidents documentent les problèmes avec précision, en fournissant de nombreux détails.  

• Les gestionnaires de tickets servent à gérer les incidents, les demandes et les évolutions dans divers contextes tels que le support client, la gestion de projets et le développement logiciel.

• Le bilan de la campagne doit détailler le projet, les tests, leur exécution, les résultats et l’analyse de ceux-ci. Il peut aussi contenir des recommandations d’amélioration et les leçons apprises, par exemple.              

• Pour communiquer les résultats d'une campagne de test aux parties prenantes, rédigez un document bien structuré incluant une introduction, le contexte, la méthodologie de test, les résultats, l'analyse, les enseignements tirés et les recommandations.

Bravo, vous avez rédigé votre bilan de campagne, il est temps de le communiquer à vos parties prenantes !