Industrialisation : tests et recette

Industrialisation : tests et recette
Support de formation INDUSTRIALISATION PPT SM-200 révision C INDUS6 –Tests Et Recette Octobre 2007

Objectifs de la session
Compléter le module INDUS0 par un approfondissement du domaine du test dans le cadre de la démarche d'industrialisation de la Service Line Atos Origin System Integration Présenter les standards et ressources associées (outils, guides, etc.) à la gestion des tests (QW5) Sensibiliser les équipes projets aux bonnes pratiques (y compris tests unitaires,..) Cette session : est destinée à tous les acteurs directement concernés par le domaine des tests donc aussi bien les collaborateurs impliqués dans des tests que ceux qui les pilotent (Chef de Projet, Responsable d'équipe) et a deux prérequis : une expérience minimum du domaine du test la session INDUS0 (présentation globale industrialisation) n'est pas une formation aux méthodes de test ni aux outils de test Dans le cadre du plan d'industrialisation lancé par Atos Origin, cette session est destinée aux personnes ayant une implication significative dans le domaine du test (conception, exécution, pilotage) Elle s'attache à décrire la méthodologie standard en soulignant les points généralement les plus sensibles Formation durée : 2 heures N’hésitez pas à m’interrompre QW5 = Quick Win 5

Sommaire Contexte / Généralités sur les tests Les exigences client
La stratégie et typologie des tests Environnement de test La Recette Organisation L’outillage de test Les indicateurs Le référentiel Zoom sur les tests unitaires Annexes : indicateurs INPx

Contexte Avant-vente M a n a g e m e n t d u p r o j e t Spécification
Étude générale Dossier de conception (le comment) Modèle de données Dossier de spécif. interfaces Prototypes Étude détaillée Composants testés Documents techniques Suivi tests unitaires Manuels Environ. d’intégr. Réalisation Solution conforme Suivi des tests d’intégr. et de valid. interne . Livraison Intégration & validation interne PV recette FFT instruites Corrections re-livraisons Recette Client Selon le contrat : Plan de déploiement Formations Environne-ment de production Mise en exploitation Bilan de Projet Clôture Avant-vente Dossier d’affaire Achats Équipe PPP - PQP Réunions lancement Lancement M a n a g e m e n t d u p r o j e t (planification, suivi, reporting, relation client, gestion équipe, etc.) Gestion des exigences Gestion de configuration et de documentation Assurance qualité Gestion des plates-formes Spécification Dossier de spécification (le quoi) Maquettes Stratégie et plan de tests Environt de dévt Conception Dossier de conception (le comment) Important : vocabulaire commun (capitalisation) possibilité de découpage en sous-phase. Spécification : Que faut-il faire? stratégie de test Réalisation : TU Vérifier la conformité (unitaire) des composants Intégration : assemblage du système (=> tests d’interfaces) Validation : tests des exigences validées autres noms : vérification usine, validation usine, recette interne Livraison : mise à disposition chez le client Recette : Acter la conformité du produit (Mise en exploitation / déploiement) Les cas de tests sont rédigés et/ou complétés en parallèle de la phase de réalisation (y compris leur valorisation). Les tests de performance font partie de l’étape « Intégration et Validation Interne » dans le schéma ci-dessus. Les Tests sont partout, dans toutes les phases du projet

Les tests, ces mal-aimés !
Les a priori Tester c’est chercher à détruire Les testeurs retardent la livraison Les testeurs sont des pinailleurs Personne ne sait plus tester Je suis un bon développeur donc mes logiciels sont sans bug En fait NON : c’est en fait construire la solution définitive. Le test est un projet qui suit son propre cycle de vie (stratégie, conception, réalisation, bilan et pilotage) NON : ils ne font que répercuter le retard déjà pris. Et il vaut mieux livrer en retard mais un produit de qualité. NON : ils ne font que trouver des défauts que le client ne ratera pas Le test est un Métier, qui nécessite des compétences spécifiques. On ne s’improvise pas testeur : il faut suivre les formations au métier du test. NON : Quel est le produit qui n’a aucun défaut ? Combattre les a priori sur les tests Voici ce que tout le monde dit (citer les a priori) En réponse : Tout le monde a le droit de faire des erreurs, surtout dans notre métier Le développeur (au sens large) travaille bien, mais il peut faire des erreurs Les tests font partie intégrante du travail Les clients sont souvent d’accord pour un décalage de livraison si l’argumentaire est objectif et si ce décalage est suffisamment anticipé. Personne ne sait plus tester : école d’ingénieur spécialisée en informatique recrutement

Or, les tests, c’est fondamental
La phase de tests représente une part prépondérante du développement de logiciel Tests internes (unitaires, intégration, validation) Tests externes (recette) : sous la responsabilité du Client La phase de tests internes est essentielle : Plus une erreur est découverte tôt moins elle coûte cher Moins il y a d’anomalies en recette, meilleure est notre image Des indicateurs de défauts résiduels (INPx) sont en place pour mesurer et améliorer la qualité des livrables Les Tests sont importants (en intérêt et en coût) On reste dans le domaine de l’artisanat : Donner un exemple Les clients changent d’avis comme de chemise Tests internes : Vérifions que ce que l’on a fait correspond bien à ce qui était prévu Tests externes : Le client s’approprie le logiciel. Il va vérifier que l’outil que l’on a fabriqué correspond à ce qu’il voulait vraiment. Les tests internes sont donc prépondérants. On a intérêt à trouver un maximum d’anomalies chez nous Confiance avec le client Industrialisation : On y gagne en productivité, les développeurs y gagnent en confort, en passant d’un projet à un autre. L’industrialisation de la pratique de test est nécessaire : Pour partager nos pratiques Pour reproduire nos pratiques Pour optimiser nos pratiques En tenant compte des exigences spécifiques de nos clients

Tests : positionnement global
Atos Origin Client Étude générale Etude détaillée Réalisation Intégration et Validation Recette provisoire Recette définitive Garantie Définition de la Stratégie de tests et du Plan de tests Mise à jour de la Stratégie de tests et du Plan de tests Codage/ paramétrage Tests unitaires Pré-intégration Cas de test et jeux d’essai Intégration Performances Non régression Validation interne Tests du client (contrôle usine) Recevabilité Recette techn. et fonctionnelle Tests client hors environnement de production - VABF - Installation dans environnement de production Usage réel en production - VSR - Garantie L I V R A S O N L'activité test est largement répartie tout au long du cycle de vie du projet. Pré Intégration : intégration de sous ensembles, utilisé dans le cadre de gros projets, de sous-traitance des développements… Lors de projets de TRA, la responsabilité et les activités d’Atos Origin peuvent s’étendre au périmètre des activités sous responsabilité du client dans le slide ci-dessus : la vision présentée ici est orientée Projet et TMA. Visite Check-list fin de phase d’Intégration : vue Indus  Intégration Revue de Phase / Pairs Revue de phase Revue de phase Revue de livraison BL signé PV de recette BL fourni PV de recette

