L’état des lieux

Tout produit doit être testé pour être accepté en livraison. La spécification UML change la passation de certains tests, mais ne change pas la nature obligatoire des tests.

On teste tout ce qui est spécifié. Tester ce qui n’est pas spécifié revient à tester les besoins implicites : être en mesure de tester les besoins implicites suppose de partager la même culture métier que les futurs utilisateurs du produit.

Le cahier des charges du projet, exploitant toutes les possibilités d’analyse et de formalisation offertes par UML, vient d’être proposé à l’équipe (interne, externe) chargée de sa réalisation. La réalisation va conduire l’équipe à livrer un ou plusieurs livrables (un livrable global, ou plusieurs livrables si le cycle de production est itératif et/ou incrémental). Ce ou ces livrables devront être testés afin d’être recettés ; autrement dit, ils devront porter la preuve qu’ils fournissent les services attendus d’eux.

La qualité du cahier des charges résidera dans sa capacité à permettre la construction d’un produit conforme aux attentes, mais aussi à identifier et à réaliser les tests permettant l’acceptation de ce produit...

Les types fondamentaux de recettes

Selon les conventions les plus couramment admises, on distingue les familles de recettes suivantes :

la recette technique (encore appelée recette MOE, celle menée par l’équipe de réalisation) ;
la recette fonctionnelle (abus de langage pour désigner la recette métier) ;
la recette usine (tests menés par le commanditaire chez le réalisateur du produit) ;
la recette d’homologation (recette qui vérifie l’aptitude du produit à réaliser ce pour quoi il est fait, sur une longue période, en environnement de production grandeur réelle) ;
la recette de déploiement et de montée en charge ;
la recette non fonctionnelle (teste les exigences dites non fonctionnelles : performance, qualité, robustesse, maintenabilité, sécurité, portabilité, etc.) ;
la recette utilisateur (vérifie que le produit s’adapte bien au contexte de travail des utilisateurs).

Chaque participant au projet montre que le livrable qu’il produit est apte à rendre le service attendu (conforme à ses spécifications). Donc à tout niveau, on teste, on vérifie, on certifie : on apporte la preuve que la livraison correspond à ce qui est attendu par le commanditaire.

La recette technique désigne l’ensemble des tests menés...

La recette technique d’un produit spécifié en UML

UML impacte (et aide tout particulièrement) les tests unitaires et les tests d’assemblage.

Chez LOCA’ROYANS, le projet est géré en mode itératif et incrémental, c’est-à-dire que chaque cas d’utilisation est réalisé, testé et livré en trois fois :

réalisation, tests et livraison du scénario nominal ;
réalisation, tests et livraison des scénarios d’extension (les cas optionnels) ;
réalisation, tests et livraison des scénarios d’exception (les cas d’erreur).

Le comité de pilotage se prononce au vu des tests sur l’acceptation ou le refus de la livraison.

Lorsque chaque cas d’utilisation est confié intégralement au même développeur (ou à la même équipe du prestataire), on pourra considérer que les tests unitaires sont les tests des cas d’utilisation.

1. Les tests de cas d’utilisation

Ces tests sont menés par les développeurs en environnement de développement.

Ainsi, la mission d’un réalisateur (équipe ou développeur, interne ou sous-traitant) s’organisera autour des cas d’utilisation. Tester un cas d’utilisation nécessitera un environnement de test (y compris une base de données ad hoc) qui pourra être le même que l’environnement de développement.

Cette activité produit des fiches et des cas de tests. Une fiche de tests énumère les actions à mener par le testeur lorsque le cas d’utilisation est exécuté. Le « décalque » à partir de la description du cas d’utilisation est presque immédiat.

a. Le scénario de tests

Soit le cas d’utilisation simple suivant : référencer client.

Il comprend un scénario nominal et deux scénarios d’exception (d’erreur). Pour chaque scénario du cas d’utilisation, il convient de construire un scénario de tests.

Un scénario de tests est un ensemble de cas de tests, c’est-à-dire d’actions utilisateurs à vérifier.

P3 CU3 : RÉFÉRENCE CLIENT
LIENS AVEC AUTRES CAS D’UTILISATION
ÉTEND...

La priorisation des tests par les risques

Cette section est destinée à démontrer uniquement que l’analyse des risques portés par les fonctionnalités livrées permet d’optimiser la répartition des ressources des tests ; elle n’est pas consacrée spécifiquement à l’étude des risques.

L’équipe de tests est dans la situation où tous les cas de tests ne peuvent être exécutés. Il faut donc les choisir et en laisser de côté un certain nombre.

Comment choisir les cas de tests qui seront effectivement joués ? La réponse est : le choix est guidé par l’évaluation des risques induits.

Soit la situation suivante : le prestataire livre le cas d’utilisation P3CU3 référencer Client avec un compte rendu de tests révélant que le scénario nominal a été testé correctement, avec un bon résultat, mais le scénario exceptionnel « autorisation de la banque non accordée » n’a pas été testé. La raison invoquée est l’impossibilité d’établir une connexion entre la banque de LOCA’ROYANS et l’environnement de test.

Ce test nécessite une simulation de communication avec la banque, ainsi qu’une vérification que la connexion avec la banque permet la bonne prise en compte de sa réponse.

La première réaction est de se dire que la non-sécurisation de cette fonctionnalité nécessitera un test complet avant de lancer les tests d’assemblage. Néanmoins, ce test va consommer du temps qui sera pris sur d’autres...

Pour aller plus loin

La documentation UML ne traite pas de la recette des projets spécifiés dans ce langage. On est donc obligé de se rabattre sur des ouvrages traitant spécifiquement de la recette et d’adapter les pratiques conseillées au contexte UML.

Cela signifie-t-il que la discipline des tests reste indifférente à la méthode de conception du livrable et ne s’intéresse qu’à l’étude de conformité des résultats obtenus ?

En première approche, on peut répondre oui, mais ce serait faire l’impasse sur la qualité spécifiquement induite par telle ou telle architecture des produits logiciels. Par exemple, on pourrait s’attendre à ce que la maintenabilité d’un logiciel conçu par composants soit meilleure, et qu’à l’inverse un produit classiquement conçu offre de meilleures performances.

De cela, il faut tenir compte lorsqu’on élabore la stratégie de tests.

On pourra approfondir cette discipline des tests grâce à un ouvrage très accessible et complet d’Emmanuel Itié : Gestion des tests logiciels, ENI éditions.

Le Comité français des tests logiciels (CFTL, www.cftl.fr) est une association de professionnels spécialisés dans le test des logiciels et destinée à promouvoir...

Les impacts d'UML sur la recette d'un livrable