← QA Mobile : principes, métier et pratique
Glossaire et tables de référence — antisèche QA mobile
Toutes les tables de référence du cours en un seul endroit : QA vs QC vs Testing,
niveaux de test, sévérité/priorité, outils par catégorie.
QA, QC, Testing
| Terme | Nature | Quand |
|---|
| Quality Assurance (QA) | Préventif, orienté processus | Avant / pendant le développement |
| Quality Control (QC) | Vérification du produit fini | Après qu’une fonctionnalité existe |
| Testing | Technique d’exécution, sous-ensemble du QC | Pendant le QC |
Les 7 principes du test
| # | Principe | En bref |
|---|
| 1 | Tester montre la présence de défauts | Jamais leur absence totale |
| 2 | L’exhaustivité est impossible | Il faut prioriser par risque |
| 3 | Tester tôt fait économiser | Shift-left testing |
| 4 | Les défauts s’agglutinent | Concentrer l’effort sur les zones à risque |
| 5 | Le paradoxe du pesticide | Réviser les tests régulièrement |
| 6 | Tester dépend du contexte | Rigueur adaptée au risque métier |
| 7 | L’absence de bug n’est pas suffisante | Verification ≠ Validation |
Niveaux de test (pyramide)
| Niveau | Portée | Volume recommandé |
|---|
| Unitaire | Une fonction / classe isolée | Nombreux |
| Intégration | Plusieurs modules ensemble | Modéré |
| Système (E2E) | L’app entière, conditions réelles | Peu nombreux |
| Acceptation | Conformité au besoin métier | Peu nombreux, ciblés |
Sévérité vs priorité
| Axe | Mesure | Exemple |
|---|
| Sévérité | Impact technique du défaut | Crash au démarrage = sévère |
| Priorité | Urgence business de la correction | Défaut visible avant une campagne = prioritaire |
Spécificités mobile à tester
| Axe | Ce qu’il faut vérifier |
|---|
| Fragmentation OS | Versions Android/iOS supportées, surcouches constructeur |
| Fragmentation matérielle | Tailles d’écran, densités, capteurs disponibles |
| Réseau | Coupure, reprise, mode hors-ligne |
| Cycle de vie | Foreground / background / killed / resumed |
| Permissions | Accordée, refusée, révoquée en cours d’usage |
Types de tests non-fonctionnels
| Type | Vérifie | Outils typiques |
|---|
| Performance | Vitesse, fluidité, batterie, mémoire | Profileurs natifs (Android Studio, Instruments) |
| Compatibilité | Comportement sur la matrice OS/appareils | BrowserStack, Firebase Test Lab |
| Sécurité | Chiffrement, interception réseau | Charles Proxy, mitmproxy |
| Accessibilité | Lecteurs d’écran, contraste | VoiceOver, TalkBack |
| Utilisabilité (UX) | Clarté du parcours utilisateur | Tests utilisateurs, sessions exploratoires |
Outils par catégorie
| Catégorie | Outils courants |
|---|
| Tracker de bugs | JIRA |
| Gestion de cas de test | Google Sheet (petite équipe), TestRail, Zephyr, Xray |
| BDD / Gherkin | Cucumber, Behave, SpecFlow |
| Automatisation Android | Espresso |
| Automatisation iOS | XCUITest |
| Automatisation multiplateforme | Appium |
| Cloud de devices | BrowserStack App Automate, Firebase Test Lab |
| Distribution de builds de test | TestFlight (iOS), Play Console – piste interne (Android) |
| Interception réseau | Charles Proxy, mitmproxy |
| Suivi de crash en production | Firebase Crashlytics |
Structure d’un cas de test
ID · Titre · Préconditions · Étapes (numérotées) · Résultat attendu (vérifiable) ·
Priorité · Environnement.
Mots-clés Gherkin (BDD)
| Mot-clé | Rôle | Exemple |
|---|
Feature | La fonctionnalité couverte par le fichier .feature | Feature: Connexion à l'application |
Background | Les Given communs à tous les scénarios du fichier | Background: Given l'app est installée |
Scenario | Un exemple concret de comportement attendu | Scenario: Connexion valide |
Given | Contexte de départ (préconditions) | Given l'utilisateur est déconnecté |
When | L’action déclenchée (une seule par scénario) | When il tape sur « Se connecter » |
Then | Résultat observable et vérifiable | Then il arrive sur l'écran d'accueil |
And / But | Enchaîne des lignes du même type | And son nom apparaît dans le profil |
Scenario Outline + Examples | Un scénario rejoué sur plusieurs jeux de données | table | email | message | |
@tag | Étiquette pour exécuter un sous-ensemble | @smoke, @regression, @android |
Outils d’exécution : Cucumber (JVM/JS), Behave (Python), SpecFlow (.NET) — reliés à
l’app par des step definitions (Appium, Espresso, XCUITest).
Structure d’un bug report
Titre (spécifique) · Étapes de reproduction · Résultat observé · Résultat attendu ·
Sévérité · Priorité · Environnement · Preuves (capture, vidéo, logs).
Voir aussi la carte du cours pour naviguer entre
les leçons.