Les principaux termes (1/4)
Définition Tests unitaires (TU) Un test unitaire -qu'on pourrait aussi appeler élémentaire- porte sur un élément fin et précis dont on veut vérifier le fonctionnement correct sur tel ou tel aspect. Cet élément peut être technique (fonction, méthode, comportement face à une situation donnée,…) ou fonctionnel (règles de gestion, règle de saisie,...). Tests d’intégration (TI) L’intégration est l’assemblage progressif des différents composants de la solution, en effectuant au fur et à mesure des tests pour vérifier le fonctionnement correct. D'où le nom de tests d'intégration. Tests de validation interne Ces tests permettent de vérifier la conformité de l’application aux spécifications fonctionnelles détaillées. Tests de non régression (TNR) Tests ayant pour objectif de vérifier que les modifications induites par la correction d’un ou plusieurs défauts (ou l'apport d'évolutions) n’ont pas eu pour effet d'introduire de nouvelles erreurs. Les tests préexistants (unitaires, d’intégration ou de validation) qui s’exécutaient sans lever de défauts, doivent toujours faire de même après les modifications. Tests de Performance Tests dont l'objectif est de contrôler que les performances de l’application ou de certains composants logiciels, sont conformes au seuil d’acceptation (niveau à atteindre pour obtenir une conclusion positive du test) Ce sont les principaux termes : il y a autant de termes en matière de recette que de clients ou presque. Ces termes font partie du glossaire général qu'on trouve dans le SMP (Cf. document WBS - Phases, activités, produits et modèles contenant la terminologie officielle – doc. Word : Vue Indus  Cycle de vie)

Définition Recevabilité Cette étape exécutée en début d'intégration ou de recette a pour but de s’assurer que la livraison installée permet le bon déroulement des campagnes prévues. Elle est réalisée à partir de quelques scénarios significatifs et sur une période très courte. Recette provisoire La phase de recette provisoire (aussi appelée VABF Vérification d'Aptitude Au Bon Fonctionnement) permet de s'assurer, par des tests techniques et fonctionnels, que les exigences convenues sont satisfaites, et que la fourniture est apte à démarrer chez le client une phase d'utilisation. A l'issue de cette phase il y a prononciation de la recette provisoire (sans ou avec réserve). Recette définitive La prononciation de la recette définitive est la dernière étape d'un processus de recette (équivalent à la prononciation de la VSR Vérification de Service régulier). Garantie A l’issue des étapes de Recette, le logiciel passe en garantie. C’est une période dont la durée et les obligations sont contractuelles. En général le contractant est tenu de réparer les défauts du logiciel, par rapport aux spécifications validées. La recevabilité est un mini test fait par le récipiendaire d’une livraison (ex : par le client avant d’être livré) Sa pratique permet de constater un niveau de fonctionnement minimum. Cela permet de confirmer l'engagement des moyens –souvent importants- de la recette

