Test des applications mobiles dentreprise pour SAP

(Alexander Ilg) (11 novembre) , 2020)

Les tests sont une partie importante de tout projet de développement logiciel – tests unitaires, tests dintégration, tests dacceptation des utilisateurs, etc. Dans ce blog, je souhaite discuter des tests des applications mobiles dentreprise, en particulier celles destinées à une utilisation hors ligne.

Aucun logiciel nest parfait. Les roquettes sont envoyées sur Mars et se brisent à cause de bugs. Certains avions sarrêtent sils ne sont pas « redémarrés » au moins tous les 248 jours (et vous me demandez pourquoi jai peur de voler).

Peur de voler? Ne regardez pas les rapports de bogues pour les logiciels davion!

La liste est longue, il y a même un article Wikipedia qui montre des exemples de bogues dans tous zones – https://en.wikipedia.org/wiki/List\_of\_software\_bugs .

Avoir et corriger un bogue dans un endroit central comme un Le système SAP peut déjà être pénible (redémarrage du système, temps darrêt, utilisateurs mécontents, données perdues, etc.). La correction dun bogue dans une application installée sur de nombreux ordinateurs (comme par exemple SAP GUI) est un peu plus délicate, mais toujours gérable si toutes les machines sont en interne et connectées au réseau de lentreprise.

Cela devient beaucoup plus difficile dexpédier une nouvelle version dune application mobile dentreprise hors ligne qui est installée sur les smartphones et les tablettes en dehors du bureau de lentreprise. Même si vous disposez dune solution de gestion dappareils comme Idaptive, SAP Mobile Secure, Mobile Iron ou Airwatch, cela représente encore beaucoup de travail. Si les utilisateurs ont une mauvaise connexion réseau, il est difficile de distribuer de nouvelles versions. Pire encore sil existe des dépendances entre lapplication mobile et le logiciel côté serveur – dans ce cas, les deux doivent être mis à jour en même temps, ce qui peut être vraiment délicat si la base dutilisateurs se trouve dans plusieurs fuseaux horaires et est distribuée dans le monde entier. Pour cette raison, il est important de tester très attentivement les applications mobiles dentreprise. Peu importe la plate-forme que vous utilisez – Agentry, SMP, SCP Mobile Services, MobiLink ou autre. Les tests doivent être effectués sur toutes les couches, y compris le client, le middleware et le backend. Voici une liste de tests à effectuer pour chaque application.

Tests fonctionnels

  • Test de toutes les fonctionnalités dans les deux sens – créez des données dans SAP et synchronisez-les avec lappareil mobile. Créez des données sur lappareil mobile et envoyez-les à SAP. Mettez à jour les enregistrements des deux côtés, supprimez les données et vérifiez quelles sont également supprimées sur le système opposé.
  • Testez la validation sur lappareil mobile – lutilisateur reçoit-il le bon message davertissement / derreur lorsquil saisit de mauvaises données ?

Tests de performances – synchronisation et sur lappareil

  • Synchronisez avec le volume de données maximum que vous attendez. Tenez également compte du fait que le volume de données peut augmenter avec le temps.
  • Testez avec le nombre maximum dappareils simultanés pour voir comment le système peut gérer la charge.
  • Testez lappareil avec la quantité maximale de données – comment sont les performances des listes et des boîtes de dialogue détaillées? Dans quelle mesure la navigation dans lapplication est-elle fluide? Quelle est la vitesse du temps de démarrage? Tester sur un simulateur / émulateur nest jamais assez bon, vous devez le tester sur lappareil réel que lutilisateur tiendra entre ses mains plus tard!

Test contre les directives UI / UX du système dexploitation mobile

  • Si vous avez une application native, est-ce quelle suit les directives UX dApple, Google et Microsoft?
  • Si vous avez une application hybride / indépendante de la plate-forme , est-ce quil suit des directives courantes (par exemple le guide SAP Fiori UX)?

Tests dutilisabilité

  • Donnez lapplication aux utilisateurs et laissez-les tester. Est-ce intuitif? Peuvent-ils comprendre comment lutiliser même sans ou avec seulement un peu de documentation?
  • Testez votre solution avec des utilisateurs expérimentés avec les smartphones / tablettes et avec ceux qui ne sont pas habitués aux technologies modernes.
  • Si vous vous déployez à linternational, testez avec des utilisateurs de différents pays pour voir comment ils réagissent au logiciel.
  • Testez avec différentes langues et paramètres de localisation pour vous assurer que tout saffiche correctement
  • Laissez la traduction être révisée et testée par un locuteur natif
  • Écoutez vos utilisateurs de test! Cest de loin le meilleur retour que vous puissiez obtenir!

