Tester une application mobile avant sa sortie

Le test d’une application mobile vérifie, avant la publication, que chaque fonction donne le résultat attendu, que l’interface tient sur tous les écrans visés, que l’application reste rapide, sûre et accessible, puis la confronte à de vrais utilisateurs. La décision de sortie se prend ensuite sur des critères écrits à l’avance, jamais sur une impression.

Cette étape arrive souvent en bout de course, juste avant la date annoncée. C’est pourtant là qu’un test d’application mobile bâclé coûte le plus cher : une application qui plante au premier lancement récolte des avis négatifs que les correctifs suivants n’effacent pas.

Commencer le test d’une application mobile par un plan écrit

Avant de toucher un appareil, écrivez ce que vous allez vérifier, sur quels téléphones et selon quels critères la version sera jugée prête. Ce plan de test sert surtout à arbitrer quand le temps manque, ce qui arrive toujours.

Le syllabus Foundation Level de l’ISTQB, l’organisme qui certifie les testeurs logiciels, en donne la raison : tester de façon exhaustive est impossible hors des cas triviaux, et les défauts se regroupent dans un petit nombre de composants. Mieux vaut tester à fond là où se trouve le risque.

Un plan utile tient en quatre rubriques :

• les parcours critiques, ceux qui font perdre un client ou des données s’ils échouent : inscription, connexion, paiement, synchronisation ;
• les modèles, tailles d’écran et versions du système retenus, autrement dit la matrice d’appareils ;
• les environnements : serveur de recette, comptes de test, données fictives ;
• les critères d’entrée et de sortie, qui disent quand une version devient testable, puis publiable.

Bâtissez la matrice sur l’audience réelle et ajoutez volontairement un modèle ancien et peu puissant. Le référentiel général d’écoconception de services numériques, publié par l’Arcep et l’Arcom avec l’ADEME et mis à jour le 28 mai 2024, demande qu’une application native reste utilisable sur des versions du système d’exploitation remontant jusqu’à cinq ans.

Vérifier ce que fait l’application

Cette première famille, celle des tests fonctionnels, répond à une question simple : l’application fait-elle ce qui était prévu ? Les tests non fonctionnels, eux, évaluent la manière dont elle le fait.

Les fonctions, scénario par scénario

Chaque fonctionnalité devient un cas de test : un état de départ, une suite d’actions, un résultat attendu. Après le cas nominal viennent les écarts qui font tomber les applications en production : champ vide, saisie trop longue, double appui sur le bouton de validation, retour arrière en plein paiement, session expirée.

Le mobile ajoute ses interruptions. Simulez un appel entrant pendant une saisie, une notification qui ouvre un écran profond, une mise en veille prolongée, une perte de réseau, le refus d’une autorisation d’accès à la localisation. Une application solide survit à chaque cas sans perdre la saisie en cours.

L’interface et les gestes

Contrôlez ce que l’utilisateur voit et touche : libellés coupés, boutons masqués par le clavier virtuel, écrans qui débordent en mode paysage, zones tactiles trop étroites. Passez chaque écran en grande taille de police système puis en mode sombre, deux réglages qui révèlent beaucoup de défauts de mise en page. Balayage, appui long et pincement doivent produire le même effet partout.

Mesurer comment elle se comporte

Une application capable de remplir toutes ses fonctions reste parfois pénible à utiliser. Le modèle de qualité de la norme ISO/IEC 25010, repris par l’ISTQB, classe parmi les caractéristiques non fonctionnelles l’efficacité des performances, la compatibilité, l’utilisabilité, la fiabilité et la sécurité, entre autres. Quatre d’entre elles pèsent lourd avant une sortie.

Performance, batterie et réseau

Mesurez le démarrage à froid, la fluidité du défilement dans les longues listes, la mémoire occupée après une demi-heure d’usage et la vitesse à laquelle la batterie se vide. Rejouez ensuite les parcours critiques sur une connexion dégradée : réseau lent, coupure en plein envoi, bascule vers les données mobiles. Le référentiel d’écoconception pose aussi la question de l’usage en bas débit ou hors connexion.

Compatibilité entre appareils et versions

Les tests de compatibilité déroulent la matrice. Le parc est si fragmenté qu’un défaut peut ne surgir que sur un seul modèle. Vérifiez aussi la cohabitation avec le reste du téléphone : clavier tiers, mode économie d’énergie, langue modifiée, autorisations retirées entre deux lancements.

Sécurité des données

Le projet de l’OWASP dédié aux applications mobiles publie un standard de vérification et un guide de test, du stockage des données à la vie privée. Au minimum, vérifiez que les identifiants et jetons de session ne restent jamais lisibles sur l’appareil et que chaque autorisation sert une fonction réelle.

Accessibilité

Au niveau AA, les WCAG 2.2 du W3C demandent par exemple des cibles tactiles d’au moins 24 pixels CSS de côté, hors exceptions prévues, un contenu qui ne s’enferme pas dans une seule orientation sans nécessité, et une lecture sans défilement dans les deux sens sur une largeur équivalente à 320 pixels CSS. Parcourez aussi l’application avec le lecteur d’écran activé. Le cadre français et le RGAA sont détaillés dans les obligations d’accessibilité d’une application.