Définition Cas de tests Description d'un cas de fonctionnement que l’on peut vérifier. Il est de même nature qu'une spécification (technique ou fonctionnelle) mais ne décrit qu'une occurrence de comportement alors qu'une spécification est l'enveloppe de tous les comportements possibles. Fiche de Description de Test (FDT) Fiche permettant de décrire un cas de test en indiquant le contexte d’exécution (environnement, données en entrée), la description détaillée du cas de test et les résultats attendus en sortie. Fiche de Fait Technique (FFT) Signalisation formelle d'un défaut dans un livrable ou d'une autre difficulté (mise en œuvre, documentation, mauvaise interprétation,...). La FFT (Fiche de Fait Technique) sert à décrire un fait technique. Synonymes : RTA (Rapport Technique d'Anomalie), FO (Fiche d'Observation), AVP (Avis de Problème)... Scénarios de tests Un scénario de tests est un enchaînement de cas de tests prévus pour se dérouler les uns derrières les autres en une seule passe (sauf en cas de découverte d'anomalie allant à l'encontre de cet enchaînement), cohérent fonctionnellement et dont le résultat est un état stable du système. Ces termes sont utilisés pour décrire les tests et structurer entre eux.

Tests (pour révéler les défauts) Anomalie Erreur Défaut (dysfonctionnement, (humaine) défaillance) Mise au point (pour corriger Il faut s'efforcer d’utiliser le bon vocabulaire. Ne pas confondre les tests et la mise au point les erreurs)

Le CMMI et les tests Le modèle CMMI couvre les tests avec 3 domaines :
PI (Product Integration) VER (Verification) VAL (Validation) Le CMM formule des exigences bien compréhensibles : Se préparer à la vérification/intégration/validation Choisir les produits à vérifier-valider Définir la séquence d’intégration Assurer la compatibilité des interfaces Etablir l’environnement Établir les procédures et critères Vérifier / assembler / valider le produit ou les composants de produit Etablir les plans de tests Réaliser la vérification / intégration / validation Analyser les résultats PRODUCT INTEGRATION correspond à l’intégration La VERIFICATION consiste à s'assurer que la fourniture satisfait les exigences convenues (correspond à la validation interne). La VALIDATION permet de s'assurer que l'on a bien ce dont on avait besoin (correspond à la recette client) En règle générale (selon le contrat) la validation (au sens CMMI) est plutôt une activité du client (recette, phase pilote) Verification Although “verification” and “validation” at first seem quite similar in CMMI models, on closer inspection you can see that each addresses different issues. Verification confirms that work products properly reflect the requirements specified for them. In other words, verification ensures that “you built it right.” [FM114.HDA102.HDB121.T101] (ça marche) Validation Validation confirms that the product, as provided, will fulfill its intended use. In other words, validation ensures that “you built the right thing.” [FM114.HDA102.HDB122.T101] (ça répond au besoin exprimé)

Quoi tester …….. Ce schéma existe depuis plus de 20 ans et rien n’a changé. C’est un vrai régal. Le client : voilà ce que je veux Contrat : il n’est pas trop éloigné de ce que veut le client. Celui-ci ne s’est pas exprimé très clairement. Nous on a interprété. Il n’a pas forcément lu la proposition finale. Le cahier des charges est flou. Analyste : il faut aller vite. L’analyste qui va voir le client mais pas forcément le même que celui qui a rédigé le CDC. Il n’a pas forcément l’expérience nécessaire, il est pressé par les délais. Programmeur : pas péjoratif. Il s’est rapproché de la solution Etape de tests : cf. 1ers slides. Il trouve des bugs. Il n’a pas beaucoup de temps. Pb technique. On est à la bourre. Il faut trouver une solution. Prendre le temps de bien tester  cela n’est pas fait Recette finale : Que fallait-il tester ?? Grand fondamental industriel  recenser les exigences client. Commençons par identifier ce que voulait le client.

Il faut tester…ce qu’il fallait
Les exigences client Atos Origin doit collecter et clarifier le besoin client Comment identifier les exigences : Avec les éléments d’avant vente (contrat, proposition,…) Tout au long des spécifications Rédaction des spécifications par AO possible selon projet (AT / forfait) Relecture formelle des spécifications par AO / réunions … Exigences implicites : à proscrire => trace écrite en attendant la mise à jour de la spécification => voir procédé exigences (formation INDUS3) Les exigences client : il y a d’abord les éléments produits avant le démarrage du projet (cahier des charges, proposition) exigences implicites : évidences que l’on ne dit pas. Les utilisateurs n’ont pas été consultés en avant-vente. Mails : on a de tout  des détails insignifiants, des éléments fondamentaux. On a tous du mal à faire le tri par manque de temps, parce que trop de mails. Oral : Il faut alerter, remonter vers la hiérarchie  cela peut provoquer une demande de changement  cela génère du travail, donc de l’argent et au final le client est content (le produit répond à ses attentes). CMMI est très exigeant sur cet aspect, c’est une faiblesse de notre métier. Un chantier Exigences fait partie du référentiel. Il faut s’y référer.  Le nombre de fois où le Chef de Projet n’a pas le contrat de son projet!!!!

Il faut tester…comme demandé
Les contraintes client Norme externe applicable selon projet Eventuellement déclinée dans un plan client applicable à Atos Origin réduit la marge de manœuvre Atos Origin n’empêche pas d’être pro-actif pour conseiller le client sur la stratégie qu’il propose Les contraintes client : Importance de la force de proposition AO dans les choix de stratégie de test Une marge de manœuvre existe : à nous de proposer des choix efficaces pour atteindre les objectifs de vérification/validation.

Exigences / contraintes
Comment tester ? Exigences / contraintes Client Contraintes contractuelles Périmètre des tests Moyens Planning À valider avec le client Stratégie de tests AO Stratégie de test => Plan de Test (compromis entre l’idéal et les moyens) On a d’un coté les exigences client, de l’autre les contraintes contractuelles. Par moyens on entend moyens humains, techniques. Il faut concilier les deux (Les boites n’ont pas la même taille volontairement). Que faire? on augmente les moyens on diminue les exigences client. La mise en adéquation donne la stratégie de tests à faire valider par le client. Comme ça on est d’accord sur ce qui sera fait et ce qui ne sera pas fait. Cette stratégie fait partie d’un document que l’on appelle plan de tests. Selon la taille des projets on peut en faire 2 documents.  visite du modèle de stratégie de test (Vue Indus  Intégration) L’objectif n’est pas de réciter le guide mais de faire comprendre l’importance des tests et l’importance du recueil des exigences. Les deux sont intimement liés.

La stratégie de tests (1/3)
Définir le périmètre applicatif Définir les exclusions du périmètre Définir les phases et types de tests à effectuer Tests unitaires, d’intégration, de validation, de non régression, de performance , … Définir le taux de couverture de tests pour chaque phase Objectifs On n’est pas obligé d’exécuter toutes les étapes. Cela dépend des projets. Il est important de préciser que ce ne sont pas les outils qui permettent de faire de bons tests. C’est la stratégie. Comme disait ma grand-mère : « Il n’y a que les mauvais ouvriers qui ont de mauvais outils ».  visite du procédé tests et recette (Vue Indus  Validation Interne) Une bonne stratégie de tests et des mauvais outils feront quand même des bons tests, pas l’inverse !!

Définition du périmètre Quelles sont les fonctions, les interfaces que l’on va tester? NORMALEMENT TOUTES Parmi les fonctions testées, lesquelles sont testées dans leur globalité, partiellement, par quoi commence-t-on? Quels sont les éléments qui vont guider nos choix? La fonction est-elle très utilisée (de nombreux utilisateurs sont coincés) Si la fonction ne marche pas, quels sont les risques que cela provoque Risque humain (centrale nucléaire, aviation) Grosse perte financière Qualité du code produit (facteur technique et/ou humain) Exigences client La règle d’or : A = On teste tout. B= S'il pas possible ou raisonnable de tout tester, on le fait savoir clairement à son responsable Et quand on ne peut pas, il faut faire des choix. Ces choix sont souvent guidés par la gestion des risques. Il existe un guide tests et recette  le visiter (Vue Indus  Validation Interne)

Exemple de définition du périmètre Électricité d’une maison On va tester Que l’électricité est bien au compteur Que les lumières s’allument La lumière de l’entrée, des salles principales On ne va pas tester Que la centrale nucléaire fournit bien l’électricité Si la lumière de la cave ne marche pas, cela n’est pas trop grave, celle-ci n’est pas encore aménagée On a volontairement pris un exemple qui n’est pas du domaine informatique. La définition du périmètre est fondée à partir des exigences client et de nos faiblesses internes. On va tenir compte de l’expérience du développeur (s’il débute dans la techno).

Typologie des tests (1/6)
Les Tests Unitaires Rappel définition : Un test unitaire -qu'on pourrait aussi appeler élémentaire- porte sur un élément fin et précis dont on veut vérifier le fonctionnement correct sur tel ou tel aspect. Cet élément peut être technique (fonction, méthode, comportement face à une situation donnée,…) ou fonctionnel (règles de gestion, règle de saisie,...). Objectif des TU : Vérifier que le composant répond aux exigences de bas niveau décrites dans la conception, ou découlant de sa fonction Exemple : Toutes les prises de courant sont bien montées (Aucun fil nu qui subsiste ?) Le compteur électrique est connecté physiquement au réseau électrique Le postulat de départ est de faire les tests unitaires complets, c’est à dire que tous les composants doivent être testés et que pour chaque composant on vérifie que toutes les règles de gestion sont correctes, toutes les branches sont vérifiées. Pourquoi ? Parce que plus un test est fait tôt, plus une anomalie est détectée tôt, plus sa résolution est facile à faire (diagnostic plus simple à faire), moins le coût de résolution est élevé  Visiter la check-list d'aide à l'identification des tests unitaires (Vue Indus  Réalisation, tests unitaires)

Les Tests d’Intégration Rappel définition : L’intégration est l’assemblage progressif des différents composants de la solution. Objectif des TI : Vérifier que l’assemblage progressif des composants répond aux exigences de spécification ; vérifier les interfaces entre composants. On va aussi se poser la question de savoir : Le critère d’entrée en phase d’intégration s’il faut le faire en plusieurs étapes, une partie puis une autre, par quoi on commence (les composants les plus critiques, les plus utilisés) Le critère de sortie de phase d’intégration L’ordre dans lequel vont être exécutés les tests est fondamental. Il faut s’assurer que les cas les plus courants, les plus utilisés marchent. Cela représente souvent une grosse partie de l’application. Les autres cas devront être triés en fonction de critères donnés souvent par le client, à l’aide d’une matrice applicative par exemple. On va traiter les différentes fonctions en tenant compte d’une criticité, d’un facteur risque.  visiter le modèle de dossier d'intégration (Vue Indus  Intégration) Exemple : Vérifier que le courant est présent en sortie du tableau électrique (liaison réseau + compteur + câblage + disjoncteur + tableau électrique + prise).

Les Tests de validation interne Rappel définition : Test d’un système complet par rapport à sa spécification Objectif des TV : Vérifier la conformité du logiciel avec les exigences Client On va aussi se poser les questions suivantes : Critère d’entrée en phase de validation Choix du niveau de couverture fonctionnelle attendu Critère de sortie de phase de validation (itérations possibles selon anomalies résiduelles) Visite de la fiche de test : Vue Indus  Validation interne Exemple : On vérifie par l’utilisation de la machine à laver que le système électrique fonctionne.

Les Tests de non régression Rappel définition : Tests ayant pour objectif de vérifier que les modifications induites par la correction d’un ou plusieurs défauts (ou l'apport d'évolutions) n’ont pas eu pour effet d'introduire de nouvelles erreurs sur des fonctionnalités non modifiées. Les tests préexistants (unitaires, d’intégration ou de validation) qui s’exécutaient sans lever de défaut, doivent toujours faire de même après les modifications. En cas d’ajout ou de modification de composant(s) il faut vérifier que tout ce qui a pu être impacté de près ou de loin continue de fonctionner. On va aussi se poser la question (dès la stratégie de test) : Doit-on tout vérifier ? Ne doit-on vérifier que les composants en relation avec le composant modifié ? Vrai pour les tests de performance également. Choisir les tests qui doivent être exécutés suite à une modification en effectuant une étude d’impact. Il peut être décidé avec le client, que certaines fonctions seront systématiquement testées, après une modification de l’application, parce que le facteur risque est trop élevé. Parfois, il sera décidé que certains tests ne doivent pas être effectués, le coût est trop élevé en regard de la probabilité de survenance d’un problème. Exemple : Pose d’une ouverture/ fermeture électrique sur la porte du garage, vérifier que l‘on peut ouvrir en parallèle le portail à ouverture électrique et la porte du garage. L’électricité dans le garage continue de fonctionner. Ne pas vérifier la lumière de la cave (qui n’est pas sur le même fusible). Exemple : Après toute intervention, on choisit de tester une prise par pièce de la maison, un seul radiateur, l’alimentation du congélateur.

Les Tests de performance Rappel définition : Tests dont l'objectif est de contrôler que les performances de l’application ou de certains composants logiciels, sont conformes au seuil d’acceptation (défini par le Client sous forme d’exigence) Dans certains cas, il va être nécessaire de vérifier que le nouveau système répond à des contraintes de temps de réponse, différentes opérations par minute, durée du traitement ou de charge réseau (exigences client). Les tests de performance sont déclenchés au moyen de : Montées en charge (augmentation du nombre d’utilisateurs) Montées en stress (augmentation du volume des données) On pourra ajouter à ce moment là un mot sur les tests de robustesse s’ils sont spécifiés sous forme d’exigence, ce n’est plus de la robustesse mais des cas dégradés (fonctionnels ou techniques) S’ils ne sont pas spécifiés, il s’agit de tests « aléatoires » de type « test du singe » puisqu’on n’a pas d’objectif précis de vérification sinon d’essayer de planter l’application. Exemple : Faire un test aux limites avec le maximum d’appareils électriques branchés et en fonctionnement.

Les Tests opérationnels ou « de bout en bout » Rappel définition : Les tests opérationnels ont pour but de jouer en amont des phases de recette des scénarios assez complexes et faisant intervenir la plupart des fonctions du système testé. Objectif : détecter au plus tôt dans un contexte « réaliste » d’utilisation les défauts du logiciel. L’objectif des tests doit être défini avec le client. visite de la check-list d'aide à la revue du plan de test : Vue Indus  Contrôle qualité, revues par les pairs  Compte rendu de revue de plan de test Exemple : Mettre une famille en situation d’utilisation normale d’une maison durant une journée

Environnement de test Choix primordial :
Définir avec le client la représentativité de l’environnement de test (structure et contenu) Planifier la réalisation de bouchons / simulateurs / jeux de données Prévoir les ressources matérielles associées (plate-forme, réseau, serveur, …) => essayer de l’anticiper au maximum car potentiellement chemin critique de réalisation des tests A prévoir assez tôt, complexe et critique Les simulateurs sont souvent les parents pauvres en terme de planning mais peuvent devenir un point bloquant en phase de test. L’environnement de test disponible impacte fortement la préparation et l’exécution des campagnes. Ex : un environnement disposant d’un nombre de couloirs limité aura une influence sur la durée et la parallélisation possible des tests pendant les campagnes.

La Recette Définition : La recette est une suite d'opérations permettant de montrer qu'un produit, réalisé suivant un processus industriel défini et approuvé, est conforme aux spécifications détaillées validées par le client (vision Contrat) et répond aux exigences d'acceptation des utilisateurs (vision Métier). Cette étape est de la responsabilité du client et s’effectue généralement chez lui Elle est en principe bornée contractuellement (délais et critères) Le client peut mettre à disposition d’Atos Origin (fourniture client) un cahier de test de recette pour détecter de manière anticipée les anomalies de recette Démarre à la livraison du produit par Atos Origin Se concrétise par la signature du Procès Verbal de fin de Recette Garantie (ou passage en TMA) : est en général déclenchée à partir de la signature du Procès Verbal de fin de Recette Du point de vue d’Atos Origin, l’application livrée doit bien entendu être conforme aux Spécifiations Validées. Cependant, pour le client, la recette vise aussi à démontrer que l’application livrée couvre bien les besoins des utilisateurs. Dans le cas contraire, des évolutions seront demandées et à instruire. Les conditions de recette peuvent être très variables d'un client/contrat à un autre. Dans un cas complexe on peut successivement trouver : une vérification en nos locaux avant livraison (appelée recette usine) la livraison proprement dite la vérification de l'installabilité et de la recevabilité la phase de recette technique et fonctionnelle (VABF=Vérification d'Aptitude Au Bon Fonctionnement) la phase de recette définitive (VSR=Vérification de Service Régulier) la phase de garantie visiter procès verbal de recette : Vue INDUS  Livraison, installation, recette, formation  Recette  Procès verbal de recette

Organisation de l’équipe de tests
Les rôles : Chef de Projet de Test : porteur de la stratégie de test, estimation, planification, organisation de l’équipe de test, reporting client et interne, coordination des intervenants, arbitrage en accord avec le client et le DP/Chef de Projet Atos Origin Développeur : créer les Tests Unitaires, les exécuter, corriger les anomalies détectées Testeur : créer les autres types de tests, préparer les jeux d’essai, les exécuter, détecter des anomalies, valider les corrections d’anomalies Ne pas confondre Rôle et Personne qui remplit ce rôle

Organisation des tests
Planification des activités de tests : Préparation des tests (stratégie, spécification/conception et valorisation, définition du contenu des campagnes de test), Exécution des tests (passage des cas, analyse des écarts, faits techniques et validation des corrections), Bilan des tests (nombre de cas passés et statuts, bilan des faits techniques et liste des faits techniques résiduels). Enchaînement des phases de test : Lancement et suivi des phases de test et des critères de passage à la phase suivante (définis par la stratégie de test) Suivi de la détection des défauts et planification de leur prise en compte

Organisation du processus de tests
Demandes d’évolution, Bugs Spécifications / Exigences tech/fonc. Version d’application Livraison Recette Client Exigences Les concepts du processus de tests de validation Est vérifiée par … n Scénario / Plan de tests Est constituée de Campagne de tests Lien entre les évènements d’un projet et les outils. On retrouve en amont les grandes phases d’un projet. On retrouve en aval, les étapes du processus de tests. Donne lieu à n n Déroulement des tests Permet de constater Faits techniques

Bien se comprendre sur l'outillage de test
Outillage bureautique (Word, Excel) Administration des tests Cars (Compuware) (préconisé) Test Director – Quality Center (Mercury) Ne pas confondre E X C U T I O N Junit (tests unitaires) Open Source OpenSTA (performances) On évoque ici les produits de test de la gamme Mercury, mais les produits de l'éditeur Compuware présentent une différentiation analogue et sont préconisés au niveau de la Service Line Systems Integration Cf. D2I JEE Toolset – disponible dans le répertoire INDUS6 « Documents pour visite » : D2IJEEToolSetInitiative ppt Contacter DTO pour la mise en œuvre des outils de tests faisant l’objet d’un partenariat (Compuware + Mercury) … Automatisation des tests QuickTestPro Produits Mercury LoadRunner … TestPartner Produits Compuware … + TMX, file-aid, ETL ...

L’outillage "bureautique"
Plan de tests Livraison des corrections Référentiel de tests Campagne de tests Suivi des faits techniques Cas de test, scénarios Exigences On retrouve les étapes du processus de tests et les outils bureautiques associés Lors du déroulement des tests, en phase de tests unitaires, utiliser l’aide d’identification des tests unitaires On entend par outillage "bureautique" l'utilisation de Word et Excel (éventuellement PowerPoint et Access) Cf. templates de document dans Vue INDUS  Validation Interne Liste des cas de tests Fiche de Description de Tests (FDT) Fiche de Description des Scénarios (FDS) Liste/suivi des tests Suivi des scénarios de test Fiche de Fait Technique (FFT) Suivi des Fiches de Faits Techniques (T-FFT)

Outillage bureautique : description / suivi des tests
2 outils bureautiques utilisables pour décrire les tests La FDT Fiche de Description d’un cas de Tests : fiche de description de test complet, comprenant le contexte d’exécution (environnement, données en entrée), la description et les résultats attendus La FDS Fiche de Description de Scénario : description de la liste des cas de test à enchaîner comme un tout 2 outils bureautiques utilisables pour suivre l’exécution des tests La liste des cas de tests : c'est un tableau élémentaire avec la liste des cas de tests (résultats pour chaque test) L’outil de suivi des tests : c'est un outil de suivi de l'exécution des scénarios par phase, produisant automatiquement un certain nombre de graphiques d'avancement et de résultats A partir de la stratégie, on va élaborer, dès la phase de spécification un référentiel de tests, qui va être utilisé lors des différentes étapes de tests du projet. Cf. templates de document dans Vue INDUS  Validation Interne (si pas déjà vu slide précédent) :  visite de la Fiche de Description de Test (FDT)  visite de la Fiche de Description de Scenario (FDS)  visite de la "liste des cas de test"  visite de « l’outil suivi des tests »

L'outillage de gestion de tests Mercury/Compuware
Livraison des corrections Exigence de Tests Plan de tests Campagne de tests Suivi des faits techniques Mercury QC9.2/Test Director CPW CARS Référentiel des cas de test Le référentiel SMP contient 3 ressources liées à QC : un modèle pour initialiser l'outil un guide de prise en main de QC  le visiter un guide sur l'utilisation de QC Report Un serveur national (jetons + produit) à Sophia-Antipolis : Cf. DTO pour mise en œuvre. Pour les outils Compuware, la mise à jour du SMP est en cours. Mercury WinRunner, QuickTestPro, LoadRunner CPW TestPartner Automatisationdes tests

Exemple d’outillage intégré (1/2) Support outils à la Démarche
Rational Rose Référentiel Qualification Cars Référentiel Métier Référentiel Script Référentiel FTR/Cas de tests Produit Atos Matrice de criticité TMX ClearQuest Référentiel Gestion demandes Analyse d’impact / tests Produit Atos Scripts manuels Scripts robots Gestion des campagnes Reporting Robotisation Atos Scénarios Valoris. Robotis. Tests N.B. : l’exemple et l’outillage présentés concernent le projet Hélios (Division Secteur Public)

Exemple d’outillage intégré (2/2) Mise en œuvre
Initialisation du référentiel de tests Référentiel ROSE Extraction des Domaines, CU et Fonctionnalités Conception des cas de tests Évaluation de la couverture du risque Rédaction des scripts de tests CARS Master: Domaine, CU, Fonctions à tester Cas de tests Couverture du risque Scripts de tests Création des campagnes de tests Liste des fonctions à tester Liste des services Modifiés/Créés Demandes Calcul d ’impact Rose CARS Campagnes: Tests des Evolutons Tests de N-R Tests de recevabilité de la version Tests des Anomalies ClearQuest N.B. : l’exemple et l’outillage présentés concernent le projet Hélios (Division Secteur Public)

Choix de l’outillage de test (1/2)
Types d’outillage : outillage d’automatisation des tests (junit, scripts, makefile…) outillage de suivi d’exécution des tests : des évolutions et test associés des anomalies identifiées, corrigées, revalidées outillage de documentation du produit (la description des tests en fait partie) Critères de choix : nature des tests à effectuer (fonctionnels, performance, ...) type d’application (TR, batch, WEB, …) ; technologies mises en œuvre (C, Client/serveur, Java, …) du type de tests (TU, TI, TV, non régression, ..) pérennité de l’application (il n’est par exemple pas forcément utile d’investir dans les tests d’une application jetable) taille du projet exigences clients (performance, qualification, …). En début de projet le Plan de Production Projet (PPP) permet de fixer formellement la solution outillage de test adoptée par le projet, y compris avec sa justification (standard Atos Origin, demande client ou solution projet spécifique justifiée)

Choix de l’outillage de test (2/2)
Recommandation : Projets existants : les outils actuels sur les projets existants satisfont en général aux exigences  analyse d’écart par rapport aux outils préconisés  conservation des outils existants ou plan d’action approprié pour les faire évoluer Projets nouveaux : bien préciser dans le PPP la solution adoptée pour : l'exécution des tests automatiques la description des tests (c'est de la documentation du produit) la trace de l'exécution des tests, et les indicateurs qui en résultent Les choix standards : outils de la gamme Compuware outils de la gamme Mercury (si contrainte projet – compatibilité multisites par ex. – ou client) outillage bureautique (si taille critique non atteinte pour le projet) A propos des produits Mercury : Test Director et Quality Center 9.2 (QC9.2) sont des outils à iso-fonctionnalités QC9.2 est plus récent, écrit dans une autre technologie PPP = Plan de Production Projet : Cf. Vue Indus  Maîtrise de la qualité, plan qualité  Plan Qualité Projet  PPP (Plan de Production Projet)

