TGV Tests à Géométrie Variable. Olivier Denoo ps_testware S.A.S.

Transcription

1 TGV Tests à Géométrie Variable Olivier Denoo ps_testware S.A.S.

2 Agenda Introduction Les projets contraints Le TRH comme pierre angulaire de la méthode Les aspects pratiques du projet TGV: La méthode

3 Contraintes des projets TIC Coût Temps Qualité

4 Le Projet: AssurCo Assurances non-vie

5 Et vint l externalisation Client métier Utilisateurs Test Manager Cellule qualité? Intégrateur Client TIC

6 AssurCo Refonte du l interface courtier pour le nonvie (auto + incendie + RC) Externalisation du développement Externalisation de la qualité Fonctionnel et métier Automatisation (Non-régression et Performances) Experts métier et environnement TIC 100 personnes années (au total) 4500 défauts trouvés Jusqu à 30 testeurs en parallèle

7 Organisation du projet de test Projet AssurCo Tests automatisés Tests Manuels Non régression fonctionnelle Tests Fonctionnels Performance Tests de configuration «Fine Tuning» Ergonomie Validation Tests de charge Expert Scénarii Mise à l échelle

8 L approche ps_testware Tests orientés risque

9 Structurer au moyen du TRH Test requirement 1 Test requirement 1.1 Test requirement 1.2 Test requirement Test requirement Test requirement Test requirement 1.3 Test requirement Test requirement Organigramme structure hiérarchique des exigences du test Orienté- métier Retrace tous les chemins possibles pour atteindre le but de l entreprise Orienté- Processus Commence avec des processus et se termine avec la cartographie des fonctions Echelle de mesure de la qualité Test requirement 1.4

10 Terminologie du concept du TRH TRH: TR (Test Requirement) : exigence susceptible d être testée, non ambigüe et validée afin d atteindre le but fixé pour le test. H (Hierarchy) : structure hiérarchique définissant le niveau de l exigence. TRH: traduit le métier de l entreprise en attentes plus significatives (approche des exigences), divise en parts uniques et mesurables, le métier identifié, prend en compte les hypothèses cachées.

11 Besoins Un TRH: pourquoi faire? Un outil de planification de tests à éxecuter: Que faut-il tester? Un outil de décision et de gestion des tests: Dans quel ordre d importance faut-il tester? (prioritisation) - business priorities & technical priorities Un outil de mesure des tests. Quelle est la couverture des tests exécutés, réussis, échoués et restant à faire? Un outil de communication entre les différents intervenants de la phase de test (utilisateurs, testeurs, développeurs et analystes).

12 Organisation des tests Requirement Management - TRH Scenarii Cas de test Navigation, Prologue & Epilogue, mots-clefs Validation des mots-clef Jeux de données de test Textes Bla bla bla Scripts Tests manuels Outils de test Tests automatisés Application testée

13 100% Périmètre Que faire quand ça dérape? Productivité 66% 50% % Deadline attendue Deadline étendue Temps

14 Une stratégie à Géométrie Variable Option 2 Limiter le périmètre moins de qualité Plus de risque Glissement coût dû au retard sur le marché Effet d annonce manqué Option 3 Augmenter les ressources Surcoût engendré 2 femmes en 4.5 mois ne feront jamais un enfant

15 TGV Tests à Géométrie Variable Mitigation entre les options 2 et 3 Utiliser ce que l on sait déjà pour prévoir et se préparer Organiser une stratégie créative orientée-risque Sanity check Flexibilité des ressources Planning en fonction des capacités de chacun Tenir compte des ressources existantes Tenir compte des activités Test des nouvelles fonctionnalités Re-test (corrections) Test de non-régression (re-validation) / Multiplier les PC (automatisation) Exécution en fonction du risque / priorités Le plus important d abord Plus important = plus en détail

16 Modèle estimatif Corrigés Hérités des phases précédentes Estimés (Trouvés?) Exportés vers les phases suivantes Planning Phase de test n

17 Campagne: planning prévisionnel Tests manuels (n) Tests manuels (n+1) et automatisés (n) d1 d2 d3 0? SP 2.1 SP 2.2 SP 2.3? 21/03 27/03 2/04 18/04 02/05 21/05 SC hérités de SP2.0 hérités de SP1.x h1 h2 h3 h1 h2 Σhi Σ hi? Σhi Σ hi? 8? Correction > c1 Go / No Go Correction > c2 Production? di = nombre de défauts estimé sur la phase ci = nombre de défauts corigés sur la phase hi = nombre de défauts hérités Production?! Performance! Disponibilité! Stabilité

