Published by

Il y a 10 ans -

Temps de lecture 19 minutes

Qualité et industrialisation des développements mobiles sur iOS & Android (IT-expert)

Rachat de la division mobile de Nokia par Microsoft, avenir incertain pour BlackBerry… Décidément, le marché de la mobilité est hyperactif et en train de revivre une petite révolution. Il faut y voir le signe de son arrivée à maturité : réduction du nombre d’acteurs, rationalisation des plateformes, concurrence accrue. Le canal mobile a fait ses preuves et représente déjà pour certains un relais de croissance incontournable. Après l’euphorie des débuts, place aux services et produits mobiles durables.

Dans le même temps, le nombre et la qualité des outils mis à disposition des développeurs mobiles ou produits par la communauté progressent significativement. Ils permettent de mettre en place une réelle politique de qualité dans les développements mobiles (tests unitaires et fonctionnels par exemple) et aident à l’industrialisation de ces derniers (intégration continue, voire déploiement continu).

Cet article s’adresse aux lecteurs désireux d’industrialiser, d’améliorer la qualité et de rendre plus "agiles" leurs développements mobiles. Au programme : 

Évolution de la boîte à outils du développeur mobile

La boîte à outils du développeur mobile a quelque peu évolué récemment. Certains IDE se perfectionnent toujours comme Xcode pour iOS, tandis que d’autres font une apparition remarquée dans la communauté comme Android Studio ou AppCode pour iOS. Choisir son IDE relève peut-être des goûts personnels, il faut néanmoins considérer leurs qualités et leurs défauts.

Android Studio

Android Studio a été annoncé par Google durant la Google I/O cette année. Il s’agit d’une alternative à l’utilisation d’Eclipse dans le développement d’applications Android et il a rapidement trouvé ses fans dans la communauté. Son atout : Android Studio est basé sur IntelliJ IDEA et apporte un certain nombre de fonctionnalités très pratiques. Par exemple, il est possible de voir le rendu des écrans développés directement en plusieurs langues, selon différentes tailles d’écran ou encore d’utiliser Gradle (une solution de gestion de build reposant sur Groovy, le nouveau standard de facto supporté par Google). Précaution tout de même, Android Studio est toujours en bêta et évolue beaucoup.

AppCode

Pour les plus familiers d’IntelliJ IDEA, JetBrains signe un nouvel opus : AppCode, sorti en avril 2011 et qui bénéficie ces derniers temps d’une bonne notoriété auprès de la communauté des développeurs iOS. AppCode tire notamment sa réputation des outils performants qu’il propose dans l’assistance au codage (auto-complétion, refactoring, intégration native avec plusieurs frameworks open-source, etc.). Il est en revanche impossible de s’affranchir réellement d’Xcode, qui reste un incontournable pour la réalisation des écrans de l’application via l’IHM. En pratique, AppCode doit être vu comme une solution complémentaire à Xcode.

Extras

La boîte à outils du développeur mobile est également remplie de petits outils très pratiques permettant de simuler tel ou tel terminal, ou encore brider le débit des connexions réseaux :

  • C’est par exemple le cas de Network Link Conditionner, un outil ayant fait son apparition dans Mac OS X Lion et qui permet de simuler une mauvaise connexion réseau ou les caractéristiques de celle-ci (débit, latence, pertes..).
  • Différents plugins permettent de modifier le user-agent envoyé par les requêtes afin de tester le comportement d’un site Web mobile en développement dans son navigateur de bureau. (c’est par exemple le cas de User-Agent Switcher – un plugin pour Chrome).
  • Certains outils permettent également de formuler des requêtes simplement (Web Services) et d’interpréter les réponses renvoyeés (c’est le cas d’Advanced REST Client – une extension pour Chrome).
  • Enfin, il existe des outils qui permettent de voir et d’analyser toutes les connexions HTTP et SSL/HTTPS entre un téléphone et internet : c’est le cas de Charles qui peut être qualifié de proxy HTTP.

Qualité sans compromis

Nous en avons parlé, les outils mis à disposition de la communauté des développeurs mobiles iOS & Android se sont grandement améliorés ces dernières années. Dans les équipes suffisamment matures, ils accompagnement désormais la mise en place de pratiques comme le TDD ("Test Driven Development") ou encore le BDD ("Behaviour Driven Development"). Ces outils sont issus ou très ressemblant à ceux déjà utilisés dans les technologies plus classiques (Java par exemple).

