Tests - probablement la partie la plus sous-évaluée du développement d'applications

Pourquoi devrais-je vous payer pour tester votre propre travail ?

C'est une question que j'ai souvent entendue au fil des ans lorsque j'ai discuté des budgets de test avec les clients. Pour les non-initiés, cela ressemble à une question juste. Cependant, toute personne impliquée dans le développement de logiciels sait à quel point les tests peuvent être complexes et chronophages. Les tests sont, en fait, l'une des parties les plus importantes de tout projet de développement logiciel.

Une grande plate-forme de commerce électronique est une chose incroyablement complexe avec des millions de lignes de code, des gigaoctets de données et de nombreux points d'intégration. Il y a tellement de pièces mobiles interconnectées ; tellement de maillons dans la chaîne qu'il est très facile que quelque chose tourne mal. L'application sera utilisée de millions de façons différentes via une multitude de navigateurs sur de nombreux appareils de bureau et mobiles. Le projet de développement aura duré au moins 6 mois avec de nombreuses personnes différentes travaillant dessus. Le nombre de domaines et de scénarios qui pourraient être testés est presque illimité. C'est un miracle que quelque chose fonctionne !

Les tests peuvent être divisés en plusieurs domaines différents, mais chaque domaine de test est important à prendre en compte. Chaque projet est un peu différent; certains clients aiment s'occuper eux-mêmes d'une grande partie des tests, d'autres préfèrent les externaliser, tandis que d'autres s'attendent à ce que leur développeur s'occupe de tout. Les tests ne sont pas non plus une entité fixe ; vous pouvez faire beaucoup de tests et vous pouvez en faire un peu. Plus vous testez, plus vous réduisez les risques du projet, mais plus cela prendra du temps et plus cela coûtera cher.

Tests unitaires

Un test unitaire est un test qui teste de petites "unités" de code pour s'assurer qu'elles fonctionnent comme prévu. Par exemple, lorsqu'un formulaire est soumis, il doit enregistrer les détails saisis dans une table de base de données. Il s'agit d'un test autonome qui garantit spécifiquement, et uniquement, que l'unité fonctionne comme prévu. En utilisant une véritable méthodologie de développement pilotée par les tests, un développeur écrira d'abord un test avant de créer réellement un code afin que le code puisse être considéré comme terminé uniquement lorsque le test réussit. En pratique, les tests unitaires ne sont utilisés que sur certains domaines clés de l'application pour s'assurer que les fonctions principales fonctionnent comme prévu. Bien que les tests unitaires puissent réduire la probabilité de problèmes fonctionnels, ils peuvent également augmenter le temps de développement.

Test de fumée

Vous entendrez probablement beaucoup votre agence de développement parler des tests de fumée. Un test de fumée est un sous-ensemble pragmatique de scénarios de test qui couvrent les parcours et les fonctions clés de l'utilisateur tout au long de votre application. À tout le moins, votre développeur devrait effectuer des tests de fumée avant de vous remettre quoi que ce soit pour UAT.

Test de l'interface utilisateur

Les tests d'interface utilisateur (UI) peuvent être très complexes et chronophages. La vaste gamme d'appareils mobiles, de tablettes et d'ordinateurs de bureau, de systèmes d'exploitation et de navigateurs qui seront utilisés pour accéder à un site Web signifie qu'il est presque impossible de tester manuellement chaque combinaison de manière exhaustive. En raison du grand nombre de variations différentes qui doivent être couvertes, les tests d'interface utilisateur sont un candidat idéal pour les tests automatisés. Les outils de test automatisés sont capables de suivre un parcours scénarisé sur votre site Web et de tester si les résultats attendus sont atteints. Ils peuvent également enregistrer chaque trajet afin que chacun puisse être rejoué. Bien que cette méthode ne soit pas parfaite, elle peut réduire considérablement le nombre de problèmes majeurs d'interface utilisateur auxquels un site Web peut être confronté.

