Un appareil préchauffé est un vrai téléphone déjà démarré, avec votre application mobile déjà installée et ouverte. Quand l'un d'eux est disponible, votre exécution mobile s'y rattache et démarre en deux secondes environ, au lieu d'attendre qu'un appareil soit trouvé, démarré et chargé. Vous n'avez rien à configurer : Thunders garde des appareils préchauffés pour vous, et le sélecteur d'appareil vous indique quand l'un d'eux est prêt.

Cela compte surtout là où les tests font le plus mal. Démarrer un vrai téléphone est la partie la plus lente du test mobile, et écrire un test veut dire le relancer après chaque petite modification. Un appareil préchauffé supprime cette attente à chaque itération.

Les appareils préchauffés sont une fonctionnalité Enterprise. Si votre offre ne les inclut pas, parlez-en à votre Customer Success Manager ou contactez notre équipe commerciale : ils vous expliqueront ce que leur activation implique.

Ouvrez le sélecteur Appareil dans un cas de test mobile. Un pool ou un appareil prêt affiche un badge Préchauffé, et l'infobulle l'explique :

« Un appareil tourne déjà pour cette application et cet environnement, un test démarre sans attendre son démarrage. »

Le badge apparaît sur les pools d'appareils comme sur les appareils individuels, vous pouvez donc choisir délibérément un appareil préchauffé quand la vitesse compte.

Pendant la préparation d'un appareil, l'interface affiche Préparation de l'appareil..., ce qui vous permet toujours de distinguer un appareil en cours de préparation d'une exécution bloquée.

Un appareil préchauffé correspond exactement à ce que vous vous apprêtez à exécuter. Il doit concorder sur tous ces points :

L'orientation ne fait pas partie de la correspondance : faire pivoter l'aperçu ne vous coûte donc jamais un appareil préchauffé.

En pratique, le préchauffage suit le travail que vous répétez. Lancez un cas de test, modifiez une étape, relancez : la seconde exécution réutilise l'appareil de la première.

Les appareils sont réclamés par les exécutions que vous lancez vous-même depuis l'éditeur, la boucle modifier-exécuter où l'attente pèse le plus.

Ils arrivent de partout ailleurs. Une exécution dans un groupe de test, une exécution planifiée et une exécution lancée par votre pipeline laissent chacune leur appareil préchauffé pour votre organisation à la fin. La capacité que votre suite nocturne a déjà payée attend la personne qui ouvre un cas de test le matin.

Un appareil n'est réutilisé qu'au sein de l'organisation qu'il a déjà servie. Un appareil qui a exécuté votre application mobile n'est jamais confié à un autre client.

Sur Android, un appareil peut être réutilisé après une exécution. Sur iOS, une exécution ne réclame qu'un appareil qui n'a pas encore servi, car iOS n'offre aucun moyen d'effacer sur place les données d'une application. Les exécutions iOS profitent toujours d'appareils déjà démarrés, elles n'héritent simplement pas d'un appareil ayant déjà exécuté un test.

Environ deux secondes entre le lancement et la première étape. L'appareil est déjà alloué, votre application mobile est déjà installée et l'application est déjà ouverte : les trois parties lentes du démarrage d'un test mobile ont toutes eu lieu avant que vous ne lanciez. Démarrer un appareil depuis zéro est un ordre de grandeur plus lent, et c'est cette attente qu'un appareil préchauffé supprime.

Sur de vrais téléphones, et c'est précisément là que cela compte. Le matériel physique est ce qu'il y a de plus long à obtenir et à démarrer en test mobile, donc garder de vrais appareils préchauffés est là où le temps se gagne. Les émulateurs en profitent de la même façon.

Lancez le cas de test une fois. L'appareil utilisé reste préchauffé pour votre organisation sur la même application mobile, le même Environnement, le même appareil et la même langue : votre exécution suivante le réclamera. Garder votre travail sur un appareil et un Environnement constants est le meilleur moyen de rester préchauffé.

Votre travail d'écriture. Les exécutions d'un groupe de test contribuent leurs appareils plutôt que de les réclamer : le groupe laisse donc des appareils préchauffés derrière lui, et c'est l'exécution suivante que vous lancez depuis l'éditeur qui démarre instantanément.

Chaque exécution contribue. Les exécutions planifiées, celles du pipeline et celles en arrière-plan laissent toutes leur appareil préchauffé pour votre organisation. La première personne à ouvrir un cas de test le matin hérite d'une capacité que sa suite a déjà payée.

L'exécution démarre un appareil de la façon habituelle : un échec de correspondance n'est jamais plus lent qu'avant. Le sélecteur d'appareil vous montre à l'avance quel choix est préchauffé.

Appuyez-vous sur la correspondance, qui est stricte : un appareil portant votre build de staging n'est jamais utilisé pour une exécution de production, et un appareil n'est réutilisé qu'au sein de l'organisation qu'il a déjà servie.

Réglez Réinitialisation de l'app sur Réinitialisation complète ou Installation propre. L'un comme l'autre exclut l'exécution des appareils préchauffés, qui obtient donc son propre appareil, et empêche aussi cette exécution de laisser son appareil préchauffé pour d'autres. Utilisez-le quand un parcours ne doit rien hériter, par exemple quand votre application mobile se connecte via un compte au niveau de l'appareil.

Ils sont inclus dans une offre Enterprise. Parlez-en à votre Customer Success Manager si vous en avez un, ou contactez notre équipe commerciale. Si vous ne voyez le badge Préchauffé nulle part dans le sélecteur d'appareil, c'est la première chose à vérifier.