Pourquoi tester son application avant ses utilisateurs

Imaginez cet avis sous votre application, un lundi matin : « Une étoile. J’ai envoyé 15 000 FCFA, l’argent est parti, aucun reçu. Arnaque. » Ce n’est pas une arnaque : le reçu s’est perdu quand le réseau a coupé au mauvais moment. Mais l’avis, lui, reste en ligne.

Ce défaut, un test d’une demi-heure dans un taxi, entre deux zones mal couvertes, aurait pu le révéler. Votre utilisateur l’a trouvé à votre place, et il vous l’a fait payer en confiance.

Les stores ne restent pas neutres non plus. Google l’écrit noir sur blanc : si au moins 1,09 % de vos utilisateurs quotidiens subissent un plantage en cours d’utilisation, Google Play peut réduire la visibilité de votre app et afficher un avertissement sur sa fiche.

Vous allez voir ce que coûte vraiment un bug trouvé par vos utilisateurs, ce que le test vous apporte, qui doit tester quoi et quand commencer. Vous repartirez avec une liste de contrôle à appliquer dès aujourd’hui.

Que coûte un bug découvert par vos utilisateurs ?

Corriger le code est souvent la partie la moins chère. Un défaut qui atteint vos utilisateurs vous envoie quatre factures, et la plupart ne passent jamais par votre équipe technique.

La note sur le store

Un avis d’une étoile est l’une des premières choses que lit un futur utilisateur, parfois avant vos captures d’écran. Sur Google Play, la note affichée accorde plus de poids aux avis récents. Une mise à jour ratée peut donc faire chuter votre note en quelques jours, même si l’app était appréciée depuis longtemps.

Vous pouvez répondre à chaque avis, une fois, et l’utilisateur est prévenu de votre réponse. C’est utile. Mais une réponse répare rarement une mauvaise première impression : elle prouve seulement que vous êtes là.

La désinstallation silencieuse

Beaucoup d’utilisateurs déçus ne prennent pas la peine d’écrire. Ils désinstallent. Sur un téléphone de 32 Go déjà rempli de photos et de vidéos reçues sur WhatsApp, l’app qui plante est la première sacrifiée quand il faut faire de la place. Vous ne saurez jamais pourquoi elle est partie : vous verrez seulement baisser la courbe de vos utilisateurs actifs.

Le support qui déborde

Chaque défaut visible se transforme en messages, en appels et en captures d’écran floues à déchiffrer. Dans une app qui manipule de l’argent, c’est pire : chaque transaction douteuse demande une vérification, parfois un remboursement, toujours une explication. Le temps passé à éteindre ces feux n’est pas passé à construire la suite.

La visibilité et la réputation

Les stores mesurent la qualité à votre place. Google Play suit les plantages et les blocages de chaque app (les ANR, pour Application Not Responding : l’app ne répond plus). Au-delà de certains seuils, il peut la montrer moins souvent. Apple, de son côté, annonce qu’il rejette les apps qui plantent ou qui présentent des problèmes techniques évidents. Et le bouche-à-oreille fonctionne dans les deux sens : un « évitez cette app » partagé dans un groupe de famille pèse lourd.

Le tableau suivant suit un même défaut, un bouton « Payer » qui reste actif pendant le chargement, selon le moment où on le découvre.

Que vous apporte vraiment le test ?

Trois mots reviennent sans cesse dans le métier. Les distinguer vous aidera à comprendre vos testeurs :

• L’erreur est humaine : un développeur a mal compris une règle, ou il était pressé.
• Le défaut, le fameux bug, est la trace de cette erreur dans le code ou dans un document.
• La défaillance est ce que voit l’utilisateur quand le défaut se déclenche : l’écran blanc, le reçu qui n’arrive pas.

Un défaut ne provoque pas toujours une défaillance. Certains dorment des mois, jusqu’au jour où un utilisateur réunit les bonnes conditions : un vieux téléphone, un réseau faible, un nom avec une apostrophe.

Voici ce que le test vous apporte concrètement :

• Des défauts trouvés avant vos utilisateurs, quand ils coûtent encore peu.
• Une information pour décider : publier aujourd’hui ou attendre une semaine ? Sans test, ce choix se fait à l’aveugle.
• La voix des utilisateurs dans l’équipe : un testeur se met à la place de ceux qui n’assistent pas à vos réunions.
• La conformité : les stores exigent une app stable, et certains secteurs, comme la banque ou la santé, ont leurs propres obligations.
• La confiance : vous publiez en sachant ce qui a été vérifié, et ce qui ne l’a pas été.

Le test a aussi ses limites. Il montre la présence de défauts, jamais leur absence : c’est le premier des sept principes du test logiciel. Et tester n’est pas déboguer. Le testeur provoque et décrit la défaillance ; le développeur en cherche la cause et la corrige. Le testeur vérifie ensuite que la correction fonctionne, et qu’elle n’a rien cassé ailleurs.

Qui teste quoi dans un projet d’application ?

Tout le monde teste, mais personne ne voit tout. Le tableau ci-dessous montre ce que chacun teste le mieux, et ce qui lui échappe.

L’ISTQB parle d’indépendance du test. Un testeur éloigné de l’auteur repère d’autres défauts, parce qu’il n’a pas les mêmes biais. L’indépendance ne remplace pas la connaissance du produit : un développeur trouve très efficacement beaucoup de défauts dans son propre code. La bonne pratique consiste donc à combiner plusieurs niveaux. Pour savoir ce qui revient aux humains et ce qui revient aux scripts, lisez notre guide test manuel ou automatisé.

