Supposons que 10 développeurs ont mis 6 mois pour développer une application. En tant que chef de projet, combien de temps devrais-je consacrer à mes plans de test?Comment planifier l'heure du test
6 mois d'effort comprend les tests unitaires. Je suis spécifique au test fonctionnel et au test d'acceptation par l'utilisateur.
Y a-t-il un rapport ou une relation entre le temps de développement et le temps de test?
Voici un short article de Alan Page, Test Architect on l'équipe d'ingénierie d'excellence de Microsoft:
Quelques exemples de choses à considérer dans l'estimation de test sont:
- données historiques - au moins, vous pouvez estimer la conception des tests basé sur des projets précédents
- Complexité - La complexité est directement liée à la testabilité. Simples applications peuvent être testées plus rapidement que des programmes complexes
- des objectifs commerciaux - L'application d'un prototype ou application de démonstration? Ou est-ce un logiciel de contrôle de vol pour un vaisseau spatial ?Les objectifs commerciaux influencent l'ampleur et la profondeur de l'effort de test
- Conformance/Compliance - Si l'application doit être conforme à une norme , ces exigences doivent être pris en compte lors estimation des tests tâche.
Y at-il rapport ou relation entre le temps de développement et le temps de test?
Non, il n'y en a vraiment pas. Vous devez examiner les exigences fonctionnelles de votre application pour déterminer quels sont les besoins testés et combien de temps cela va prendre.
Et combien de retouches seront nécessaires. Si vous vous attendez à beaucoup de retravailler, il vaut mieux prévoir beaucoup de tests. –
En règle générale, le test prend 1/3 du temps de développement, mais il peut varier considérablement en fonction de ce que vous faites et du nombre de tests que vous attendez.
pouvez-vous site une référence pour la règle 1/3 –
Je ne crois pas que ce soit une question à laquelle nous pouvons répondre pour vous. Pour vous donner une estimation raisonnable, nous aurions besoin de savoir plusieurs choses:
Quels sont vos objectifs de test? (Couverture du code, défauts trouvés/corrigés, exigences testées, etc.)
Combien de temps avez-vous passé à tester sur des projets similaires?
Quels problèmes de qualité avez-vous rencontrés sur ces projets? (Trop de défauts découverts, la gravité des défauts est acceptable/inacceptable)
Avez-vous déjà planifié des tests?
Combien de défauts les tests unitaires ont-ils mis au jour? Y a-t-il des domaines d'intérêt plus ou moins important? Comment avez-vous abordé ces questions?
Quelle sorte d'analyse de test allez-vous faire?
Il existe des statistiques que vous pouvez utiliser pour vous donner une estimation approximative de ce type de travail, mais le problème est qu'elles doivent être adaptées à votre environnement pour donner des estimations significatives. Une mesure peut suggérer 2 mois de test, mais vous ne réalisez peut-être pas que votre environnement nécessite deux fois ce délai jusqu'à ce que vous ayez besoin de 4 mois.
Il est difficile de répondre à cette question. Cela dépend probablement de votre expérience dans des projets similaires. Je peux juste vous fournir quelques statistiques pour certains projets dans lesquels j'ai travaillé. Vous pouvez voir qu'il est difficile d'obtenir une formule pour le temps de développement en termes de temps de développement:
Projet | Complexité | Temps de développement | Temps de test | # Développeurs | # Testeurs
A | 4 | 90 jours | 60 jours | 4 | 1
B | 1 | 60 jours | 30 jours | 2 | 1
C | 5 | 90 jours | 120 jours | 4 | 1
D | 2 | 15 jours | 7 jours | 2 | 2
E | 3 | 120 jours | 90 jours | 2 | 2
J'espère que vous, en tant que chef de projet, prévoyez d'utiliser un processus de développement itératif comme Scrum ou un autre agile method. Je ne considérerais pas le test comme une phase du développement qui devrait être fait après la phase de développement, mais comme une partie essentielle du processus de développement.
Les tests unitaires sont excellents et devraient être obligatoires partout, mais ne commettez pas l'erreur de commencer trop tard avec les tests fonctionnels. Si le projet dure aussi peu que 6 mois, il est essentiel d'avoir un système opérationnel en deux fois, même s'il manque la plupart des fonctionnalités, et commencez avec cette partie du test pendant que le reste des fonctionnalités est ajouté.
Agile est grand, mais la régression est toujours nécessaire après le développement est fait pour s'assurer qu'aucune des nouvelles fonctionnalités à la fin du développement a brisé les anciennes caractéristiques ennuyeuses depuis le début de développement. Et les tests automatisés ne peuvent pas attraper * tout * dans la plupart des domaines. – tloach
Vrai, et n'oublie pas les rétrospectives! –
Je suis d'accord avec la réponse acceptée de Pascal Paradis.
En outre, assurez-vous d'inclure la planification des tests dans votre planification. La planification peut prendre autant de temps que les tests réels, sinon plus. Cela peut être difficile car cela nécessite une documentation finalisée de l'équipe de développement.
Je vote pour clore cette question hors-sujet parce qu'il ne s'agit pas de programmation. –