AppReviewX Se connecter

Checklist de smoke test pour chaque nouveau build

Dix contrôles à faire en cinq minutes avant de partager un build avec qui que ce soit.

mis à jour ·3 min de lecture

Dans ce guide

Un smoke test répond à une seule question : ce build vaut-il le temps de quelqu'un ? C'est une porte rapide, pas un test complet. Si un contrôle échoue, arrête-toi, corrige et fais un nouveau build. N'envoie pas aux testeurs un build qui plante au lancement.

Fais-le sur un vrai appareil, avec le fichier de build que tu vas partager (pas une exécution de debug depuis ton IDE).

Modèle (à copier-coller)

SMOKE TEST : <nom de l'app> build <numéro>     Date : <date>
Appareil / OS : <appareil, version>            Testeur : <nom>

Arrête-toi au premier échec.

[ ] 1. S'installe proprement (installation neuve, pas une mise à jour)
[ ] 2. Se lance sans crash ni écran blanc
[ ] 3. La version et le numéro de build affichés sont les attendus
[ ] 4. L'écran principal se charge avec des données réelles ou de test
[ ] 5. L'inscription ou la connexion fonctionnent (compte de test)
[ ] 6. L'action principale fonctionne de bout en bout : <à nommer>
[ ] 7. Les données survivent à la fermeture et à la réouverture de l'app
[ ] 8. La navigation retour et le changement d'app ne cassent pas l'écran
[ ] 9. Hors ligne : l'app s'ouvre et affiche un message cohérent, sans crash
[ ] 10. Le build de release pointe vers le bon back-end / la bonne config (pas de test ni de local)

Résultat : RÉUSSI / ÉCHOUÉ (point : __ )
Notes :

Pourquoi ces dix, et comment vérifier

  1. Installation propre. Les mises à jour masquent les problèmes d'installation. Vérification : désinstalle d'abord.
  2. Lancement. Les crashes au démarrage sont l'erreur la plus fréquente qui bloque un build. Vérification : lance deux fois, une fois à froid.
  3. Version et numéro de build. Détecte l'envoi du mauvais fichier. Vérification : compare avec tes notes.
  4. Écran principal. Les données vides ou cassées apparaissent ici en premier. Vérification : attends la fin du chargement.
  5. Inscription ou connexion. La plupart des testeurs ne peuvent pas avancer sans cela. Vérification : utilise un compte de test préparé.
  6. Une action principale. Prouve que la raison d'être du produit fonctionne encore. Vérification : nomme-la dans le modèle et fais-la une fois.
  7. Persistance. Les bugs de stockage coûtent cher. Vérification : force la fermeture, rouvre, cherche tes données.
  8. Navigation. Une pile de retour cassée frustre tout de suite. Vérification : retour, accueil, retour dans l'app.
  9. Hors ligne. Les vrais utilisateurs perdent le signal. Vérification : mode avion, puis lance l'app.
  10. Configuration. Livrer une adresse de serveur de test est un classique. Vérification : regarde l'indicateur d'environnement ou le log, ou fais une requête que tu peux vérifier.

Exemple (illustratif)

SMOKE TEST : Example Notes App build 87     Date : 2026-11-04
Appareil / OS : téléphone milieu de gamme, Android 13    Testeur : Sam
[x] 1  [x] 2  [x] 3  [x] 4  [x] 5
[ ] 6. Action principale : créer et enregistrer une note   -> ÉCHEC : le bouton enregistrer ne fait rien
Résultat : ÉCHOUÉ (point 6). Build non partagé.

Comment l'adapter

  • Remplace le point 6 par ton action principale, et ajoute une ligne si un second élément est indispensable (un achat, par exemple).
  • Garde-le à dix points. S'il dépasse cinq minutes, déplace les ajouts vers la liste de non-régression.
  • Automatise plus tard, si besoin. Un passage manuel suffit tant que tu ne builds pas souvent.

Liens

Le build passe ? Commencer gratuitement pour obtenir des retours privés et structurés dessus.