GameTime/docs/qa-ticket-261-android-closed-test-release.md

Ticket #261 — Volet QA première release Android en test fermé Play

Objectif

Préparer une validation QA exécutable avant le premier upload Android en test fermé Play pour GameTime, en réutilisant les gates et runbooks déjà présents dans le repo.

Références de base :

• docs/qa-gate-239-functional-flutter.md
• docs/qa-gate-241-critical-screens-smoke.md
• docs/qa-gate-242-monetization-free-pro.md
• docs/qa-gate-243-device-runbooks.md
• docs/release-compliance-checklist.md
• server/docs/integration-checklist.md

1. Checklist de validation exécutable avant upload

A. Repo-only obligatoire avant upload

Préparer l'environnement Flutter :

export HOME=/tmp
export XDG_CONFIG_HOME=/tmp
export FLUTTER_SUPPRESS_ANALYTICS=true
export DART_SUPPRESS_ANALYTICS=true

Exécuter les vérifications suivantes :

1. Politique release Android et manifests

rg -n 'usesCleartextTraffic="true"' android/app/src/main watch_app/android/app/src/main
rg -n 'usesCleartextTraffic="true"' android/app/src/debug android/app/src/profile
rg -n 'android.permission.INTERNET' android/app/src/main/AndroidManifest.xml

Verdict attendu :

• aucun usesCleartextTraffic="true" en release/main
• usesCleartextTraffic="true" autorisé uniquement en debug/profile
• permission INTERNET présente sur l'app téléphone

2. Smoke écrans critiques téléphone

./tool/qa_gate_241_critical_screens_smoke.sh

3. Gate monétisation actuellement testable en local

./tool/qa_gate_242_monetization_partial.sh

4. Suite watch widget locale

cd watch_app
/home/anthony/Documents/Projects/GameTime/.ideai/flutter-sdk-1785572580/bin/flutter test test/presentation/watch_session_screen_test.dart

5. Suite fonctionnelle transverse téléphone

cd /home/anthony/Documents/Projects/GameTime
./.ideai/flutter-sdk-1785572580/bin/flutter test test/functional/functional_coverage_test.dart

Règle de sortie :

• upload interdit si une suite repo-only censée être gate release est rouge
• les blockers connus doivent être enregistrés avant handoff device/Play

B. Build/signature à vérifier avant upload

Le repo impose une signature release locale partagée côté téléphone et montre :

• android/app/build.gradle.kts
• watch_app/android/app/build.gradle.kts
• android/key.properties

Points à vérifier :

• android/key.properties présent
• keystore référencé présent
• même signature pour téléphone et montre
• versionCode et versionName cohérents pour le lot livré
• URL API release en HTTPS si build release connecté

C. Device/manual obligatoire avant upload ou juste après distribution interne

Téléphone :

• runbook Health Connect
• runbook import/export réel
• smoke nominal installation / lancement / navigation / exécution d'une séance

Montre :

• runbook watch companion complet avec collecte d'artefacts téléphone + montre

Entrées de référence :

./tool/qa_device_health_connect.sh start
./tool/qa_device_import_export_real.sh start
WATCH_SERIAL=<watch-adb-serial> ./tool/qa_device_watch_companion.sh start

2. Cas de tests réels prioritaires phone et watch

Priorité P0 téléphone

1. Installation release puis premier lancement

• l'app démarre sans crash
• l'icône, le nom et le thème de lancement sont corrects

2. Parcours coeur offline

• créer ou utiliser un contenu existant
• lancer une séance
• exécuter score manuel, chrono, repos, skip
• terminer la séance
• vérifier historique et reprise si sortie intermédiaire

3. Import/export réel

• export réussi
• import merge réussi
• import replaceAll sur dataset jetable
• refus d'import si séance active

4. Profil / partage / sync exposés sans blocage

• profil déconnecté utilisable
• navigation vers boîte de réception des partages
• aucun blocage du coeur gratuit si non connecté

Priorité P0 montre

1. Projection d'une séance téléphone vers montre

• la séance active apparaît côté montre
• le statut de connexion est cohérent

2. Action round-trip montre -> téléphone

• pause / reprise / validation ou autre action watch
• effet visible et cohérent sur le téléphone

3. Fin de séance cohérente sur les deux appareils

• teardown propre côté montre
• pas d'état fantôme après clôture

Priorité P1 téléphone

1. Health Connect gratuit

