Imaginez que le logiciel le plus important de votre entreprise tombe soudainement en panne. Que se passerait-il ? Les commandes peuvent être perdues, les délais peuvent être dépassés, mais les clients vont certainement se plaindre.
Ce scénario cauchemardesque peut être évité: en implémentant un processus de test continu et rigoureux, qui détecte les problèmes avant qu'ils ne provoquent le chaos. Toutefois, la mise en œuvre d'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 faites vos premiers pas avec les tests dans votre entreprise et comment vous pouvez les exploiter à 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 œuvre une culture du test dans votre équipe
Pour réussir la mise en place des tests dans votre équipe, tout le monde doit partager un état d'esprit commun et percevoir la qualité non pas comme un fardeau, mais comme un investissement. Il s'agit d'un processus qui, comme tout autre changement culturel, nécessite du temps et de la cohérence.
Une chose qui peut contribuer à façonner cette culture est des réunions régulières pour discuter des défauts, de leur impact, de leur origine et des étapes nécessaires pour les corriger. Cela vous permet de comprendre pourquoi il est bon de prévenir de tels défauts en premier lieu.
Le fait de disposer d'une personne dédiée dans l'équipe qui supervise et pilote les efforts peut fortement augmenter les chances de réussite. Quelqu'un qui définit les directives d'équipe, voire à l'échelle de l'organisation, recueille les bonnes pratiques, les partage et les défend à tous les niveaux.
Un autre instrument utile peut consister à alterner le rôle d'assistance de votre produit. Obtenir des insights directs et non filtrés de vos clients et en savoir plus sur les problèmes quotidiens auxquels ils sont confrontés avec votre produit peuvent ê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 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é. Parce que les tests garantissent la qualité de l'emballage.
Un 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 "Definition of Done"
En ajoutant des tests comme exigence de fonctionnalité, vous indiquez qu'une fonctionnalité n'est pas prête à être expédié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. Elles ne nécessitent aucune intervention humaine et peuvent être exécutées sur chaque étape critique de votre pipeline de développement. Exemple :
- À chaque commit.
- À chaque demande d'extraction.
- Après chaque modification de version complète ou d'environnement
Si vous utilisez des services tiers dans votre environnement de production, il peut même être judicieux d'exécuter vos tests en production pour vérifier 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 afin de 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é dans ce contexte, car ils garantissent que les versions peuvent se dérouler en toute confiance.
- Rapports de bugs: une tendance à la baisse dans les rapports de bugs peut être un signe positif de l'efficacité de vos tests (et de vos processus de développement).
- Couverture des tests: bien qu'elle ne soit jamais une métrique exacte, la couverture peut être un bon indicateur du niveau de détail que vous testez pour les cas d'utilisation critiques.
Notez que ces métriques sont également influencées par d'autres facteurs qui pourraient les fausser. Par exemple, le nombre de versions peut diminuer pendant une période de fêtes, tandis que les rapports de bug augmentent. Ne vous fiez donc pas uniquement à quelques-unes d'entre elles et assurez-vous de les croiser avec les autres données disponibles pour votre équipe.
Lorsque vous mettez en œuvre ces étapes avec succès avec votre équipe, l'état de votre produit en sera certainement bénéfique à long terme. Mais vous pouvez encore faire bien d'autres choses !
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 toujours influencer le workflow de développement pour de bon. 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 son fonctionnement à l'aide des versions de Chrome et des règles d'entreprise.
Versions disponibles de Chrome
Par défaut, Chrome se met à jour automatiquement pour garantir que chaque utilisateur exécute la dernière version, la plus stable et la plus sécurisée de Chrome, y compris toutes les dernières fonctionnalités, à savoir la version stable.
En tant qu'entreprise développant un produit Web, vous pouvez utiliser un navigateur avant la version stable, afin de 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 au total quatre versions disponibles, destinées à différents groupes d'utilisateurs.
Dans le cas de Chrome, vous pouvez utiliser différentes versions disponibles pour anticiper les futures modifications du navigateur et tester les dernières fonctionnalités avant leur lancement général:
- Version stable: c'est là que se trouvent la plupart des utilisateurs. La version stable est automatiquement mise à jour dès qu'une nouvelle version de Chrome est disponible, avec un abonnement mensuel.
- Version bêta: cette version deviendra stable en quatre à six semaines, ce qui vous permet de prévisualiser et de tester une prochaine version stable, et de la préparer.
- Version en développement: cette version dispose d'une nouvelle version de Chrome une fois par semaine et inclut tous les derniers correctifs qui seront à terme en version bêta. Comme le nom de la chaîne l'indique, elle est en cours de développement et peut donc ne plus fonctionner de manière inattendue. Toutefois, elle inclut également les dernières fonctionnalités, parfois bien avant qu'elles ne deviennent stables. La version en développement est donc un excellent outil pour le prototypage et le développement de pointe.
- Canary channel (Version Canary) : version la plus expérimentale contenant toutes les dernières fonctionnalités, mais sans tests. Au moins une fois par jour.
Pour en savoir plus sur les versions de Chrome, consultez l'épisode correspondant à Chrome Concepts.
Utiliser les canaux dans une organisation exemplaire
La structure des équipes produit varie selon les organisations, car il n'existe pas d'approche universelle du développement de logiciels. Prenons l'exemple d'une équipe occupant les rôles suivants: gestion des produits, expérience utilisateur et interface utilisateur, ingénierie, opérations et assistance.
Dans une organisation comme celle-ci, vous pouvez envisager la division de chaîne suivante:
- Gestion de produits: les chefs de projet utilisent généralement la version stable, afin d'utiliser la même version que la plupart des utilisateurs. Ils peuvent parfois utiliser la version bêta ou en développement s'ils travaillent sur une fonctionnalité nécessitant une API qui n'a pas encore été lancée.
- Ingénierie et expérience utilisateur: certaines parties de ces équipes peuvent utiliser la version dev pour leur donner accès aux dernières fonctionnalités, telles que l'affichage des transitions, avant même d'être stables.
- Opérations: peut être en version bêta pour prévoir les dysfonctionnements affectant les utilisateurs par la suite.
- Assistance: peut rester sur la version stable, afin de s'assurer qu'ils interagissent avec le produit dans 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 donner des directives et de laisser le choix du canal à utiliser, Chrome propose également des outils d'entreprise et d'administration permettant de gérer activement le canal utilisé par chaque utilisateur. Cela permet d'augmenter immédiatement la surface de test de quelques utilisateurs à un ensemble déterministe d'utilisateurs, ce qui permet d'identifier la défaillance 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 limiter les risques 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 (de 5 à 10%) peut avoir accès à la version bêta. Cette version offre un aperçu de la version stable pendant quatre à six semaines. Elle peut aider les administrateurs à identifier les éventuels problèmes liés à une version, ce qui leur laisse plus de temps pour les résoudre avant qu'elle ne soit déployée pour tous les autres utilisateurs.
- Service informatique: les membres du service informatique, y compris les administrateurs système eux-mêmes, peuvent utiliser la version beta ou dev pour avoir un aperçu des nouveautés de la version stable de Chrome pendant 4 à 6 ou 9 à 12 semaines.
Versions à long terme
Il est possible que le développement du produit ne se déroule pas aussi rapidement que prévu et que la fréquence de publication de Chrome (un mois) soit trop élevée. Pour ce cas d'utilisation, Chrome fournit une version stable étendue qui permet de recevoir les mises à jour de fonctionnalités moins fréquemment, tout en continuant à recevoir les correctifs de sécurité. Cette version est mise à jour toutes les huit semaines.
Le diagramme suivant montre comment les différents jalons se déroulent à travers les différentes versions de Chrome:
- Les versions stable et stable étendue des vaisseaux sont les mêmes pendant les quatre premières semaines, après quoi les deux divergences se sont produites.
- Il n'existe pas de version bêta étendue. À la place, le cycle bêta standard de quatre semaines est utilisé pour stabiliser la version stable et la version stable étendue. Les entreprises qui choisissent d'activer la version stable étendue de huit semaines doivent continuer à utiliser la version bêta comme elles le font actuellement afin d'identifier de manière proactive les problèmes pouvant affecter leur environnement.
Conclusion
Les tests constituent un élément essentiel des entreprises de développement de logiciels pour garantir la qualité de leurs produits. Ils constituent également une étape importante pour les administrateurs système, car ils permettent aux employés d'une organisation d'accéder à des logiciels de haute qualité et ne perturbent pas les processus métier.
Pour réussir la mise en œuvre d'un workflow de test au sein de votre organisation, il est important que tout le monde partage un état d'esprit commun : la qualité et, par conséquent, les tests sont une fonctionnalité.
Dans cet article, nous avons passé en revue différentes manières 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 fluides.
Pour obtenir des conseils pratiques sur les tests du début à la fin, consultez également notre récent cours "Learn Testing" et les bonnes pratiques concernant l'automatisation des tests sur web.dev.