“Dans le cadre du test d’applications mobiles, qu’est-ce qu’un parc de test pertinent ? J’aimerais construire un parc de test de zéro, par où commencer ? Mon parc d’appareils n’a pas été mis à jour depuis longtemps, sur quels aspects dois-je porter mon attention pour l’actualiser intelligemment ?”

Dans cet article, nous tenterons de répondre simplement à ces questions essentielles pour les développeurs. Plus particulièrement, nous nous pencherons sur le cas de la création et de la mise à jour d’un parc de test de smartphones et de tablettes Android.

En effet, il est bien plus simple de constituer un parc de test d’appareils Apple, et ce pour plusieurs raisons.
D’une part, le taux d’adoption des nouvelles versions d’iOS est impressionnant : en France par exemple, plus de 50% des utilisateurs d’iPhone installèrent iOS7 dans la semaine qui suivit sa sortie (source). Aujourd’hui, 90% des appareils mobiles Apple dans le monde fonctionnent sous iOS7 (source).
D’autre part, les nouvelles versions d’iOS tendent de plus en plus à être compatibles avec la plupart des appareils en circulation : par exemple, iOS8 sortira sur tous les smartphones et tablettes Apple à l’exception de l’iPhone 4/3GS/3G et l’iPad 1 (source).
D’une manière générale, la stratégie d’intégration verticale d’Apple contribue à rendre la vie facile aux développeurs. Apple conçoit ses produits du processeur au système d’exploitation, ce qui permet aux développeurs de créer des applications mobiles dans un environnement monolithique, constitué d’un nombre d’appareils restreint fonctionnant tous avec une architecture matérielle semblable et un système d’exploitation identique. Par conséquent, lorsque vous développez des applications sur iOS, il n’est pas forcément nécessaire de faire des tests sur tous les appareils Apple en circulation. Tester vos applications sur chacune des quatre tailles d’écran existantes (iPhone 3x/4x, 5x, iPads et iPads Mini) est suffisant. Simplement, n’oubliez pas de les tester aussi sur iOS6, pour être sûr de satisfaire les derniers 10% d’utilisateurs sur cette version.

Contrairement à Apple, Google a opté pour une stratégie plus horizontale, en se cantonnant principalement au développement de son système d’exploitation Android et de ses applications et services. Google laisse donc une grande liberté aux constructeurs dans la conception des appareils sur lesquels sera installé Android, ce qui mène à une fragmentation importante de la plateforme. Ainsi, il n’est pas étonnant d’avoir sur le marché un nombre important d’appareils complètement différents (11868 appareils Android différents ont été recensés l’année dernière - source) fonctionnant sous une multitude de versions et de sous-versions d’Android. Cependant, Android a conçu sa plateforme pour offrir un bon niveau d’abstraction aux développeurs, leur évitant souvent une gestion au cas par cas. Reste que théoriquement, pour avoir la certitude qu’une application fonctionnera absolument tout le temps, il faudrait la tester sur chaque appareil existant avec toutes les versions d’Android. Évidemment, cela est impossible, mais soyez rassurés : cet article vous aidera à construire votre parc de test de manière à pouvoir garantir au plus grand nombre d’utilisateurs que votre application est bel et bien fonctionnelle.

Quelles tailles d’écran et densités doivent avoir les appareils de mon parc de test ?

Le premier choix que vous aurez à faire lorsque vous commencerez à vous procurer de nouveaux appareils concerne les caractéristiques d’affichage.
Si vous partez de zéro dans la construction de votre parc de test, il pourrait s’avérer intéressant de se pencher sur les chiffres donnés par Google sur la répartition mondiale des tailles d’écran et des densités de pixels des appareils Android en circulation (Google source). Avec ces données en tête, vous pourrez vous constituer un parc de test représentatif de la répartition réelle des différentes catégories d’appareils Android dans la population. Puis, en testant vos applications sur les catégories d’écran les plus répandues, vous serez certains de pouvoir satisfaire la plupart des utilisateurs. Sur le schéma suivant, vous pouvez observer comment sont faites ces différentes catégories d’affichage.