FFT (Faits Techniques) / PV recette
2 outils bureautiques sont utilisables pour gérer les faits techniques : La FFT Fiche de Fait Technique : fiche permettant de décrire le dysfonctionnement éventuel lors d’un test, afin de permettre sa reproduction et son traitement T-FFT Tableau de suivi des FFT : document recensant toutes les Fiches de Fait Technique, leur état d’avancement et les tableaux récapitulatifs 1 outil préconisé pour la gestion des Faits Techniques : Mantis (open source) 1 outil utilisé en conclusion de recette : Procès verbal de recette : document contractuel signé par le client, actant la recette du logiciel livré (ou de l'une de ses phases) Cf. templates de document dans Vue INDUS  Validation Interne si pas déjà vu dans les slides précédents :  visiter la FFT  visiter T-FFT Une alternative recommandée à l'usage des FFT est l'utilisation du logiciel OpenSource Mantis. Cela suppose toutefois un accord avec le client sur la mode de signalisation par le client des anomalies. NB : Mantis permet également de traiter les demandes de changement (pour lesquelles l'outillage "bureautique" prévu est constitué de la FC Fiche de Changement) Citer pour mémoire les outils TrackRecord (Compuware) faisant partie de la suite d’outils acquise par la Service Line et Defect (Mercury). Citer également ClearQuest (Rational).

