Après les caractéristiques de l’audit de code, publié dans notre numéro 55, nous abordons les principes des tests applicatifs. Avec cinq bonnes pratiques : professionnaliser les pratiques par la certification, tester le plus en amont possible, intégrer les tests à l’ensemble de la chaîne de développement, établir des priorités pour les tests et penser à l’externalisation.
« Nous avons découvert un dysfonctionnement sur l’application une fois celle-ci livrée. Personne n’avait eu le temps de la tester ! » Ce type d’anecdote reste fréquent alors qu’il devrait appartenir au passé. Les tests, étape essentielle dans tout projet de développement, sont encore trop souvent réduits à la portion congrue, quand ils ne sont pas tout simplement occultés.
Des délais sous-estimés, des priorités non définies, des ressources indisponibles ou des environnements mal calibrés pénalisent la réalisation des tests. Conséquence directe : nombre de défauts qui auraient pu être détectés et corrigés en phase de développement sont identifiés lors du déploiement, générant des coûts supplémentaires et le mécontentent des utilisateurs.
À l’instar de l’audit de code, les tests sont primordiaux pour s’assurer de la qualité des applications. Tandis que l’analyse du code permet de vérifier si une application est bien écrite, les tests s’attachent quant à eux à vérifier la qualité de l’exécution.
L’étape de test a deux grands objectifs : le premier est de contrôler que l’application est conforme aux exigences du donneur d’ordres, à la fois au niveau fonctionnel et au niveau technique. Le second est de rechercher la présence de défauts.
Au-delà de ces objectifs généraux, il est possible de mener des tests plus spécifiques pour se concentrer sur certains aspects de l’application, notamment les performances, la tenue face à la charge, la sécurité, l’ergonomie ou encore l’accessibilité.
Professionnaliser les pratiques par la certification
On le voit, il existe une vaste palette de possibilités en matière de tests. La gestion de cette étape nécessite une expertise et un savoir-faire spécifiques, d’autant plus que les applications actuelles sont bien souvent bâties selon des architectures distribuées qui complexifient encore la donne.
Conscients de ces nouveaux enjeux, les professionnels du test se sont regroupés dans une organisation internationale, l’ISTBQ (International Software Testing Qualifications Board) afin de définir des normes et de proposer des certifications pour leur métier.
En France, le CFTL (Comité français des tests logiciels), créé en 2004, propose les certifications de l’ISTBQ. Il faut signaler également la mise en place d’actions collectives de formation sur les métiers du test, sous l’égide du Fafiec.
Tester le plus tôt possible
Reléguer les tests en fin de projet, comme dans les cycles de développement classiques, revient bien souvent à les sacrifier, ceux-ci ayant vite fait de passer à la trappe en cas de retard sur les délais.
Une bonne pratique issue des méthodes de développement agiles consiste à élaborer les tests avant même d’écrire le code. S’il n’est pas forcément nécessaire d’aller jusque-là, de manière générale, plus tôt démarrent les tests, plus les coûts liés à la non-qualité seront réduits. Le CFTL distingue plusieurs niveaux de tests (voir encadré) : si les deux derniers nécessitent de disposer de l’application entière, les deux premiers peuvent être menés au fil de l’eau durant le développement.
Il est important également de bâtir le plan de tests dès le démarrage du projet, afin de disposer d’une vue d’ensemble des actions à mener. Prévoir les différents tests à mener permet notamment d’identifier certains prérequis nécessaires pour la réalisation de ces tests : la réservation des ressources spécifiques par exemple, ou encore la mise à disposition de jeux de données anonymisées.
Intégrer les tests à l’ensemble de la chaîne de développement
L’adéquation entre la demande des utilisateurs et l’application finale reste fondamentale. Si les besoins changent, cela a un impact sur l’ensemble du processus de développement. Pour tenir compte de ces changements, susceptibles de survenir dès la phase de développement initial mais aussi tout au long de la vie de l’application, il est important de ne pas concevoir les tests comme une étape isolée.
Les testeurs doivent partager avec les développeurs et les personnes élaborant le cahier des charges une « vision unique de la vérité ». Les tests doivent donc être étroitement intégrés à la gestion des exigences. Cette intégration permet d’établir les tests fonctionnels et techniques adéquats, mais elle sert également pour les tests de non-régression, pour lesquels il peut être important de disposer de l’historique des exigences.
Une intégration à la gestion des changements est également importante, celle-ci permettant de prévoir les futurs tests à mettre en place. Les grands éditeurs de solutions ont bien identifié ce besoin et proposent désormais des suites d’outils intégrés, conçus autour d’un référentiel unique.
Établir des priorités pour les tests à mener
En matière de tests, il faut renoncer d’emblée à l’exhaustivité : tout tester dans les moindres détails est rarement possible, mais surtout, cela n’a pas de sens dès lors que l’on se place dans une optique bénéfices/coûts.
En effet, il vaut mieux consacrer le gros de l’effort de test aux modules les plus stratégiques, sur lesquels le risque de non-qualité est le plus lourd, plutôt que de passer trop de temps sur des modules secondaires pour lesquels la portée d’un défaut sera bien moindre.
Toute la difficulté réside donc dans l’arbitrage préalable : il s’agit de définir sur quels modules devront se concentrer les efforts, ceux qui devront être couverts à 100 % par les tests tandis que d’autres peuvent supporter une couverture inférieure. Ainsi, les fonctions de paiement en ligne et l’ergonomie seront probablement plus sensibles pour un site de commerce électronique que le fait de gérer les dates d’anniversaire des clients.
Idéalement, cet arbitrage doit être mené par les maîtrises d’ouvrage. En effet, ces dernières sont les mieux à même de définir quelles sont les exigences prioritaires et quel est le niveau de risque lié aux différents besoins exprimés.
À défaut, il est utile de disposer dans les équipes de développement de profils possédant une double compétence métier afin d’effectuer cet arbitrage : il vaudra toujours mieux tester peu mais de manière pertinente que de disperser les efforts de test.
Penser à l’externalisation des tests
Un autre facteur expliquant parfois pourquoi certains tests ne sont pas effectués est le manque de ressources. Les tests de charge, en particulier, tombent souvent dans ce cas de figure : peu d’entreprises ont en effet les moyens d’aligner des dizaines de serveurs simplement pour simuler des centaines de milliers de connexions, même parmi les grands groupes.
En outre, le modèle économique classique pour les solutions de test de performance, avec des tarifs basés sur le nombre d’utilisateurs, représente vite des coûts importants. Dans ce cadre, le recours à des prestataires externes peut s’avérer utile pour les applications amenées à supporter une charge importante.
Des acteurs comme Scopteam proposent ainsi des services de test basés sur une plate-forme mutualisée, une façon de partager les coûts pour les clients. Les évolutions technologiques récentes apportées par le cloud computing (architecture dans laquelle les traitements sont distribués sur des serveurs distants en fonction des besoins) peuvent également fournir des réponses intéressantes.
Il devient possible grâce à ces nouvelles architectures de faire appel à des services distants pour simuler à la demande autant d’utilisateurs que nécessaire. Micro Focus a ainsi présenté récemment l’offre CloudBurst, basée sur ce principe. Gageons que si l’offre convainc, les autres acteurs vont rapidement s’aligner
Les quatre niveaux de test selon le CFTL
- Tests de composants : il s’agit de tester le fonctionnement d’un composant en l’exécutant de manière autonome. Ces tests sont également connus sous le terme de « tests unitaires » et leur objectif principal est la recherche d’anomalies.
- Tests d’intégration : il s’agit de tester les interactions entre différentes briques constituant l’application : interfaces, échanges de données, accès aux fichiers, etc.
- Tests système : il s’agit de tester l’ensemble de l’application, dans des conditions les plus proches possible de l’environnement de production.
- Tests d’acceptation : il s’agit de vérifier que l’application est conforme aux besoins et qu’elle peut être déployée. Ces tests sont également connus sous le terme de « recette » et sont généralement menés par les donneurs d’ordres.