Press "Enter" to skip to content

Creusons cette stratégie d’analyse de risque

Cette stratégie de gestion de risque est composée de plusieurs parties :

  1. Le changelog
  2. L’analyse de risque
  3. (Interne à l’équipe) Le plan de test de non-régression
  4. (Externe à l’équipe) La validation par les partenaires
  5. La stratégie de mise en production

Changelog

Qu’est-ce qui a été modifié ?

Le changelog est l’ensemble exhaustif des changements apportés par cette release.

Il était à l’origine rédigé par les développeurs. Par la suite ils ont mis en place une rigueur dans la rédaction des messages de commit GIT et désormais le changelog n’est rien d’autre que le condensé des messages de commit.

Analyse de risque

Qu’est-ce qui peut être potentiellement cassé ou impacté par cet ensemble de changements connus ?

L’analyse de risque requiert une manière de penser particulière, typiquement étrangère aux développeurs.

Si vous posez la question aux développeurs, ils penseront immédiatement à comment valider les changements ce qui tape complètement à côté de la question : ces nouveaux changements sont probablement la partie la mieux testée de l’application à ce moment présent. En effet, en amont de la mise en production, tout le monde a déjà dû tester ces changements dans tous les sens.

Au contraire ce que l’on veut vérifier c’est tout ce qui est autour du changement mais pas directement lié au changement en lui-même. Afin de gérer les impacts.

C’est là l’une des compétences clés des testeurs : effectuer des analyses de risques constitue le cœur de métier des testeurs. Les développeurs peuvent aussi apprendre cette compétence (ce qui fera d’eux de meilleurs développeurs) mais avoir un testeur à disposition dans l’équipe sera un gros avantage. Le binômage (pair-testing) est votre meilleur ami.

Plan de non-régression

Quels sont les tests que nous exécuterons pour gérer les risques que nous avons identifié ?

À nouveau, le but n’est pas de valider les changements mais de s’assurer que les changements n’ont rien cassé.

Le plan de test de non-régression est mis sur pied à partir de l’analyse de risque :

  • L’ensemble des scenarii de test qui doivent être exécutés pour bien couvrir la zone à risque
  • L’ensemble des devices/OS/browsers qui doivent être testés, d’un point de vue compatibilité

On peut aussi inclure des sessions de test exploratoire.

Validation par les partenaires

Quelles vérifications recommandons-nous aux partenaires ?

Nous ne travaillons pas en isolation. Nous avons différentes sortes de partenaires :

  • Nous produisons une librairie qui sera utilisée par des clients internes à l’entreprise
  • Certains fonctionnalités requièrent une validation formelle par une tierce partie afin de certifier que notre produit respecte bien les spécifications du marché
  • Certaines fonctionnalités sont sur le chemin critique de la rentrée d’argent, aussi nos partenaires voudront être sûr que l’équipe ne casse rien de lié à ces fonctionnalités

Comment traiter ces partenaires ? Comment les impliquer juste ce qu’il faut ? S’il est impossible de les éviter complètement, on ne veut pas non plus trop les impliquer car cela impacterait négativement la vitesse de l’équipe. En effet, la validation par les partenaires est en général longue et bloquante.

Dans cette section nous proposons un compromis entre une implication totale et une ignorance complète de la part des partenaires. Dans tous les cas, il ne s’agit que d’une recommandation : c’est aux partenaires de décider s’ils veulent la suivre ou non.

Il est essentiel de fournir la totalité de la stratégie de gestion de risque aux partenaires. Sinon ils ne seront pas capables de faire le choix entre suivre ou non nos recommandations. Ce n’est qu’en ayant toute l’information en main qu’ils sont capables de faire un compromis et d’éviter l’option de la non-régression complète.

Stratégie de mise en production

Va-t-on mettre en production incrémentalement ou bien d’un seul coup ? Dans le cas d’une mise en production incrémentale, quelles sont les étapes intermédiaires ?

Enfin, nous proposons une stratégie de mise en production.

Pour l’instant notre outillage n’est pas le plus adapté pour permettre de vrais déploiements progressifs. Aussi il peut arriver que nous préférions éviter les déploiements progressifs pour ménager nos efforts mais aussi pour accélérer notre rythme de mise en production.

Il y a aussi des cas de figure où un déploiement progressif n’aide pas vraiment à détecter rapidement les problèmes.

Enfin il est déjà arrivé que nos partenaires nous demandent explicitement un déploiement progressif en lieu et place de tests de non-régressions de leur côté.

C’est top que nos partenaires aient complètement confiance dans nos propres tests ! Bon, ils demandent quand même un déploiement progressif pour se rassurer 😋

Communication avec l’équipe des exploitants

C’est en effet extrait d’un ticket JIRA.

Hey ! C’est un ticket JIRA.

Oui, en effet. C’est parce que le process actuel de l’équipe d’exploitants est basé sur JIRA. Il semblait judicieux de partager les stratégies de gestion de risque avec l’équipe des exploitants. Et puisque nous cherchions un endroit pour les rédiger et stocker, alors ce ticket JIRA obligatoire était l’endroit logique.

Effet de bord intéressant : en liant l’analyse de risque à la création du ticket JIRA exploitation, nous nous assurions que ce ticket JIRA n’était pas créé au dernier moment. Une situation gagnant-gagnant !

Communication avec nos partenaires

Etant donné que la validation avec nos partenaires peut bloquer notre process, il est essentiel de mettre l’effort nécessaire pour bien gérer ces dépendances.

Pour réduire le risque de blocage, nous leur suggérons quelle validation ils devraient faire. Nous suivons le même mode de fonctionnement basé sur l’analyse de risque. Mais encore plus important, nous partageons tous les éléments qui nous ont menés à cette suggestion.

Si nous ne leur fournissons pas cette information (changelog + analyse de risque + quels tests seront effectués en amont d’eux) alors la seule option qui s’offre à eux est d’effectuer une passe de non-régression complète. Ce que nous essayons d’éviter à tout prix pour continuer d’avancer vite.

Pour éviter le test en boîte noire, il faut ouvrir la boîte.

Communication avec le reste de l’entreprise

Enfin, nous gardons le reste de l’entreprise informé des derniers changements dans le produit.

La vitesse de release de l’équipe rend simplement impossible une communication par e-mail à chaque release. À la place l’équipe a créé une salle spécifique dans le Slack de l’entreprise et y annonce les releases. Comme d’habitude, la totalité de la stratégie de gestion de risque est fournie.

En conclusion…

Faites une véritable analyse de risque mais, encore plus important, partagez-la avec le reste du monde !

Vous ne pouvez tout simplement pas demander aux autres équipes comment ils devraient tester votre produit si vous ne leur dites pas ce que vous avez fait à votre produit.

Une bonne communication est essentielle. Partagez l’information dont vous disposez.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Top