Test derrière le rideau – non seulement linterface utilisateur, mais également lintégration du middleware et du backend

  • Test client, middleware (si vous en avez) et backend. Tout doit bien fonctionner ensemble.
  • Assurez-vous que la communication entre les trois composants fonctionne correctement.

Testez les cas positifs et négatifs

  • Testez votre solution avec des données et des cas de test qui devraient fonctionner
  • Testez votre solution avec des données qui devraient échouer.Nous savons tous que les utilisateurs entreront les informations les plus inattendues et vous devez vous assurer que lapplication ne plante pas dans un tel scénario.
  • Assurez-vous que les deux cas sont traités avec succès
  • Test lapplication lorsque le serveur middleware est arrêté. Se comporte-t-il comme prévu? Testez-le également lorsque SAP nest pas disponible.
  • Tuez durement lapplication au milieu dun processus de sauvegarde ou de synchronisation. Cela fonctionne-t-il toujours? Avez-vous perdu des données?

Cela vous semble familier?

Testez en dehors du laboratoire / avec le réseau réel

  • Testez votre application avec le réseau réel que vos utilisateurs utiliseront plus tard. Les performances sont-elles encore assez bonnes avec GPRS ou Edge? Les performances sont-elles acceptables sur des sites distants?
  • Testez le logiciel sur lappareil réel, pas seulement sur un simulateur. Tout est-il affiché comme il se doit? Les performances sont-elles conformes aux attentes?
  • Testez le logiciel avec lappareil réel en conditions réelles. Pouvez-vous lire lécran en plein soleil? Lappareil fonctionne-t-il à lextérieur par temps chaud ou froid?
  • Testez la solution avec toutes les autres applications installées – y a-t-il des effets secondaires? Avec la philosophie sandbox dAndroid et diOS, cela devrait fonctionner, mais vous feriez mieux de le tester.
  • Testez-le dans des situations de faible mémoire – lapplication fonctionne-t-elle toujours? Quelle est la performance dans ce cas? Que se passe-t-il si lapplication est supprimée de la mémoire?
  • Testez lapplication avec les anciennes versions du système dexploitation. Testez-le également avec des versions bêta qui seront publiées dans le futur!
Pouvez-vous travailler à une vitesse acceptable au milieu de nulle part?

Rédiger des scripts de test automatisés

Laissez vos développeurs créer des scénarios de test automatiques qui peut être exécuté avant chaque build. Cela peut réduire leffort de test et détecter déjà les premiers bogues avant que les vrais testeurs ne commencent leurs activités. Les tests unitaires automatisés ne peuvent cependant jamais remplacer les tests «réels», il suffit de les compléter.

Test sur différents appareils

Si vous avez une stratégie BYOD (apportez votre propre appareil), essayez de tester lapplication sur différents appareils. Lapplication fonctionne-t-elle sur toutes les résolutions décran? Si elle est indépendante de la plate-forme, fonctionne-t-elle sur toutes les plates-formes?

Testez linstallation / la mise à jour

Testez linstallation et la mise à niveau de votre application mobile. LAPK, lIPA ou le XAP peuvent-ils être téléchargés via la connexion téléphonique?

Testez la sécurité de lapplication

  • Utilisez un sniffer réseau pour voir si le cryptage que vous avez activé est actif.
  • Essayez douvrir la base de données de lappareil pour voir si elle est vraiment chiffrée.
  • Testez le stockage sécurisé comme par exemple le trousseau iOS – ces données sont-elles uniquement locales ou sont-elles envoyer vers le cloud?

Tester la partie administration de lapplication

  • Pouvez-vous créer de nouveaux utilisateurs, appareils, etc. dans votre paysage mobile?
  • Pouvez-vous désinscrire / supprimer des appareils?
  • Les journaux sont-ils correctement configurés? Ont-ils suffisamment dinformations pour analyser les problèmes? Est-il suffisamment bas pour que le journal ne diminue pas les performances?

Peu importe la durée et la qualité de vos tests, il y aura des bugs qui passeront entre les mailles du filet. Plus lapplication est complexe, plus cela est probable. Pour cette raison, vous devriez toujours avoir une solution de secours – cela peut être une feuille Excel ou simplement un morceau de papier. Idéalement, vous n’avez jamais besoin de l’utiliser.

Les tests sont un sujet brûlant – combien de tests suffisent-ils? Combien cest trop? On pourrait dire que lon ne peut jamais tester assez, cependant, quelquun doit payer pour cela. Comme pour tout, vous devez trouver le bon équilibre.

Bonne chance pour vos tests! Et si vous avez des questions ou avez besoin daide pour vos tests, veuillez me contacter à [email protected] .

Laisser un commentaire

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