Proposer des applications mobiles de qualité aux consommateurs de vos produits ou services peut vous différencier de vos concurrents.
C’est bien souvent l’un des critères de choix d’une marque.
Pour autant, concevoir une application mobile n’est pas une mince affaire : il s’agit de répondre rapidement à un besoin… tout en maximisant la qualité de l’application.
Autant dire résoudre la quadrature du cercle !
Quand on sait le nombre de terminaux mobiles existants, de versions des systèmes d’exploitation… Et la fréquence à laquelle Apple et Google mettent à jour les versions de leurs OS.
Les cycles de développement étant de plus en plus courts (notamment dans le contexte de développement en mode Agile), éviter les bugs et autres anomalies semble irréalisable…
Sauf si vous disposez de temps et d’argent [Ebook « Applications mobiles : A quel prix et dans quel délai »] !
Mais si on ne peut éviter les bugs, qu’en est-il des conséquences sur l’image de marque et sur les opportunités de business ? On le sait, elles peuvent être dramatiques.
Alors, est-ce que produire des applications mobiles de qualité représente un challenge irréalisable ?
Bien sûr, la réponse est : Non.
Et pour le prouver, il nous faut revenir un cran en arrière et expliquer la notion de Qualité.
En préambule, rappelons que l’erreur est humaine, donc inévitable. En prendre conscience et mettre en œuvre les moyens d’y remédier est la première étape d’une stratégie Qualité efficace.
Un service Qualité : Est-ce vraiment nécessaire ?
Comme dans tout autre domaine, le rôle d’un service Qualité en matière de développement d’applications mobiles est de vérifier que les développements réalisés sont conformes aux périmètres spécifiés.
Rappelons-le, la Qualité est un VRAI MÉTIER s’appuyant sur des méthodes et des outils (tests unitaires, d’intégration, revue de code, Test Driven Development…) et nécessitant pour les testeurs, des compétences bien particulières (goût du challenge, persévérance, curiosité, etc.)
Qualité du code
Les développeurs d’applications mobiles ont bien sûr un rôle important à jouer dans la qualité du code : ils sont tenus de suivre des normes d’écriture et doivent tester leurs codes de manière statique (avec des outils tels que SonarQube) ou dynamique (revue de code par un autre développeur).
Mais cela ne remplace pas le travail du testeur, car tester nécessite d’être objectif.
Il n’est pas rare qu’un testeur tombe immédiatement sur un bug que le développeur, qui est plongé dans l’application toute la journée, n’aura pas détecté pendant plusieurs jours.
Il n’y a donc pas de meilleur testeur qu’un spécialiste de la question, indépendant du développement et qui aura toute l’objectivité et la connaissance Métier nécessaires pour mener sa mission de manière efficace.
Que teste-t-on ?
En dehors des aspects fonctionnels, les tests d’applications mobiles sont tout à fait spécifiques aux équipements sur lesquels ils fonctionnent ; ils concernent l’installation, la performance (une appli trop lente sera abandonnée ou désinstallée), la connexion (fonctionnement hors connexion par exemple), la montée en charge du serveur (on « stresse » le serveur pour voir comment il réagit) ou du réseau, l’ergonomie (cohésion de l’interface utilisateur, utilisabilité), la mémoire, la sécurité (par exemple, une application bancaire ne devra pas être hackable), le bon fonctionnement sur les différentes tailles de matériels (smartphone, tablette, phablette…), etc.
Les tests Qualité d’applications mobiles : en quoi ça consiste précisément ?
En mode Agile, au début du projet de développement, on décrit dans un document toutes les exigences auxquelles devra répondre l’application mobile.
Ce « backlog », découpé en tâches, est signé par toutes les parties concernées (entreprise et prestataire si le développement est externalisé).
Ce backlog donne lieu à un découpage en « Sprints de développement » couvrant une ou plusieurs fonctionnalités.
Quand fait on des tests ?
Les tests interviennent au cours de chaque Sprint et donnent lieu à une recette, sur la base des exigences validées par l’entreprise (ou par le service émetteur de la demande).
Ceci étant dit, en quoi consistent les tests ?
A chaque fonctionnalité correspondent des scenarii détaillant les comportements des futurs utilisateurs et décrivant chaque action. On parle ici de « campagne de tests ».
Le testeur reproduit donc ces scenarii et s’assure que tout est bien conforme à ce qui a été spécifié d’un point de vue fonctionnel, technique, performance ou ergonomie.
Quels sont les différents types de tests ?
Il existe différents types de test : tests unitaires qui concernent une action, tests d’intégration qui concernent une fonctionnalité comportant plusieurs actions, tests de non régression pour s’assurer que de Sprint en Sprint, des actions ou fonctionnalités précédemment testées ne sont pas remises en cause.
Il existe plusieurs façons de tester :
- Test automatisés : ceux-ci sont réalisés à l’aide d’outils, d’algorithmes qui comparent automatiquement les résultats obtenus à ceux attendus ; cette approche nécessite de prévoir des scripts détaillés en amont (et donc le temps pour les écrire).
- Tests manuels : ils sont réalisés par un testeur expérimenté qui navigue dans le produit pour l’utiliser comme pourraient le faire les futurs utilisateurs. Ces tests manuels peuvent être scénarisés (ils suivent des parcours prédéfinis et permettent de contrôler la qualité de l’appli sur des problématiques bien précises) ou exploratoires : ils permettent de parcourir le produit librement sous des angles variés (fonctionnels, graphiques, ergonomiques) sans plan de test.
Sur quels outils s’appuie-t-on ?
Des outils de suivi et de reporting tels que Jira permettent au testeur de documenter les tests et de produire des courbes pour mesurer la qualité du développement des applications mobiles concernées (nombre de bugs détectés, nombre de revues de code, etc.)
Dans Jira, le testeur rédige un rapport sur le contexte et les étapes pour reproduire le bug. Le rapport comporte un numéro d’identification, un titre qui résume le problème rencontré et le contexte (nom de l’utilisateur, OS et version de l’équipement mobile utilisé, version de l’application, marque et modèle du téléphone, etc.).
Documenter un bug permet de faciliter sa correction.
Y’a-t-il de bonnes pratiques permettant de limiter le nombre de bugs et optimiser la qualité des applications mobiles ?
Bien communiquer entre équipes projet et développement
Cela peut paraître évident mais il n’est pas inutile de le rappeler : une bonne partie des bugs sont attribués à une communication déficiente ou à de mauvaises interprétations des spécifications.
Ne pas se précipiter
Le manque de temps peut inciter les développeurs à faire des compromis… ce qui peut générer des bugs.
Même si le temps est compté dans les projets de développement d’applications mobiles, prendre le temps permet bien souvent d’en gagner et d’augmenter la qualité du travail réalisé.
A titre d’exemple, les revues de code ne sont pas du temps perdu car elles permettent à des développeurs plus expérimentés de suggérer un meilleur code qui rendra l’application plus performante.
Être rationnel
Les entreprises ont parfois le défaut d’établir une longue « liste de courses » fonctionnelles : plus il y a de fonctionnalités, plus le temps de développement sera long, plus les plannings risquent d’être serrés. Donc, il n’est pas inutile d’essayer de prioriser et de se concentrer sur les fonctionnalités incontournables. Le code sera moins important, le développement et les tests plus rapides, les corrections plus vite implémentées.
Accepter l’imperfection
Bien sûr, l’objectif reste de faire le mieux possible, mais dans la mesure où atteindre la perfection relève du mythe, autant l’accepter… et cela nous conduit tout droit au point suivant.
Qualifier le degré de criticité d’un bug
Puisque l’objectif est de minimiser le nombre de bugs dans le temps et le budget impartis, il est capital de mesurer le niveau de criticité des bugs que l’on identifie.
Il y a des bugs mineurs qui touchent peu d’individus dans des circonstances vraiment très particulières ou qui concernent une fonctionnalité rarement utilisée. Il y a par contre des bugs très gênants qui rendent impossibles la poursuite de la navigation, par exemple.
On peut estimer le niveau de gravité d’un bug selon qu’il est bloquant (il empêche la fonctionnalité d’être utilisée), majeur (un contournement est possible pour réaliser l’action) ou mineur (on peut utiliser la fonctionnalité mais pas tout à fait comme ce qui était prévu).
En fonction du niveau de gravité du bug, on va décider s’il est nécessaire qu’il soit immédiatement corrigé ou bien que cela peut attendre le prochain Sprint, ou encore « la prochaine release ».
La qualité en matière d’applications mobiles : une histoire de curseur…
Vous l’aurez compris, pour concevoir des applications mobiles de qualité, il est indispensable de
- disposer des équipes qualifiées de testeurs et du matériel nécessaire (terminaux mobiles, serveur),
- s’appuyer sur les méthodes appropriées et éprouvées,
- mettre en place les outils de suivis et
- appliquer de bonnes pratiques permettant d’atteindre un juste équilibre entre correction du nombre maximum de bugs, respect des budgets et des plannings prévisionnels.
Enfin, toute cette organisation ayant pour but ultime la satisfaction du client (interne ou externe), son implication est incontournable pour réaliser des tests complémentaires à ceux effectués par l’équipement de développement ou le prestataire extérieur.
En conclusion, on peut dire que la Qualité est un projet à part entière, au sein même des projets de développement d’applications mobiles.
Pour aller plus loin :
[ Infographie ] Comment choisir entre application native, hybride et WebApp ?
Vous souhaitez réagir ou en savoir plus ?
On vous offre un café et, en bonus, la check-list de votre cahier des charges, pour ne rien oublier.
Vous êtes partant(e) ?