Tests mobile automatisés : app native et responsive

En bref

Un test mobile rejoue un parcours sur l'application native iOS et Android, et sur le site en version mobile. Il s'exécute sur des fermes de terminaux réels, avec les gestes propres au mobile : balayage, appui long, rotation, notification. Un rendu correct dans une fenêtre redimensionnée ne dit rien de ce que vit un utilisateur.

Le mobile ne se teste pas en réduisant la fenêtre

Une fenêtre de navigateur réduite ne reproduit ni la mémoire d’un téléphone d’entrée de gamme, ni le clavier natif qui recouvre le champ de saisie, ni la version d’Android que vos clients utilisent encore. L’inverse est vrai aussi : un site parfaitement validé sur ordinateur peut avoir son bouton de commande hors écran sur un iPhone SE, sans qu’aucun test ne l’ait vu passer.

Les vraies applications natives

Vos apps iOS et Android jouées sur des fermes de terminaux réels, avec les versions d’OS de vos utilisateurs.

Le web aux résolutions mobiles

Les mêmes parcours navigateur rejoués aux tailles d’écran de votre audience, là où se cachent les débordements et les boutons inatteignables.

Un parc, pas un modèle

Vous choisissez les combinaisons de terminal et d’OS à couvrir, à partir de vos statistiques d’usage plutôt que du dernier modèle sorti.

Les gestes propres au mobile

Défilement, appui long, rotation, retour arrière système, reprise après mise en arrière-plan. Ce qui n’existe pas sur un ordinateur.

Chaque build testé avant d'arriver sur les stores

Vos tests mobiles se déclenchent depuis votre CI, s’exécutent sur des terminaux réels et remontent là où vos équipes travaillent déjà. Rien à réoutiller.

1 Déclenchement Vos outils gardent la main

GitLab
Jenkins
Microsoft Azure
Appel API
Planification

2 Exécution

vos scénarios tournent sur vos environnements réels

Parcours web
Applications natives iOS et Android
Fermes de mobiles réelles
API et flux internes

3 Restitution Le résultat arrive où vous travaillez

Jira
Slack
SMS
Webhook
API

Et une maintenance qui tient dans le temps

Blocs réutilisablesune modification met à jour tous les scénarios qui l'utilisent
Réparation assistée par IAdes correctifs proposés sur les scénarios en erreur
Regroupement des incidentsles anomalies similaires sont traitées une seule fois

Ce que change l'automatisation, ligne par ligne

Tests mobile manuelsAvec Mr Suricate

Tests mobile manuels

Avec Mr Suricate

Deux téléphones sur un coin de bureau, et on espère que ça suffit.

Un parc de terminaux réels, couvert à chaque campagne.

Le responsive se vérifie en réduisant la fenêtre du navigateur.

Les parcours sont rejoués aux vraies résolutions.

Une régression sur une ancienne version d'Android passe inaperçue.

Les versions d'OS de votre parc sont testées.

L'application et le site sont testés séparément, par deux équipes.

Les deux périmètres vivent dans le même cahier de tests.

On découvre le bouton hors écran par un avis sur le store.

On le voit sur la capture d'écran de l'exécution.

Chaque livraison mobile repart pour un tour de tests manuels.

La campagne se relance seule, à chaque build.

RésultatVos parcours vérifiés sur les terminaux et les résolutions que vos clients utilisent réellement, à chaque livraison.

Sur terminaux réels

Le rendu, les gestes et les notifications tels que l'utilisateur les vit

Les écarts entre versions d'OS et entre constructeurs deviennent visibles

Le comportement réseau et les permissions sont réellement joués

Sur un navigateur redimensionné

Suffisant pour un contrôle de mise en page

Ne dit rien des notifications ni des permissions

Masque les écarts entre constructeurs

tests mobiles, cross-browser, jeu de données : les définitions sont dans le glossaire QA.

LIVRE BLANC · AUTOMATISATION DES TESTSEt si vos bugs ne coûtaient plus rien à votre business ?Le vrai coût des bugs sur mobile, et comment bâtir une automatisation qui suit le rythme des sorties d’application.

Télécharger le livre blanc

“ Un outil facile à prendre en main, de façon ludique, qui rappelle Scratch. La gestion des campagnes me permet d'être plus sereine avant chaque déploiement. ”

Coralie Cebron de LisleTesteuse logiciel, Optivalue

Vos scénarios mobiles, écrits par vous ou par nous

Avec Mr Suricate, votre équipe QA n’est pas remplacée, elle est renforcée. Vous choisissez ce que vous internalisez et ce que vous déléguez : la création des scénarios, leur exécution, ou leur maintenance dans le temps.

