Questions clés concourant à l'estimation des charges de Test

www.mind-testing.fr Par Jean-Christophe Rodrigues Practice Leader Testing
Infrastructure de test
1. Plate(s)-forme(s)
2. Outil(s)
3. Données
4. ...
Ce que propose également TMap Next
1. Dans la phase de Planificiation, une des tâches a pour objectif d'estimer l'Effort de Test requis pour l'intégralité du processus de test à partir de la stratégie, pour que le client donne son accord ou demande des ajustements TMap Next met gratuitement à disposition sur son site des check-lists et feuilles de calcul : http://www.tmap.net/en/tmap-next/downloads/tmap-next-downloads
  1. Techniques d'estimation (plus en détail) La sélection de techniques d'estimation est une étape qui requiert de l'experience. Il existe plusieurs techniques qui permettent justement d'évaluer l'effort requis. Une estimation de plan de test maître peut être basée sur: - les ratios - la taille de l'objet de test - l'organigramme des tâches (WBS - Work Breakdown Structure) - l'estimation proportionnelle - l'analyse par point de test TAP®
TMap est disponible en version française sous la référence: ISBN 9789072194893 TMap est également disponible gratuitement sur les magasins Itunes et Android (TMap Life Cyle App)
Notes
1. Dans une matrice, intégrez les questions clés ci-dessus que vous pondérerez en fonction de votre contexte (ex: 0-non applicable,... , 5-très importante) et du score de chacune d'elle (Orange: +2 points / Bleu: 0 point / Vert: -1 point). Cette notation vous permettra d'ajuster votre estimation initiale de charge de test en fonction de votre maturité dans le test. Affinez votre matrice avec le retour d'expérience.
2. Il existe aujourd'hui des outils tels que le TPI® (Test Process Improvement issu de la méthodologie TMap Next®) que l'on trouve dans le commerce, qui peuvent vous permettre de réaliser une analyse de votre niveau de maturité par rapport à un processus de test structuré et éprouvé. Mon prochain article: "Que peut vous apporter l'analyse de maturité de votre Processus de Test" sera dédié à ce thème.
  1. Topic
3. Les tests de validation fonctionnelle sont souvent estimés entre 15% et 30% du budget de développement mais dans les faits, ils ne sont pas toujours mis en pratique à cette hauteur. - d'une part (et en grossissant le trait), parce que certaines équipes ne se posent la question de ce que vont être les tests que lorsque la phase d'exécution des tests est arrivée. Toutes les phases du processus de test en amont de l'exécution n'auront donc pas été mises en oeuvre (planification, préparation, spécification, gestion de l'infrastructure, ...) ou que très partiellement. Les tests faits seront bien souvent mal faits, aléatoires et ne seront pas pérénnisés dans un référentiel, - d'autre part, parce que certains projets atteignent des dérives telles que le budget qui devait servir aux tests est englouti dans des charges supplémentaires de développement sans que l'ensemble des charges du projet ne soit revu.
4. N'oubliez pas mon article: "Pas de risque, pas de test… Vrai ou Faux?" La charge de test pourrait donc être nulle tout comme bien supérieure à 30%, ceci dépendant des risques encourus. Il y a d'autres paramètres à prendre en compte dans les chiffrages des projets d'aujourd'hui : - certains peuvent intégrer de plus en plus de solutions telles que des progiciels ou OpenSources. Dans ce cas, les charges de développement des projets sont plus faibles se "réduisant" à du paramétrage. La charge de test ne peut donc se résumer à un ratio de la charge de développement, - la structuration du futur produit lui même doit être pris en compte qu'il soit majoritairement IHM (et dépendant parfois de navigateurs dont nous ne pouvons maîtriser les évolutions et les rythmes de mise à jour) ou bien Batch ou bien Infra ou encore un savant mélange de tout cela. Dans tous ces cas, il convient de rester vigilant afin d'adapter correctement la charge de test.
5. Retrouvez également les préconisations proposées par d'autres professionnels au travers du teasing fait à ce sujet dans un forum Viadéo http://tinyurl.com/bp8xjzt
1/2 Evaluation ayant trait aux caractéristiques du Produit (issue de bonnes pratiques)
1. Complexité des Exigences
  1. Métiers
    1. Faible
    2. Moyenne
    3. Elevée
  2. Techniques
    1. Faible
    2. Moyenne
    3. Elevée
2. Criticité/Impact du Produit sur le S.I en cas de dysfonctionnement
  1. Faible
  2. Moyen
  3. Fort
3. Interdépendance avec le reste du SI
  1. Faible
  2. Moyenne
  3. Forte
4. Existance documentations relatives au Produit
  1. Oui , à jour et gérées en version
    1. Toujours
    2. Partiellement
  2. Non
5. Paramétrage ad-hoc du Produit
  1. Faible
  2. Moyen
  3. Fort
6. Fréquence d'utilisation du Produit
  1. Faible
  2. Moyenne
  3. Elevée
7. Taux de disponibilité du Produit
  1. Faible
  2. Moyen
  3. Fort
8. Robustesse du Produit
  1. Importante
  2. Moyenne
  3. Déficiente
9. Maturité du Produit
  1. Importante
  2. Moyenne
  3. Déficiente
10. Fréquence de mise en service des nouvelles évolutions (Fonctionnelles ou Techniques)
  1. Faible
  2. Moyenne
  3. Elevée
2/2 Evaluation ayant trait au Processus de Test (issue de bonnes pratiques)
1. Existence d'un Processus de Test
  1. Oui
    1. Processus de niveau "Aléatoire"
    2. Processus de niveau "Optimisé"
    3. Processus de niveau "Déterministe"
    4. Topic
  2. Non
2. Equipe de Test
  1. Dédiée
    1. Oui
    2. Non
  2. Professionnalisée
    1. Oui
    2. Non
  3. Reconnaissance de l'équipe de test par les différentes parties prenantes du projet
    1. Oui
    2. Non
  4. Niveau de connaissances fonctionnelles
    1. Elevé
    2. Moyen
    3. Faible
  5. Niveau de connaissances techniques
    1. Elevé
    2. Moyen
    3. Faible
3. Infrastructure de test
  1. Disponible
    1. Toujours
    2. Souvent
    3. Rarement
  2. Opérationnelle
    1. Toujours
    2. Souvent
    3. Rarement
  3. Stable
    1. Toujours
    2. Souvent
    3. Rarement
4. Les stratégies de qualification sont systématiquement définies pour les phases de tests
5. Outils / Méthodes / Référentiels
  1. Document de stratégie de tests
    1. Oui
    2. Non
  2. Existance d'un Référentiel de Test
    1. Oui
      1. Existe-t-il des normes relatives aux: - Exigences - Cas de Test - Scénarios
      2. Oui
      3. Non
    2. Non
  3. Existance d'un Référentiel de Gestion: - des Demandes - des Anomalies
    1. Oui
    2. Non
  4. Automatisation des rejeux
    1. Complètement
    2. Partiellement
    3. Non
  5. Existance d'un processus d'intégration continue
    1. Oui
    2. Non
  6. Planning des activités de test
    1. Oui
    2. Non
  7. Gestion des indicateurs Opérationnels (couverture de test, anomalie par type, ...)
    1. Oui
    2. Non