Certains services de test tiers tels que Bug Finders offrent un service de crowdsourcing où des centaines de testeurs humains indépendants du monde entier sont utilisés pour tester un site Web et sont payés lorsqu'ils trouvent un problème. Cette approche peut être un moyen relativement rentable de tester votre application sur des centaines de combinaisons appareil/plate-forme/navigateur. Il est normal qu'un cycle de test génère environ 200 problèmes. Le défi consiste souvent à catégoriser et à hiérarchiser les problèmes afin que vous concentriez vos ressources sur les problèmes les plus importants. Chaque site Web aura un arriéré constant de problèmes de bas niveau qui ne seront probablement jamais résolus.

Les tests de régression

Les tests de régression sont une partie extrêmement importante du développement en cours. Il est conçu pour tester si des modifications apportées à une partie de l'application ont causé un problème à une autre partie. Par exemple, une modification d'une fonction JavaScript utilisée pour valider le formulaire de contact pourrait potentiellement avoir un impact sur les formulaires utilisés lors du paiement. En raison de la nature complexe de toute plate-forme de commerce électronique, les problèmes de régression ne sont pas rares. Il est donc essentiel de concevoir un plan de test de régression solide pour garantir que l'expérience de vos utilisateurs ne soit pas affectée par ces problèmes.

UAT

Les tests d'acceptation des utilisateurs (UAT) sont une partie essentielle de tout projet de développement et impliquent que le client effectue des tests complets de bout en bout de la plate-forme avant sa mise en service. L'UAT est le processus que je vois le plus souvent sous-estimé. C'est aussi la partie d'un projet qui est la première à souffrir lorsque les délais sont serrés. Cependant, cela est susceptible d'entraîner un taux d'échec plus élevé. Pour toute nouvelle construction de site Web, nous vous conseillons de prévoir au moins 2 mois d'UAT. Votre site Web de commerce électronique n'est qu'une partie de votre activité commerciale et le processus de bout en bout impliquant la recherche, le paiement, la gestion des commandes, le paiement, l'expédition, le service client, les finances et toutes les autres parties de la chaîne doit être testé.

UAT est souvent confondu ou fusionné avec SIT (System Integration Testing) où vous testerez spécifiquement l'intégration entre plusieurs systèmes. SIT fait partie des tests de bout en bout qui garantissent que toutes les parties de la chaîne fonctionnent correctement ensemble.

Un bon UAT implique la création de cas de test et de plans de test. Ceux-ci prennent généralement la forme d'un ensemble de scripts (un script étant un ensemble de tâches à exécuter) qu'un testeur manuel exécutera et réussira ou échouera le test en fonction du résultat. Il n'est pas rare qu'un plan de test UAT de bout en bout inclue plus de 500 cas de test.

Le A dans UAT est l'une des raisons pour lesquelles il est si important. À la fin du processus UAT, vous serez généralement réputé avoir accepté l'application, il est donc important que vous l'ayez soigneusement testée pour vous assurer qu'elle fonctionne exactement comme vous l'attendiez. Cela ne signifie pas que les bogues non découverts ne seront pas sous garantie, mais s'il existe une fonctionnalité qui ne fonctionne pas comme prévu, cela doit être récupéré dans UAT. L'autre raison pour laquelle il est si important est qu'il s'agit de la dernière chance de détecter les problèmes avant qu'il ne soit mis en ligne. Tous les bugs et problèmes sont susceptibles d'avoir un impact négatif sur l'expérience utilisateur.

L'UAT demande beaucoup d'efforts de la part du client, ce qui est souvent sous-estimé. Certains clients utilisent des agences de test externes pour les soutenir pendant l'UAT, ce qui peut réduire considérablement les risques d'un projet où le client n'a pas la main-d'œuvre nécessaire pour mener à bien l'UAT.

Tests de sécurité

