TGV Tests à Géométrie Variable Olivier Denoo ps_testware S.A.S.
Agenda Introduction Les projets contraints Le TRH comme pierre angulaire de la méthode Les aspects pratiques du projet TGV: La méthode
Contraintes des projets TIC Coût Temps Qualité
Le Projet: AssurCo Assurances non-vie
Et vint l externalisation Client métier Utilisateurs Test Manager Cellule qualité? Intégrateur Client TIC
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
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
L approche ps_testware Tests orientés risque
Structurer au moyen du TRH Test requirement 1 Test requirement 1.1 Test requirement 1.2 Test requirement 1.2.1 Test requirement 1.2.2 Test requirement 1.2.3 Test requirement 1.3 Test requirement 1.3.1 Test requirement 1.3.2 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
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.
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).
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 0001001 Tests manuels Outils de test Tests automatisés Application testée
100% Périmètre Que faire quand ça dérape? Productivité 66% 50% 1 3 2 0% Deadline attendue Deadline étendue Temps
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
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
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
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 1 2 3 4 5 6 7 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é
Mesures et reporting Le bulletin météo
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%
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 SP2.3 2148 1850 233 0 65 % 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 SP2.3 445 # SP2 defects re-tested that date 22 OK NOK Not testable # SP2 defects re-tested while executing ds SP2.3 211 184 26 1 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 SP2.3 106 # 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 SP2.3 99 81 16 0 0 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 -
# Defects # encoded defects that day 18 Urgent High Medium Low # active defects in Defect Tracker for SP2.3 102 20 51 24 7 102 # active defects in Defect Tracker 411 29 257 110 15 411 Open IT exam Pend. TEST Sub-total Active Whole IT Factory 65 0 21 86 Ready TLF Pend. TLF User Exam 411 Test Factory 2 297 26 325 Closed Deferred Archived 2419 Not active defects 454 47 1507 2008 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
...et les actions correctives Le programme de fitness
Fitness Program Data set foreseen / executed 3000 2500 2000 1500 1000 Executed Cumulated DS DS foreseen this day (intial planning) 500 0 5/aug 7/aug 9/aug 13/aug 19/aug 21/aug 23/aug 27/aug 29/aug 2/sep 4/sep 6/sep 140
Retest defects SP1 foreseen / executed 140 120 100 80 60 Re-tested this daysp1 + SP2 ad hoc Foreseen to be retested this day (intial planning) 40 20 0 5/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
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
Merci pour votre attention Avez-vous des questions?
ps_testware S.A.S. 4 rue Louis Neel 59260 Lezennes Tel +33 3 59 30 42 02 Fax +33 3 59 30 42 03 http://www.pstestware.fr infofr@pstestware.com