estimation de l'effort de mise à l'essai en pourcentage du temps de développement [terminé]
quelqu'un utilise-t-il une règle empirique pour estimer l'effort requis pour les essais en pourcentage de l'effort requis pour le développement? Et si oui, quel pourcentage utilisez-vous?
10 réponses
lorsque vous estimez les tests, vous devez déterminer la portée de vos tests - est-ce qu'on parle de test unitaire, fonctionnel, UAT, interface, sécurité, performance stress et volume?
si vous êtes sur un projet de chute d'eau, vous avez probablement quelques tâches de frais généraux qui sont assez constants. 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 cas de test nécessite souvent au moins autant d'effort pour extraire des exigences / spécifications / Récits de l'utilisateur qu'il faudra pour exécuter. En outre, vous devez inclure un certain temps pour l'augmentation de défaut / nouveau test. Pour une plus grande équipe, vous aurez besoin de prendre en compte la gestion des tests - planification, rapports, réunions.
en Général, mes estimations sont fondées sur la complexité des fonctionnalités livrées plutôt qu'à un pourcentage de dev effort. Toutefois, cela nécessite l'accès à au moins un un ensemble d'instructions de haut niveau. Des années à faire des tests me permettent de comprendre qu'un test d'une complexité particulière demandera x heures d'effort pour sa préparation et son exécution. Certains tests peuvent exiger un effort supplémentaire pour la configuration des données. Certains tests peuvent impliquer des négociations avec des systèmes externes et avoir 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 Développement alors il peut y avoir quelque chose de faux 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 constant pour les gestionnaires de projet.
Le Blog Google Testing discuté de ce problème récemment:
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.
(snip)
ces avantages se traduisent par une valeur réelle aujourd'hui comme demain. J'écris des tests, parce que les avantages supplémentaires que je reçois plus que compenser le coût supplémentaire de 10%. Même si je n'inclus pas les avantages à long terme, la valeur que j'obtiens de test aujourd'hui en vaut la peine. Je suis plus rapide dans le développement de code avec test. Ça dépend de la complexité du code. Plus la chose que vous essayez de construire est complexe (plus de fi/boucles/dépendances), plus les avantages des tests sont importants.
d'après mon expérience, 25% des efforts sont consacrés à L'analyse; 50% à la conception, au développement et aux essais unitaires; 25% aux essais. La plupart des projets respecteront une variation de +/-10% de cette règle empirique en fonction de la nature du projet, de la connaissance des ressources, de la qualité des intrants et des extrants, etc. On peut ajouter un frais généraux de gestion de projet à l'intérieur de ces pourcentages ou comme frais généraux au-dessus dans une fourchette de 10-15%.
il y a quelques années, dans un domaine critique pour la sécurité, j'ai entendu quelque chose comme un jour où l'unité testait dix lignes de code.
j'ai également observé 50% de l'effort pour le développement et 50% pour les tests (pas seulement les tests unitaires).
parlez-vous de tests automatisés d'intégration ou de tests manuels?
pour le premier, ma règle empirique (basée sur les mesures) est de 40-50% ajouté au temps de développement, c'est - à-dire si le développement d'un cas d'utilisation prend 10 jours (avant QU'un QA et un bugfixing sérieux ne se produisent), la rédaction de bons tests prend encore 4 à 5 jours-bien que cela devrait mieux se produire avant et pendant le développement, pas après.
le temps D'essai est probablement plus étroitement corrélé à la portée de la caractéristique qu'au temps de développement. Je dirais aussi (peut-être de façon controversée) que le temps de test est corrélé à la compétence 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 temps de test, effectué par les testeurs réels (pas l'équipe de développement) qui sont bien versé dans le logiciel qu'ils seront tester (c.-à-d., 2 semaines ne comprend pas le temps de montée en puissance). C'est pour une projet qui a ~5 développeurs.
quand vous parlez de tests, vous pouvez parler de chute d'eau ou de développement de tests agiles. Dans un environnement agile, les développeurs devraient passer 50% de leur temps à développer et à maintenir des tests.
mais ces 50% supplémentaires seront save vous chronométrez le moment de la reconfiguration et de la vérification manuelle.
Gartner, en octobre 2006, affirme que les essais absorbent généralement entre 10% et 35% du travail sur un projet d'intégration de systèmes. Je suppose qu'il s'applique à la méthode de la cascade. C'est une gamme assez vaste - mais il existe de nombreuses dépendances sur le montant de la personnalisation d'un produit standard et le nombre de systèmes intégrés.
la seule fois où je prends en compte le temps supplémentaire pour les tests est si je ne suis pas familier avec la technologie de test que j'utiliserai (par exemple, en utilisant des tests au sélénium pour la première fois). Ensuite, je prends en compte peut-être 10 à 20% pour me mettre à jour sur les outils et mettre en place l'infrastructure d'essai.
sinon les tests ne sont qu'une partie innée du développement et ne justifient pas une estimation supplémentaire. En fait, je voudrais probablement augmenter l'estimation pour le code fait sans test.
EDIT: notez que j'écris habituellement un test de code-en premier. Si je dois venir après le fait et écrire des tests pour le code existant qui va ralentir les choses. Je ne trouve pas que le développement de test-first me ralentit du tout, sauf pour le codage très exploratoire (lire: jeter-away).
jugez par le temps d'hier. Combien de temps ça a pris la dernière fois? Est-ce que vous avez une tendance plus longue ou plus courte? Chaque boutique est différente.
la plupart des ateliers agiles ont besoin de beaucoup moins de temps, ont beaucoup moins de défauts, et plus de temps pour les résoudre en raison de TDD. Malgré cela, la plupart des ateliers agiles disposent d'un temps mesurable consacré aux essais et au contrôle de la qualité.
si c'est le premier essai pour cette application, alors la réponse est "permet de voir" suivi d'une tentative. Cela dépend de la vitesse à laquelle vous pouvez obtenir des réponses, - comment testable il est, - combien de fonctionnalités/fonctions - combien de défauts sont découverts, - comment les problèmes sont résolus rapidement, - combien de fois le cycle de code grâce à des tests, et - combien de fois le test est bloqué par bugs. Il n'y a aucun moyen de savoir. Vous pouvez l'appeler 50% ou 175% ou plus, et ne vous trompez pas. Pourquoi ne pas faire une supposition grossière et multiplier par Pi? Ce ne sera pas pire que n'importe quelle autre réponse que vous pouvez inventer.
Vous devez () 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 bits d'information, vous devriez être capable de deviner assez bien.