Quand faut-il commencer à tester ?

Le plus tôt possible. C’est un autre principe de l’ISTQB : tester tôt économise du temps et de l’argent. Un défaut éliminé au début ne contamine pas la suite du travail. On parle de shift left (« décaler vers la gauche ») : on avance le test sur la ligne du temps du projet, sans pour autant abandonner les tests de fin de parcours.

Vous pouvez tester bien avant la première ligne de code :

1. L’idée : cinq futurs utilisateurs reconnaissent-ils le problème que vous voulez résoudre ?
2. Le cahier des charges : chaque phrase est-elle claire ? Pourrait-on écrire un test pour la vérifier ?
3. Les maquettes : faites-les parcourir sur un vrai téléphone, pas sur un grand écran d’ordinateur.
4. La première version : testez chaque écran dès qu’il fonctionne.
5. Chaque nouvelle version : vérifiez que ce qui marchait marche toujours, avec des tests de non-régression (voir smoke test, régression et recette).
6. Après publication : lisez les avis et les rapports de plantage de la console du store, chaque semaine.

Que tester en premier quand le temps manque ?

Personne ne peut tout tester. Il faut choisir, et le bon critère est le risque : que se passe-t-il si cette partie casse, et quelle est la probabilité qu’elle casse ? Dans l’ordre, regardez d’abord :

1. Tout ce qui touche à l’argent : paiement, transfert, abonnement, remboursement.
2. Tout ce qui touche aux données : inscription, connexion, sauvegarde, suppression.
3. Le premier lancement : installation, inscription, premier écran. C’est là que se joue la première impression.
4. Le parcours principal : la raison d’être de votre app, commander, réserver, payer.

Testez ensuite ces parcours dans les conditions réelles de vos utilisateurs, et pas dans celles de votre bureau. Un téléphone d’entrée de gamme avec peu de mémoire. Un réseau lent, ou qui coupe (voir notre guide pour tester sur un réseau lent). Des données mobiles chères, qui font hésiter avant une mise à jour lourde. Un appel ou un SMS qui interrompt un paiement. Une app utilisée en français, en anglais, parfois les deux. Un petit écran et une police agrandie.

Par quoi commencer dès aujourd’hui ?

Vous n’avez besoin ni d’outil ni de budget pour faire un premier pas. Il vous faut un téléphone, trente minutes et un peu de méthode.

1. Écrivez les cinq parcours qui comptent pour vos utilisateurs, en une phrase chacun.
2. Prenez le téléphone le moins cher auquel vous avez accès : c’est celui d’une partie de vos utilisateurs.
3. Passez la liste de contrôle ci-dessous, en données mobiles, pas en Wi-Fi.
4. Faites essayer l’app à trois personnes qui ne l’ont jamais vue. Ne les aidez pas. Notez où elles hésitent.
5. Notez chaque problème avec les étapes pour le reproduire, le résultat attendu et le résultat obtenu. Notre guide du rapport de bug efficace vous montre comment.

Avant de publier, passez aussi notre liste de contrôle avant publication.

Faut-il tout tester soi-même ?

Si vous êtes seul ou en petite équipe, la tentation est grande de faire tester vos proches. C’est mieux que rien, mais ils ont souvent les mêmes téléphones que vous, ils vous connaissent et ils restent polis. Leurs retours sont rarement les plus utiles.

Les stores, eux, poussent à tester avec de vraies personnes. Sur Google Play, un compte développeur personnel créé après le 13 novembre 2023 doit mener un test fermé avec au moins 12 testeurs inscrits sans interruption pendant au moins 14 jours avant de demander l’accès à la production. Tout est expliqué dans notre guide du test fermé à 12 testeurs.

Sur iPhone et iPad, les versions de test passent par TestFlight, que nous détaillons dans le guide pour tester une app iPhone avec TestFlight.

C’est précisément le rôle de GeekTest : mettre votre app entre les mains de testeurs réels et rémunérés, sur leurs propres téléphones et ordinateurs, et vous rendre des retours structurés. Pour Android, la page 12 testeurs pour Google Play détaille la formule ; nos tarifs couvrent aussi iPhone, web et ordinateur.

Et si traquer les défauts vous plaît, c’est un vrai métier, qui s’apprend : voyez comment devenir testeur d’applications.

Le meilleur moment pour trouver le bug du double paiement, c’était avant la publication. Le deuxième meilleur moment, c’est aujourd’hui.

Pour aller plus loin

• Syllabus ISTQB Niveau Fondation v4.0, en français (CFTL) (nouvel onglet) : la définition du test, l’erreur, le défaut et la défaillance, l’indépendance du test (chapitre 1) et l’approche shift left (section 2.1.5).
• Aide Play Console : Android vitals (nouvel onglet) : la définition des taux de plantage et d’ANR perçus par les utilisateurs, et leurs seuils de mauvais comportement.
• Android Developers : Android vitals (nouvel onglet) : comment ces indicateurs influencent la visibilité d’une app sur Google Play.
• Aide Play Console : notes et avis (nouvel onglet) : le calcul de la note, qui privilégie les avis récents, et les réponses aux avis.
• App Review Guidelines d’Apple (nouvel onglet) (en anglais) : la règle 2.1 sur les apps incomplètes ou qui plantent.
• Aide Play Console : exigences de test pour les nouveaux comptes personnels (nouvel onglet) : le test fermé avec 12 testeurs pendant 14 jours.