L'app plante après une mise à jour : premiers contrôles

La nouvelle version est sortie et des testeurs signalent des plantages que l'ancienne n'avait jamais eus. Quelque chose a changé entre les deux builds. Le plus rapide est de suivre un ordre fixe de contrôles, du suspect le plus probable et le moins coûteux au plus rare et au plus cher.

Étape 0 : sépare les deux types de plantage

Pose une seule question au testeur : le plantage est-il arrivé après une mise à jour par-dessus l'ancienne version, ou aussi sur une installation propre ?

• Seulement après la mise à jour : le problème est dans le chemin de mise à jour, généralement d'anciennes données qui rencontrent un nouveau code.
• Aussi sur une installation propre : le problème est dans le nouveau build lui-même.

Cette seule réponse divise la recherche par deux.

Les contrôles, dans l'ordre

1. Lis le rapport de plantage. Récupère la trace de la pile et la version exacte. Note la première ligne de ton propre code. Voir [comment les testeurs envoient un rapport de bug Android pour ce que les testeurs peuvent t'envoyer.
2. Compare la version. Liste ce qui a changé depuis le dernier bon build : code, bibliothèques, réglages de build, configuration. Le plantage se trouve presque toujours dans cette liste.
3. Migration de données. As-tu modifié un schéma de base de données, un réglage sauvegardé ou un format de fichier ? Des données anciennes que le nouveau code ne reconnaît pas sont le classique plantage de mise à jour. Voir [tester une migration de base de données sans perdre de données.
4. Bibliothèques ou SDK mis à jour. Une nouvelle version peut changer le comportement ou supprimer une fonction. Regarde les changements de chaque dépendance qui a bougé.
5. Configuration et clés. Valeurs de configuration, clés d'API, indicateurs de fonctionnalités ou réglages serveur manquants ou modifiés que le nouveau build lit.
6. Différences de build. La réduction et l'obfuscation du code peuvent supprimer ou renommer quelque chose utilisé à l'exécution. Un plantage qui n'apparaît que dans le build de production, et pas en debug, pointe ici.
7. Signature. Un build signé différemment du précédent peut empêcher la mise à jour ou l'accès aux données protégées. Vérifie que les builds de test et de production sont signés comme tu l'entends.
8. Changements côté serveur. Un changement de backend livré en même temps peut ressembler à un plantage de l'app. Vérifie si les anciennes versions échouent aussi.

Reproduis la mise à jour, pas seulement le nouveau build

La plupart des équipes ne testent qu'une installation propre de la nouvelle version. Fais plutôt ceci :

1. Installe la version précédente et utilise-la jusqu'à avoir de vraies données.
2. Mets à jour par-dessus vers le nouveau build.
3. Ouvre chaque écran principal et répète les actions clés.
4. Recommence depuis une version beaucoup plus ancienne si tu as encore des utilisateurs dessus.

[Comment tester une mise à jour d'une app en production détaille cette démarche.

Quoi demander aux testeurs

• Quelle version avaient-ils avant, et laquelle maintenant ?
• Ont-ils mis à jour ou réinstallé ?
• Qu'ont-ils fait juste avant le plantage ?
• Ça arrive à chaque fois ?

Contenir le problème

Une fois la cause connue, décide vite : déployer un correctif, ou arrêter le déploiement si tes outils de store le permettent. Vérifie les options actuelles dans la console de ton store. Ensuite, ajoute le cas de mise à jour défaillant à ta checklist de sortie.

Liens

• Hub : [Problèmes de tests d'apps : causes et solutions
• [Tester ce qui se passe quand les utilisateurs refusent les permissions
• [Les testeurs ne peuvent pas se connecter : problèmes de compte de test

Les testeurs qui utilisent l'ancienne version puis mettent à jour détectent ce qu'une installation propre masque. Sur AppReviewX, tu reçois des retours privés et structurés sur ton build. Commence gratuitement.