1ère étape : Mise en place des tests unitaires

La mise en place de tests unitaires dans votre projet vous permet notamment de vous assurer du bon fonctionnement et de la non régression d’une partie de vos développements au gré de l’évolution de votre produit. En mobilité, les tests unitaires se concentrent généralement sur la vérification du "code métier" (règles internes régissant le comportement de votre application), les comportements d’IHM étant souvent difficilement testables par ce biais.

Pour iOS, il existe désormais plusieurs frameworks vous permettant de remplir cette fonction :

  • OCUnit (SenTesting) : Intégré par défaut dans Xcode, il est assez simple à mettre en place et à conseiller aux personnes débutant sur le sujet
  • GHUnit : Une fois l’installation effectuée, GHUnit permet l’exécution des tests et la visualisation des résultats dans le simulateur iOS

  • Kiwi : En utilisant cette bibliothèque, vos tests deviendront plus lisibles et simples à écrire. Kiwi propose en effet un formalisme de type BDD. De plus, ce framework permet d’écrire des tests asynchrones (notamment via son propre système de "mock"), sans se baser sur des bibliothèques tierces. Le projet a été récemment intégré dans AppCode, il est activement maintenu et à conseiller lorsque l’on envisage de mettre en place du TDD.

Concernant Android :

  • JUnit : "On ne change pas une équipe qui gagne". La déclinaison pour Android du célèbre framework de tests Java est directement intégré à l’environnement de développement Android et est un incontournable. À conseiller pour les débutants.
  • Robolectric : L’utilisation de Robolectric ne pose pas de difficultés particulières mais se destinera davantage aux développeurs disposant d’un grand nombre de tests et recherchant la rapidité d’exécution de ces derniers. Robolectric permet en effet une exécution déportée de ces tests directement dans la JVM du poste de développement. Indispensable lorsque l’on envisage de mettre en place du TDD.

Plus d’informations sur les tests unitaires sous iOS sur le blog de Paul SOLT "iPhone Unit Testing Explained". Concernant la plateforme Android, les ressources Google sont toutes indiquées ici : "Testing Fundamentals".

2ème étape : Mise en place des tests fonctionnels

Les tests fonctionnels vous permettent de vous assurer du bon fonctionnement et de la non régression des fonctionnalités de votre produit mobile avec l’avancement du projet. D’une abstraction généralement supérieure aux tests unitaires, les tests fonctionnels permettent de décrire l’ensemble des comportements attendus pour votre application mobile.  Ci-dessous nous allons vous décrire quelques outils utiles pour les mettre en place. Il est important de noter que leur temps d’exécution peut devenir assez long au cours du temps, il est donc conseillé de choisir des scénarios pertinents, couvrant un maximum de fonctionnalités, sans les multiplier.

Pour ce faire, plusieurs outils sont à votre disposition comme Frankou le plus abouti Calabash pour iOS :

  • Calabash-iOS : Il s’agit d’un outil d’automatisation de tests pour iOS basé sur Cucumber. Après avoir décrit les comportements de votre application dans le langage Gherkin, Calabash-iOS permet d’exécuter les différents scénarii dans le simulateur ou un terminal iOS. Les atouts de Calabash sont nombreux : lancement des tests par script, possibilité d’exécuter ses tests sur plusieurs versions d’OS, possibilité de personnaliser ou créer ses propres "commandes fonctionnelles", mise à disposition du résultat de l’exécution des tests sous plusieurs formats (comme par exemple HTML, JSON ou encore JUnit XML pour une intégration facilitée dans Jenkins)
Scenario: Log a user
GIVEN I am on the home screen
AND I enter "1337" into the "clientNumberTextField" field
WHEN I touch the button "Connect"
THEN I should read "user connected" in less than 5 sec
  • Concernant Android, la plateforme intègre nativement un framework d’instrumentation permettant d’interagir avec les composants d’une application. Les fonctionnalités offertes restent néanmoins bas niveau, ce qui rend l’écriture de tests fonctionnels plus que laborieuse.C’est pour remédier à ce problème que Robotium a vu le jour. Il s’agit d’un outil d’automatisation de tests pour des applications natives ou hybrides. Il offre un niveau d’abstraction du framework d’instrumentation qui facilite l’écriture de tests robustes en mode “boite noire”. Ces tests peuvent s’exécuter sur des émulateurs mais aussi directement sur des appareils physiques. Grâce à cette librairie, il est possible de mettre en place des campagnes de tests d’acceptance permettant de détecter au plus tôt les régressions.
  • Le principal défaut de Robotium est qu’il ne permet pas de récupérer le résultat de l’exécution d’une campagne de tests sous un format facilement exploitable. C’est à ce moment que Spoon entre en action. Il s’agit d’une librairie open-source développée par Square qui permet l’exécution distribuée des tests Robotium sur un ensemble d’appareils et/ou émulateurs. Une fois les tests achevés sur tous les terminaux, elle se charge de regrouper les résultats des exécutions et de les exposer au format HTML. Le site généré permet de voir en un clin d’oeil si des tests ont échoué et quels sont les terminaux concernés. Il met à disposition plusieurs écrans avec différents niveaux de détail afin de comprendre au mieux l’origine de l’échec d’un test.

spoon

Spoon permet notamment l’exécution de vos tests fonctionnels en parallèle sur un pool de terminaux physiques