• ouverture du flux permission ou fallback réglages
• retour propre dans GameTime
• état UI rafraîchi

2. Cas dégradés réseau / sync

• l'app reste utilisable hors connexion pour le coeur offline
• un échec de sync reste neutre pour le flux principal

Priorité P1 montre

1. Télémétrie visible

• fréquence cardiaque si autorisée
• distance / pas si disponibles sur l'appareil

2. Reconnexion

• perte puis retour de connexion
• resync cohérent sans actions fantômes

3. Ce qui peut être validé sans Play Console ni devices

Validable maintenant depuis le repo

1. Politique manifests/release

• usesCleartextTraffic absent des manifests release/main
• INTERNET présent côté téléphone

2. Smoke UI téléphone

• ./tool/qa_gate_241_critical_screens_smoke.sh

3. Surface monétisation gratuite actuellement testable

• ./tool/qa_gate_242_monetization_partial.sh

4. UI/watch locale

• watch_app/test/presentation/watch_session_screen_test.dart

5. Présence du câblage signature/build

• android/key.properties
• config release téléphone + montre

Preuves réellement exécutées le 28 août 2026

Vert :

• ./tool/qa_gate_241_critical_screens_smoke.sh
• ./tool/qa_gate_242_monetization_partial.sh
• watch_app/test/presentation/watch_session_screen_test.dart exécuté depuis watch_app/ : 33 tests verts

Rouge :

• ./.ideai/flutter-sdk-1785572580/bin/flutter test test/functional/functional_coverage_test.dart

Échec réel constaté :

• test en échec : QA functional fast foundation QA seed inserts deterministic coverage content once
• fichier : test/functional/functional_coverage_test.dart
• ligne signalée : 48
• symptôme : attente de 3 exercices, valeur réelle 5

Conséquence QA :

• la gate transverse #239 ne doit pas être considérée comme verte au 28 août 2026
• un upload peut être préparé administrativement, mais pas validé “QA green” tant que ce rouge reste ouvert si #239 fait partie de la barrière release retenue

4. Ce qui reste bloquant sans l'utilisateur

Bloquant sans Play Console

• création/configuration du closed testing track
• upload réel AAB/APK et vérification post-upload
• app content forms Play
• URL publique finale de privacy policy
• éventuelle déclaration/review Play liée à Health Connect
• vérification de la fiche store et des audiences/testeurs

Bloquant sans devices réels

• installation réelle téléphone Android
• installation réelle montre Wear OS
• permissions Health Connect réelles
• bridge téléphone <-> montre via Data Layer
• télémétrie capteurs réelle
• import/export réel via file picker système

Bloquant sans intervention utilisateur/produit

• sélection du build exact à uploader
• confirmation du endpoint release HTTPS final
• validation finale des identifiants/signature destinés à la release
• exécution des scénarios manuels sur compte(s) et appareil(s) de test fermés
• arbitrage sur le statut du rouge actuel de la gate #239

Recommandation QA pour le ticket

Ordre recommandé avant premier upload fermé :

1. corriger ou rebaseliner le rouge actuel de test/functional/functional_coverage_test.dart
2. rerun repo-only : #241, #242, #239, suite watch
3. exécuter les runbooks device #243
4. seulement ensuite procéder à l'upload Play fermé

Dans l'état observé le 28 août 2026, le repo permet déjà de préparer une grande partie du volet QA release, mais pas de fermer la validation complète sans devices, sans Play Console, et sans décision explicite sur le rouge de la gate fonctionnelle transverse.

Attentes testables minimales pour guardrails release

1. Version / build number phone et watch

• versionName doit être identique entre téléphone et montre pour un même lot release
• versionCode doit être identique entre téléphone et montre pour un même lot release
• si phone et watch divergent, le build release doit être considéré invalide pour livraison

2. GAMETIME_API_BASE_URL en release

• si GAMETIME_API_BASE_URL est absent en release, le build doit échouer explicitement
• si GAMETIME_API_BASE_URL n'utilise pas https:// en release, le build doit échouer explicitement
• aucun fallback implicite HTTP, localhost ou LAN ne doit être autorisé en release

3. Statut du rouge functional_coverage_test

• au 28 août 2026, test/functional/functional_coverage_test.dart est rouge
• ce rouge ne doit pas bloquer à lui seul une première release fermée phone-only si les gates release retenues sont #241, #242 et les validations device téléphone
• en revanche, il bloque toute décision annonçant la gate fonctionnelle transverse #239 comme verte