Organisation des outils bureautiques
Client Plan de tests Fiche de Changement Fiche de Description de Test Fiche de Description de Scénario Déroulement des tests Corrections (et changements) Recette & Garantie T-FC Suivi des FC Ce schéma représente l’organisation des outils bureautiques entre eux. PV de Recette Liste des cas de tests Suivi des scénarios de tests Fiche de Fait Technique T-FFT Suivi des FFT

Les indicateurs Standard : trois types d'indicateurs :
Indicateurs d'avancement de test de 0% à 100% en général par lot et/ou par phase Indicateurs de résultats de test non testé (ou à faire) non testable OK KO (échec) Par criticité / par lot et/ou par phase Indicateurs de défauts nombre brut défauts pour 100 hxj de projet défauts, pondérés suivant gravité, pour 100 hxj de projet Par gravité / par lot et/ou par phase Représentés graphiquement dans l'outil de suivi par phase Les indicateurs utilisés dans la maîtrise des tests sont assez naturels : il s'agit de comptages et de pourcentages. Pour le comptage des défauts, afin de tenir compte de la taille des projets, on ramène le nombre de défauts à 100 hxj de projet. Cela revient à dire qu'on s'attend à trouver deux fois moins de défauts dans un projet de 500 hxj que dans un projet de hxj Cf. PAMPA : Vue INDUS  Reporting de projet ou d'affaire  PAMPA  Point d'Avancement Mensuel Projet ou Affaire - Office 2000 Cf. BDP : Vue INDUS  Clôture, bilan (Projet)  BDP (Bilan De Projet) Les indicateurs présents dans l'outil Bilan De Projet (BDP) vont plus loin dans la mesure où : ils pondèrent différemment les défauts critiques, majeurs et mineurs ils différencient les différentes phases : INP7 pour la validation interne INP6 pour la période de recette INP5 pour les 6 mois suivant la prononciation de la recette provisoire Cf. présentation de ces indicateurs en slides « Annexe » de cette présentation. Pour aller plus loin sur les indicateurs, on pourra se reporter au référentiel où on trouve : la spécification de tous les indicateurs : SMP : rechercher « indicateur »  Le référentiel des mesures et indicateurs le guide d'analyse des indicateurs de production : SMP : rechercher « indicateur »  Guide d'analyse des indicateurs de production Dans PAMPA Dans bilan de projet (BDP)

