Une stratégie de test mobile, c’est l’ordre dans lequel vous décidez quoi tester, pas la liste des appareils sur lesquels vous le testez. La plupart des équipes commencent par la liste : un tableur d’iPhone, de Samsung et de versions d’OS. Ce tableur est un résultat. La stratégie, ce sont les quatre décisions qui le produisent, et c’est en se trompant d’ordre que les équipes finissent avec une large couverture d’appareils sur les mauvais risques.
Qu'est-ce qu'une stratégie de test d'applications mobiles ?
C’est la structure de décision qui détermine ce qui est testé, dans quel ordre et qui donne le feu vert, avant que quiconque n’ouvre un laboratoire d’appareils. C’est différent d’une liste de vérification pour les tests d’applications mobiles, qui répond à « que vérifie-t-on dans ce build ». Une stratégie répond d’abord à une question plus difficile : quelles défaillances nous coûteraient réellement de l’argent, et qui détecte chacune avant la mise en production ?
La plupart des guides publiés sur le sujet commencent par « choisissez vos appareils » et traitent la matrice comme la stratégie elle-même. C’est l’inverse. Une matrice d’appareils construite en premier reflète généralement les parts de marché des stores plutôt que le risque réel de votre application. Vous finissez exhaustif sur les appareils et léger sur la défaillance qui vous aurait coûté le lancement.
Décision 1 : quelles défaillances vous coûteraient vraiment de l'argent
Avant toute chose, classez les types de défaillance qui comptent pour cette application précise :
- Plantage au lancement ou à la première utilisation. Bloque l’activation avant même que l’utilisateur se fasse une opinion du produit.
- Échec de paiement. Perte de revenu directe, plus le coût du support et des remboursements qui suit.
- Perte ou corruption de données. Détruit immédiatement la confiance, surtout pour toute application qui gère du contenu généré par les utilisateurs ou l’état d’un compte.
- Rejet par le store. Apple et Google rejettent des applications pour des raisons sans rapport avec les bugs (métadonnées, formulation des autorisations, manifestes de confidentialité), et un rejet au mauvais moment peut vous coûter entièrement une date de lancement.
Classez-les pour votre application, sans les traiter comme également probables ou également coûteux. Une application par abonnement redoute surtout l’échec de paiement. Une application sociale, la perte de données. Une première version lancée auprès d’un public qui ne vous connaît pas encore redoute surtout le rejet par le store, car il n’existe aucun capital de confiance pour absorber un retard. Ce classement est la première section du véritable document de stratégie, et c’est celle que la plupart des équipes sautent parce qu’elle ressemble à une discussion business plutôt qu’à une discussion QA. C’est les deux.
Décision 2 : quelle couche détecte chaque type de défaillance au moindre coût
Une fois que vous savez ce qui coûte cher, décidez où chaque type de défaillance est détecté avant d’atteindre un utilisateur. Un même bug coûte plus ou moins cher selon l’endroit où il est trouvé :
Plantage au lancement
Test de fumée automatisé à chaque build
S’exécute en quelques minutes et empêche le build d’arriver sur un appareil
Échec de paiement
Tests exploratoires manuels sur de vrais circuits de paiement
Les environnements sandbox ne reproduisent pas les refus de carte ni les nouvelles tentatives du monde réel
Perte de données
Tests d’intégration sur le vrai backend
Les tests unitaires simulent la base de données ; le bug se trouve dans la transmission
Rejet par le store
Revue manuelle des règles avant la soumission
Aucune couche automatisée ne lit pour vous les directives actuelles d’Apple ou de Google
Il s’agit d’une décision de placement, pas d’automatisation. Elle vous indique si un risque relève d’une étape précoce (rapide, automatisée, peu coûteuse) ou plus tardive (plus lente, manuelle, mais la seule couche qui le voit vraiment). Pour voir comment ces couches s’articulent sur le calendrier d’une version, consultez notre article sur les phases du test logiciel. Mettre en place l’automatisation elle-même est une décision distincte, avec ses propres compromis, qui mérite sa propre discussion une fois ce placement arrêté.
Décision 3 : qui tranche pour un build limite
Chaque version comporte au moins un build dont on ne sait pas clairement s’il faut le livrer ou non. Un plantage mineur sur une ancienne version d’OS. Un cas limite de paiement qui ne se déclenche qu’avec un seul type de carte. Quelqu’un doit être responsable de cette décision avant qu’elle ne se présente, pas dans la précipitation du jour de la mise en ligne.
Nommez le rôle, pas une personne : en général le responsable technique pour le risque technique, le PM pour le risque business, et un circuit d’escalade convenu quand les deux ne sont pas d’accord. Mettez-le par écrit. Les équipes qui se brûlent les doigts ne sont pas celles qui manquent de jugement, ce sont celles où la décision limite est prise par la personne qui se trouve dans la pièce, sous pression, sans accord préalable sur ce que « risque acceptable » signifie pour cette application. C’est aussi là que le rôle d’un partenaire QA compte : la décision se prend plus vite quand l’équipe QA travaille comme une seule équipe avec l’ingénierie et le produit, plutôt que comme un prestataire qui remet une liste de bugs et attend.
Décision 4 : vous pouvez maintenant construire la matrice d'appareils
Une fois les trois premières décisions prises, la matrice d’appareils devient un exercice simple : quels appareils et quelles versions d’OS représentent réellement les risques classés lors de la décision 1, testés sur la couche attribuée lors de la décision 2. Un risque d’échec de paiement implique de tester sur les versions d’OS et les appareils où votre SDK de paiement se comporte différemment, pas sur les dix téléphones les plus vendus. Un risque de rejet par le store implique de tester sur les versions d’OS sur lesquelles Apple et Google appliquent actuellement leurs règles, ce qui change chaque année.
C’est aussi là que la matrice reste volontairement petite. Une matrice construite à partir du risque couvre moins d’appareils qu’une matrice construite à partir des parts de marché, et c’est tout l’intérêt. Chaque appareil ajouté sans risque derrière lui représente une couverture que vous payez sans l’utiliser.
Le squelette du document de stratégie de test
Un document de stratégie de test d’applications mobiles n’a pas besoin d’être long. Huit sections, avec une ligne d’orientation chacune, suffisent pour qu’un PM le remplisse l’après-midi même :
- Types de défaillance classés – l’ordre par coût financier issu de la décision 1, propre à cette application.
- Affectation des couches – quel type est détecté sur quelle couche, d’après la décision 2.
- Responsable des builds limites – le rôle et le circuit d’escalade, d’après la décision 3.
- Matrice d’appareils et d’OS – le résultat de la décision 4, rattaché aux risques classés.
- Critères de mise en production – ce qui doit être vrai pour qu’un build soit livré, en langage clair.
- Périmètre de régression par version – ce qui est revérifié à chaque fois et ce qui ne l’est qu’en cas de changement majeur.
- Exclusions connues – ce que cette stratégie ne couvre volontairement pas, et pourquoi.
- Fréquence de révision – quand ce document est réexaminé (un nouveau prestataire de paiement, une nouvelle version d’OS, un lancement raté).
Quand adapter cet ordre
Cette séquence de quatre décisions suppose une application avec de vrais utilisateurs et de l’argent réellement en jeu. Elle est excessive pour un outil interne ou un prototype jetable, où « tester le parcours nominal et livrer » est la réponse honnête. Elle suppose aussi que quelqu’un accepte d’avoir la discussion sur les coûts de la décision 1, ce qui exige de réunir le produit et l’ingénierie dans la même pièce. Si cette discussion ne peut pas avoir lieu, la stratégie retombera sur une liste d’appareils, parce qu’une liste d’appareils est ce qui reste quand personne ne veut classer ce qui compte vraiment.
Comment QAwerk la construit avec vous
QAwerk a mené à bien plus de 300 projets QA, et un schéma revient souvent : les équipes qui passent directement à la matrice d’appareils dépensent leur budget de test sur le mauvais risque. BeFamily est venue voir QAwerk avec une toute nouvelle application : l’équipe a rédigé les plans de test, créé plus de 500 scénarios de test et testé les nouveaux builds sur 9 appareils. Depuis son lancement, BeFamily n’a connu aucun plantage ni problème majeur en production, et son nombre d’utilisateurs actifs a triplé en une semaine.
C’est la différence entre un prestataire QA qui exécute une liste de vérification et une équipe qui travaille avec vous sur les décisions 1 et 3 avant d’écrire le moindre cas de test. Si vous mettez en place des tests d’applications mobiles pour la première fois, ou si vous héritez d’un processus qui ne détecte pas ce qui compte, c’est par là que la discussion doit commencer, pas par les téléphones.
Qu'est-ce qu'une stratégie de test d'applications mobiles ?
C’est l’ordre des décisions derrière un effort de test : quelles défaillances comptent le plus selon leur coût, quelle couche de test détecte chacune au moindre coût, qui valide un build limite et, seulement ensuite, quels appareils et quelles versions d’OS sont testés. Ce n’est ni la liste d’appareils elle-même, ni la liste de vérification de ce qu’il faut contrôler pour chaque fonctionnalité.
Que doit contenir un document de stratégie de test d'applications mobiles ?
Huit sections suffisent : les types de défaillance classés, l’affectation des couches par type de défaillance, le responsable des builds limites et le circuit d’escalade, la matrice d’appareils et d’OS, les critères de mise en production, le périmètre de régression par version, les exclusions connues et une fréquence de révision.
Comment planifier une stratégie de test mobile ?
Commencez par le coût, pas par les appareils. Classez les défaillances (plantage au lancement, échec de paiement, perte de données, rejet par le store) qui coûteraient le plus cher à votre application. Affectez ensuite chacune à la couche la moins coûteuse qui la détecte, désignez qui tranche une décision de mise en ligne limite, et seulement ensuite construisez la matrice d’appareils autour de ces risques classés.
Une matrice d'appareils est-elle la même chose qu'une stratégie de test ?
Non. Une matrice d’appareils est l’un des résultats d’une stratégie, le dernier. Les équipes qui construisent d’abord la matrice se retrouvent avec une large couverture d’appareils qui ne reflète pas leur risque réel, parce que la matrice a été construite à partir des parts de marché plutôt que du coût classé des défaillances.
Qui doit piloter une stratégie de test mobile, la QA ou le produit ?
Ni l’un ni l’autre seul. Le classement du coût des défaillances est une décision produit et business ; l’affectation des couches est une décision QA et ingénierie. La stratégie fonctionne quand un seul document réunit les deux, avec un responsable désigné pour les moments où les deux ne sont pas d’accord.
Découvrez comment une application iOS a corrigé des bugs critiques, des plantages, et des lacunes UX avant soumission, et a été lancée sans reprise coûteuse