Si votre objectif est simplement de mettre à jour votre parc de test déjà existant, essayez de garder en tête l’idée générale suivante : une grande partie des utilisateurs d’appareils Android n’a pas d’appareils haut de gamme. Il n’est donc pas utile de moderniser à tout prix votre parc d’appareils. Faites simplement en sorte que vos applications marchent également sur des appareils munis de petits écrans à faible densité de pixels. Idéalement, votre parc de test doit comporter un appareil de chaque type de taille : small, normal, large and xlarge. Concernant les densités de pixels, les catégories les plus fréquemment rencontrées aujourd’hui sont les suivantes : mdpi, hdpi, xhdpi et xxhdpi. Encore une fois, il convient d’avoir un appareil mobile de chacune de ces catégories et si possible, d’avoir des appareils combinant différentes tailles et densités de pixels.

Quelle puissance doivent avoir les appareils de mon parc de test ?

Pour continuer sur la lancée des spécifications techniques du hardware, parlons maintenant de la puissance que les appareils de votre parc de test devraient idéalement avoir, c’est-à-dire de la vitesse et de l’efficacité des SoC (System on a Chip, puce comportant le CPU et le GPU d’un appareil) de vos appareils. Là encore, la diversification est essentielle.

N’avoir que des smartphones équipés des derniers SoC à la pointe de la technologie actuelle pourrait s’avérer être une grave erreur. En réalité, il est préférable de tester vos applications sur des appareils Android dotés d’une puissance de calcul moyenne, voire basse. De cette manière, si vos applications marchent correctement sur ces appareils, vous serez certain d’une part de satisfaire l’utilisateur lambda, et d’autre part que vos applications marcheront indubitablement mieux sur des appareils plus puissants.
Peu importe si votre intention est de construire un nouveau parc de test ou simplement de le mettre à jour, l’idée principale est toujours la même : s’assurer d’avoir des appareils de toutes les gammes de caractéristiques techniques.

Dois-je prendre en compte les surcouches ajoutées par les constructeurs de smartphones et tablettes ?

Oui, il est même essentiel de le faire. Les surcouches (incluant des changements dans l’interface utilisateur ou parfois des changements plus profonds dans l’OS) préinstallées par les constructeurs par-dessus Android peuvent parfois beaucoup changer la façon dont vos applications fonctionnent. Selon le constructeur et sa surcouche installée sur le téléphone, des problèmes d’affichage peuvent survenir ou non.
Par exemple, certains constructeurs installent dans leurs surcouches des navigateurs fonctionnant avec des moteurs de rendus divers. Les conséquences pour les développeurs sont problématiques : une simple page web s’affichera différemment sur chaque surcouche, sur chaque appareil, sur chaque version de l’OS.
Néanmoins, Google fait des efforts pour lutter contre la fragmentation dans ce domaine (source). Depuis peu, les constructeurs d’appareils mobiles se voient imposer des contraintes vis-à-vis de leurs surcouches, qui doivent être respectées sous peine de perdre la possibilité d’utiliser les services de Google, comme Google Maps. Par exemple, Google impose d’être le moteur de recherche par défaut sur le navigateur, ou de préinstaller sur les appareils une dizaine d’applications développées par Google. De cette manière, Google réussit à éviter une dispersion trop importante au niveau des surcouches.
Dans tous les cas, pour éviter les mauvaises surprises, renseignez vous sur les surcouches installées sur les appareils que vous acquérez.

Une mauvaise solution serait de ne se procurer que des appareils fonctionnant avec Android pur, c’est-à-dire avec l’interface utilisateur d’Android sans surcouche, afin d’éviter tout problème lié à ce sujet. En effet, une application fonctionnant parfaitement avec Android pur ne fonctionnera évidemment pas de manière systématique après l’ajout d’une surcouche. Bien sûr, la meilleure façon de faire lorsque vous en venez à tester vos applications est de les tester sur les surcouches les plus répandues : Touchwiz de Samsung, HTC Sense, Sony Xperia UI ou LG Optimus UI. Une fois de plus, vous ne serez pas en mesure de tester vos applications sur toutes les surcouches des constructeurs. En effectuant des tests sur les quatre surcouches précédemment citées en plus de Android pur, vous serez certain de couvrir presque tous les utilisateurs Android.