Les ressources tests (ressources principales)
Rubrique Ressources Standard Procédé Tests et Recette Guide Guide Tests et Recette Prise en main de QC8 Utilisation de reports sous QC8 Démarche de test de charge (complément J2EE) Check-list pour aider à l'identification des tests unitaires Modèle Stratégie de tests Dossier d'intégration Compte-rendu de revue de plan de test - Check-list FDS : Fiche de Description de Scénario FDT : Fiche de Description de Test Liste des cas de tests Outil de suivi des tests FFT : Fiche de Fait Technique T-FFT : Tableau de suivi des Fiches de Faits Techniques Procès Verbal de Recette Modèle pour l'outil QC8 Présentation Support de formation Tests et Recette Outils et aides proposés dans le standard SMP N’hésitez pas à faire part de vos remarques pour améliorer ces documents.

Conclusion : attention au cercle vicieux
…… Ne vous laissez pas embarquer !…… Augmentation de la pression Je suis trop à la bourre Moins de temps pour écrire des tests Beaucoup de corrections à réaliser Code moins stable

La stratégie et typologie des tests Environnement de test La Recette Organisation L’outillage de test Les indicateurs Le référentiel Zoom sur les tests unitaires Annexes : indicateurs INPx 10.1 Pourquoi il faut des TU de qualité 10.2 Comment procéder, conseils 10.3 Responsabilité et suivi des TU 10.4 La pratique et les outils de relecture de code

