Le test manuel n’est pas mort !

On entend trop souvent que l’automatisation va supprimer les tests manuels, que ces derniers sont en voie de disparition et appartiennent à un ancien monde. L’automatisation seule suffirait à garantir un logiciel de bonne qualité. On parle même, avec certains outils, de tests d’acceptance automatisés !

Attention, le but de cet article n’est pas de dire que l’automatisation c’est mal. Le but de cet article c’est de montrer que les tests manuels sont toujours utiles et le seront encore pour longtemps (je préfère éviter de dire toujours, on ne sait jamais !).

L’automatisation est-elle suffisante pour atteindre la bonne qualité de l’application ?

Il est maintenant temps de se demander ce qui pousse certaines personnes à prédire la fin du test manuel et bien sûr expliquer les failles de ces raisonnements

• Lorsque l’on n’est pas dans le métier du test, il arrive souvent que l’on pense que les tests unitaires suffisent à tester un produit.

Si les tests unitaires suffisent tout peut être automatisé car les tests unitaires le sont. Malheureusement les tests unitaires ne suffisent pas, sinon il n’y aurait jamais eu de tests d’intégration, tests systèmes et tests d’acceptance.

• Avec déploiement continu tout est automatisé et va directement en production. Cela prouve bien que les tests manuels ne sont nécessaires.

A cet argument pertinent je me dois de répondre en plusieurs parties.

Tout d’abord la fonctionnalité avant d’être déployée en production est au moins testée sur l’environnement de développement afin de valider cette fonctionnalité. Les tests de validation sont généralement fait manuellement car n’étant pas ré-exécuté il coûterait trop cher de les automatiser

Il existe des systèmes de tests d’acceptance implémenté dans les entreprises maitrisant bien le déploiement continu comme Facebook. Dans le cas de Facebook, les fonctionnalités sont mises en service que pour certains usagers (généralement une zone géographique) avant d’être généralisées. Facebook parle même dans ce cas de phases de test.

• L’automatisation ne coûte quasiment rien comparé aux tests manuels

C’est bien évidemment faux. Ce qui ne coûte quasiment rien en automatisation, c’est l’exécution ! Toutes les phases d’écriture, d’analyse et de maintenabilité coûtent autant voire beaucoup plus.

D’un point de vue purement financier, on peut espérer un retour sur investissement pour des tests IHM après environ 8 itérations. Même si l’on s’améliore et que l’on passe à 4 itérations, les tests IHM qui ne seront exécutés qu’une seule fois coûteront moins cher à faire manuellement qu’à automatiser.

• Les outils utilisant le MBT peuvent générer tous les scénarios et même les automatiser

Sur le papier et avec une bonne utilisation des parcours utilisateurs, il est possible de générer des tests automatisés (avec du KDT donc compréhensible même par des fonctionnels !) et même de les maintenir. Malheureusement cela induit une maitrise parfaite de ces parcours et cela ne génère principalement que des cas auxquels on a pensé et que l’on a spécifiés. Aucune trace de test d’ergonomie, de ressenti ou de parcours non envisagés comme ce qui arrive tout le temps quand un logiciel est mis à disposition des utilisateurs.

L’apport des tests manuels :

Au-delà des limitations de l’automatisation les tests manuels permettent beaucoup de choses comme :

• Faire des campagnes de tests exploratoires afin de manipuler l’application et exécuter des scénarios non prévus à l’avance (un bon outil contre le paradoxe des pesticides).
• Très important pour les tests d’ergonomies. Un bouton caché peut être « cliqué » de façon automatique alors qu’il n’est pas vu par un utilisateur.
• De mon point de vue, les tests manuels sont indispensables pour les tests d’acceptance afin de connaitre les ressentis des (futurs) utilisateurs. Qui imaginerait une campagne de bêta test automatisé ?
• Les tests manuels restent importants pour les tests d’accessibilité (même s’il existe déjà quelques outils performants d’automatisation permettent de couvrir un large panel de ce point de vue)
• Les tests manuels sont un bon point d’entrée pour tout testeur afin de se familiariser avec le logiciel à tester et le connaitre. Cela leur permet de concevoir des tests plus pertinents.

Conclusion :

Le test manuel a encore de beaux jours devant lui, et ce même si l’automatisation devient de plus en plus importante. De ce point de vue on peut faire le parallèle entre l’industrie logicielle et l’industrie classique. Dans l’industrie classique, l’automatisation a supprimé de nombreux poste d’humains au profit de machines. Néanmoins il reste toujours des hommes dans ces usines, leur travail est juste différent et avec plus de plus-value. L’automatisation des tests permet donc de supprimer les phases avec le moins de valeur ajoutée (l’exécution des tests de régressions) afin de se concentrer sur les autres phases, non automatisables, qui ne sont pas automatisables (au moins pour le moment).

L’arrivée de l’Intelligence artificielle dans les tests permettra probablement d’automatiser encore plus de scénarios… Néanmoins, je ne pense pas que cela invalidera les arguments cités ci-dessus.

Autre article à ce sujet : https://m.signalvnoise.com/the-value-of-human-exploratory-testing-2dabcc371b3b

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles