Dans ce guide
Une app sans contenu paraît cassée. Une app remplie de données réelles de clients pose un problème de vie privée. Les testeurs ont besoin d'un entre-deux : des données réalistes mais fictives, et des comptes qui ne peuvent blesser personne. Voici une liste de contrôle pour préparer les deux.
Pourquoi c'est important
Les testeurs qui ouvrent une app vide ne peuvent pas tester les écrans qui comptent : listes, recherche, filtres, parcours de modification. Soit ils signalent « rien à voir », soit ils abandonnent. Et s'ils se connectent à une copie de tes données réelles, tu exposes de vraies personnes à des inconnus.
Liste de contrôle : données
- N'utilise jamais de données réelles d'utilisateurs. Pas d'exports de production, même « juste pour tester ». Les vrais noms, e-mails et messages ne doivent pas atteindre les testeurs. Il s'agit de conseils généraux, pas d'un avis juridique ; vérifie les règles qui s'appliquent à toi.
- Crée des données de test volontairement. Écris un petit ensemble d'enregistrements fictifs qui couvre les cas normaux et les cas limites.
- Couvre les cas limites. Inclus un nom très long, un champ vide, des caractères spéciaux, un élément sans image, une liste d'une seule entrée et une liste très longue.
- Rends-les reconnaissables comme fictifs. Utilise des noms et adresses manifestement inventés pour que personne ne les prenne pour de vraies données.
- Rends-les réinitialisables. Décide comment restaurer l'état de départ : un bouton de réinitialisation, un script ou un compte neuf. Sans cela, les testeurs suivants voient le désordre laissé par les précédents.
- Adapte les données à la fonction. Si tu veux un retour sur la recherche, il faut assez d'éléments pour que la recherche ait un sens.
Liste de contrôle : comptes
- Fournis des comptes de test si ton app demande une connexion. Ne demande pas aux testeurs de te confier leurs vrais mots de passe.
- Un compte par testeur quand l'état compte. Si les testeurs partagent un compte, ils s'écrasent mutuellement leurs modifications et ne peuvent pas tester l'inscription ni l'accueil. Les comptes partagés ne conviennent que pour des vérifications en lecture seule.
- Utilise des permissions limitées. Un compte de test ne doit pas accéder aux outils d'administration, aux paiements réels ni à la messagerie en direct.
- Propose les deux parcours. Permets aux testeurs de créer aussi leur propre compte, pour que l'inscription soit testée.
- Ne laisse pas d'identifiants dans des endroits publics. Envoie-les en privé aux testeurs qui en ont besoin, puis change-les ou supprime-les ensuite.
- Vérifie les services tiers. Si les connexions passent par un autre fournisseur, assure-toi que les utilisateurs de test peuvent vraiment se connecter. Voir planification des versions et appareils de test Android pour associer les testeurs aux configurations.
Paiements et effets externes
Si ton app peut envoyer des e-mails, des notifications push ou prendre des paiements, passe-les en mode test ou dirige-les vers des cibles inoffensives. Un testeur qui appuie sur « Acheter » ne doit jamais coûter d'argent à quelqu'un ni prévenir un vrai client. Pour tester les paiements, utilise les outils de test de ton fournisseur de paiement et consulte sa documentation actuelle.
À inscrire dans les instructions de test
Donne aux testeurs un court bloc : quel compte utiliser, quelles données existent, quoi faire en premier et quoi ignorer. Cela leur évite de deviner et te fait gagner des doublons de rapports. Pour les mises en page sur plusieurs appareils, voir tailles d'écran Android.
Retour au guide de test des apps Android.
Commence ici et décris la configuration de test quand tu demandes un retour.