Un verdict, pas un tableau de bord
GO, GO avec réserves ou NO-GO, et la liste de ce qui a changé depuis la version précédente. Pas de suite de tests à écrire, pas de matrice à configurer : c'est la différence avec une plateforme de tests.
Sur de vrais téléphones
Ma nouvelle version est-elle publiable ?
Une seule question, une seule réponse. Go/No-Go installe votre APK sur un vrai appareil, déroule la checklist de régression et rend un verdict — avec ce qui a changé depuis la version précédente, captures à l'appui.
Sans carte bancaire pour commencer. Paiement sécurisé par Stripe quand vous changez d'offre.
GO
9 contrôles mesurés, aucun bloquant. 3 contrôles ne sont pas mesurés.
- Installation propre
- Mise à jour en place
- Démarrage à froid 1 240 ms
- Exploration monkey (3 min) 0 crash
- Comparaison visuelle accueil
- targetSdk 34
- Taille de l'APK 18,4 Mo
- Nouvelles permissions aucune
- versionCode 42
- Refus des permissions non mesuré
- Rotation, arrière-plan non mesuré
- Démarrage hors ligne non mesuré
12 contrôles9 mesurés3 non mesurés
exit 0 — publiable
D'une version à l'autre
Ce qui a changé depuis 1.4.2
Un verdict ne dit rien s'il ne dit pas ce qui a bougé. Donnez la version précédente : Go/No-Go compare, et met en réserve ce qui régresse.
| Mesure | 1.4.2 | 1.5.0 | |
|---|---|---|---|
| Démarrage à froid | 1 180 ms | 1 240 ms | +5 % |
| Taille de l'APK | 18,0 Mo | 18,4 Mo | +2 % |
| targetSdk | 33 | 34 | à jour |
| Nouvelles permissions | — | aucune | 0 |
| versionCode | 41 | 42 | croissant |
| Écrans comparés | accueil | accueil | 1 écran |
Trois contrôles ne sont pas mesurés en phase 1.
Refus des permissions, rotation/arrière-plan/mort du processus, mode avion : le socle ne les pilote pas encore. Ils sortent en
skipped avec leur raison — jamais en passed, jamais en échec.
Un faux GO casse une publication ; un faux NO-GO en bloque une légitime. Une version qui ne passe pas au vert sur un point non mesuré le dit, elle ne le devine pas.
En toute franchise
Ce que nous ne faisons pas
Un produit qui cache ses limites fait perdre du temps à tout le monde. Voici les nôtres, aujourd'hui.
- Trois contrôles ne sont pas mesurés : refus de permission, rotation/arrière-plan/mort du processus et mode avion. Le socle ne les pilote pas : ils sortent en `skipped`, jamais en `passed`.
- Un crash qui ne se produit que sur la rotation n'est donc pas détecté.
- Une vérification utilise un seul appareil : le multi-appareils n'est pas fait, malgré les 4 appareils annoncés par l'offre de vérification unique.
- Le contenu des données n'est pas lu après une mise à jour ; seules la mise à jour en place et le redémarrage sont vérifiés.
- Les parcours personnalisés (flows Maestro) ne sont pas branchés.
- L'upload d'APK par l'API n'existe pas en phase 1 : le CLI dépose lui-même chez Hangar. Pas de GitHub Action, pas de badge, pas d'iOS.
- La comparaison visuelle ne couvre qu'un écran, l'accueil : les écrans multiples demandent un parcours.
- Stripe n'est pas branché : la page de facturation le dit et la route de paiement répond 503.
Ce que ça fait
Concrètement
Une checklist sans rien écrire
Installation propre, mise à jour, démarrage à froid, exploration `monkey` de 3 min à graine fixée, comparaison visuelle et contrôles statiques (`targetSdk`, taille de l'APK, nouvelles permissions, `versionCode` croissant).
Un code de sortie qui bloque une publication
`gonogo check --apk … --wait` rend 0 si GO ou GO avec réserves, 1 si NO-GO, 2 si la vérification est impossible. Dans un script de publication, ça arrête tout avant la Play Console.
La page de verdict, à partager
`GET /verdict/:token` : une page HTML autonome, sans clé API, où chaque point est listé avec sa preuve. C'est le lien qu'on colle dans un ticket ou un message d'équipe.
Ce qui n'est pas mesuré est écrit
Trois contrôles ne sont pas pilotables par le socle en phase 1 : ils sortent en `skipped` avec leur raison, jamais en `passed` et jamais en échec. Un faux verdict coûte plus cher que pas de verdict.
Questions
Questions fréquentes
Que signifie « non mesuré » ?
Le socle ne sait pas encore refuser une permission, faire tourner l'écran ni passer en mode avion. Ces trois contrôles sortent en `skipped` avec leur motif : jamais en `passed`, jamais en échec — un faux NO-GO bloque une publication légitime, un faux GO la casse.
Le contenu des données est-il vérifié après une mise à jour ?
Non : la mise à jour en place et le redémarrage sont vérifiés, mais le contenu des données n'est pas lu. Le contrôle est marqué « mesuré partiellement ».
Une même build donne-t-elle toujours le même verdict ?
Oui. L'exploration utilise une graine fixée (424242), la même d'une version à l'autre : pas de hasard, donc deux vérifications de la même build donnent le même verdict.
Puis-je ajouter mes propres parcours ?
Pas encore : les parcours personnalisés (flows Maestro : connexion, achat…) s'ajouteront à la checklist, mais ils ne sont pas branchés, même si le job `flow` du socle existe.
Le dépôt de l'APK se fait par le site ?
Pas en phase 1 : le CLI dépose le fichier lui-même chez le socle. L'upload d'APK par l'API et le dépôt manuel sur le site viendront plus tard.
Essayez sur un vrai téléphone
Créez un compte, prenez une clé, lancez votre premier test. C'est gratuit pour commencer.