Smoke test, régression, recette : le b.a.-ba des mises en ligne

Vendredi, 17 heures. La correction tient en une ligne : un nouveau libellé sur le bouton de paiement. Personne ne reteste, l’équipe publie et part en week-end. Lundi matin, le service client croule sous les messages : sur certains téléphones, le bouton ne répond plus.

Ce scénario n’a rien d’exceptionnel. Chaque changement, même minuscule, peut casser quelque chose ailleurs. Les équipes qui publient sereinement ne testent pas forcément plus que les autres : elles testent dans le bon ordre.

Le smoke test (ou « test de fumée »), le test de confirmation, le test de régression et la recette forment la colonne vertébrale d’une mise en ligne. Dans ce guide, vous verrez à quoi sert chacun, quand le lancer, et comment organiser une sortie de version avec un calendrier et une liste de contrôle réutilisables.

Pourquoi une mise en ligne demande-t-elle plusieurs tests différents ?

Parce qu’une sortie de version pose quatre questions distinctes, dans cet ordre. Le tableau ci-dessous les résume ; les durées sont des ordres de grandeur, à adapter à la taille de votre application.

Le build est la version compilée de l’application, prête à être installée. Chaque nouveau build est un nouveau candidat à la sortie.

Sur mobile, l’enjeu est encore plus fort que sur le web. Sur Google Play, interrompre un déploiement empêche de nouveaux utilisateurs de recevoir la version, mais ceux qui l’ont déjà la gardent ; pour réparer, il faut publier une nouvelle version corrigée. Une erreur publiée ne se retire pas d’un clic.

Qu’est-ce qu’un smoke test, et en quoi diffère-t-il d’un sanity test ?

L’image parle d’elle-même : on branche l’appareil, et s’il se met à fumer, inutile d’aller plus loin. Le syllabus de l’ISTQB cite « tous les smoke tests sont passés » parmi les critères d’entrée typiques d’une campagne de test, et range les smoke tests parmi les tests souvent automatisés. Un smoke test ne cherche pas les petits défauts : il cherche la panne qui rend tout le reste inutile.

Un bon smoke test tient sur une page. Pour une application de livraison :

Si un seul point échoue, la version est refusée et repart chez les développeurs. C’est une économie, pas un échec : vous évitez que des testeurs perdent une journée sur une version qui ne démarre pas.

Et le sanity test ? Son sens varie d’une équipe à l’autre. Le plus souvent, il désigne une vérification rapide et ciblée sur la zone qui vient de changer, alors que le smoke test balaie les fonctions vitales de toute l’application. L’essentiel est de vous mettre d’accord, dans votre équipe, sur ce que chaque mot recouvre.

Comment vérifier qu’un bug est vraiment corrigé ?

C’est le rôle du test de confirmation, qu’on appelle aussi retest. Selon le syllabus de l’ISTQB, on rejoue les tests qui avaient échoué à cause du défaut, et on peut en ajouter pour couvrir ce que la correction a modifié. Quand le temps manque, on se limite au minimum : refaire les étapes qui reproduisaient la défaillance, et vérifier qu’elle ne se produit plus.

Quatre règles pratiques :

1. Reproduisez dans les conditions du rapport : même appareil, même version du système, même type de réseau.
2. Variez autour de la correction. Le bug touchait un montant à virgule ? Essayez 0, 1, 999 999, un montant avec des espaces.
3. Changez d’appareil si le bug semblait lié au téléphone.
4. Faites fermer le bug par quelqu’un d’autre que son développeur. « Ça marche chez moi » n’est pas une confirmation.

Comment organiser les tests de régression ?

Le test de régression vérifie qu’un changement n’a pas fait apparaître de défauts dans les parties qui, elles, n’ont pas changé. Le syllabus de l’ISTQB rappelle que les dégâts peuvent toucher le même module, d’autres modules, des systèmes connectés, voire l’environnement. D’où son conseil : commencer par une analyse d’impact, pour savoir quelles zones le changement peut atteindre.

Le tableau suivant montre comment traduire un changement en zones à retester.

La dernière ligne n’a rien de théorique : Google Play relève régulièrement la version d’Android que les mises à jour doivent cibler, et chaque saut modifie certains comportements du système. Notre guide pour tester la compatibilité détaille ces pièges.

Pour construire votre suite de régression :

1. Commencez par les parcours d’argent : inscription, connexion, commande, paiement, remboursement.
2. Ajoutez un test pour chaque bug grave corrigé, pour qu’il ne revienne jamais.
3. Classez par priorité : A à chaque version, B à chaque version majeure, C de temps en temps.
4. Renouvelez vos tests. L’ISTQB rappelle que des tests répétés à l’identique deviennent de moins en moins efficaces : variez les données et ajoutez des sessions exploratoires.
5. Automatisez ce qui se répète. La régression grossit à chaque version : c’est la meilleure candidate à l’automatisation. Voyez test manuel ou automatisé.

