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 pourraient être dépassés, mais les clients se plaindraient certainement.
Ce scénario cauchemardesque est évitable: en implémentant un processus de test continu et rigoureux qui détecte les problèmes avant qu'ils ne provoquent le chaos. Toutefois, mettre en œuvre un tel processus dans votre organisation est plus facile à dire qu'à faire.
Cet article vous explique tout ce que vous devez prendre en compte lorsque vous commencez à effectuer des tests dans votre entreprise, et comment vous pouvez en bénéficier à 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.
Instaurer une culture de test dans votre équipe
Pour réussir à intégrer les tests dans votre équipe, chacun doit partager un état d'esprit commun et considérer la qualité non comme un fardeau, mais comme un investissement. Ce processus, comme tout autre changement culturel, nécessite du temps et de la cohérence.
Pour façonner cette culture, vous pouvez organiser des réunions régulières afin de discuter des défauts, de leur impact, de leur origine et de ce qui a été nécessaire pour les corriger. Cela permet de sensibiliser les utilisateurs à la nécessité d'éviter de tels défauts.
La présence d'une personne dédiée dans l'équipe qui supervise et pilote l'effort peut fortement augmenter les chances de réussite. Il définit des consignes pour l'équipe, voire pour l'ensemble de l'organisation, collecte les bonnes pratiques et les partage, et défend l'effort à tous les niveaux.
Vous pouvez également faire tourner le rôle d'assistance de votre produit. Obtenir des insights directs 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 enrichissante 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 toute autre fonctionnalité que vous créez pour votre produit. Une fois que tout le monde a adopté ce mode de pensée, il est naturel de comprendre que les tests sont également une fonctionnalité. Car ce sont les tests qui garantissent la qualité du produit livré.
Processus de test par étapes
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 l'état "Terminé""
En ajoutant des tests comme exigence de fonctionnalité, vous indiquez qu'une fonctionnalité n'est pas prête à être déployée tant qu'elle n'a pas été testée correctement et automatiquement.
Effectuer 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 d'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 é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 veillant à ce que les versions puissent être publiées en toute confiance.
- Rapports de bugs: une tendance à la baisse des rapports de bugs peut être un signe positif que vos tests (et vos processus de développement) sont efficaces.
- Couverture des tests: bien qu'elle ne soit jamais une métrique exacte, la couverture peut être un bon indicateur de la profondeur des tests des 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 la période des fêtes, tandis que le nombre de signalements de bugs augmente. Ne vous appuyez donc pas sur quelques données seulement et veillez à les croiser avec les autres données disponibles pour votre équipe.
Lorsque vous aurez implémenté ces étapes avec votre équipe, l'état de votre produit en bénéficiera à 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 reposent 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 toujours influencer le workflow de développement de manière positive. 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 et des règles d'entreprise de Chrome.
Versions disponibles de Chrome
Par défaut, Chrome se met à jour automatiquement pour s'assurer que tous les utilisateurs exécutent la dernière version de Chrome, la plus stable et la plus sécurisée, 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 avant le canal stable afin de laisser le temps à vos équipes produit d'adapter votre produit aux modifications apportées à la plate-forme Web.
Pour ce cas d'utilisation, Chrome propose un total de quatre canaux de publication, destinés à différents groupes d'utilisateurs.
Dans le cas de Chrome, vous pouvez utiliser différents canaux de publication pour anticiper les futures modifications du navigateur et tester les dernières fonctionnalités avant qu'elles ne soient largement disponibles:
- Canal stable: la plupart des utilisateurs se trouvent sur ce canal. Le canal stable est mis à jour automatiquement lors de la publication d'une nouvelle version de Chrome, ce qui se produit tous les mois.
- Canal bêta: cette version deviendra stable dans quatre à six semaines. Vous pourrez ainsi prévisualiser et tester une prochaine version stable et vous y préparer.
- Version en développement: cette version reçoit une nouvelle version de Chrome une fois par semaine et inclut toutes les dernières corrections qui passeront éventuellement en version bêta. Comme son nom l'indique, il est en cours de développement et peut donc se bloquer de manière inattendue. Il inclut également les dernières fonctionnalités, parfois bien avant qu'elles ne soient disponibles en version stable. Cela fait de la version développeur un excellent outil pour le prototypage et le développement de pointe.
- Canary channel (Canary) : canal le plus expérimental, contenant toutes les dernières fonctionnalités, mais sans beaucoup de tests. Au moins une fois par jour.
Pour en savoir plus sur les canaux Chrome, consultez l'épisode sur les concepts Chrome correspondant.
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 universelle pour le développement logiciel. Par exemple, nous allons supposer qu'une équipe comprend les rôles suivants: gestion de produit, UX et UI, ingénierie, opérations et assistance.
Pour une entreprise comme celle-ci, vous pouvez envisager la répartition des canaux suivante:
- Gestion de produit: les responsables produit peuvent généralement utiliser le canal stable afin d'utiliser la même version que la plupart des utilisateurs. Il peut parfois utiliser la chaîne bêta ou développeur s'il travaille sur une fonctionnalité nécessitant une API qui n'a pas encore été lancée.
- Ingénierie et expérience utilisateur: des membres de ces équipes peuvent utiliser la version dev pour accéder aux dernières fonctionnalités, comme les transitions de vue, même avant qu'elles ne soient stables.
- Opérations: peut être en bêta pour anticiper les pannes qui affecteront les utilisateurs à l'avenir.
- Assistance: peut rester sur le canal stable pour s'assurer qu'il interagit avec le produit avec le même navigateur que la plupart de vos clients.
Gérer les canaux à l'aide de règles d'entreprise
Plutôt que de donner des consignes et de laisser l'utilisateur choisir le canal à utiliser, Chrome propose également des outils d'entreprise et d'administration pour gérer activement le canal utilisé par chaque utilisateur. Cela est utile, car cela augmente immédiatement la surface de test de quelques individus à un ensemble déterministe d'utilisateurs, ce qui permet d'identifier les erreurs 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 de perturbation, la plupart des employés doivent utiliser la version stable, qui a été entièrement testée par l'équipe de test Chrome. De plus, un faible pourcentage d'utilisateurs (entre 5 et 10%) peut être sur le canal bêta. Cette version bénéficie d'un aperçu de la version stable de 4 à 6 semaines. Elle peut aider les administrateurs à détecter d'éventuels problèmes liés à une version, ce qui leur laisse plus de temps pour les résoudre avant le déploiement général.
- Département IT: les membres du département IT, y compris les administrateurs système, peuvent utiliser la version bêta ou la version 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
Le développement du produit risque de ne pas aller aussi vite que prévu, et la cadence de publication d'un mois de Chrome pourrait être trop élevée. Pour ce cas d'utilisation, Chrome propose une version stable étendue qui permet de recevoir des mises à jour de fonctionnalités moins fréquemment, mais qui inclut tout de même les correctifs de sécurité. Cette version est mise à jour toutes les huit semaines.
Le diagramme suivant montre comment les différents jalons progressent dans les différents canaux de publication de Chrome:
- Les versions stables et stables étendues sont identiques pendant les quatre premières semaines, après quoi 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 stables et stables étendues. Les entreprises qui choisissent d'activer la version stable étendue de huit semaines doivent continuer à exécuter 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.
Conclusion
Les tests sont une partie essentielle des entreprises de développement logiciel pour garantir la qualité de leurs produits. Ils constituent également une étape importante pour les administrateurs système, qui doivent donner aux employés d'une organisation accès à des logiciels de haute qualité et éviter de perturber les processus métier.
Pour réussir à implémenter un workflow de test au sein de votre organisation, il est important que tous les membres partagent le même état d'esprit, à savoir que la qualité et, par conséquent, les tests sont une fonctionnalité.
Dans cet article, nous avons passé en revue différentes façons d'intégrer les bonnes pratiques de test dans votre organisation. Pour un examen approfondi des outils de test existants, consultez notre article Outils de Chrome pour des tests automatisés et fluides.
Pour obtenir des conseils pratiques sur les tests, du début à la fin, consultez également notre cours de formation sur les tests et les bonnes pratiques d'automatisation des tests sur web.dev.