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, mais les clients se plaindraient à coup sûr.
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 sèment le chaos. Mais mettre en place un tel processus dans votre organisation est plus facile à dire qu'à faire.
Cet article vous explique tout ce que vous devez savoir pour commencer à 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 cet article explique comment commencer à implémenter des tests dans votre workflow.
Mettre en place une culture de test dans votre équipe
Pour introduire les tests dans votre équipe, il est essentiel que chacun partage un état d'esprit commun et considère 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.
Pour contribuer à façonner cette culture, vous pouvez organiser des réunions régulières pour discuter des défauts, de leur impact, de leur origine et des mesures prises pour les corriger. Cela permet de sensibiliser les utilisateurs à l'importance de prévenir de tels défauts.
Le fait d'avoir une personne dédiée dans l'équipe pour superviser et mener à bien les efforts peut fortement augmenter les chances de succès. Il s'agit d'une personne qui définit des consignes pour l'équipe, voire pour l'ensemble de l'organisation, qui collecte les bonnes pratiques et les partage, et qui défend les efforts à tous les niveaux.
Une autre approche utile consiste à faire tourner le rôle d'assistance de votre produit. Obtenir des insights de première main et non filtrés 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 responsables 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 n'importe quelle autre que vous développez 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 permettent de garantir la qualité des produits.
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 des tests en tant qu'exigence de fonctionnalité, vous indiquez qu'une fonctionnalité n'est pas prête à être déployée tant qu'elle n'a pas été correctement et automatiquement testée.
Exécuter des tests régulièrement
Une fois implémentés, 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 activité. Voici quelques exemples de métriques que vous pouvez utiliser :
- Releases par mois : un nombre élevé de releases 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 bug : une tendance à la baisse des rapports de bug peut être un signe positif indiquant 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, tandis que le nombre de rapports de bug augmente. Ne vous fiez donc pas à quelques-uns seulement et assurez-vous de les mapper avec d'autres données disponibles pour votre équipe.
Si vous parvenez à mettre en œuvre ces étapes avec votre équipe, l'état de votre produit s'en trouvera certainement amélioré à long terme. Mais vous pouvez encore en faire plus !
Bonnes pratiques de test pour les administrateurs système
Les équipes produit ne peuvent pas travailler seules. Ils 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, en utilisant les canaux et les règles Enterprise de Chrome.
Versions de Chrome
Par défaut, Chrome se met à jour automatiquement pour s'assurer que chaque utilisateur exécute la version la plus récente, la plus stable et la plus sécurisée de Chrome, y compris toutes les dernières fonctionnalités (la version de Chrome publiée sur le canal stable).
En tant qu'entreprise développant un produit Web, vous pouvez utiliser un navigateur en avance sur le canal stable pour donner à vos équipes produit le temps d'adapter votre produit aux modifications apportées à la plate-forme Web.
Pour ce cas d'utilisation, Chrome propose un total de quatre versions disponibles, destinées à différents groupes d'utilisateurs.
Dans le cas de Chrome, vous pouvez utiliser différents canaux de diffusion pour anticiper les futures modifications du navigateur et tester les dernières fonctionnalités avant qu'elles ne soient largement disponibles :
- Canal stable : c'est celui que la plupart des utilisateurs utilisent. Le canal stable se met à jour automatiquement lorsqu'une nouvelle version de Chrome est disponible, ce qui se produit tous les mois.
- Canal bêta : cette version deviendra stable dans quatre à six semaines. Vous aurez ainsi la possibilité de prévisualiser et de tester une prochaine version stable, et de vous y préparer.
- Version en développement : une nouvelle version de Chrome est disponible une fois par semaine. Elle inclut tous les derniers correctifs qui seront ensuite intégrés à la version bêta. Comme son nom l'indique, ce canal est en cours de développement et peut donc être interrompu de manière inattendue. Toutefois, il inclut également les dernières fonctionnalités, parfois longtemps avant qu'elles ne soient disponibles dans la version stable. Le canal de développement est donc un excellent outil pour le prototypage et le développement de pointe.
- Canal Canary : le canal le plus expérimental, qui contient toutes les dernières fonctionnalités, mais sans beaucoup de tests. Au moins une fois par jour.
Si vous souhaitez en savoir plus sur les canaux Chrome, consultez l'épisode Concepts Chrome correspondant.
Utiliser des chaînes 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. Par exemple, supposons qu'une équipe comporte 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 responsables 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 développeur s'ils travaillent sur une fonctionnalité qui nécessite une API qui n'a pas encore été lancée.
- Ingénierie et UX : certaines équipes peuvent utiliser le canal dev pour accéder aux dernières fonctionnalités, comme Afficher les transitions, avant même qu'elles ne soient disponibles dans la version stable.
- Opérations : elles peuvent être en bêta pour anticiper les problèmes qui affecteront les utilisateurs par la suite.
- Assistance : peut rester sur le canal stable pour s'assurer d'interagir avec le produit avec le même navigateur que la plupart de vos clients.
Utiliser des règles d'entreprise pour gérer les chaînes
Au lieu de fournir des consignes et de laisser l'utilisateur décider du canal à utiliser, Chrome propose également des outils d'administration et pour les entreprises permettant de gérer activement le canal utilisé par chaque utilisateur. Cela est utile, car cela augmente immédiatement la surface de test, qui passe de quelques utilisateurs individuels à un ensemble déterministe d'utilisateurs. Cela permet d'identifier les problèmes 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 de test Chrome. De plus, un petit pourcentage d'utilisateurs (entre 5 et 10%) peut être affecté au canal bêta. Ce canal permet aux administrateurs de découvrir d'éventuels problèmes liés à une version stable 4 à 6 semaines à l'avance, 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, peuvent utiliser la version bêta ou en développement pour avoir un aperçu des fonctionnalités à venir quatre à six semaines ou neuf à douze semaines avant leur sortie dans la version stable de Chrome.
Canaux de publication à long terme
Il se peut que le développement du produit ne se déroule pas aussi rapidement que prévu et que la cadence de publication mensuelle de Chrome soit trop élevée. Pour ce cas d'utilisation, Chrome propose une version stable étendue qui permet de recevoir les mises à jour de fonctionnalités moins souvent, tout en continuant à recevoir les correctifs de sécurité. Cette version est mise à jour toutes les huit semaines.
Le schéma suivant montre comment les différentes étapes progressent dans les différents canaux de publication de Chrome :
- Les versions stable et stable étendue sont identiques pendant les quatre premières semaines, puis elles divergent.
- Il n'existe pas de canal bêta étendu. Le cycle bêta standard de quatre semaines est utilisé pour stabiliser les versions stable et stable étendue. Les entreprises qui choisissent d'activer 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'affecter leurs environnements.
Importance continue des versions bêta et en développement pour les utilisateurs de la version stable étendue
Alors que la version stable passe à un cycle de publication de deux semaines et que votre organisation adopte le cycle stable étendu de huit semaines pour gagner du temps pour les tests, il est toujours essentiel d'utiliser les versions bêta et de développement. Il n'existe pas de canaux "développement étendu" ni "bêta étendu" distincts. Les canaux de développement et bêta standards sont utilisés pour stabiliser les versions stables et stables étendues.
En continuant à utiliser les canaux de développement et bêta, les entreprises peuvent identifier de manière proactive les problèmes susceptibles d'avoir un impact sur leurs environnements. Les versions en développement et bêta offrent un aperçu de quatre semaines de la prochaine version stable. Pour les utilisateurs de la version stable étendue, cette fenêtre d'aperçu est essentielle pour découvrir et résoudre les éventuels problèmes de compatibilité bien avant la mise à jour des fonctionnalités de huit semaines.
Les canaux de développement et bêta servent essentiellement de système d'alerte précoce principal pour toute modification apportée à votre environnement stable étendu de huit semaines, ce qui garantit la compatibilité de vos applications d'entreprise. Les administrateurs système peuvent continuer à attribuer un petit groupe déterministe d'utilisateurs (par exemple, 5 à 10% des utilisateurs de l'application) aux canaux de 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, car ils permettent de garantir la qualité de leurs produits. Ils constituent également une étape importante pour les administrateurs système, car ils permettent de donner aux employés d'une organisation l'accès à des logiciels de haute qualité et d'éviter de perturber les processus métier.
Pour réussir à implémenter un workflow de test dans votre organisation, il est important que chacun partage l'état d'esprit commun selon lequel la qualité, et donc les tests, sont une fonctionnalité.
Dans cet article, nous avons examiné différentes façons d'intégrer les bonnes pratiques de test dans votre organisation. Pour en savoir plus sur les outils de test existants, consultez notre article Outils Chrome pour des tests automatisés et fluides.
Pour obtenir des conseils pratiques sur les tests, du début à la fin, consultez également notre récent cours sur les tests et les bonnes pratiques d'automatisation des tests sur web.dev.