10. Zoom sur les Tests Unitaires
10.1 Pourquoi il faut des TU de qualité 10.2 Comment procéder, conseils 10.3 Responsabilité et suivi des TU 10.4 La pratique et les outils de relecture de code

Définition des tests unitaires
Rappel : un test unitaire -qu'on pourrait aussi appeler élémentaire- porte sur un élément fin et précis dont on veut vérifier le fonctionnement correct sur tous ses aspects. (Une Classe, une méthode, une fonction C, un morceau de Shell ou de script, etc…) Les TU permettent au développeur de découvrir les erreurs et de les corriger au plus tôt, ce qui est plus efficace. On distingue : le tests des cas courants le tests des cas spéciaux (cas aux limites, cas d’erreur…) Ne pas confondre avec les tests d’intégration : même dans le cas ou c’est peut être toute l’application qui est présente, c’est bien l’élément précis considéré –et lui seul- qui reste l’objet du test unitaire. Attention, on pense toujours aux cas courants, ils ne représentent souvent que la face visible de l’Iceberg.

Les fondements à retenir
DETECTION : les erreurs sont trouvées plus facilement à un stade où leur détection est encore facile : les TU repérent des défauts qui ne sont détectables qu'avec beaucoup de difficultés aux étapes ultérieures du développement CORRECTION : plus une erreur est détectée tôt, moins il faut d’énergie pour la corriger. En général : au stade TU : quelques minutes au développeur à un stade ultérieur : des heures à débugger un petit rien, simplement parce qu'au moment où le bug a été généré, les tests unitaires n‘ont pas été bien faits CAS SPECIAUX : souvent plus nombreux que les cas courants. L'effort de TU doit particulièrement les adresser (les bugs risquent d'y être plus nombreux, et plus délicats à déceler après l’intégration)

Tests unitaires insuffisants : conséquences (au travers d’un cas réel)
Dérapage de charge (tests + correction) Coût supplémentaire Nombre d’anomalies anormalement élevé en phase de validation Beaucoup d’anomalies bloquantes Nécessité d’une passe de tests supplémentaire + de 60% d'échec sur la première passe de tests de validation interne Décalage de la date de livraison Révision tardive du planning Forte pression Insatisfaction du client Risque sur la qualité du produit livré

Démarche générale de test unitaire
Ecrire le code Concevoir les cas de test (préparer les résultats attendus) Effectuer les tests Corriger le code source Contrôler les résultats Etablir la liste des points à résoudre Développeur convaincu du fonctionnement correct

Quels environnements pour exécuter les TU ?
Deux approches valables Simulation externe : Outils du commerce/open (JUnit, autres) Outils maison (XbeanTest, autres) Développement spécifique, bouchon Environnement applicatif déjà + ou - intégré Attention aux risques de dispersion : Stabilité des composants Responsabilité des anomalies Ne pas confondre avec l’intégration Attention aux cas spéciaux difficiles à produire

Quelles méthodes pour conduire les TU ?
Complémentarité interne/externe Observation externe (boîte noire : je ne m'intéresse qu'aux résultats) Observation interne (boîte blanche : je regarde l'intérieur) Debugger Pour les tests boite blanche, précis, souple Permet toutes les manipulations, visualisation, step by step Pas toujours utilisable (environnement de dev, temps réel) Traces Facile à mettre en oeuvre Attention aux effets de bord Patch interne Attention le composant n’est plus intègre Permet de tester des cas très spéciaux

Conseils généraux pour les tests
L'ensemble des échantillons doit couvrir : les cas fonctionnels nominaux (les cas "droits") les valeurs particulières et valeurs à proximité des limites (en-dessous et au-dessus) les cas d'erreur Prendre en compte les événements ou actions qui provoquent la transition d'un état à un autre Bien vérifier les libérations de ressources (fréquente source de bugs difficiles à traquer) Procéder dans un ordre logique : le cas nominal avant les cas particuliers en cas d'héritage, démarrer le test par les super-classes etc. Ne pas oublier que des TU sont aussi nécessaires après des modifications

Conseils généraux pour la mise au point
Ne jamais négliger une anomalie aussi insignifiante qu'elle puisse paraître Re-tester après chaque correction : une correction peut créer un nouveau défaut Ne jamais corriger un défaut sans l'avoir complétement analysé et compris Si trop de défauts sont trouvés, il faut penser à réécrire Ne pas hésiter à faire intervenir un œil extérieur (car il n'est pas facile de voir ses propres erreurs sinon on n'en ferait pas)  Etre demandeur de revues de code

TU : responsabilités et suivi
Comportement général attendu du Chef de Projet fixe les dispositions en la matière pilote véritablement le domaine fait un suivi de l'avancement des TU (besoin de confiance dans l'exécution) organise et suit les revues de fin de phase + revues par les pairs liées au code et aux tests (entre autres) Comportement général attendu du développeur Application des directives du Chef de Projet Transparence Responsabilisation : doit être convaincu du fonctionnement correct des composants Respect budget et calendrier (ou alerter) Trois types de solutions de suivi possibles parmi d'autres : attributs des composants dans l'outil de gestion de configuration fiche de suivi des TU (ne pas confondre avec description des TU) attributs dans l'outil de gestion des exigences Ressource disponible : check-list d'aide à l'identification des TU