Qu’est-ce que la recette, et qui doit la faire ?

En français, la recette désigne le test d’acceptation : le moment où le client, ou les futurs utilisateurs, vérifient que l’application répond à leur besoin et peut être mise en service. Pour l’ISTQB, ce test vise la validation et la démonstration que le système est prêt à être déployé ; idéalement, il est mené par les utilisateurs prévus. La différence entre vérifier et valider est expliquée dans vérification et validation.

Il en existe plusieurs formes :

• La recette utilisateur (UAT, User Acceptance Testing) : de vrais utilisateurs accomplissent leurs tâches habituelles.
• La recette opérationnelle : l’équipe qui exploitera le service vérifie les sauvegardes, la surveillance, la restauration.
• La recette contractuelle ou réglementaire : on contrôle les engagements du contrat ou les obligations légales.
• Les tests alpha et bêta : par des personnes extérieures à l’équipe de développement, chez l’éditeur (alpha) ou dans leur propre environnement (bêta).

Pour une recette utile :

• Fixez les critères d’acceptation avant, par écrit. Sinon, la recette tourne à la négociation.
• Utilisez des scénarios de la vraie vie : une commerçante qui encaisse vingt clients à l’heure de pointe, pas un seul paiement de 100 FCFA.
• Concluez par un procès-verbal (PV) de recette : acceptée, acceptée avec réserves (listées et datées), ou refusée.

Pour une application mobile, la bêta passe par les canaux des stores : les tests fermés de Google Play, ou TestFlight côté Apple (voir tester une app iPhone avec TestFlight). Pour un compte développeur personnel créé après le 13 novembre 2023, Google exige au moins 12 testeurs inscrits à un test fermé depuis 14 jours sans interruption avant d’ouvrir l’accès à la production : c’est l’objet de notre guide sur le test fermé Google Play à 12 testeurs et de la page 12 testeurs pour Google Play.

Quand placer chaque test dans un cycle de publication ?

Voici un exemple de calendrier pour la version 2.4 d’une application mobile, sur deux semaines. J désigne le jour de publication.

La publication progressive est votre filet de sécurité. Sur Google Play, le déploiement par étapes (staged rollout) distribue une mise à jour à un pourcentage d’utilisateurs que vous choisissez, puis que vous augmentez vous-même ; vous pouvez l’interrompre et le reprendre. Il ne concerne que les mises à jour, pas la toute première publication. Chez Apple, la publication par phases étale la mise à jour automatique sur sept jours : 1 %, 2 %, 5 %, 10 %, 20 %, 50 %, puis 100 % des utilisateurs, avec des pauses possibles jusqu’à 30 jours au total. Pendant ce temps, chacun peut quand même la télécharger manuellement.

Surveillez alors les indicateurs. Dans Android vitals, Google considère comme un « mauvais comportement » un taux de plantage perçu par les utilisateurs supérieur à 1,09 % en moyenne, ou à 8 % sur un modèle de téléphone donné ; au-delà, la visibilité de l’application sur Google Play peut baisser. Fixez votre propre seuil d’arrêt avant le jour J, et désignez qui a le droit de stopper le déploiement.

Quelle liste de contrôle suivre le jour de la mise en ligne ?

Copiez cette liste dans votre outil de suivi et cochez-la à chaque version. Pour la conformité aux règles des stores, complétez-la avec notre checklist avant publication.

Une petite équipe n’a pas toujours assez de bras, ni assez de téléphones, pour la régression et la recette. C’est typiquement ce que l’on confie à des testeurs externes, comme ceux de GeekTest : nos formules sont détaillées sur la page des tarifs.

Pour aller plus loin

• Syllabus ISTQB Foundation Level v4.0.1 (nouvel onglet) : sections 2.2.1 (le test d’acceptation et ses formes), 2.2.3 (confirmation et régression) et 2.3 (test de maintenance) (en anglais).
• Glossaire ISTQB : smoke testing (nouvel onglet) : la définition officielle du smoke test (en anglais).
• Aide Play Console : déployer des mises à jour par étapes (nouvel onglet) : choisir le pourcentage, interrompre, reprendre un déploiement.
• Aide Play Console : exigences de test pour les nouveaux comptes personnels (nouvel onglet) : la règle des 12 testeurs pendant 14 jours.
• App Store Connect : publier une mise à jour par phases (nouvel onglet) : le calendrier sur sept jours et les pauses (en anglais).
• Android vitals (nouvel onglet) : les seuils de mauvais comportement pour les plantages et les blocages.