Le bon dosage entre trop et trop peu de tests logiciels

Les tests logiciels détectent les problèmes avant qu’ils n’apparaissent en production, et prouvent que les fonctions font ce qu’elles doivent faire. Ce qui compte, ce n’est pas le nombre de tests, mais leur sélection : une série de tests qui ne couvre rien de critique pour l’activité coûte du temps sans apporter de sécurité.

Quatre types de tests et leur utilité

Les méthodes courantes se répartissent en quatre classes. Chacune a un objectif différent, elles ne se remplacent pas les unes les autres.

Tests unitaires et tests de modules

Ils vérifient en détail les fonctions d’un composant isolé. Les routines de test sont généralement écrites pendant le développement du module, avant qu’il ne soit intégré au système global ou mis en ligne. Dans le développement agile, elles font partie intégrante de la réalisation : la qualité d’un module est ainsi établie avant son déploiement.

Tests d’intégration

Ils vérifient si les composants d’un système fonctionnent bien ensemble, en premier lieu les interfaces. L’échange de données avec les systèmes connectés se déroule-t-il sans erreur ? Cette question gagne en importance à mesure que des systèmes se greffent sur une plateforme. Un test d’intégration se compose donc généralement de toute une série de séquences de test. Ces tests montrent aussi très tôt dans quelle mesure une nouvelle solution s’intègre dans le paysage existant.

Smoke tests

Ils contrôlent si des fonctions et des services sont bien présents et accessibles. Deux moments sont pertinents : avant la mise en production d’une nouvelle application, pour vérifier une dernière fois la disponibilité de l’ensemble de la plateforme, et pendant l’exploitation courante. Si un composant sur le serveur ou un script externe tombe en panne sans que personne ne s’en aperçoive, une fonction disparaît sans que la page ait l’air cassée. Pour les exécutions automatisées, nous utilisons Ghost Inspector, qui fait par ailleurs partie de notre stack technologique.

Tests manuels

La variante la plus coûteuse en effort, et la seule qui montre comment une application s’utilise réellement. C’est là que ressortent des déroulements techniquement corrects, mais compliqués ou illogiques. Les tests manuels sont donc surtout un outil pour l’UX et l’UI, moins pour prouver le bon fonctionnement.

Le bon mix dépend du projet

Combien de tests suffisent ? À notre avis, cela dépend fortement du projet. Un projet de site web compte généralement beaucoup moins de fonctions qu’une application web qui reproduit des processus métier entiers, et nécessite donc moins d’automatisation des tests et moins d’effort de développement pour les tests.

Le garde-fou reste le même : tous les déroulements critiques pour l’activité doivent être sécurisés. Le panier d’une boutique en ligne doit fonctionner, sinon le chiffre d’affaires se perd directement. Pour ce type de règles, nous écrivons des tests unitaires ou des tests Behat.

Les tests Behat décrivent un scénario en langage courant avant qu’une ligne de code de test ne soit écrite, selon le schéma « Étant donné », « Quand », « Alors ». Ainsi, même sans formation en développement, on peut lire ce qu’un test sécurise réellement.

Comme les déroulements critiques pour l’activité diffèrent d’un projet à l’autre, les tests existants peuvent rarement être réutilisés tels quels. Les réécrire, en revanche, va vite, ce qui maintient l’effort par projet dans des limites raisonnables.

Ce que les tests apportent concrètement

Mettre en service une nouvelle plateforme sans tests est risqué dans des environnements informatiques interconnectés : si un seul composant ne fonctionne pas comme prévu, il entraîne toute une série d’autres processus avec lui. Les bénéfices se situent donc à plusieurs niveaux :

• Assurance qualité. Une stratégie de test ciblée couvre un large éventail de problèmes avant qu’ils n’atteignent l’exploitation productive.
• Contrôle des fonctions. Des exécutions automatisées vérifient à haute fréquence si les déroulements configurés sont disponibles.
• Meilleure ergonomie. Les tests manuels révèlent des faiblesses de l’UI et de l’UX qu’aucun test automatisé ne détecte.
• Rentabilité. Une fois mise en place, une série de tests automatisés ne demande presque plus d’effort et peut tourner aussi souvent que nécessaire.

Comment nous vous impliquons

L’objectif n’est pas de tester le plus possible, mais de choisir les bons tests pour le résultat souhaité. Nous définissons avec vous lesquels : pour les applications métier, personne ne connaît les exigences mieux que vous.

Pour cela, nous mettons à votre disposition un environnement de test dédié, dans lequel vous pouvez vérifier par vous-même. La phase de développement se termine avec le procès-verbal de test et de recette.

Le mix que nous utilisons dans nos propres plateformes est présenté dans l’article suivant.