Tutorial : bien utiliser le testing manuel et le testing automatisé

Dans l’IT, les phases de tests peuvent être de différentes natures : l’œil humain sert bien souvent 
à vérifier et essayer lignes de code, logiciels ou système, à travers des tests manuels, quand les tests 
automatisés viennent analyser les fonctionnalités de manière « préconçue ». Différents, mais complémentaires, 
ces deux processus peuvent s’associer, côté back-office. 

TUTORIAL

Étape 1 : connaître les différences entre le testing manuel et le testing automatisé

En informatique, on parle de testing manuel dès lors que le test d’un logiciel, d’un module ou d’un système est réalisé par un humain qui imite le comportement de l’utilisateur final. De cette façon, en suivant des scénarios d’utilisation et en évaluant différentes possibilités, le testeur peut chercher les bugs, les pistes d’amélioration et d’éventuels problèmes de scalabilité ou de performance. Dans le domaine du développement de logiciels, cette phase est devenue un métier : les « testeurs QA » sont chargés du suivi de qualité d’une application avant commercialisation ou mises à jour.

D’invention plus récente, le testing automatisé remplace l’humain sur des vérifications de fonctionnalités et de performance à l’aide de scripts. Pour ce faire, un développeur préconçoit des scénarios d’utilisation du logiciel, et décrit des cas d’itération où l’application va être utilisée plusieurs fois dans différentes configurations. Pour les cas nécessitant des répétitions fréquentes de tests, il s’agit de la méthode idéale.

On applique donc davantage le testing humain sur des projets nécessitant des vérifications ponctuelles ou l’analyse d’une interface, et le testing automatisé pour les aspects « répétitifs » des fonctionnalités à analyser. Ces différences expliquent que l’on emploie fréquemment les deux types de test sur un même projet, mais sur des parties différentes : dans un logiciel de trading, les testeurs manuels explorent l’UX et l’UI, les scénarios complexes d’utilisation des fonctionnalités, tandis que les scripts de tests automatiques analysent les performances, la conformité des algorithmes et la sécurité du code employé pour les fonctions métier.

Étape 2 : mettre en place une politique de Testing

Suivant le mode de développement choisi pour un projet, les tests manuels et automatisés sont placés à différentes étapes.

Dans le cas d’un développement en « cascade », la conception démarre avec une ébauche humaine des fonctionnalités à tester et la création de scénarios détaillés. Au moment du développement proprement dit, les codeurs peuvent créer un environnement de test qui servira ensuite à l’exécution de tests automatisés : ceux-ci sont réalisés sur les premières versions des logiciels, avec des tests unitaires de composants critiques, des tests d’intégration, et enfin des stress tests et des essais de montée en charge. Enfin, le test manuel reprend ses droits lorsqu’il ne reste plus que l’UI et l’UX à analyser.

Lorsqu’une philosophie de développement de type DevOps/intégration et déploiement continus est adoptée, les tests sont généralisés à quasiment chaque étape (on parle d’ailleurs de CT, « continuous testing » pour résumer cette approche). Si les tests manuels sont réalisés en parallèle du développement et de la mise en production comme en modèle cascade, les tests automatisés sont multipliés et réitérés à chaque étape, puis bouclés en fonction des retours : les scripts sont donc optimisés et les tests affinés.

Étape 3 : choisir les outils de testing adaptés 

Le marché de l’IT a vu le nombre de frameworks de testing automatisé augmenter au fil du temps. Et chacune d’entre elles s’adapte à des aspects spécifiques des applications à tester. Dans les environnements avec une interface web, on utilise ainsi de manière préférentielle Selenium, tandis que Ranorex peut s’adapter à des logiciels desktop en élaborant des scénarios dédiés à différents objets. Enfin, Tricentis Tosca permet de déployer des tests basés sur les risques (« risk-based testing ») ou d’appliquer des modèles spécifiques.

Étape 4 : adapter les tests à un domaine 

Pour prendre l’exemple d’un back-office dans la finance (banque, fonds), la qualité logicielle est associée à une conformité comptable absolue dès lors que des ordres d’investissement ou des mouvements de fonds, le management des risques sont rendus possibles par une application métier.

Dans ce type d’entreprise, des solutions de tests automatisés vont être dévolues à différents aspects d’une nouvelle application : on utilisera Selenium pour le reporting web du trading, Ranorex pour les applis desktop de back-office financier (bouton par bouton, fonction par fonction), Tricentis Tosca dans les processus métier nécessitant l’application de règlements spéciaux de conformité financière… Les scripts permettent ainsi de vérifier que chaque transaction ou écriture comptable remonte au bon endroit et que les effets soient pris en compte sur le système gérant la conformité bancaire (typiquement l’impact des transactions d’une journée sur le ratio bilan/hors bilan d’une société d’investissement) à travers un test de l’agrégation de données, un autre des algorithmes de calcul de positions ou encore une analyse des rapports réglementaires générés automatiquement par la solution de trading. Comptabilité oblige, des tests de « réconciliation » par le biais de solutions de testing automatisé permettent de vérifier, en dernière instance, qu’il n’y a pas d’écart entre différentes bases de données.

Les analyses automatisées de ce type d’applis font ensuite l’objet de tests manuels sur les aspects explorés préalablement : les spécialistes de la qualité logicielle ont à chercher la pertinence des workflows et à élaborer des scénarios complexes, de manière à avoir une vue plus précise des tenants et des aboutissants de chaque fonctionnalité d’un logiciel de back-office.

Tests automatisés et manuels cohabitent donc dans ce type de secteurs où l’on a à la fois besoin d’analyse récurrente de la part de la machine et de l’œil d’experts qui vont détecter les phases critiques et les besoins opérationnels d’un logiciel. Et les développeurs de garder en tête le testing au moment d’élaborer leur projet !

Rejoins-nous !