1Identification des parcours critiques, front et back
2Écriture des tests, sans code
3Supervision continue et alertes
4Maintenance et évolution des scénarios

Résultatvous gagnez en couverture sans alourdir la charge de vos équipes. Et si vous préférez tout déléguer, l'externalisation QA prend le relais.

ALLER PLUS LOIN

Les autres types de tests

Quinze types de tests, quatre familles. Chacun répond à une question différente sur votre application.

Tests fonctionnelsVérifier qu'une fonctionnalité produit bien le résultat attendu, du point de vue de l'utilisateur.En savoir plus Tests de non-régressionRejouer l'ensemble des parcours validés avant chaque mise en production.En savoir plus Tests end-to-endLe parcours complet, d'un bout à l'autre de la chaîne, y compris les systèmes tiers.En savoir plus Tests de performanceLe temps de réponse réel de vos parcours, mesuré en continu et comparé à vos seuils.En savoir plus Tests graphiquesLa comparaison visuelle pixel par pixel, pour les changements qu'aucune assertion ne détecte.En savoir plus Tests d'accessibilitéLa conformité de vos parcours aux critères d'accessibilité, vérifiée automatiquement.En savoir plus Tests de sécuritéVérifier ce qu’un utilisateur peut réellement atteindre : droits par profil, sessions, authentification, HTTPS.En savoir plus Les 15 types de testsLa vue d'ensemble : quatre familles, quinze types, et par quoi commencer selon votre situation.En savoir plus

Un terme vous échappe ? Le glossaire du test automatisé le définit.

VOS QUESTIONS

Questions fréquentes

Ce qu'on nous demande le plus souvent sur les tests mobile.

Testez-vous les vraies applications natives, ou seulement le site en responsive ?

Les deux. Les applications iOS et Android sont jouées sur des fermes de terminaux réels, et vos parcours web sont également testés aux résolutions mobiles. Ce sont deux périmètres distincts, souvent confondus, et ils se traitent dans le même cahier de tests.

Sur quels terminaux les tests sont-ils joués ?

Sur des terminaux réels et sur les combinaisons de modèle et de version d'OS que vous choisissez. Le bon critère est votre propre répartition d'audience, pas le dernier appareil sorti : c'est souvent un modèle ancien qui révèle les défauts.

Faut-il écrire un scénario différent pour iOS et pour Android ?

Les deux plateformes n'ont pas les mêmes composants ni les mêmes gestes système, donc le scénario est adapté à chacune. En revanche la logique du parcours et les données de test sont partagées, et les blocs réutilisables évitent de tout dupliquer.

Le responsive, est-ce que ça ne suffit pas ?

Cela dépend de ce que vous vendez. Si votre application native porte du chiffre d'affaires ou un service client, elle doit être testée pour elle-même : un site responsive validé ne dit rien du comportement de l'app sur un téléphone chargé, avec une connexion faible ou une notification qui interrompt le parcours.

Faut-il coder pour automatiser un test mobile ?

Non. Les scénarios mobile se construisent comme les autres, par capture assistée ou assemblage de blocs. C'est ce qui permet à un profil métier de maintenir la couverture au rythme des livraisons de l'application.

Sur quoi les tests s’exécutent-ils réellement ?

Sur des parcs de terminaux réels via nos partenaires BrowserStack et LambdaTest, sur le modèle et la version retenus pour le test. Nous opérons cette infrastructure pour vous. Nous n’exploitons pas notre propre parc de téléphones, et le nombre d’exécutions simultanées dépend des licences prévues au contrat.

Les blocs sont-ils les mêmes que pour le web ?

Non, et c’est important. Un scénario d’application native utilise un catalogue dédié : tap sur un élément ou à des coordonnées, scroll sur l’écran ou dans un élément, chaînage de gestes, sélecteurs iOS et Android. Le moteur est différent, il se choisit à la création du scénario.

Comment fournit-on l’application à tester ?

Le fichier de l’application se dépose dans la gestion des documents de votre espace, et le scénario s’appuie dessus. Une nouvelle version se remplace au même endroit, sans toucher aux scénarios.

Que couvre-t-on au-delà du parcours nominal ?

La saisie sur les champs à code, PIN ou OTP, la limitation du débit réseau pour reproduire une connexion dégradée, le contournement du calendrier du téléphone, les boîtes de dialogue système et le masquage du clavier. Ce sont les points qui font échouer un test mobile bien plus souvent que le parcours lui-même.

Tests mobile : l'app native et le responsive, testés pour de vrai

Ils nous font confiance