Pourquoi formaliser les TU ?
Formaliser = laisser une trace plus ou moins importante Intérêts d'une formalisation demandée par le Chef de Projet : donne visibilité aux acteurs de l'intégration et au Chef de Projet industrialise le processus (structure l'activité, est plus indépendant des individus) exploitation possible des résultats chiffrés pour améliorer le processus Possibilité de réutilisation et d’enrichissement progressif (en TMA par ex.) Inconvénients charge de travail ressentie plus élevée peut être un peu ressenti comme "administratif" Niveau de formalisation à adapter suivant contexte projet (budget, criticité, sécurité… Exemples : simple trace du passage, description des tests eux-mêmes, nombre de cas de test unitaires passé…

But des relectures de code
Déceler et corriger au plus tôt des défauts sans exécution de code Promouvoir et partager des bonnes pratiques de codage, et donc élever le niveau des individus et de l'équipe Apporter des réponses pour les défauts récurrents Identifier et éliminer mauvaises habitudes et autres dérives qui nuiront à la maintenance Bénéfices attendus : Avertisseur précoce (non respect spécif. ou normes de dévelop.) Actions correctives et préventives au bon moment (identification d'erreurs sur le code complexe) Apprentissage par l'expérience (formateur pour le relecteur comme pour l'auteur) Catalyseur pour le succès des projets (homogénéisation du code) On peut considérer que les relectures de code font partie dans une certaine mesure des tests (sans exécution de code). En effet elles permettent de trouver des bugs, et même souvent avec un bon rendement. Elles doivent donc logiquement faire partie de la stratégie de test : volumétrie cible (volume, pourcentage) critères de sélection du code relu

Deux types de relectures de code
1 Décidé par le développeur lui-même au fil de l'eau, en demandant au collègue sans formalisme ou trace demandé typiquement pour : vérifier qu'une solution tient la route lever un doute recueillir des idées d'amélioration voir ce qu'en pense le collègue qui a déjà fait un truc analogue… Usez et abusez, comme complément aux TU, pour garantir la qualité du code produit …. 2 Décidé (organisé) par le Chef de Projet (sous le nom de revue par les pairs) . dans le cadre plan de développement du projet (fixé au départ) . échantillons choisis selon critères comme : . code de complexité importante . production de développeurs peu expérimentés ou nouveaux sur le projet . fonctionnalité critique pour la solution … . traces attendues (FRC) pour voir résultat et piloter processus (et en mesurer le retour sur investissement) Les relectures de code sont vivement encouragées dans tous les cas. C'est un moyen de progrès important pour les collaborateurs, en plus bien sûr d'un moyen efficace de déceler des défauts ou imperfections. La pratique n° 2 est de type revue par les pairs (conformément au procédé du même nom). C'est pour cela que certaines règles sont à respecter, en particulier la production d'une trace sous la forme d'une FRC Fiche de Relecture de Code

Cas particulier des corrections d’anomalies
Dans le cas de corrections d’anomalies à faire en urgence, la relecture de code est : Moins coûteuse (car le volume de code modifié est souvent faible) Plus importante (car il n’est pas toujours possible d’avoir une forte couverture de tests de non-régression) Le rapport « qualité/prix » est donc optimum Il convient dans ce cas de faire une relecture : de type différentiel (comparer ancien code/nouveau code), axée sur la « détection de régression potentielle » (et non sur la validité de la correction elle-même)

Indicateurs de défauts : INP7, INP6, INP5
Début validation interne Présentation en recette Prononciation recette provisoire VALIDATION INTERNE RECETTE 6 MOIS SUIVANT LA RECETTE INP7 INP6 INP5 On ramène tout à 100 hxj pour rendre les projets comparables 100 INPx = (10B + 5M + I) x J B = Nombre d’anomalies BLOQUANTES M = Nombre d’anomalies MAJEURES I = Nombre d’anomalies MINEURES J = Charge en HxJ Charge totale réelle (ou estimée) Les indicateurs INPx représentent la qualité de notre fourniture Retour

Indicateurs de défauts : valeurs usuelles
INP7 INP6 INP5 Validation interne Recette provisoire 6 mois suivants 100 90 90 Valeurs types (usuelles) 80 Plage(s) pouvant être considérée comme normale(s) 70 60 50 50 40 35 Les données présentées proviennent de l’exploitation de 66 bilans de projet et maintenances réalisés de 2003 à 2006 sur 8 sites différents. Il a ainsi pu être déterminé la plage des valeurs usuelles pouvant donc être considérées comme normales pour un projet Le graphique représente ces valeurs les 3 indicateurs INP7, INP6 et INP5 Certaines valeurs mesurées sont anormales (voir slide 65 : nuage de points). 30 30 20 20 15 10 10 5 Retour

Historique des révisions
Nom Fonction Date Auteur V. Santy H. Masset Pilote “Tests et recette” DAQ 11/10/ /10/2007 Vérificateur(s) N. Pollet-Lemesle Resp. Référentiel Qualité 12/10/2007 Approbateur(s) P. Cogoluègnes Directeur Industrialisation Révision Date Modification Origine Auteur A Déc. 2005 Création SIROCO V. SANTY 2.0 Mar. 2007 Mise à jour pour le cycle de formation industrialisation de Telecom Ile de France (et pour la formation dans les autres divisions), par adaptation des supports standard SIROCO et des instanciations faites par les sites P. D'ERSU 3.0 Sep. 2007 Appropriation Secteur Public INDUS M. CRAYS H. MAZIOUD V. EBERHARDT C Oct. 2007 Mise en cohérence avec la charte graphique et le SMP DAQ V. Santy H. Masset

Industrialisation : tests et recette

Présentations similaires

Présentation au sujet: "Industrialisation : tests et recette"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Industrialisation : tests et recette

Présentations similaires

Présentation au sujet: "Industrialisation : tests et recette"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back