AppReviewX Se connecter

Modèle de checklist de non-régression

Construis une courte liste de non-régression à partir de tes parcours clés et des bugs passés.

mis à jour ·3 min de lecture

Dans ce guide

Un test de non-régression pose la question : tout ce qui marchait avant fonctionne-t-il encore après mon changement ? Tu ne peux pas retester toute l'app à chaque fois, alors garde une courte liste et fais-la grandir à partir de vrais bugs. Une liste de 15 contrôles que tu exécutes vraiment vaut mieux qu'une liste de 150 que tu sautes.

Comment la liste grandit

  1. Commence par tes parcours clés. Les 5 à 8 choses qu'un utilisateur doit pouvoir faire (inscription, tâche principale, achat, restauration).
  2. Ajoute chaque bug qui a échappé. Quand un bug atteint un utilisateur ou un testeur, ajoute une ligne qui l'aurait attrapé. C'est la partie la plus précieuse de la liste.
  3. Ajoute les zones fragiles. Tout ce que tu as modifié trois fois, ou qui dépend d'un service tiers.
  4. Élague. Supprime les contrôles de fonctions retirées et fusionne les doublons. Relis la liste à chaque release.

Modèle (à copier-coller)

LISTE DE NON-RÉGRESSION : <nom de l'app>          Dernière relecture : <date>

À exécuter avant chaque release. Marque chaque ligne : R (réussi) / E (échoué) / N (non exécuté, à justifier)

PARCOURS CLÉS
[ ] R-01 <parcours> : <contrôle en une ligne>                  Source : parcours clé
[ ] R-02 <parcours> : <contrôle en une ligne>                  Source : parcours clé

BUGS PASSÉS
[ ] R-10 <ce qui a cassé> : <le contrôle qui l'aurait attrapé> Source : bug <lien/ID>, <date>
[ ] R-11 <ce qui a cassé> : <le contrôle qui l'aurait attrapé> Source : bug <lien/ID>, <date>

ZONES FRAGILES
[ ] R-20 <zone> : <contrôle>                                   Source : <pourquoi elle est fragile>

EXÉCUTION DE RELEASE
Build : <version>   Date : <date>   Appareil / OS : <liste>
Éléments échoués : <IDs>   Décision : <go / corriger d'abord>

Exemple (illustratif)

PARCOURS CLÉS
[ ] R-01 Inscription : créer un compte avec e-mail, atteindre l'écran d'accueil    Source : parcours clé
[ ] R-02 Tâche principale : ajouter un élément, le voir dans la liste              Source : parcours clé
[ ] R-03 Restauration : réinstaller, se connecter, les données reviennent          Source : parcours clé

BUGS PASSÉS
[ ] R-10 Crash à la rotation dans l'écran d'édition : tourner l'appareil pendant une édition  Source : bug #8
[ ] R-11 Double débit au double tap : toucher Buy deux fois rapidement                       Source : bug #14

ZONES FRAGILES
[ ] R-20 Connexion avec un compte social : se connecter puis se déconnecter                  Source : dépend d'un login tiers

Comment l'adapter

  • Chaque ligne doit pouvoir être exécutée en une minute. Si elle demande un scénario, elle appartient à un cas de test.
  • Note l'origine de chaque ligne. Quand tu te demandes si la supprimer, la source te le dira.
  • Avant les mises à jour d'une app en production : ajoute « la mise à jour depuis la version précédente conserve les données ». Voir [comment tester une mise à jour d'app en production.
  • Différence avec le smoke test : le smoke test demande « ce build est-il utilisable du tout ? » et tourne sur chaque build ; la liste de non-régression est plus profonde et tourne avant une release.

Liens

Commencer gratuitement et laisse des testeurs externes exécuter ta liste sur des appareils que tu ne possèdes pas.