Comment sont gérés les tests de l’application ?
Il existe deux grandes familles de tests pour les applications web et mobiles :
- Les tests fonctionnels, aussi appelés tests d’acceptance, sont écrits du point de vue de l’utilisateur. Ils assurent que le système fonctionne comme les utilisateurs s’y attendent. Dans le cadre d’un audit applicatif, il faudra vérifier le plan de tests.
- Les tests unitaires sont écrits du point de vue du développeur. Ils sont faits pour s’assurer qu’une méthode particulière, une fonction, une unité, une classe, … etc., effectue un ensemble de tâches spécifiques, correctement. Pour les besoins de l’audit, l’évaluation des tests unitaires sera réalisée par l’analyse du code source de l’application.
Tests fonctionnels et plan de tests
Une enquête d’AxioCode sur les pratiques pour la création rapide d’applications web et mobiles pérennes révèle que les tests fonctionnels sont loin d’être systématiques et encore moins automatisés. Pourtant, les tests sont déterminants dans l’objectif de la réalisation d’applications pérennes. Chaque livraison d’une mise à jour ou d’une nouvelle version de l’application doit être précédée d’une phase de tests complets. Car il est fréquent qu’une modification ait des répercussions inattendues, des “effets de bord” qui se traduisent par des bugs. Il n’y a rien de pire que de livrer une nouvelle version de l’application qui ne fonctionne pas correctement. Pour éviter cela, il est nécessaire de réaliser des tests fonctionnels exhaustifs. Réalisés “manuellement”, ils sont chronophages. D’où l’intérêt de mettre en place des tests fonctionnels automatisés qui vont simuler le comportement des différents profils d’utilisateurs et signaler d’éventuelles anomalies.
Pour les besoins de l’audit, il convient de vérifier qu’un plan de tests existe et d’évaluer sa qualité en se posant les questions suivantes :
- Est-ce que chaque fonctionnalité / exigence de l’application est couverte par au moins un cas de test ?
Cela témoigne du degré de complétude du plan de tests, facteur essentiel de la qualité des tests. Un plan de tests partiel est contre productif. - Est-ce que les cas de tests sont correctement décrits ?
Ils doivent indiquer clairement quelle action est réalisée, par quel profil d’utilisateur, et quel résultat concret est attendu. - Est-ce que des jeux de données de tests sont prévus et cohérents ?
Les cas de tests doivent prévoir quelles informations seront manipulées ; autant que possible, d’une campagne de tests à une autre, les cas de tests reprendront les mêmes données qui doivent donc être inventoriées. - Quand les campagnes de tests sont-elles effectuées ? A la demande, à chaque mise à jour de l’application, uniquement lors des mises à jour importantes ?
Idéalement, chaque livraison d’une nouvelle de l’application doit faire l’objet d’une campagne de tests ; c’est d’autant plus important que l’application est critique pour l’entreprise ou l’organisation. - Par qui sont effectués les tests ? par les développeurs uniquement, des utilisateurs identifiés ?
Il est souvent délicat pour les développeurs de “changer de casquette”, de passer de la fonction de développeur qui réalise des tests techniques dits “unitaires” à un rôle d’utilisateur lambda de l’application. D’où l’intérêt d’impliquer de “vrais” utilisateurs dans les phases de tests. Les équipes de développement les mieux organisées disposent de compétences spécifiques pour l’organisation et la réalisation des campagnes de tests de leurs applications. - Est-ce que certains tests, notamment les plus récurrents ou fastidieux, sont automatisés ?
Tester une application dans son ensemble demande beaucoup de temps. C’est la raison pour laquelle les tests sont rarement exhaustifs, presque toujours incomplets. La solution est de mettre en place des tests fonctionnels automatisés : ils sont codés et mis en œuvre via un système spécifique (comme Sentry par exemple) et ont tout leur intérêt pour les fonctionnalités les plus utilisées et les plus critiques.
Tests unitaires
Les tests unitaires sont techniques : ils permettent au développeur de tester une fonction, une procédure, un module, etc, indépendamment du reste de l’application. L’objectif est de s’assurer que l’unité testée fonctionne correctement en toutes circonstances. Cette vérification est essentielle, en particulier dans les applications métier critiques.
L’évaluation des tests unitaires passe par l’analyse du code source de l’application. Les questions à se poser sont les suivantes :
- Quel est le taux de couverture des tests unitaires ?
Les outils d’analyse du code source (Sonarqube, Code Climate, Codacy, Coverity, Checkmarx,… etc.) vous permettent d’obtenir cette information qui sera exprimée en pourcentage. - Quel est le framework de tests unitaires utilisé ? Est-ce un outil du marché ou open source répandu, à jour ?
- Comme pour les tests fonctionnels, est-ce que des jeux de données de tests sont prévus et cohérents ?
- A quel moment les tests unitaires sont-ils exécutés ? Manuellement par les développeurs ? Dans un processus d’intégration continue, automatique ?
Quelle est la qualité de la documentation technique ?
Le cahier des charges initial de l’application comporte le plus souvent des spécifications techniques. Mais au fil du temps et des changements apportés à l’application, cette documentation n’est pas toujours mise à jour.
L’enquête d’AxioCode sur les pratiques pour la création rapide d’applications web et mobiles pérennes indique que les spécifications (fonctionnelles et techniques) ne sont “le plus souvent mises à jour” que pour un peu plus de 50% des participants. La principale raison pour laquelle les spécifications ne sont pas mises à jour est le manque de temps ou de budget. Pourtant, des spécifications qui ne sont pas à jour sont problématiques, en particulier lorsqu’il faut se replonger dans l’application après quelque temps ou lorsque de nouveaux développeurs doivent intervenir. Lorsque l’on se base sur des spécifications qui ne sont pas à jour, le risque est d’apporter des modifications non pertinentes ou incohérentes, sources d’erreurs ou d’oublis. Il faudra parfois refaire ce qui avait été fait, ce qui se traduit finalement par de la perte de temps.
Le maintien à jour de la documentation technique est un investissement fondamental pour la bonne santé de l’application et sa pérennité.
L’audit de la documentation technique consiste à vérifier que celle-ci comporte des informations essentielles :
- l’architecture logicielle détaillée de l’application,
- les diagrammes pertinents, par exemple en UML avec les classes utilisées,
- le schéma de la base de données,
- le cas échéant, la description des API et des web services utilisés,
- la liste des composants techniques utilisés, documentés autant que possible.
Il convient par ailleurs de se pencher sur le circuit de rédaction, de relecture et de validation de la documentation technique. Et bien sûr de vérifier que la documentation technique est bien maintenue dans le temps.
Quelle est la qualité du processus de développement et de déploiement ?
Les méthodes et les processus de développement et de déploiement sont déterminants dans la qualité et la pérennité des applications web et mobiles.
Les points à étudier sont les suivants :
- Quelle méthodologie l’équipe de développement suit-elle ? Est-ce une méthode classique ou une méthode agile ? La méthode retenue est-elle adaptée ?
En pratique, les méthodes agiles mettent le “propriétaire” de l’application (product owner) au centre de l’organisation
des travaux au quotidien. Par ailleurs, ces méthodes ne garantissent pas à la fois le périmètre fonctionnel et les délais de réalisation : ce qui sera livré, c’est ce que l’équipe de développement aura eu le temps de coder en fonction des décisions prises de sprint en sprint. Autant dire que ces méthodes sont difficilement compatibles avec un développement en sous-traitance, au forfait. A l’inverse, c’est une approche à retenir avec une équipe de développement interne qui travaille main dans la main avec les experts métier. - Est-ce que la pratique de revue de code est en place ? Est-elle systématique ? Est-elle efficace ?
Comme l’indique Wikipédia, la revue de code est ”un examen systématique du code source de l’application. Il peut être comparé au processus ayant lieu dans un comité de lecture, l’objectif étant de trouver des bugs ou des vulnérabilités potentielles ou de corriger des erreurs de conception afin d’améliorer la qualité, la maintenabilité et la sécurité du logiciel (…). La revue de code est depuis longtemps reconnue comme un moyen performant d’améliorer la qualité des applications”. L’efficacité des revues de code peut être analysée au travers des bugs de l’application en se demandant pourquoi ils n’ont pas été détectés dans la phase de revue de code. Il convient également de consulter les historiques de revue de code, dont les commentaires seront instructifs. - Est-ce que des environnements techniques différents sont disponibles ? Comme par exemple un environnement d’intégration pour les développeurs et un environnement de validation pour la recette (les tests), tous deux différents de l’environnement final de production ?
- Il est aussi intéressant de vérifier la méthode de déploiement de l’application : existe-t-il un processus d’intégration continue permettant de s’assurer que les nouveaux développements ne génèrent pas de régression ? Quelle stratégie de déploiement en production est en place ? Le déploiement est-il automatique ou manuel ?
Découvrez cette étape en vidéo
Comment évaluer la couverture des tests, de la documentation, du processus de développement et de déploiement ?
Rediffusion du webinaire sur l’audit de la couverture des tests, de la documentation, du processus de développement et de déploiement d’une application web ou mobile, présenté par Antony Zanetti, Directeur Technique et co-fondateur d’AxioCode. Une séance de questions/réponses suit la présentation. Vous avez des questions supplémentaires ? Posez-les nous.
En conclusion
Vous avez en main les clés d’analyse de la couverture des tests, de la documentation, du processus de développement et de déploiement d’une application web ou mobile. Pour mener à bien ces analyses, contrairement à d’autres phases d’audit comme la vérification de la complétude fonctionnelle par exemple, vous aurez besoin de compétences techniques. Idéalement le chef de projet technique ou un développeur de l’application.
Une application professionnelle vous pose problème ? Vous n’avez pas les compétences en interne ? Vous n’avez pas le temps d’analyser votre application ? AxioCode peut vous aider.
Demandez conseil à un expert ou faites un diagnostic autonome rapide de votre application.
Evaluez l’obsolescence de votre application
Vous pouvez bénéficier de notre service d’audit dédié aux applications web et mobiles. Vous obtiendrez ainsi une étude détaillée de votre application et une feuille de route.
