Mais où allez-vous effectuer tous ces tests ?

Il se passe actuellement quelque chose d'intéressant au sein des équipes d'assurance qualité. Les agents d'IA et les outils basés sur MCP permettent aux testeurs de créer des automatisations plus rapidement que jamais. Ce qui nécessitait auparavant une semaine de développement peut désormais être esquissé en un après-midi. Une couverture de test qui paraissait autrefois inaccessible est soudainement à portée de main. C'est vraiment enthousiasmant. Et cela crée discrètement un problème dont personne ne parle.

Lorsque la création de tests devient plus rapide, la conversation se concentre presque toujours sur la création : quel outil utiliser, comment structurer les invites, comment obtenir des localisateurs fiables. Ce que personne ne se demande, c’est la question qui détermine réellement si ces tests seront déployés.

Où exactement allez-vous effectuer tous ces tests ?

L'IA peut générer des centaines de nouveaux tests là où il en fallait dix auparavant. C'est un véritable atout. Mais cet atout amplifie tout ce qui le sous-tend, y compris une infrastructure non conçue pour supporter une telle charge. Les équipes qui découvrent cela actuellement ne sont pas en échec d'automatisation ; elles y réussissent plus vite que leur couche d'exécution ne peut suivre.

L'automatisation des bâtiments est une étape importante. La mettre en œuvre de manière fiable et à grande échelle est un tout autre problème.

Le schéma que suivent presque toutes les équipes

Tout commence généralement de façon assez simple. Quelques appareils Android sur un bureau. Un iPhone partagé entre deux ingénieurs. Des scripts Appium exécutés sur un ordinateur portable avant une mise en production. Ça fonctionne. Et pendant un certain temps, c'est suffisant.

Puis, le périmètre s'élargit. Davantage de modèles d'appareils, de versions de systèmes d'exploitation, la prise en charge de plusieurs navigateurs, et plusieurs équipes devant exécuter des tests en parallèle. Du jour au lendemain, la contrainte change. La question n'est plus « Peut-on automatiser cela ? » mais « Avons-nous la capacité d'exécution nécessaire pour le faire ? » La plupart des équipes ne sont pas préparées à ce moment, non pas parce qu'elles n'ont pas vu venir l'automatisation, mais parce que le problème d'exécution surgit sournoisement.

À quoi ressemble réellement « l’échelle » ?

À un certain stade, le volume des tests n'est plus le principal obstacle. C'est tout ce qui l'entoure qui pose problème : la fragmentation des appareils, les combinaisons de systèmes d'exploitation, les différences de versions de navigateurs, les équipes réparties sur plusieurs fuseaux horaires qui tentent d'accéder simultanément au même parc d'appareils. Le nombre de tests ne cesse d'augmenter. L'infrastructure n'a pas été conçue pour cela.

Et ce, avant même d'aborder les cas plus complexes : les flux d'accessibilité qui se comportent différemment sur du matériel physique, les fonctionnalités dépendantes de l'opérateur qui ne s'affichent pas sur un émulateur Wi-Fi uniquement, et les intégrations de véhicules connectés pour Android Auto ou CarPlay qui sont impossibles à reproduire sur un ordinateur. Il ne s'agit pas de cas particuliers. Ce sont des aspects essentiels d'applications réelles, pour lesquels la plupart des environnements d'exécution échouent discrètement.

Voici à quoi ressemble concrètement la dette technique : l’équipe d’assurance qualité cesse de rédiger des tests et se consacre à la gestion des mises à jour du système d’exploitation, au débogage des conflits de capacité et au traitement des plaintes concernant des résultats instables qui s’avèrent être dus à des problèmes de configuration. L’automatisation, censée accélérer les mises en production, finit par générer ses propres coûts supplémentaires.

Le vrai problème n'est pas de posséder des appareils, mais de construire la couche supplémentaire par-dessus.

De nombreuses équipes possèdent déjà leurs propres appareils, et c'est très bien ainsi. Le problème ne réside pas dans les appareils eux-mêmes. Le problème, c'est tout ce qu'il faut construire autour : l'orchestration, les intégrations, les contrôles d'accès, et la garantie d'un fonctionnement fiable malgré les changements de versions de systèmes d'exploitation et le vieillissement du matériel. Il ne s'agit pas d'une configuration ponctuelle, mais d'un travail continu dont quelqu'un doit prendre la responsabilité.

