Le temps du testeur devrait-il être inclus lors de l'estimation des billets?
Lors de la création d'estimations de temps pour les tickets, le temps nécessaire aux testeurs (AQ) doit-il être inclus dans une estimation des tickets? Nous avions auparavant toujours estimé sans le temps des testeurs mais nous parlons de toujours l'inclure. Cela a du sens pour notre sprint actuel, le dernier avant une sortie, car nous devons connaître le temps total que les tickets prendront avec une semaine.
J'ai toujours compris que l'estimation ne concernait que le temps des développeurs car cela tend à être la ressource limitante des équipes. Un collègue dit que partout où ils ont travaillé avant l'heure du testeur a également été inclus.
Pour être clair, il s'agit d'un processus où les développeurs écrivent des tests unitaires, d'intégration et d'interface utilisateur avec une bonne couverture.
Ma recommandation: vous pouvez soit inclure le temps de test dans le ticket, soit ajouter un ticket pour représenter la tâche de test elle-même. Toute autre approche vous fait sous-estimer le vrai travail nécessaire.
Bien que le temps des développeurs soit souvent un goulot d'étranglement, d'après mon expérience, de nombreuses équipes sont contraintes au test. En supposant que la ressource limitante est l'une ou l'autre sans preuve, cela peut vous mordre.
En tant que collègue, je n'ai pas vu d'organisation réussie qui ne prenne pas en compte le temps de test.
Addendum selon votre clarification: Même si les développeurs écrivent des tests automatisés, en particulier des tests unitaires (les tests d'intégration font mieux), ils sont insuffisants pour tester correctement.
S'il y a des gens d'AQ impliqués, leur temps doit être estimé, d'une manière ou d'une autre. Ce n'est que si vous décidez de retirer des employés de l'assurance qualité de la paie que leur temps de travail a effectivement disparu et que vous pouvez le supprimer de l'estimation. Mais cela aurait des effets secondaires faciles à ignorer. Et vous pouvez toujours manquer des tests de performance, de stress, de sécurité et d'acceptation.
Surtout, Oui
Les tests font partie du processus de développement. Si votre équipe passe réellement du temps à tester le logiciel, le temps passé à tester doit faire partie de l'estimation.
Si c'est agile, j'inclurais l'effort de test dans le total des points de l'histoire. Par exemple, l'effort de développement peut être de 1 jour et le test de 1 jour, ce serait donc une histoire en 2 points.
Cela dépend de votre définition du terme "fait", mais généralement de son développement complet, de son acceptation commerciale et de sa signature de test dans l'itération. Si le DoD n'est qu'une acceptation commerciale, les efforts de test ne doivent pas nécessairement être inclus dans les points de l'histoire, mais ils doivent toujours être suivis.
L'estimation doit représenter tous les travaux nécessaires pour compléter le ticket. Si le test est une partie obligatoire du ticket, il doit être inclus dans le devis. Si le test est un ticket séparé, il ne devrait pas l'être.
Bien sûr, cela peut devenir flou une fois que vous commencez à utiliser des points d'histoire, car la différence entre un 5 uniquement pour les développeurs et un 8 pour les seuls développeurs sera assez proportionnelle à un dev-and-QA 5 par rapport à un dev-and-QA 8.
J'ai vu notamment le travail du temps des testeurs. J'ai vu des histoires distinctes fonctionner. J'ai vu des tâches distinctes, chacune estimée par le groupe qui les fait fonctionner. Faites ce qui a du sens pour vous, après tout le processus est là pour vous servir, et non l'inverse.
Le fait que vous ne puissiez pas répondre à cela suggère fortement vous ne savez pas pourquoi vous écrivez des estimations (ou du moins que vous n'êtes pas d'accord avec votre collègue pourquoi vous écrivez des estimations). C'est un problème plus important que celui de savoir si les estimations devraient ou non inclure des tests.
Découvrez, ou parvenez à un accord, pourquoi vous écrivez des estimations. S'il s'agit de prédire ce qu'une équipe particulière réalisera à un moment donné, la réponse dépend simplement du fait que cette équipe, celle pour laquelle vous effectuez une estimation, effectue le test ou non. Si votre équipe d'assurance qualité est distincte et a sa propre planification, elle pourrait être intéressée de savoir combien de temps de test vous (les développeurs) pensez être nécessaire d'elle sur un ticket donné. Ils peuvent ignorer vos chiffres et mettre les leurs. De toute façon, ils peuvent suivre cela séparément des estimations de temps de développement.
D'un autre côté, si une équipe fait tout le développement, les tests et l'AQ, et que le but des estimations de temps est de prédire et de planifier ce que cette équipe fait dans un laps de temps particulier, alors bien sûr les estimations de temps doivent inclure l'AQ, ainsi que toute autre tâche que cette équipe doit effectuer pour atteindre l'objectif déclaré. D'ailleurs, si vous devez avoir une réunion de lancement pour chaque ticket, ou remplir des documents à la fin, le temps pour l'administrateur doit être là quelque part. Vous ne pouvez pas simplement l'ignorer.
S'il s'agit d'une seule équipe mais avec des rôles séparés "développeurs" et "testeurs", cela peut signifier que vous avez beaucoup de tickets sur lesquels un seul côté de la fracture est capable de travailler, et votre diagramme de Gantt (peut-être entièrement hypothétique) ressemble exactement comme le graphique de deux équipes distinctes. Ce fait bouleversera certaines méthodologies plus que d'autres, et vous feriez peut-être mieux de diviser la planification à cause de cela, mais si vous ne la divisez pas, vous devez établir un ticket et estimer tout ce que l'équipe doit faire ou vos prédictions seront sans espoir .
Si le but des estimations est autre chose que la prédiction et la planification, par exemple "parce que nous suivons sans réfléchir un rituel vide qui les inclut", ou "parce que la direction les utilise comme un bâton pour nous battre pour nous faire des heures supplémentaires", ou "parce que nous devons faire une offre à prix fixe et que les chiffres entrent dans une formule énorme" (merci John Wu), alors il pourrait être plus difficile de comprendre ce qu'ils devraient inclure ;-)
Estimez toujours tout le travail qui doit être fait pour faire une histoire utilisateur/fonctionnalité/ticket vraiment fait. Nous appelons cela DoneDone .
Nous avons terminé lorsque nous sommes prêts pour la production .
Cela inclut tous les tests manuels et exploratoires, mais même les tests d'acceptation des utilisateurs.
Une équipe Agile devrait être en mesure de publier à tout moment une nouvelle partie du travail terminé. Comme:
Un logiciel fonctionnel est la principale mesure du progrès.
Comment savoir si cela fonctionne, si vous ne l'avez pas testé? Vous écrivez maintenant que le temps de développement est le goulot d'étranglement de votre temps. En tant qu'ingénieur QA, je pense que la plupart des équipes ont leur goulot d'étranglement dans la capacité de test ou qu'elles prennent simplement des raccourcis.
Pour faire une histoire courte, estimez également l'effort de test. Gardez à l'esprit que cela pourrait influencer votre vitesse. Si vous avez fait des estimations relatives dans les récits, le test peut déjà être intégré à votre vitesse moyenne.
Voici quelque chose de très important: Toutes les estimations doivent être accompagnées d'hypothèses et d'exclusions .
Cela comprend la spécification de ce qui est inclus: développement uniquement, conception et développement, tests de développement et unitaires, couverture des tests d'acceptation, construction de l'infrastructure, etc.
Si vous fournissez un document d'estimation à un chef de projet, il va convertir ce document en ordre de travail ou énoncé de travail pour un client ou (s'il s'agit d'un projet interne) pour le PMO . Ils mai ont défini des formules pour ajouter des frais généraux (par exemple, certains projets peuvent ajouter X% pour couvrir l'AQ, puis ajouter Y% pour couvrir la gouvernance et la gestion de projet) qui sont définies par contrat ou définies par expérience. Et vous ne voulez pas doubler le compte. D'un autre côté, ils peuvent ne pas les ajouter automatiquement.
Les pratiques diffèrent. Celui qui utilise ces chiffres devra savoir ce que signifient les chiffres, et vous devez être explicite si vous incluez ou non le temps de test.
Le temps doit être inclus dans l'estimation mais vous ne doit pas estimer le temps des testeurs, mais les testeurs doivent estimer leur temps.
Ne pas inclure le temps de test est une fausse estimation du temps total qu'il faudra, mais le temps du développeur et le temps du testeur ne sont pas interchangeables (notamment parce que vous travaillez probablement en parallèle, avec les testeurs une itération derrière), vous devez donc les estimer séparément. De plus, vous n'êtes pas en mesure d'estimer le temps dont les testeurs auront besoin pour tester les changements, seule l'équipe de test elle-même devrait le faire.
Encapsulation
Je vais aborder cela d'un point de vue et d'un langage de développement logiciel.
- Vous êtes un petit rouage dans une grosse machine.
- De l'extérieur de votre équipe, votre système de billetterie agit comme une interface/API pour votre équipe
- Les utilisateurs professionnels qui utilisent le système de billetterie ne sont pas des développeurs
De la bonne conception logicielle, vous devez simplifier et encapsuler autant que possible.
Donc, pour regarder le processus du point de vue des utilisateurs professionnels, ils ne se soucient vraiment que de 2 choses.
- Combien ça coûtera?
- Avons-nous finit?
Permettre à l'utilisateur professionnel de connaître le processus interne de votre équipe est une mauvaise gestion; s'apparente à donner à public l'accès à l'état interne.
Le fait de ne pas protéger l'état interne de votre équipe invite les autres équipes à gérer vos ressources et à jouer avec votre état interne.