Tests manuels et automatisés : la juste répartition

Il ne s’agit pas de choisir, mais de répartir le travail. La pyramide de tests présentée dans le syllabus de l’ISTQB résume cette logique : à la base, de nombreux tests petits, isolés et rapides ; au sommet, quelques tests de bout en bout, plus lents, qui traversent l’application comme un utilisateur.

Ce qui gagne à être automatisé

• la batterie de tests de régression rejouée à chaque version, candidat naturel à l’automatisation selon l’ISTQB ;
• les contrôles répétitifs sur toute la matrice, lancés la nuit sur émulateurs ou appareils distants ;
• la comparaison de captures d’une version à l’autre, qui repère un bouton déplacé ;
• les mesures de performance, rejouées dans des conditions identiques.

Ce qui reste à la main

Le test exploratoire, où un testeur cherche délibérément à mettre l’application en défaut, échappe aux scripts, tout comme le jugement : un libellé ambigu ou un enchaînement d’écrans illogique passent les tests automatisés au vert. Autre limite relevée par l’ISTQB, des tests répétés à l’identique s’usent. Renouvelez scénarios et données à chaque cycle.

Le bêta-test, ou l’épreuve des vrais utilisateurs

Le syllabus de l’ISTQB range l’alpha-test et le bêta-test parmi les formes du test d’acceptation, qui vérifie que le produit répond aux besoins réels et qu’il est prêt à être déployé. Le bêta sort l’application de l’équipe, vers les téléphones et le quotidien de vrais utilisateurs.

Recruter les bons testeurs

Visez des profils proches de la clientèle plutôt que des collègues, qui connaissent trop le projet et pardonnent tout. Variez appareils, âges et aisance numérique. Les magasins proposent un test fermé, réservé à une liste d’invités, et un test ouvert à toute personne qui s’inscrit. L’un des deux grands magasins impose même aux comptes personnels de développeur récents un test fermé, d’une durée et d’un effectif minimaux, avant tout accès à la production.

Recueillir des retours exploitables

Un bêta-test sans consignes produit surtout du silence. Confiez à chaque vague une mission précise, créer un compte ou passer une commande fictive, et un canal de retour intégré qui joint automatiquement le modèle d’appareil et les versions en cause. Ajoutez quelques entretiens courts : les méthodes de recherche utilisateur apprennent à observer sans orienter.

Trier les anomalies sans s’y noyer

Chaque retour devient un rapport d’anomalie. D’après le syllabus de l’ISTQB, il contient un identifiant, un titre court, la date et l’auteur, l’objet testé et son environnement, les étapes de reproduction avec captures, le résultat attendu et le résultat obtenu, la gravité, la priorité et le statut. La norme ISO/IEC/IEEE 29119-3 en fournit des modèles, sous le nom de rapports d’incident.

Gravité et priorité se confondent souvent. La première mesure l’impact, la seconde dit quand corriger : un plantage sur un modèle marginal peut être grave et peu prioritaire, une coquille sur l’écran d’accueil bénigne mais urgente. Certaines remontées se révèlent aussi des faux positifs ou des demandes d’évolution, d’où l’intérêt d’un circuit unique, de l’enregistrement à la clôture.

La recette, puis la décision de publier

Pendant la recette, le commanditaire vérifie que la version livrée correspond à la commande. Elle se conclut par une décision adossée aux critères de sortie du plan, que l’ISTQB classe en mesures (couverture atteinte, anomalies non résolues, cas en échec) et en conditions binaires (tests prévus tous exécutés, régression automatisée).

Pour une première sortie, une grille réaliste ressemble à ceci :

• aucune anomalie bloquante ou majeure ouverte sur les parcours critiques ;
• toute la matrice parcourue au moins une fois sur appareil réel ;
• les textes provisoires effacés et chaque lien vérifié ;
• un compte de démonstration prêt si l’application exige une connexion, exigence explicite de l’un des deux grands magasins ;
• une procédure de retour à la version précédente écrite et testée.

Le même syllabus admet qu’un manque de temps ou de budget clôture les tests si les parties prenantes ont examiné et accepté le risque de publier en l’état. Écrivez cette acceptation, avec la liste des anomalies connues : elle prépare la première mise à jour.

Chaque mise à jour repasse par le banc d’essai

La sortie ouvre un cycle. Chaque correctif appelle deux vérifications : le test de confirmation, qui s’assure que l’anomalie corrigée a disparu, et le test de régression, qui contrôle que rien n’a été abîmé ailleurs.

Les nouvelles versions du système d’exploitation imposent leur calendrier : installez les préversions destinées aux développeurs et rejouez les parcours critiques avant vos utilisateurs. La diffusion progressive proposée par les magasins limite ensuite l’effet d’un défaut passé entre les mailles. Surveillez enfin les notes et avis de votre fiche : un pic de commentaires négatifs après une version trahit souvent un appareil absent de la matrice.

Prochaine étape : listez vos trois parcours critiques et les cinq appareils les plus représentatifs de votre clientèle, puis écrivez pour chacun le critère qui autorisera la sortie. Ce plan tient sur une page et resservira à chaque version.