Imaginez que le logiciel le plus important de votre entreprise tombe soudainement en panne. Que se passerait-il ? Les commandes pourraient être perdues, les délais non respectés, et les clients se plaindraient.
Ce scénario cauchemardesque peut être évité en mettant en place un processus de test continu et rigoureux qui détecte les problèmes avant qu'ils ne provoquent le chaos. Toutefois, il est plus facile à dire qu'à faire.
Ce document vous explique tout ce que vous devez prendre en compte lorsque vous commencez à effectuer des tests dans votre entreprise, et comment vous pouvez en tirer parti à long terme.
Bonnes pratiques de test pour les équipes produit
La première partie de ce document décrit le processus de mise en œuvre des tests dans votre workflow.
Mettre en place une culture de test dans votre équipe
Pour réussir à introduire les tests dans votre équipe, il est essentiel que tous partagent un état d'esprit commun et considèrent la qualité non pas comme une contrainte, mais comme un investissement. Comme tout changement culturel, ce processus nécessite du temps et de la cohérence.
Les réunions régulières pour discuter des défauts, de leur impact, de leur origine et de la manière dont ils ont été corrigés peuvent contribuer à façonner cette culture. Cela permet de sensibiliser les équipes à l'importance de prévenir ces défauts dès le départ.
Le fait qu'une personne dédiée de l'équipe supervise et dirige les efforts peut fortement augmenter les chances de succès. Cette personne définit des consignes à l'échelle de l'équipe, voire de l'organisation, collecte les bonnes pratiques, les partage et défend les efforts à tous les niveaux.
Un autre instrument utile peut consister à faire tourner le rôle d'assistance de votre produit. Obtenir des informations directes et non filtrées de vos clients, et découvrir les problèmes quotidiens qu'ils rencontrent avec votre produit peut être une expérience précieuse pour les chefs de produit, les concepteurs et les développeurs.
L'objectif est que tous les membres de votre équipe comprennent que la qualité est une fonctionnalité, aussi importante que toute autre fonctionnalité que vous créez pour votre produit. Une fois que tout le monde a adopté cet état d'esprit, il est naturel de comprendre que les tests sont également une fonctionnalité. En effet, les tests garantissent la qualité du produit livré.
Processus de test étape par étape
Une fois que les différentes équipes impliquées dans le développement du produit sont alignées, vous pouvez formaliser davantage l'existence et l'utilisation des tests.
Intégrer les tests à la "définition de terminé"
En ajoutant les tests en tant qu'exigence de fonctionnalité, vous indiquez qu'une fonctionnalité n'est pas prête à être livrée tant qu'elle n'a pas été testée correctement et automatiquement.
Effectuer des tests régulièrement
Une fois mis en œuvre, les tests automatisés peuvent vous protéger à chaque étape du processus de développement. Ils ne nécessitent aucune intervention humaine et peuvent être exécutés à chaque étape critique de votre pipeline de développement. Exemple :
- À chaque commit.
- À chaque demande d'extraction.
- Après chaque version complète ou modification de l'environnement.
Si vous vous appuyez sur des services tiers dans votre environnement de production, il peut même être judicieux d'exécuter vos tests en production pour vous assurer que les API tierces se comportent comme prévu.
Définir et collecter des métriques
Il est important de définir un ensemble de métriques pour mesurer l'efficacité de vos tests et l'impact des workflows de test sur votre entreprise. Voici quelques exemples de métriques que vous pouvez utiliser :
- Versions par mois : un nombre plus élevé de versions par mois peut indiquer un processus de développement plus agile. Les tests automatisés jouent un rôle clé ici en garantissant que les versions peuvent être déployées en toute confiance.
- Rapports de bugs : une tendance à la baisse des rapports de bugs peut être un signe positif que vos processus de test (et de développement) sont efficaces.
- Couverture des tests : bien qu'il ne s'agisse jamais d'une métrique exacte, la couverture peut être un bon indicateur de la profondeur avec laquelle vous testez les cas d'utilisation critiques.
Notez que ces métriques sont également influencées par d'autres facteurs qui peuvent les fausser. Par exemple, le nombre de versions peut diminuer pendant les fêtes de fin d'année, tandis que les rapports de bugs augmentent. Ne vous fiez donc pas à quelques métriques seulement et assurez-vous de les croiser avec d'autres données disponibles pour votre équipe.
Lorsque vous mettez en œuvre ces étapes avec succès dans votre équipe, la santé de votre produit en bénéficiera certainement à long terme. Mais vous pouvez faire encore plus.
Bonnes pratiques de test pour les administrateurs système
Les équipes produit ne peuvent pas travailler seules. Elles s'appuient sur le matériel, les outils et l'infrastructure gérés par les administrateurs système. Bien que les administrateurs système ne contribuent généralement pas directement au développement du produit, ils peuvent tout de même influencer positivement le workflow de développement. Par exemple, en gérant activement la version du navigateur utilisée par certains groupes d'utilisateurs de l'entreprise.
Cette deuxième partie de l'article explique comment cela fonctionne, à l'aide des canaux de publication de Chrome et des règles d'entreprise.
Canaux de publication Chrome
Il existe quatre canaux de publication : stable, bêta, en développement et Canary.
Pour en savoir plus, consultez Canaux de publication Chrome.
Utiliser des canaux dans une organisation exemplaire
La structure des équipes produit varie d'une organisation à l'autre, car il n'existe pas d'approche unique pour le développement de logiciels. À titre d'exemple, nous allons supposer une équipe avec les rôles suivants : gestion des produits, UX et UI, ingénierie, opérations et assistance.
Pour une organisation comme celle-ci, vous pouvez envisager la répartition des canaux suivante :
- Gestion des produits : les chefs de produit peuvent généralement utiliser le canal stable afin d'utiliser la même version que la plupart des utilisateurs. Ils peuvent parfois utiliser le canal bêta ou en développement s'ils travaillent sur une fonctionnalité qui nécessite une API qui n'a pas encore été lancée.
- Ingénierie et UX : certaines parties de ces équipes peuvent utiliser le canal en développement pour leur donner accès aux dernières fonctionnalités, comme les transitions de vue, avant même qu'elles ne soient disponibles dans la version stable.
- Opérations : peut utiliser la version bêta pour anticiper les pannes qui affecteront les utilisateurs ensuite.
- Assistance : peut rester sur le canal stable pour s'assurer qu'elle interagit avec le produit avec le même navigateur que la plupart de vos clients.
Utiliser des règles d'entreprise pour gérer les canaux
Plutôt que de fournir des consignes et de laisser la décision concernant le canal à utiliser, Chrome propose également des outils d'entreprise et d'administration pour gérer activement le canal que chaque utilisateur finit par utiliser. Cela est utile, car cela augmente immédiatement la surface de test, qui passe de quelques individus à un ensemble déterministe d'utilisateurs. Cela permet d'identifier les pannes le plus tôt possible et de manière traçable.
Si vous souhaitez utiliser ce niveau de contrôle, voici la configuration que nous vous recommandons :
- Employés (utilisateurs de l'application) : pour minimiser le risque d'interruption, la plupart des employés doivent utiliser le canal stable, qui a été entièrement testé par l'équipe Chrome responsable des essais. De plus, un petit pourcentage d'utilisateurs (de 5 à 10%) peut utiliser le canal bêta. Ce canal offre un aperçu de la version stable quatre à six semaines à l'avance et peut aider les administrateurs à découvrir d'éventuels problèmes liés à une version, ce qui leur donne plus de temps pour les résoudre avant le déploiement général.
- Service informatique : les membres du service informatique, y compris les administrateurs système eux-mêmes, peuvent utiliser le canal bêta ou en développement pour obtenir un aperçu de la version stable de Chrome quatre à six semaines ou neuf à douze semaines à l'avance.
Canaux de publication à long terme
Le développement de produits peut ne pas se dérouler aussi rapidement que prévu, et la cadence de publication mensuelle de Chrome peut être trop élevée. Pour ce cas d'utilisation, Chrome fournit un canal stable étendu qui permet d'obtenir des mises à jour de fonctionnalités moins fréquemment, tout en recevant les correctifs de sécurité. Ce canal est mis à jour toutes les huit semaines.
Le schéma suivant montre comment différents jalons passent par les différents canaux de publication de Chrome :
- Les versions stable et stable étendue sont identiques pendant les quatre premières semaines, après quoi elles divergent.
- Il n'existe pas de canal bêta étendu. Au lieu de cela, le cycle bêta standard de quatre semaines est utilisé pour stabiliser les versions stable et stable étendue. Les entreprises qui choisissent d'opter pour la version stable étendue de huit semaines doivent continuer à utiliser le canal bêta comme elles le font aujourd'hui afin d'identifier de manière proactive les problèmes susceptibles d'avoir un impact sur leurs environnements.
Importance continue des canaux en développement et bêta pour les utilisateurs de la version stable étendue
Bien que le canal stable accélère son cycle de publication à deux semaines et que votre organisation adopte le cycle stable étendu de huit semaines pour gagner plus de temps pour les tests, il est toujours essentiel d'utiliser les canaux en développement et bêta. Il n'existe pas de canaux "en développement ou bêta étendus" distincts. Les canaux en développement et bêta standards sont utilisés pour stabiliser les versions stable et stable étendue.
En continuant à utiliser les canaux en développement et bêta, les entreprises conservent la possibilité d'identifier de manière proactive les problèmes susceptibles d'avoir un impact sur leurs environnements. Les canaux en développement et bêta offrent un aperçu de la prochaine version stable quatre semaines à l'avance. Pour les utilisateurs de la version stable étendue, cette fenêtre d'aperçu est essentielle pour découvrir et résoudre les pannes potentielles bien avant la mise à jour des fonctionnalités de huit semaines.
Les canaux en développement et bêta agissent essentiellement comme le principal système d'alerte précoce pour toutes les modifications apportées à votre environnement stable étendu de huit semaines, ce qui garantit que vos applications d'entreprise restent compatibles. Les administrateurs système peuvent continuer à attribuer un petit groupe d'utilisateurs déterministe (par exemple, 5 à 10% des utilisateurs de l'application) aux canaux en développement et bêta pour maximiser cet avantage.
Conclusion
Les tests sont un élément essentiel pour les entreprises de développement de logiciels afin de garantir la qualité de leurs produits. Ils constituent également une étape importante pour les administrateurs système, afin de permettre aux employés d'une organisation d'accéder à des logiciels de haute qualité et d'éviter d'interrompre les processus métier.
Pour réussir à mettre en œuvre un workflow de test dans votre organisation, il est important que tous partagent l'état d'esprit commun selon lequel la qualité, et donc les tests, sont une fonctionnalité.
Dans ce document, nous avons examiné différentes façons d'intégrer les bonnes pratiques de test dans votre organisation. Pour une présentation détaillée des outils de test existants, consultez notre article Outils de Chrome pour des tests automatisés et sans friction.
Pour obtenir des conseils sur les tests, du début à la fin, consultez également notre récent cours Learn Testing et les bonnes pratiques d'automatisation des tests sur web.dev.