Je suis parfois très surpris de voir que certains détaillants ne prennent pas suffisamment au sérieux les tests de sécurité. Il n'est pas rare de constater que le détaillant ne sait pas quand il a effectué pour la dernière fois un test d'intrusion sur sa plate-forme Web. Ce sont généralement ceux qui n'ont pas encore été touchés par une cyberattaque (ou qui ne savent pas encore qu'ils ont été touchés). Dans le climat actuel où la cybercriminalité continue de croître en fréquence et en sophistication, et en particulier avec le RGPD à l'horizon en Europe, les tests de sécurité sont de plus en plus importants. Toutes les plates-formes Web de commerce électronique doivent être testées par un tiers spécialiste au moins une fois par an, mais idéalement deux fois par an. Il est également conseillé d'analyser régulièrement votre application à la recherche de vulnérabilités à l'aide d'un logiciel spécialisé tel que Nessus. Chez Envoy, nous avons tendance à analyser les plates-formes Web de nos clients sur une base hebdomadaire pour nous assurer que les vulnérabilités des applications sont détectées très rapidement. À tout le moins, vous devez effectuer des analyses de sécurité des applications avant chaque mise en production. Il ne sert à rien d'attendre 6 mois jusqu'au prochain test d'intrusion lorsque vous avez introduit une nouvelle vulnérabilité d'application.

Test de performance

Les tests de performance sont généralement utilisés pour déterminer le trafic, les demandes de pages, les utilisateurs simultanés et le volume de commandes que votre site Web peut gérer. C'est un processus plus difficile que vous ne pouvez l'imaginer car, pour tester avec précision, vous devez imiter le comportement de l'utilisateur réel et, comme vous le savez, les utilisateurs réels font beaucoup de choses différentes. Le mieux que vous puissiez faire est d'imiter vos principaux parcours d'utilisateurs tels que la recherche, l'ajout au panier et le paiement. Idéalement, vous souhaitez effectuer des tests de charge sur votre environnement de production plutôt que sur un environnement de test, car cela vous donnera une image beaucoup plus fidèle, mais cela risque également de mettre votre plate-forme hors ligne à un moment donné du test.

La plupart des détaillants ont tendance à effectuer des tests de charge une fois par an, normalement avant les périodes de pointe comme le Black Friday ou Noël. Le problème que cela peut causer est que, depuis le dernier test annuel, un grand nombre de modifications ont pu être apportées à l'application, dont certaines peuvent avoir eu un impact supplémentaire sur les performances. Si un test de charge annuel montre une baisse de performance par rapport à l'année précédente, il est très difficile de déterminer quel(s) changement(s) au cours de l'année écoulée ont contribué à cette baisse de performance. Cela peut également ne pas vous laisser suffisamment de temps pour résoudre les problèmes de performances avant le début des pics de trading.

Pour contrer cela, il est conseillé de réaliser des benchmarks de performance avant chaque nouvelle release de code. Ceux-ci n'ont pas besoin d'être effectués sur un environnement de production tant que chaque test est effectué sur le même environnement car l'objectif est de déterminer si les performances ont augmenté ou diminué par rapport à la dernière version. Cette approche permet aux équipes de développement de comprendre d'où proviennent les augmentations ou les diminutions de performances. Ceci, bien sûr, prend du temps et augmentera donc le temps et les coûts de développement

Bien que la liste ci-dessus ne soit pas exhaustive, vous pouvez voir que la portée des tests dans le cadre du développement logiciel peut être très vaste et complexe. Chaque type de test prend du temps et des efforts et vous ne devez pas simplement supposer que tout est fait en standard sans frais supplémentaires. Les entreprises fortement axées sur les tests alloueront jusqu'à 40 % du temps de tout projet aux tests, ce qui peut être une quantité très surprenante. De bons tests peuvent réduire les risques d'un projet et peuvent être rentabilisés à long terme, car ils se traduiront par moins de bugs, de meilleures performances et une meilleure expérience globale pour vos clients.