Tester la mise à jour depuis une ancienne version

La plupart de tes utilisateurs n'installent pas une copie neuve. Ils mettent à jour. Un build qui marche sur une installation propre peut tout de même planter en ouvrant des données écrites par une version précédente. Le test du chemin de mise à jour détecte ce cas.

Pour une vue plus large du test d'une mise à jour sur une app en ligne, voir comment tester une mise à jour d'une app en ligne. Cette page en est le script concret.

Ce qu'il te faut

• L'ancien build sous forme d'APK ou une version du store que tu peux installer (idéalement la plus ancienne encore utilisée, plus la version précédente).
• Le nouveau build, signé avec la même clé que l'ancien. Une signature différente bloque la mise à jour ; voir signature de l'app et testeurs.
• Un appareil ou un émulateur que tu peux réinitialiser.

Le script

1. Installe l'ancienne version. Pars d'un appareil propre ou après désinstallation.
2. Crée des données réalistes. Connecte-toi, remplis profil et réglages, crée les principaux objets de ton app, accorde les permissions qu'un vrai utilisateur accorderait, ajoute quelques cas limites comme un texte très long ou des champs vides.
3. Note l'état. Fais une capture des écrans clés et note les compteurs (éléments, comptes, réglages).
4. Mets à jour sur place. Installe le nouveau build par-dessus l'ancien sans désinstaller. Avec adb, adb install -r app.apk remplace l'app et conserve ses données. Mieux encore : mets à jour via le même canal que les utilisateurs, comme une piste de test.
5. Ouvre et compare. L'utilisateur est-il toujours connecté, si c'est voulu ? Tous les éléments et réglages sont-ils là et inchangés ?
6. Utilise les parties modifiées. Parcours chaque fonctionnalité touchée dans la nouvelle version, avec les anciennes données.
7. Vérifie les tâches en arrière-plan. Les tâches planifiées, notifications et synchronisations doivent reprendre sans redémarrage manuel.

Ce qui casse souvent

• Un changement de base de données sans migration correcte : plantage au premier lancement ou perte silencieuse de données. Voir tester une migration de base de données sans perdre de données.
• Clés de réglages renommées ou supprimées.
• Connexion enregistrée ou jetons devenus invalides.
• Une nouvelle permission obligatoire ou une étape d'intégration présentée aux utilisateurs existants dans le mauvais ordre.
• Fichiers en cache dans un ancien format.

Sauter des versions

Teste plus d'un saut. Les utilisateurs qui mettent à jour rarement passent de la version 3 directement à la 7. Teste de la plus ancienne à la plus récente, et aussi de la précédente à la plus récente.

Le retour en arrière est une autre question

Installer une version plus ancienne par-dessus une plus récente est en général bloqué ou fait perdre des données. Ce n'est pas un chemin supporté pour la plupart des apps, donc ne le traite pas comme un test de mise à jour.

Note le résultat

Consigne l'ancienne version, la nouvelle version, les données créées et le premier échec, avec le log s'il y a un plantage.

Retour au hub de test d'apps Android. Liens associés : installation propre et réinstallation et la checklist du premier lancement.

Les testeurs avec des appareils et des versions d'OS plus anciens repèrent ce que ton propre téléphone ne montre pas. AppReviewX te donne des retours privés et structurés ; 1 retour = 1 crédit. Commence gratuitement.