Lorsque les équipes tentent de créer elles-mêmes cette couche de gestion, celle-ci se transforme insidieusement en un second produit d'ingénierie, sans feuille de route, sans responsable dédié et avec une fâcheuse tendance à tomber en panne au pire moment. C'est le prix à payer que personne n'a jamais souhaité payer.

Posséder des appareils, c'est bien. C'est la création d'une plateforme de gestion des appareils entièrement personnalisée qui engendre de véritables coûts.

Ce que la bonne plateforme résout réellement

Lorsque les responsables QA évaluent les plateformes d'exécution, la discussion se limite généralement à la disponibilité des appareils et à l'intégration CI. Ces aspects sont importants, certes, mais ils constituent la base. La question essentielle est de savoir si la plateforme a été conçue pour répondre à l'ensemble des besoins réels de votre application en matière de tests.

Commencez par le déploiement. Certaines équipes souhaitent disposer d'appareils à la demande, sans frais d'acquisition ; une solution cloud répond à ce besoin. D'autres possèdent déjà un laboratoire d'appareils et ont besoin d'une couche logicielle adaptée pour un déploiement à grande échelle ; une solution sur site est alors plus appropriée. Le choix ne doit pas impliquer de compromis entre simplicité d'utilisation et contrôle. Une plateforme digne d'être évaluée doit prendre en charge les deux options, avec des fonctionnalités identiques dans les deux cas.

BPCELe deuxième groupe bancaire français a opté pour cette solution. Auparavant, ses tests manuels étaient incohérents et répartis sur plusieurs sites, sans traçabilité, et son équipe avait besoin d'une exécution centralisée sans pour autant renoncer à ses propres appareils. Grâce à un déploiement sur site, le groupe gère désormais 700 utilisateurs répartis sur 102 appareils et 32 ​​versions de navigateurs, avec des tests exécutés toutes les 5 à 15 minutes, 24 h/24 et 7 j/7. Lisez l'étude de cas complète.

Mais la flexibilité de déploiement n'est que le point de départ. Ce qui est plus difficile à évaluer — et que la plupart des équipes ne demandent que trop tard — c'est la profondeur de la couverture.

Repensez aux scénarios évoqués précédemment. Les flux d'accessibilité qui dépendent de TalkBack ou VoiceOver doivent s'exécuter sur des appareils physiques, car c'est le seul environnement où le comportement du lecteur d'écran est précis. Les performances en conditions réelles, telles que la charge du processeur, la consommation de mémoire et l'autonomie de la batterie, ne se manifestent qu'au niveau du matériel. Les fonctionnalités audio, les flux d'opérateur qui supposent la présence d'une carte SIM, les intégrations automobiles pour Android Auto ou CarPlay : ce sont des éléments essentiels d'applications réelles, et la plupart des plateformes ne les prennent pas en charge ou les considèrent comme des options marginales.

Lors de l'évaluation d'une plateforme, ne vous contentez pas de vérifier si elle peut exécuter vos tests Appium ; demandez-vous plutôt si elle est capable de gérer les scénarios que votre équipe a discrètement reportés. Peut-elle exécuter ces tests dans différentes régions géographiques sans que vous ayez à mettre en place des environnements de test régionaux ? S'intègre-t-elle à votre pipeline d'intégration continue afin qu'une pull request fusionnée puisse être compilée, téléchargée, exécutée et générer un rapport automatiquement ?

Les équipes qui réussissent dans ce domaine ne se contentent pas de réduire les coûts opérationnels. Elles atteignent un niveau de couverture qu'elles ne pouvaient justifier auparavant, non pas parce que les tests étaient trop difficiles à écrire, mais parce qu'il n'existait aucun environnement fiable pour les exécuter.

La question qu'il convient de se poser maintenant

Avant votre prochaine séance de planification de l'automatisation, avant la prochaine revue de sprint où quelqu'un célébrera l'atteinte d'une couverture de 80 %, posez-vous la question plus difficile.

« Où allons-nous réaliser tous ces tests dans six mois ? »

Parce que les mathématiques sont impitoyables :

Cent tests peuvent être exécutés presque partout. Cinq mille tests nécessitent une orchestration. Cinquante mille tests — couvrant les scénarios fonctionnels, d'accessibilité, de performance, audio, d'opérateur et de véhicule connecté — nécessitent une architecture.

Le choix du format (cloud, sur site ou hybride) vous appartient. Mais les équipes qui déploient avec succès à grande échelle ont toutes un point commun : elles ont abordé la question de l’exécution suffisamment tôt pour y répondre efficacement.