TOY Stratégie de TNR TOY

Présentation au sujet: "TOY Stratégie de TNR TOY"— Transcription de la présentation:

1 TOY Stratégie de TNR TOY
Nom Giacopelli Vincent Date 02/04/2013

2 Sommaire Objectifs Activités TNR dans TOY Planning
projet à moyen terme projet 2013 Environnement et organisation Outils Analyse de risque TOY Du prototype De la fabrication Stratégie TNR sur prototype TNR sur générateurs Suivi et cadrage

3 Objectifs L’objectif est de mettre en place un patrimoine de tests de non régression pour assurer la qualité TOY des versions mineures correctives et des versions majeures sur les périmètres suivants : Prototype Modèles de fabrications (# Générateur) Contexte : Versions majeures tous les trimestres Versions mineures hebdomadaires ou bi-mensuelles Déploiement sur des VM (1 par type de projet) Enjeux Déploiement de l’outil au niveau CGI monde

4 Code généré pour la mécanique standard (80%)
Activités TNR dans TOY Conception métier avec l’outil de prototypage + Définition des règles métier spécifiques Développement des modèles de fabrication pour la technologie cible (Java, .NET, iOS, Android, …) Prototype Modèle de fabrication Application complète Fabrication Code généré pour la mécanique standard (80%) Modèle de fabrication Modèle de fabrication Androiid TNR Modèle de fabrication iOS Modèle de fabrication .Net Modèle de fabrication Java Code développé (20%) Développement règles métier spécifiques TNR

5 Planning Projet à moyen terme
2011 Oct 2012 Oct 2013 Oct 2014 Oct TOY release 1.0 (July 2012) Initial release (Java environment) V2.0 : Mobile environments (iOS + Android) Prototyper and User Interface enhancements, Assistant V2.1 : .NET models V2.2 : Spring / Hibernate Java models TOY release 2.0 (1st January 2013) TOY Product Roadmap Workflow integration Protototype worklow processing Prototype business organizational structures Workflow models for external processors TOY release 3.0 (1st January 2014) TOY release 4.0 ( 1st January 2015) Rule engine integration : Prototype advanced business rules processsing Models for Rule server engines (JRULES, DROOLS) Launch of TOY Center TOY Center Business Support TOY Center extension Hosting for other countries

6 Planning Version 2013 TOY Product Roadmap TOY Layer .Net ASP
Avril 2013 Juillet 2013 Octobre 2013 Décembre 2013 TOY 2.1.0 2.2.0 2.3.0 Layer .Net ASP Layer .Net WPF 1.0.0 1.2.0 1.1.0 Layer .DLL 1.3.0 Layer DOC Layer .iOS Layer JPA Layer JSF2 1.4.0 1 2 Version majeure Version mineure 3 1.5.0 Layer SQL TOY Product Roadmap Demander confirmation des jalons, de la fréquence et du contenu Redéploiement de l’ensemble sur toutes les versions mineures.

7 Gestion des versions Version majeure : 2.x.0 (prototype) 1.x.0 (layer) Fréquence : Tous les 2 ou 3 mois Contenu : Version du prototype (évolution et correctifs) Versions sur les générateurs déjà implémentés (évolutions et correctifs de layer) Version pour un nouveau layer Les TNR sont à exécuter sur le prototype et sur les layer déjà implémentés Version mineure : 2.2.x (prototype) 1.1.x (layer) Fréquence : Hebdomadaire ou bimensuelle Version du prototype (mais pas obligatoire, correctifs ou évolutifs) Version sur des générateurs existants (mais pas obligatoire, correctifs et évolutifs) Les TNR sont à exécuter sur le prototype et/ou sur les layer Oui sur les évolutions  Concentrer les évolutions et correction sur les versions majeures  Réduire les versions mineures aux correctifs et évolutifs urgents (fréquence à réduire ?)  Effectuer des TNR exhaustifs sur les versions majeures. Réduire le risque de régression sur les versions mineures.

8 Environnements et Organisation
Utilisateurs : Demande de correctifs ou d’évolutions par ticket sous Mantis Développement : Equipe Toy Lab Poste de travail Développeur Référentiel source hébergé sur la forge (SVN) Tests : Test unitaire fait sur le poste de développement Tests d’intégration et de non régression à faire sur la VM de tests (Nouveau) Déploiement : Equipe Toy Lab Serveur centralisé 1 VM de test puis 4 VM de Production (1 VM par projet) Demande de modification Bug et évolution Déploiement Développement sur le Prototype Tests de non régression Développement sur les générateurs Test d’intégration Test unitaire Utilisateurs TOY TOY Lab Equipe Test

9 Comparaison de fichier de codes sources
Outils PIC Intégration des modules développés sur chaque PC par Hudson Tests manuels Outil ALM (Connect) Tests automatiques : Jtest : Automatisation des TU (Junit), revue de code Selenium : Automatisation des tests fonctionnels QTP : Automatisation des tests fonctionnels, suite HPQC (connect) Proposition d’un POC pour le choix de l’outil Comparaison de fichier de codes sources JAVA: codes source java(J2EE) : Comparaison du code généré (Vn et Vn+1) par WINDIFF ou éclipse. .Net : se base sur plusieurs technologies (Visual studio). Comparaison du code généré (Vn et Vn+1) par WINDIFF ANDROID : un système d’exploitation fondé sur un noyau Linux, il comporte une interface spécifique, développement en JAVA. Comparaison du code généré (Vn et Vn+1) par WINDIFF IOS : Syst. d’exploitation pour Mobile. Outil de comparaison ?? Gestion des anomalies Utilisation du Mantis actuel ( Plateforme de tests VM spécifique pour les tests d’intégration, manuels, automatique, comparaison de source Jtest analyse le propre code. Cas de tests logique. TNR = Tests fonctionnel, n to n

10 Analyse de risque du prototype
Extraction des risques par WIKI Toy et du fichier « TOY Features Fonctionnalités.xlsx » Analyse des risques faite avec la participation de J. Lacour Critères : Fréquence et impact sur un projet 79 exigences/risques fonctionnels ont été identifiés sur le prototype, avec la répartition suivante sur les criticités : Leur couverture nécessite 267 cas de tests (126 après réduction), Pas de contraintes techniques fortes identifiées à ce jour (performance, sécurité, navigateur…) Détails : RISQUES PROTOTYPE Volume Répartition 03-Impératif 50 63% 02-Important 15 19% 01-Intéressant 3 4% 00-Ignoré 11 14% Total 79 100% CAS DE TESTS PROTOTYPE Effort de tests Effort réduit Répartition 03-Impératif 204 104 83% 02-Important 40 21 17% 01-Intéressant 4 1 1% 00-Ignoré 15 0% Total 263 126 100%

11 Analyse de risque de la fabrication
Extraction des risques par WIKI Toy et du fichier « TOY Features Fonctionnalités.xlsx » Analyse des risques faite avec la participation de J. Lacour Critères : Fréquence et impact sur un projet 16 exigences/risques ont été identifiés lors de la génération du code à partir du prototype, avec la répartition suivante sur les criticités : Criticités différentes suivants les layers Détails : RISQUES FABRICATION Volume Répartition 03-Impératif 6 38% 02-Important 4 25% 01-Intéressant 00-Ignoré 0% Total 16 100% Layers impératifs Autres Layers Layer Java Jweb + JSF2 + SQL Layer .iOS et Androïd Layer Java Jweb + JSF2 + JPA Layer .net WPF (Juillet 2013) Layer .net ASP (Avril 2013) Layer .DDL et DOC .net ASP repourssé à fin mai

12 Stratégie des TNR sur Prototype (1/2)
Initialiser les TNR avec des tests manuels. Application modèle : L’application DEMO Version mineure: Une seule campagne de test est à prévoir (probabilité faible de la présence d’une régression) Objectif : Avoir une campagne de TNR restreint Devant se dérouler sur un délai court (0,5 ou 1 jour suivant l’impact de la version). Restreinte à cas de tests ciblés sur les risques impératifs et ciblés sur les fonctions impactés par les évolutions/correctifs A terme, ces tests manuels pourront être automatisés pour augmenter la couverture des tests sans impact sur le délai de la campagne Confirmer les charges retenues et les volumes de cas de tests pour chaque type de version

13 Stratégie des TNR sur Prototype (2/2)
Initialiser les TNR avec des tests manuels. Application modèle : L’application DEMO Version majeure: 2 campagnes de test (100% puis 25%) Couvrir l’ensemble des risques impératifs et ciblés Effort complet : Référentiel de 267 cdt 1er campagne : 8 jours de tests manuels (267 cdt) 2nd campagne : 2 jours (65 Cdt=25%) Effort réduit : Référentiel de 126 cdt 1er campagne : 4 jours (126 cdt) 2nd campagne : 1 jour (35 cdt=25%)  Afin de limiter le délai et la charge, nous proposons d’exclure une campagne sur l’effort de TNR complet, et de se restreindre uniquement sur l’effort de tests réduit. A terme, ces tests manuels pourront être automatisés pour réduire le délai de la campagne Confirmer les charges retenues et les volumes de cas de tests pour chaque type de version Problème de délai plus que 10 jours (200 à 300 jours de dév)

14 Stratégie des TNR sur Générateurs
Contrôle statique du code généré : Comparaison de fichier : Comparaison des exécutables de la Vn initiale avec la Vn+1 modifiée par les développeurs Significatif si peu de modification (cas des versions mineures) Code Review par des outils tels que Jtest (intégré dans la PIC) Contrôle dynamique: Automatisation de scénarios de tests fonctionnels sur l’application générée (Application DEMO) Java .net A terme sur mobile (périmètre de l’automate ?) Android .Ios Confirmer que Android et .iod doivent faire partie de l’outil d’automatisation Il faudra le planifier sur effort réduit. Toy ne bouge pas souvent Application générée bouge bcp. Grand impact sur les projets. Controles plus importants sur les application générés

15 POC automatisation des TNR
Choix de l’outil : Selenium Selenium est un outil libre de droit permettant d’automatiser des tests fonctionnels et de les rejouer à l’identique. Retour d’expérience : Selenium est très efficace pour s’interfacer avec des applications Web et simuler leur utilisation Selenium n’adresse pas les applications mobiles (émulateur sur client lourd) QuickTest Pro QTP QTP est l’automate de test de HP qui s’intègre dans la suite ALM. QTP propose des Addins permettant de s’interfacer facilement. Il possède ainsi des AddIns Ajax, .Net, java, SAP, Citrix QTP devrait pouvoir adresser des applications mobiles (émulateur sur client lourd) QTP a déjà été mis en place sur une PIC utilisant Hudson JTEST : Pas de retour d’expérience. Utilisé plutôt en test unitaire, modulaire (Junit). Confirmer que Android et .iod doivent faire partie de l’outil d’automatisation

16 POC automatisation des TNR
Objectif du POC A partir d’un scénario TNR de Toy : Confirmer la faisabilité de l’automatisation sur une même application générée par les principaux layers Java .Net .iOS et Androïd L’estimation du coût de l’automatisation des TNR résultant prendra en compte : La réalisation du socle technique La réalisation des scripts L’exécution d’une campagne V0 Le coût de la maintenance Confirmer que Android et .iod doivent faire partie de l’outil d’automatisation  OUI QTP et non selenium

17 Suivi et Cadrage Activités Charges Tests Charges Toy Charge totale
Avancancement Remarques Lister la couverture des tests 3 1 4 Terminé Formation TOY 3,5 Criticité et effort de tests Audit TOY 0,5 1,5 Construction de la stratégie – Restitution 2 2,5 En cours Chiffrage des étapes suivantes Sous total 14 16,5 Conception TNR "prototype" 10 Sous ALM Connect Conception TNR "Gérénérateur" - Comparaison exécutable 4,5 Sous windiff Exécution TNR sur version mineure 0,1 0,6 Réccursive Exécution TNR sur version majeure 5 5,5 Conception TNR "Gérénérateur" - Code review ? Jtest ? POC Automatisation (Java+.net) Outil retenu, 1 scénario automatisé sur 3 layers principaux Automatisation des tests Selon l'outil et les scénarios à automatiser Mise en place reporting ALM 0,0 Pilotage 0,25 45 50

18 Notre engagement Nous réalisons chaque mandat dans un seul but : contribuer au succès de nos clients.