estimation de l'effort de test en pourcentage du temps de développement
Quelqu'un utilise-t-il une règle empirique pour estimer l'effort requis pour les tests en pourcentage de l'effort requis pour le développement? Et si oui, quel pourcentage utilisez-vous?
D'après mon expérience, 25% des efforts sont consacrés à l'analyse; 50% pour la conception, le développement et les tests unitaires; 25% restant pour les tests. La plupart des projets s'inscriront dans un écart de +/- 10% de cette règle empirique en fonction de la nature du projet, de la connaissance des ressources, de la qualité des intrants, des sorties, etc. au sommet dans une fourchette de 10 à 15%.
Le blog de test Google a récemment discuté de ce problème :
Donc, une réponse naïve est que le test d'écriture porte une taxe de 10%. Mais, nous payons des impôts pour obtenir quelque chose en retour.
(couper)
Ces avantages se traduisent en valeur réelle aujourd'hui comme demain. J'écris des tests, car les avantages supplémentaires que j'obtiens compensent largement le coût supplémentaire de 10%. Même si je n'inclus pas les avantages à long terme, la valeur que je retire du test en vaut la peine. Je suis plus rapide dans le développement de code avec test. Combien, eh bien cela dépend de la complexité du code. Plus la chose que vous essayez de construire est complexe (plus ifs/boucles/dépendances) plus les avantages des tests sont importants.
Lorsque vous estimez les tests, vous devez identifier la portée de vos tests - parlons-nous de test unitaire, fonctionnel, UAT, interface, sécurité, stress de performance et volume?
Si vous êtes sur un projet en cascade, vous avez probablement des tâches indirectes assez constantes. Prévoyez du temps pour préparer les documents de planification, les calendriers et les rapports.
Pour une phase de test fonctionnel (je suis un "testeur de système" donc c'est mon principal point de référence) n'oubliez pas d'inclure la planification! Un scénario de test nécessite souvent au moins autant d'efforts pour extraire des exigences/spécifications/user stories qu'il faudra pour l'exécuter. De plus, vous devez prévoir du temps pour relever/retester les défauts. Pour une équipe plus importante, vous devrez prendre en compte la gestion des tests - planification, rapports, réunions.
En général, mes estimations sont basées sur la complexité des fonctionnalités fournies plutôt que sur un pourcentage de l'effort de développement. Cependant, cela nécessite l'accès à au moins un ensemble d'instructions de haut niveau. Des années de tests me permettent de comprendre qu'un test d'une complexité particulière prendra x heures d'efforts pour sa préparation et son exécution. Certains tests peuvent nécessiter des efforts supplémentaires pour la configuration des données. Certains tests peuvent impliquer la négociation avec des systèmes externes et ont une durée bien supérieure à l'effort requis.
En fin de compte, cependant, vous devez l'examiner dans le contexte du projet global. Si votre estimation est bien supérieure à celle de BA ou de développement, il peut y avoir un problème avec vos hypothèses sous-jacentes.
Je sais que c'est un vieux sujet mais c'est quelque chose que je revisite en ce moment et qui est d'un intérêt permanent pour les chefs de projet.
Il y a quelques années, dans un domaine critique pour la sécurité, j'ai entendu quelque chose comme un jour pour tester 10 lignes de code.
J'ai également observé 50% d'efforts pour le développement et 50% pour les tests (pas seulement les tests unitaires).
Parlez-vous de tests unitaires/d'intégration automatisés ou de tests manuels?
Pour les premiers, ma règle empirique (basée sur les mesures) est ajoutée de 40 à 50% au temps de développement, c'est-à-dire si le développement d'un cas d'utilisation prend 10 jours (avant qu'un contrôle qualité et un correctif de bogue sérieux se produisent), l'écriture de bons tests prend encore 4 à 5 jours. - bien que cela se produise mieux avant et pendant le développement, pas après.
Le temps de test est probablement plus étroitement corrélé à l'étendue des fonctionnalités que le temps de développement. Je dirais également (peut-être de manière controversée) que le temps de test est corrélé aux compétences de votre équipe de développement.
Pour un effort de développement de 6 à 9 mois, je demande un minimum absolu de 2 semaines de test, effectuées par de vrais testeurs (pas l'équipe de développement) qui connaissent bien le logiciel qu'ils vont tester (c.-à-d. 2 semaines pas inclure le temps de montée en puissance). C'est pour un projet qui a ~ 5 développeurs.
Lorsque vous parlez de tests, vous pourriez signifier une cascade ou un développement de test agile. Dans un environnement agile, les développeurs devraient passer 50% de leur temps à développer et à maintenir des tests.
Mais ce supplément de 50% vous économisez votre temps lorsque vient le temps de la refactorisation et de la vérification manuelle.
Gartner en octobre 2006 déclare que les tests consomment généralement entre 10% et 35% du travail sur un projet d'intégration de système. Je suppose que cela s'applique à la méthode de la cascade. Il s'agit d'une gamme assez large - mais il existe de nombreuses dépendances du nombre de personnalisations d'un produit standard et du nombre de systèmes à intégrer.
La seule fois où je prends en compte le temps supplémentaire pour les tests, c'est si je ne suis pas familier avec la technologie de test que j'utiliserai (par exemple, utiliser les tests Selenium pour la première fois). Ensuite, je prends en compte 10 à 20% pour avoir mis à jour les outils et mis en place l'infrastructure de test.
Sinon, les tests ne sont qu'une partie innée du développement et ne justifient pas une estimation supplémentaire. En fait, j'augmenterais probablement l'estimation du code effectué sans tests.
EDIT: Notez que j'écris généralement du code en premier. Si je dois entrer après le fait et écrire des tests pour le code existant, cela va ralentir les choses. Je ne trouve pas que le développement test-first me ralentisse du tout, sauf pour un codage très exploratoire (lire: jetable).
Jugez par le temps d'hier. Combien de temps at-il fallu la dernière fois? Êtes-vous plus ou moins long? Chaque boutique est différente.
La plupart des magasins agiles ont besoin de beaucoup moins de temps, ont considérablement moins de défauts et un temps plus court pour les résoudre en raison du TDD. Même ainsi, la plupart des magasins agiles ont un temps mesurable consacré aux tests/QC.
S'il s'agit du premier test effectué pour cette application, la réponse est "laisse voir" suivie d'une tentative. Cela dépend de la rapidité avec laquelle vous pouvez répondre aux questions, - de son testabilité, - du nombre de fonctionnalités/fonctions - du nombre de défauts découverts, - de la rapidité avec laquelle les problèmes sont résolus, - du nombre de fois que le code parcourt les tests et - de la manière dont plusieurs fois, les tests sont bloqués par des bogues. Il n'y a aucun moyen de le savoir. Vous pourriez l'appeler 50% ou 175% ou plus, et ne vous trompez pas. Pourquoi ne pas faire une estimation approximative et multiplier par Pi? Ce ne sera pas bien pire que toute autre réponse que vous pouvez inventer.
Vous devriez (doit) savoir combien de temps cela prend maintenant et si cela devient plus rapide ou plus lent, et si la couverture augmente ou diminue. Avec ces trois informations, vous devriez pouvoir deviner assez bien.