(Source : http://square.github.io/spoon/)

3ème étape : Les tests manuels

Nous venons de voir quelques outils assurant les tests unitaires et fonctionnels au sein de vos applications mobiles. Leur mise en place permettra déjà une sérieuse avancée dans la qualité de vos applications mobiles. Ceux-ci seront généralement complétés par un ensemble de tests manuels. Il cependant important d’établir une stratégie de tests adaptée devant la multitude de terminaux iOS et Android. En effet, si le nombre de terminaux iOS potentiellement adressés reste assez maîtrisé, la fragmentation propre à l’écosystème Android (nombreux constructeurs, différentes tailles d’écran, multiplicité des version d’OS, etc.) demeure un enjeu de taille. Également, il est très souvent impossible de s’équiper de l’ensemble des terminaux cibles, le nombre de plateformes couvertes souhaitées étant trop large.

Une stratégie plutôt efficace est celle du "plus petit dénominateur commun". Il s’agit de cibler par catégorie de terminaux le plus représentatif de cette famille au regard de sa taille d’écran ou résolution, de son OS, de sa performance, de la sur-couche constructeur installée, de sa part de marché, son prix, etc. Ci-dessous, une proposition adaptée de représentants pour iOS & Android que devrait posséder toute équipe mobile développant des applications grand-public :

Plateforme

Terminal mobile 

Pourquoi ce terminal ? 

 

 

 

Android 

 
 
 
 
 
 

LG Nexus 4

  • Version d’Android sans sur-couche constructeur et récente (Jelly Bean 4.3)
  • Grand écran 4,7" xhdpi

Samsung Galaxy S3

  • Version d’Android avec sur-couche samsung, constructeur très présent sur Android
  • Grand écran 4,8" xhdpi
  • Fort volume de vente

Samsung Galaxy S2

  • Version d’Android avec sur-couche samsung différente du Samsung Galaxy S3
  • Grand écran 4,3" hdpi
  • Fort volume de vente

Sony Xperia U

  • Ecran " 16/9 ème " hdpi
  • Version ancienne d’Android avec sur-couche Sony (Gingerbread 2.3)

HTC Wildfire

  • Ecran " 4/3 " mdpi
  • Version d’Android avec sur-couche HTC
  • Version ancienne d’Android (Gingerbread 2.3)

Samsung Galaxy Tab 2

  • Très grand écran 10,1"
  • Peu puissante

 
 

iOS

 
 
 

iPhone 4

  • Retina
  • Equivalent à l’iPhone 4S mais moins performant et moins cher (i.e : Si l’application tourne sur iPhone 4, elle tournera encore mieux sur iPhone 4S)

iPhone 5S

  • Grand écran 4"
  • Nouvelle architecture 64 bits

iPad Mini

  • Non Rétina
  • Equivalent à l’iPad 2 (même résolution, même performance) mais moins cher

iPad 3 (Occasion)

ou iPad 4

  • Rétina
  • iPad 3 équivalent à l’iPad 4 mais moins performant et moins cher (i.e : Si l’application tourne sur iPad 3, elle tournera encore mieux sur iPad 4)

Bien sûr, le choix de ces représentants peut être longuement discuté. Pourquoi ne pas avoir mis l’iPhone 3GS ? Le nombre d’utilisateurs sur cette plateforme est-il si faible ? Ou encore pourquoi ne pas avoir choisit un terminal avec une sur-couche LG ? Pourquoi ne pas avoir sélectionné des modèles ultra-récents comme le Samsung Galaxy Note III ? Il est avant-tout issu de notre expérience et du meilleur compromis entre représentativité et coût d’équipement. Chaque équipe devra adapter cette liste, en privilégiant le panel de terminaux couvrant au mieux parfois une segmentation bien choisie de ses utilisateurs cibles.

4ème étape : Aller plus loin dans les tests…

À ce stade, et en ayant pris les bonnes décisions, un projet iOS & Android devrait servir efficacement la plus grande majorité de ses utilisateurs mobiles. On peut néanmoins vouloir aller plus loin :

  • Étendre davantage sa couverture de terminaux : des sociétés se sont spécialisées dans le test d’applications mobiles à grande échelle. C’est par exemple le cas de la société Stardust qui permettra de déléguer l’exécution de ses campagnes de test sur une portion plus importante de terminaux mobiles.
  • Gérer au cas par cas certains terminaux (comme par exemple, vérifier le bon fonctionnement de son application sur de nouveaux terminaux ou sur des terminaux spécifiques posant problème) : des services en ligne permettent de le faire à distance. C’est notamment le cas du service perfecto mobile. Ce service original met à disposition des terminaux mobiles hébergés en datacenter dans différents points du globe (pratique pour les tests opérateurs également), permettant d’exécuter à distance, manuellement ou automatiquement, ses propres tests.

Industrialisation : de l’intégration au déploiement continu

Nous avons abordé précédemment les outils permettant de mettre en place des tests unitaires et fonctionnels au sein de vos projets mobiles iOS & Android. Penchons nous désormais sur leur automatisation avec Jenkins qui aura l’avantage de centraliser tous vos projets mobiles qu’ils soient iOS ou Android. 

Mise en place d’une usine logicielle

La mise en place d’une usine logicielle est indispensable pour aller vers du déploiement continu et vous permettre d’automatiser les tâches suivantes :

Récupération du code source et compilation au sein de l’usine logicielle 

Les plugins Jenkins sont nombreux pour vous permettre de rapatrier votre code source hébergé sur un repository Git ou SVN. Le plugin Github par exemple, vous permettra de rapatrier votre code source hébergé sur Github et, bien sûr, de paramétrer les actions à effectuer ensuite. Ainsi, lors de la mise à jour de votre code sur le repository central, un job jenkins sera exécuté pour récupérer cette nouvelle version et lancer la compilation des sources : vous utiliserez alors xcodebuildmavengradle, selon votre plateforme et votre gestionnaire de build. Il est à noter que les SDK des plateformes mobiles cibles doivent être installés sur la machine hôte, et donc que vous serez contraint d’utiliser un système d’exploitation Mac OS X, si vous souhaitez gérer sur cette machine des projets avec au moins une application iOS… Cette 1ère étape peut paraître anodine, mais elle permet de valider que l’application et ses ressources sont gérées correctement et que le contenu du repository du projet est suffisant pour la compilation de l’application.

Automatisation des tests unitaires

Vous avez mis en place dans votre projet des tests unitaires et vous souhaitez automatiser leur exécution, ou encore, obtenir d’autres informations comme le taux de couverture de ces tests. Encore une fois, nous allons essayer de nous reposer sur les outils fournis autour de Jenkins:

  • Sur iOS, vous mettrez à jour le job en rajoutant l’exécution de votre projet Xcode de test après le build. Vous pourrez alors invoquer GCOV en ligne de commande pour analyser la couverture de ces tests. Le plugin Jenkins Cobertura, vous permettra alors de visualiser directement dans Jenkins le rapport issu de GCOV. 

Code Coverage

  • Sur Android, l’exécution des tests unitaires est intégrée directement dans le cycle de vie du build (Maven ou Gradle). Pour analyser la couverture des tests mais aussi la qualité générale du projet, nous pouvons utiliser le plugin Sonar. L’installation de Sonarqube est néanmoins nécessaire afin d’exploiter le résultat des analyses du plugin. Sonarqube met à votre disposition un ensemble non négligeable de métriques (duplication, couverture de code, complexité …)  qui vous permet de mesurer la qualité de votre projet mais surtout d’en suivre son évolution !
Automatisation des tests fonctionnels

Il est temps désormais de mettre en place au sein de Jenkins nos outils de tests fonctionnels :

  • Intégration de Calabash-iOS : après avoir intégré Calabash-iOS dans votre "target" XCode dédiée aux tests fonctionnels, vous pourrez utiliser Jenkins pour l’exécuter automatiquement après la compilation et l’exécution des tests unitaires. Les résultats de l’exécution peuvent être enregistrés en format JUnit XML et exposés dans un graphique sur Jenkins en mettant en évidence l’évolution du nombre de tests en succès/échec. Si nécessaire, Cucumber peut aussi enregistrer les résultats des tests sous forme de fichier JSON. Un outil d’affichage peut donc être facilement mis en oeuvre pour personnaliser la restitution de l’exécution de ces tests (à l’image de la capture d’écran ci-dessous)
  • Calabash-iOS

    Page HTML personnalisée, fournissant une représentation visuelle des résultats de l’exécution des tests fonctionnels

  • Intégration de Robotium/Spoon : comme précisé ci-dessus, Spoon prend en charge l’exécution distribuée des tests Robotium sur un ensemble de terminaux. Spoon dispose d’un plugin Maven mais aussi d’un plugin Gradle. L’intégration de la phase d’exécution des tests fonctionnels dans votre système de build se fera donc sans effort. Il ne reste plus qu’à configurer un job au sein de Jenkins qui aura à charge de packager votre application ainsi que l’application de test et de lancer Spoon via son plugin. Une fois l’exécution des tests terminée, Spoon rapatriera les screenshots pris au cours de ces derniers puis générera les rapports d’exécution dont vous avez un aperçu ci-dessous. Pour finir, le plugin jenkins HTML publisher vous permettra d’accéder aux différents rapports directement sur la page de votre job, vous permettant de voir l’exécution d’un scénario en vidéo, ou encore un même scénario exécuté sur tous vos terminaux.

Spoon2spoon3

Page agrégeant le résultat de l’exécution des tests fonctionnels sur tous les terminaux / Visualisation de l’exécution d’un scénario sur 1 ou plusieurs terminaux

(Source : http://square.github.io/spoon/)

Déploiement continu de ses applications mobiles

Après avoir automatisé l’exécution de vos différents tests (unitaires, fonctionnels), vous souhaiteriez maintenant pouvoir tester / ou faire tester en continu votre application, durant la phase de développement. Choisissez Testflight, un service en ligne de déploiement à distance, désormais devenu célèbre aussi bien pour iOS que pour Android.

TestFlight permet l’administration de vos différentes "builds" (développement, recette, pré-production…) via un portail en ligne, et vous permet de les distribuer à vos bêta-testeurs. Ces derniers peuvent être organisés en groupes et listes de diffusion pour une gestion maîtrisée durant votre phase de développement. Pour Android, la configuration est assez automatique, il suffit de téléverser ses builds sur le portail TestFlight. Sur iOS, en revanche, il vous faudra en plus enregistrer les iDevices de vos betas-testeurs dans votre portail Apple, ou bien utiliser une licence Apple entreprise et un profil de distribution "in-house" (cette 2ème solution est grandement conseillée pour plus de souplesse). Après avoir créé un compte sur TestFlight, chaque testeur pourra alors ajouter son terminal mobile et accéder aux applications lui étant ouvertes.

L’intégration de TestFlight dans Jenkins (Utiliser le plugin Jenkins pour Testflight) est la dernière étape. Ceci vous permettra d’automatiser facilement le déploiement de vos builds vers Testflight et ainsi les rendre disponibles à tous vos testeurs, en continu. Vous serez ainsi en mesure de livrer une nouvelle version de votre projet mobile plusieurs fois par semaine, voire plusieurs fois par jour.

Pour aller plus loin, Testflight apporte également les fonctionnalités suivantes  :

  • Suivre le comportement de vos utilisateurs : qui a installé votre application ? Sur quel terminal ? Combien de temps vos testeurs ont-ils passé sur l’application ?
  • Remontée automatique des logs et des rapports d’anomalies : suivre sur un portail unique les bugs rencontrés par vos testeurs, les terminaux sur lesquels ceux-ci se sont produits le plus souvent, la pile d’exécution associée en vue d’une assistance à la correction.
  • Définition de Checkpoints : mesurer la portion d’utilisateurs ayant atteint telle ou telle fonctionnalité.
  • Forcer la mise à jour de l’application : lors du lancement ultérieur de votre application, vos testeurs restent informés de la présence d’une nouvelle version en ligne et sont dirigés automatiquement vers l’installation de celle-ci.

Conclusion

Le marché de la mobilité arrivant à maturité, la question de la qualité, l’industrialisation, la rationalisation de ses développements mobiles devient centrale. Nous vous avons proposé dans cet article des outils et des solutions concrètes permettant de s’y diriger.

Si l’apparition des premières applications mobiles sur les "stores" semble trivialement avoir été motivée par de la communication institutionnelle, l’enjeu de ces prochaines années paraît tout autre. Privilège sera donné à l’entreprise en mesure de fournir le meilleur service tant sur le plan de la qualité, que sur sa pertinence. Pour y arriver, les entreprises devront raccourcir leur cycle de développement et réfléchir à comment valoriser au mieux leur système d’information. Ceci passe très probablement par l’intégration de plus en plus fine des services mobiles avec ce dernier.

Pour de nombreuses sociétés, le canal mobile est aujourd’hui "regardé de près" et pressenti comme un relais de croissance extraordinaire en complément du Web. D’autres ont déjà franchi ce cap et constatent la grande vitalité de ce marché en regard de leur chiffre d’affaire grandissant sur ce vecteur. Et dire que cette mobilité dont on parle n’a que 6 ans…

> Parution de l’article également sur IT-expert 


 

Published by

Commentaire

5 réponses pour " Qualité et industrialisation des développements mobiles sur iOS & Android (IT-expert) "

  1. Published by , Il y a 10 ans

    Utilisez plutôt Diawi à la place de TestFlight : moins complexe, plus efficace et français en plus !

  2. Published by , Il y a 10 ans

    wahou, un article de qualité de plus sur ce blog !

    cet article montre selon moi combien il est cher pour une entreprise de faire des applications natives car il faut développer X fois ET tester X*4 fois.

    si l’appli est basé au maximum sur HTML/CSS/JS (type cordova ou autre), il est beaucoup plus rapide de tester automatiquement cette couche indépendamment des terminaux puis de réaliser une phase de tests manuels.
    Cela permet de ne pas avoir à développer les tests X fois même si le déploiement continu n’est plus tout a fait possible (à part via testflight que je ne connais pas et qui peut être une réponse à ce problème).

    Si seulement il existait un framework BDD qui permet d’écrire les tests 1 fois et de les jouer sur iOS et Android (i.e bridge vers robotium et calabash)…

  3. Published by , Il y a 9 ans

    Juste pour préciser depuis peu (bien après l’écriture de l’article) Apple a racheté testFlight et à rendu l’outil non utilisable pour les Android. Si on a du temps et de la patience et un serveur disponible il existe une solution (plus ou moins) clé en main disponible, « hockeyKit », il n’est plus mis à jours il me semble mais le code est en php et totalement accessible pour faire des modifications l’outil est open source. Sinon il existe d’autres outils pour faire les tests fonctionnel payant : seeTest, hp solution (se basant sur perfecto)… gratuit: KIF (pour iOS), MonkeyTalk. Merci en tout cas pour l’article vraiment très instructif.

  4. Published by , Il y a 9 ans

    @Charles : Oui en effet, c’est un point important pour Tesflight. A vrai dire, 2 solutions se proposent donc à nous :

    – En mode SAAS : HockeyApp reste un très bon player .. Mais à quand le rachat … ;)

    Nous sommes devenus un peu frileux devant la nécessité de migrer tous nos travaux en 1 mois à cause d’un changement de politique de la plateforme. (On peut rapidement se retrouver avec plusieurs dizaines de builds à migrer…)

    Donc effectivement, 2ème solution :
    – Des solutions à héberger ou que l’on peut rendre soit-même SAAS comme Knappsack également. C’est un peu de boulot et d’engagement pour le suivi de la maintenance et de l’exploitation mais cela se fait… (On y perd tout de même en fonctionnalités par rapport à Testflight!)

    Pour les outils de tests fonctionnels, effectivement, les choses bougent pas mal et Kif est rentré dans nos radars depuis notamment ;)

    Merci pour vos retours et le partage d’infos !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.