Et qu’en est-il des versions d’Android installées sur mes appareils ?

Maintenant que nous avons parlé des surcouches, jetons un oeil plus en profondeur, en direction des particularités des versions du système d’exploitation Android.
Google nous fournit des chiffres intéressants à propos de la répartition des versions de son OS à travers le monde (Google - source). Si vous êtes sur le point de commencer un nouveau parc de test, il pourrait s’avérer judicieux de créer un parc suivant la répartition des versions d’OS. Comme vous pouvez le constater, la version d’Android la plus commune est Jelly Bean (4.1-4.3). Il convient donc d’être certain qu’au minimum vos applications fonctionnent bien sur ces versions. Puis, vous pourrez diversifier votre parc de test en y ajoutant d’autres appareils dotés de Ice Cream Sandwich (4.0) ou Kitkat(4.4) et enfin des appareils fonctionnant sous des versions plus anciennes comme Gingerbread (2.3.x) qui représentent seulement 14% de la répartition globale en juillet 2014 (Google source). L’expérience montre que les problèmes surviennent plus généralement à cause des surcouches qu’à cause des différences de versions d’OS.
Finalement, l’idée générale à propos des surcouches et des versions d’OS est qu’il est préférable de diversifier les surcouches des constructeurs avant de diversifier les versions d’OS.

Y’a-t-il d’autres informations qu’il me faudrait connaître avant de commencer à construire/mettre à jour mon parc de test ?

Avant même de commencer à réfléchir à votre parc de test en lui-même, posez vous des questions sur la manière dont vous allez utiliser votre parc de test : quel type d’application allez-vous développer ? Quels utilisateurs visez-vous ? Des utilisateurs “geek” équipés des derniers modèles haut de gamme de smartphones Android ? Ou bien des utilisateurs plus standard qui pourraient potentiellement avoir des appareils plus bas de gamme voire même désuets ? En outre, faites attention aux caractéristiques techniques requises par vos applications : parfois, certains appareils, même haut de gamme, ne possèdent pas certains éléments de hardware dont vous pourriez avoir besoin. Regardez par exemple quel problème Game Oven, une société d’édition de jeux vidéo sur mobile, a rencontré lors du développement de son jeu Bounden. Pour marcher correctement, ce jeu nécessitait absolument le gyroscope de l’appareil, qui est un élément de hardware plutôt répandu dans les smartphones actuels. Cependant, ils découvrirent que leur jeu ne fonctionnait pas sur beaucoup d’appareils Android car certains de ces appareils n’avaient même pas de gyroscope ou en avaient un très mauvais…
Les caractéristiques du marché auquel vous vous attaquez ont aussi leur importance : le marché des appareils mobiles se régionalise de plus en plus et selon les pays, les constructeurs les plus répandus ne seront pas toujours les mêmes. Ainsi, il faudra vous assurer que vos tests sont bien effectués sur des appareils répandus non pas dans le monde mais plus localement, dans le pays dont vous ciblez les utilisateurs.

En résumé, gardez toujours en tête les points suivants :

• Certes, presque 80% des utilisateurs de smartphones ont des appareils Android, mais seulement une minorité possède les modèles récents et haut de gamme : une modernisation obstinée du parc de test ne sera pas efficace.

• Android est une plateforme très fragmentée, mais vous pouvez augmenter vos chances de satisfaire le maximum d’utilisateurs en diversifiant votre parc de test autant que possible en terme de hardware, surcouches et versions d’OS.

• Adaptez toujours tous ces conseils en fonction de la spécificité des applications mobiles que vous développez.