top of page

Des Tests oui … mais lesquels ?



C’est une question qui m’est souvent posée : quels tests faut-il faire ? Il n’y a pas de réponse immédiate à cette question. En fait ce n’est pas la bonne question. La bonne question est de s’interroger sur les enjeux et les risques de la (ou des) application à mettre en production.

Doit-elle satisfaire à des obligations réglementaires, fiscales, sociales ? L’expérience utilisateur a-t-elle une importance particulière ? Y-a-t-il des enjeux sanitaires ou de sécurité ? Est-elle appelée à supporter de fortes charges ? C’est la réponse à ces questions qui dicte les tests à réaliser, quand les réaliser et dans quelles conditions. Pour y répondre vous devez commencer par établir une solide stratégie de test


Deux grandes familles de test


Selon les enjeux soulevés lors de l’élaboration de la stratégie vous pourrez recourir à différentes sortes de test. J’emploie ce terme « sorte de test » parce que la littérature dans ce domaine distingue « types de test » et « niveau de test » (voir cet article de la taverne du testeur). Même si ces distinctions sont intellectuellement cohérentes, elles restent cependant théoriques. Elles masquent une réalité de terrain. Certains types ou niveau de test sont spécifiques au processus de fabrication de l’application. D’autres types ou niveau de test sont complètement en dehors. Or ce ne sont ni les mêmes contextes ni les mes acteurs qui interviennent. C’est pourquoi je les classe dans deux familles distinctes.

Les tests du cycle de fabrication

Dans cette famille nous trouvons les tests unitaires et les tests d’intégration. Les premiers permettent aux développeurs de vérifier chacun des composants logiciels. Les seconds leur permettent de vérifier que ces composants dialoguent correctement entre eux. Ce sont des scripts de portée limitée développés par des codeurs qui n’ont pas nécessairement la culture testeur. Les directeurs de projet apprécient ces tests parce qu’ils sont automatisables et s’intègrent facilement dans la chaine d’industrialisation DevOps.

Les tests du cycle de qualification

Ils regroupent les tests fonctionnels, les tests d’acceptation, les tests de charge ou de performance. Le but de ces tests est de s’assurer :

  • Que l’application fonctionne correctement en situation réelle.

  • Qu’elle répond aux attentes des utilisateurs

  • Qu’elle satisfait les objectifs marketing et commerciaux de l’entreprise

  • Qu’elle respecte toutes des contraintes réglementaires, sanitaires, de sécurité, etc.

Contrairement aux tests de fabrication, ces tests nécessitent l’expertise du testeur. Celui-ci doit reprendre l’ensemble des éléments de la stratégie de test et les décliner en objectifs de test puis en cas de test. Les objectifs de tests vont préciser ce qu’il est important de vérifier, de contrôler. Les cas de test décriront la manière d’y parvenir. Ces tests sont souvent délaissés parce que généralement manuels. Ils sont aussi plus complexes à concevoir. Une autre raison pointée dans l’édition 2021 du World Quality Report est le manque d’outillage approprié.


La solution SCAPIN

La Plateforme de Qualification SCAPIN comble ce manque en mettant l’automatisation de tests fonctionnels à la portée de tous et notamment du testeur sans compétence en codage informatique. En effet les tests SCAPIN se consultent comme des storyboard. L'image accompagne l'histoire que raconte les tests. Votre donneur d’ordre voit et comprend ce qu’ils font. Cela change radicalement la donne. Vous êtes en mesure de proposer à votre client un PV de recette crédible. Avec l'option CCM (Certification de Conformité Métier) de SCAPIN vous lui épargnez l’obligation de tester ce que vous lui livrez.


13 vues0 commentaire

Comments


bottom of page