18 Mesures et reporting Le bulletin météo

19 Bulletin météo Test Weather Report Date 27/08 Sprint 2 Release 3 # days 15/23 15 # Testers Effective Cum. % planned resources for SP2.3 Execution test designs 5,5 Check printed documents 3 58% Ad hoc tests 5 63% Quotation (Product Management) 0 100% Re-test SP1 + SP2 ad hoc defects 0 100% Traduction 0 100% Total resources coverage Release 3 13,5 62% Availability - Lost time Availability of the application that day 100,0% week 1/5 week 2/5 week 3/5 week 4/5 week 5/5 Average availability for SP2.3 85,7% 80,1% 78,6% 95,6% 85,7%

20 Test execution (2849 data sets) # data sets foreseen that date 170 Found defects # data sets tested that date 90 % data set coverage SP2.3 - against planned ds 53% OK NOK Not testable Intermediate # data sets executed SP % data sets executed SP2.3 86,1% 10,8% 0,0% 3,0% % data set coverage SP2.3 - against total ds 75,4% Docs waiting for check # SP2 defects foreseen to be re-tested during SP # SP2 defects re-tested that date 22 OK NOK Not testable # SP2 defects re-tested while executing ds SP Cumul # SP2 defects re-tested while executing ds SP2.3 87,2% 12,3% 0,5% % re-test defects coverage 47% Average datasets/p/d foreseen for SP2.3 19,9 *Average test design (15 ds/p/d) and check document (29 ds/p/d) Average datasets/p/d effective that day 16,4 Average datasets/p/d effective in SP2.3 17,3 Re-test SP2 AD HOC defects # SP2 ad hoc defects foreseen to be re-tested during SP # SP2 ad hoc defects foreseen that date 0 NOK + OK + # SP2 ad hoc defects re-tested that date 0 OK NOK New defect New defect # SP2 ad hoc defects re-tested in SP Cumul # SP2 ad hoc defects re-tested in SP2.3 81,8% 16,2% 0,0% 0,0% % SP2 ad hoc defects re-test coverage 93% Average defects re-tested/p/d foreseen for SP2.3 10,0 Average defects re-tested/p/d effective that day - Average datasets/p/d effective in SP2.3 -

21 # Defects # encoded defects that day 18 Urgent High Medium Low # active defects in Defect Tracker for SP # active defects in Defect Tracker Open IT exam Pend. TEST Sub-total Active Whole IT Factory Ready TLF Pend. TLF User Exam 411 Test Factory Closed Deferred Archived 2419 Not active defects Test exam 0 0 Remarks : Today : Finalised retest of fiches linked to "marques-modèles" has been done Application has been better regarding response time but a lot of instabilities (T000): see daily urgent defects sheet for details. Program for tomorrow : Same as today

22 ...et les actions correctives Le programme de fitness

23 Fitness Program Data set foreseen / executed Executed Cumulated DS DS foreseen this day (intial planning) /aug 7/aug 9/aug 13/aug 19/aug 21/aug 23/aug 27/aug 29/aug 2/sep 4/sep 6/sep 140

24 Retest defects SP1 foreseen / executed Re-tested this daysp1 + SP2 ad hoc Foreseen to be retested this day (intial planning) /aug 7/aug 9/aug 13/aug 19/aug 21/aug 23/aug 27/aug 29/aug 2/sep 4/sep 6/sep Availability of the application 100% 91%92% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 24% 100% 93% 64% 89% 82% 100% 100% 100% 92% 86% 100% 71% Availability 5/aug 7/aug 9/aug 11/aug 13/aug 15/aug 17/aug 19/aug 21/aug 23/aug 25/aug 27/aug 29/aug 31/aug 2/sep 4/sep 6/sep

25 Leçons à tirer Communication, communication, communication Trop de reporting nuit au reporting Objectifs en termes de correction Attention aux effets pervers Re-caractérisation et rejets (X3) Corrections <> priorités/impacts L automatisation a ses limites Eviter le «bricolage» Suivi des anomalies Reporting Faire simple

26 Merci pour votre attention Avez-vous des questions?

27 ps_testware S.A.S. 4 rue Louis Neel Lezennes Tel Fax infofr@pstestware.com