IT & Bank luxembourg

Le blog des techniques informatiques et bancaires au Luxembourg.

« | »

Le test fonctionnel pour les nuls.

oliotg | 31 mars, 2009 19:11

Type d’article : Bank 0%  IT 100%

 

L’activité du test fonctionnel est à la frontière entre le métier et L’IT, incluse entre les tests unitaires du programmeur et les tests métiers de la maîtrise d’ouvrage.

 

Les tests unitaires sont des tests « boites blanches » d’un module d’application, les tests fonctionnels sont des tests « boites noires » d’une application, les tests métiers sont des tests « boites noires » d’un processus et donc de plusieurs applications.

 

Le point d’entrée du travail du testeur fonctionnel est la documentation des exigences fonctionnelles. La première tâche consiste à rédiger les cas de test. Il faut recenser les exigences fonctionnelles et pour chacune  prévoir le ou les cas de tests qui permettent de garantir la conformité du logiciel. Il s’agit d’être astucieux en créant les cas les plus simples possibles tout en étant exhaustif.

 

Une fois les cas définis, il s’agit de les enchaîner sous forme de scénario. L’ordre d’exécution ne doit pas être laissé au hasard. Une bonne pratique consiste à estimer le niveau de risque des cas de test et de commencer quand c’est possible par les plus risqués. Ainsi on peut augmenter la probabilité que les bugs les plus graves soient trouvés en début de campagne de test, ce qui laissera plus de temps pour les corriger. Il est également utile d’estimer la complexité des cas de test car cela permet de suivre plus finement l’avancement des campagnes de test.

 

L’étape suivante est la préparation des tests. Pour chaque cas il s’agit de préparer les données de test. Deux solutions sont possibles, soit identifier des données existantes soit construire des données sur mesure. La première approche qui est la plus simple est conseillée. Malheureusement il arrive que les données n’existent pas, par exemple pour un tout nouveau système ou quand il s’agit de tester un cas très particulier. La préparation des tests inclut la réalisation d’outillage de test. Les tests fonctionnels se limitant à une seule application il est souvent nécessaire de simuler la présence d’application amont ou aval. Pour réaliser ces outils le testeur fonctionnel doit le plus souvent faire appel à un programmeur.

 

L’étape suivante est l’exécution des tests. Chaque cas est exécuté si possible dans l’ordre défini par les scénarios avec les données et les outils préparés aux étapes précédentes. Quand un résultat n’est pas conforme aux exigences, le testeur en informe l’équipe de développement qui confirme le bug ou remet en cause la pertinence du cas de test. Le testeur doit donner les informations les plus précises possibles au programmeur pour l’aider dans son diagnostique. S’il s’agit d’un bug, une nouvelle version du programme doit être livrée et testée. Un processus clair de suivi des bugs et corrections est indispensable. Régulièrement le testeur fonctionnel rend compte de l’avancement de ses tests. Le nombre de cas de test exécuté pondéré par leur complexité est un bon indicateur d’avancement.

 

Un bon testeur fonctionnel doit être rigoureux pour ne rien laisser passer, astucieux pour trouver les cas de test les plus simples, patient quand rien ne marche, diplomate pour signaler les bugs sans agresser les programmeurs et disponible quand il s’agit de donner un coup de collier à quelques jours de la mise en production. Une bonne connaissance de l’application à tester est un grand atout et du bon sens est indispensable.

 

consultante

 

Quelques conseils pour un testeur fonctionnel :

  • Avant toute chose, il faut réclamer des documents d’exigence fonctionnelle (ou en rédiger).
  • Ne pas négliger la phase de préparation pour utiliser la phase d’exécution des tests à tester réellement (La phase de préparation n'est pas sur le chemin critique du projet alors que l'exécution oui).
  • 33% de l’effort sur la rédaction des cas de test, 33% sur la préparation, 33% sur l’exécution est un bon ordre de grandeur pour la repartission de la charge.
  • Lors de la planification d’une campagne il est sage de prévoir une durée et des ressources pour exécuter plusieurs fois tous les cas de test. En effet, certains bugs peuvent bloquer l’exécution des tests pendant de longue période, ou la livraison successive de corrections nécessiter d’exécuter plusieurs fois les même cas.
  • Soyez courtois avec le programmeur même si rien ne marche.
  • Soyez inflexible sur le respect des exigences fonctionnelles, c’est votre raison d’être. Si une exigence n’est pas respectable alors il faut négocier son amendement mais ne pas cacher une non-conformité.
  • Gardez autant que possible des preuves de vos tests (par exemple des print screen), car il se trouvera toujours quelqu’un pour vous reprocher de ne pas les avoir exécuté correctement.

Gwenaël Oliot

 

Article sur les tests unitaires: http://oliotg.blog.lu/post/553/2619

IT , Management :: Commenter (0) :: Rétroliens (0) :: printview

Commentaires

Commenter
 authimage
 
Accessible and Valid XHTML 1.0 Strict and CSS
www.blog.lu | Hosted by www.netline.lu