Tout casser rapidement : une nouvelle approche du contrôle qualité et des tests

Cet article est basé sur la présentation « Accelerating QA and Testing » (Accélérer l'assurance qualité et les tests) de Greg Qualls, directeur du marketing produit, lors de la SymfonyCon 2024. Nous avons utilisé des outils d'IA pour la transcription et pour améliorer la structure et la clarté du contenu.

Avant de commencer, je tiens à préciser que j'ai plus de 18 ans d'expérience dans la vente. Si, par moments, j'ai l'air d'essayer de vous vendre quelque chose, veuillez m'en excuser. Je vous promets que ce n'est pas le cas. Je souhaite simplement partager des idées qui pourraient vous aider à envisager les tests et l'assurance qualité sous un autre angle, en particulier si vous travaillez avec Upsun ou envisagez de le faire.

Je vais également vous faire une confession : je suis très doué pour deux choses : casser des objets et poser ce que certains pourraient appeler des « questions stupides ». Aujourd'hui, nous allons explorer pourquoi ces deux compétences sont en réalité précieuses dans le développement de logiciels.

Le coût de l'attente

Commençons par une statistique qui donne à réfléchir : il est 30 fois plus coûteux de corriger un bug après sa mise en production que de le détecter plus tôt dans le processus de développement.

Ce n'est pas un chiffre inventé. La raison pour laquelle le coût est si élevé est que les défauts de production ont des répercussions bien au-delà du code lui-même. Ils ont un impact sur vos clients, nuisent à la réputation de votre marque, érodent la confiance des utilisateurs et obligent votre équipe à passer un temps précieux à éteindre des incendies au lieu de créer de nouvelles fonctionnalités.

C'est pourquoi les tests sont importants. Mais c'est là que les choses deviennent intéressantes.

La philosophie du « casser vite »

En 2012, Mark Zuckerberg a partagé une valeur fondamentale de sa philosophie « Hacker Way » : « Agissez vite et cassez des choses. Si vous ne cassez pas de choses, c'est que vous n'agissez pas assez vite. »

J'aimerais adapter cela à notre contexte : avancez rapidement et cassez des choses. Si vous ne cassez pas des choses, vous ne testez pas vraiment et vous n'avancez pas rapidement.

L'objectif des tests devrait être de casser les choses le plus rapidement possible, afin de déterminer si quelque chose fonctionne, pour que nous puissions soit le réparer, soit passer à la création de la fonctionnalité suivante. C'est ce que nous aimons vraiment faire : créer des fonctionnalités, développer des fonctionnalités, écrire du code qui compte.

Deux questions fondamentales

Quand on y réfléchit, tous les tests se résument en fait à deux questions fondamentales :

1. Est-ce que ça ne fonctionne pas ?

Cela couvre vos tests unitaires, vos tests fonctionnels, vos tests système et vos tests exploratoires. Vous vous demandez : est-ce que cela fonctionne comme prévu ?

2. Quand cela va-t-il tomber en panne ?

Cela englobe les tests de charge, les tests de pénétration, les tests d'évolutivité et les tests de pointe. Vous vous demandez : quelles sont les limites de ce système ?

Dans les deux cas, vous essayez de répondre à ces questions le plus rapidement possible.

Le problème des processus traditionnels

La plupart des processus de développement suivent un schéma familier : développement local → environnement de développement → mise en scène → production. Vous testez à chaque étape, itérez, corrigez les problèmes et finissez par voir apparaître les coches vertes qui signifient que vous êtes prêt à déployer.

Mais ce processus peut être extrêmement lent.

Mon parcours en matière de tests

Permettez-moi de vous raconter une anecdote personnelle. En 2002-2003, j'étais « webmaster » à l'Eastern New Mexico University. Tout était en HTML pur, sans JavaScript ni CSS (le CSS est arrivé plus tard, et je l'ai trouvé révolutionnaire).

Mon processus de test était d'une simplicité enfantine : écrire le code, le transférer sur le serveur via FTP, visiter la page sur enmu.edu et vérifier si cela fonctionnait. Si ce n'était pas le cas, je corrigeais le problème et je téléchargeais à nouveau. Aujourd'hui, nous appellerions cela « tester en production », mais à l'époque, il n'y avait pas de distinction : tout était en production. Il n'y avait pas d'environnements de développement, ni d'environnements de préproduction. Juste mon ordinateur et le serveur en ligne.

Les avantages cachés des tests en production

Avant de paniquer, écoutez-moi jusqu'au bout. Et si vous pouviez tester en production ? Pensez aux avantages :

• Retour immédiat : vous savez instantanément si quelque chose fonctionne.
• Données réelles : vous utilisez des serveurs, des bases de données et des services réels.
• Aucun nettoyage des données nécessaire : tout est déjà à sa place
• Découverte rapide : les problèmes spécifiques à l'environnement apparaissent immédiatement
• Tests de performance appropriés – Vous effectuez des tests dans des conditions réelles

Le seul gros problème

Bien sûr, il existe un problème majeur avec les tests en production : les utilisateurs.

Ces utilisateurs agaçants qui se plaignent lorsque le site est hors service. Puis votre patron l'apprend. Vous vous retrouvez alors dans une évaluation de performance à expliquer ce qui s'est passé. Et avant même de vous en rendre compte, vous publiez une annonce « À la recherche d'un emploi » sur LinkedIn.

Par conséquent, nous ne pouvons pas simplement tester en production. Ou peut-être que si ?

La solution : reproduire la production

La réponse consiste à reproduire la production de manière si précise que les tests effectués dans cet environnement sont essentiellement les mêmes que ceux effectués en production, à l'exception des utilisateurs.

Cependant, reproduire correctement la production est un processus incroyablement complexe. Vous devez :

• Cloner non seulement le code, mais aussi les couches de données et les services
• Gérer les éléments réseau tels que les certificats DNS et SSL
• Utiliser l'infrastructure en tant que code et des processus basés sur Git
• Gérer le contrôle d'accès et les autorisations
• S'assurer que tout se synchronise parfaitement

De nombreuses entreprises ont du mal à y parvenir. J'ai un jour discuté avec une grande université qui avait besoin de trois semaines pour mettre en place un environnement de développement. Trois semaines ! Le temps qu'ils configurent tout et synchronisent les données, la production avait déjà subi des changements importants.

Environnements de test Full-Stack

C'est là que l'approche d'Upsun devient intéressante. La plateforme offre des environnements clonés Full Stack, c'est-à-dire des répliques complètes de la production que vous pouvez mettre en place instantanément.

Lorsque vous créez une branche dans Upsun, vous ne vous contentez pas de créer une branche du code. En arrière-plan, la plateforme réplique :

• L'ensemble du code
• Toutes les bases de données et données
• Les services et les configurations
• Les paramètres réseau
• La configuration de l'infrastructure

Tout sauf les utilisateurs. 

Casser rapidement les choses dans la pratique

Plus tôt, lors de la SymfonyCon, une démonstration en direct a mis en scène deux développeurs qui tentaient de découpler une application Symfony monolithique en un frontend Next.js avec un backend Symfony. Il s'agissait d'une démonstration de 30 minutes très animée, le genre de démonstration en direct où les choses ne fonctionnent pas tout à fait au début.

Ils ont déployé. Ça n'a pas fonctionné. Ils ont modifié quelque chose et ont déployé à nouveau. Ça ne fonctionnait toujours pas. Ils ont itéré rapidement, testant et cassant les choses aussi vite que possible. Finalement, ils ont trouvé le problème : dans le fichier de configuration, ils avaient écrit « npm » au lieu de « npx », une différence d'un seul caractère.

Voici ce qui est remarquable : ils sont passés d'une application monolithique à une architecture entièrement découplée en 30 minutes, grâce à leur capacité à itérer rapidement. Ils savaient que si cela fonctionnait dans leur environnement de développement, cela fonctionnerait en production, car les environnements étaient identiques.

Le défi de la collaboration

Bien sûr, le développement est rarement une entreprise solitaire. Vous avez des collègues, ces autres développeurs qui, soyons honnêtes, ne sont jamais aussi bons que vous.

Dans les processus traditionnels, lorsque plusieurs développeurs poussent vers le même environnement de développement, les conflits de fusion sont inévitables. Quelqu'un a modifié quelque chose et maintenant votre code ne fonctionne plus. Vous avez cette conversation : « Greg, qu'est-ce que tu fais ? Je travaille là-dessus ! Tu dois d'abord installer ce service ! »

Plusieurs environnements isolés

La meilleure solution consiste à donner à chaque développeur son propre environnement de production. Vous travaillez sur votre code, ils travaillent sur le leur, de manière totalement isolée.

Lorsque vous êtes prêt, vous effectuez un push vers la production. Ensuite, votre collègue récupère vos modifications, non seulement le code, mais aussi toutes les données, les mises à jour de la base de données, les configurations de service et la mise en cache. Tout se synchronise automatiquement. Ils testent leur code par rapport à ce nouvel état, et le cycle se poursuit.

Tout le monde travaille séparément mais en collaboration, de manière fluide, car vous développez tous dans des environnements similaires à ceux de production.

Les avantages concrets

Lorsque vous pouvez casser les choses plus rapidement, en particulier avec des plateformes telles qu'Upsun, vous gagnez :

• Des cycles de test plus rapides : vous pouvez tenter des changements ambitieux, comme le découplage d'une application entière, en moins d'une heure.
• Des cycles de développement plus rapides : lorsque la direction demande quelque chose « dès que possible », vous pouvez itérer rapidement, essayer de nouveaux langages, frameworks, services ou bibliothèques d'apprentissage automatique pour voir ce qui fonctionne.
• Une meilleure qualité du code : vous testez et itérez jusqu'à ce que vous soyez sûr du résultat, sachant que si cela fonctionne ici, cela fonctionnera en production.
• Réduction des risques : vous détectez les problèmes avant les utilisateurs, évitant ainsi les évaluations de performances désagréables concernant les temps d'arrêt du site et les pertes de revenus.

Et voici un argument pour le côté commercial : il a été prouvé que des environnements de test et d'assurance qualité appropriés permettent d'augmenter de 40 % les scores de satisfaction des clients. Lorsque vous avez confiance en vos tests, vous livrez un meilleur code, ce qui rend vos clients plus heureux.

Trois conseils pratiques

Que vous utilisiez ou non Upsun, voici trois principes pour accélérer le processus de rupture :

1. Changez votre état d'esprit

Trop de développeurs pensent qu'ils doivent tout faire parfaitement dès le premier essai. Au contraire, considérez l'échec comme un apprentissage. Essayez. Voyez si cela fonctionne. Réessayez. Vous apprendrez davantage en cassant les choses qu'en réussissant du premier coup.

Je n'oublierai jamais cette démonstration en direct : si vous créez votre application Next.js avec npx, assurez-vous que la commande utilise également npx, et non npm. J'ai appris cela en voyant quelqu'un d'autre échouer, et cette leçon m'est restée.

2. Tirez parti des environnements de test

Ne partez pas d'ici en pensant : « Greg a dit qu'il fallait simplement tester en production ! » Si vous dites cela à vos supérieurs, ils vous demanderont « Qui est Greg ? » et vous aurez des ennuis.

Vous avez besoin d'environnements de test. Mais ils doivent être aussi proches que possible de la production. Réfléchissez à toutes les variables : infrastructure, données, services, réseau et contrôle d'accès. Couvrez-en autant que possible.

3. Automatisez tout

Il ne s'agit pas seulement de casser des choses, mais de les casser rapidement. Automatisez la création de votre environnement. Mettez en place des pipelines CI/CD. Faites en sorte que les environnements de test se lancent instantanément et que les déploiements se fassent automatiquement lorsque les tests sont réussis.

Plus vous pouvez casser et réparer rapidement, plus vite vous pouvez vous remettre à développer de nouvelles fonctionnalités et faire progresser votre produit.

Conclusion

Les tests ne doivent pas nécessairement être une corvée. Lorsque vous disposez des bons outils et du bon état d'esprit, ils font partie intégrante du processus créatif, un moyen d'explorer les possibilités, de repousser les limites et d'apprendre rapidement.

L'objectif n'est pas d'éviter de casser des choses. L'objectif est de les casser le plus rapidement possible dans des environnements sûrs, d'apprendre de ces casses et de livrer un code fiable.

Alors n'hésitez pas : cassez des choses. Mais cassez-les rapidement, cassez-les en toute sécurité et tirez des leçons de chaque casse.

Vous avez des questions sur Upsun ou sur la mise en œuvre de ces pratiques ? Visitez le site web d'Upsun ou essayez notre version d'essai gratuite pour découvrir les environnements de test full-stack en action.