Codage et test dans le même sprint
Comment les tests sont-ils gérés dans le même sprint que le codage, si tout ou partie du codage n'est pas effectué avant la fin du sprint? (Je fais référence au développement et au test de la "soupe aux noix" d'un PBI unique dans un sprint.)
La plupart des réponses que j'ai vues en ligne concernent l'automatisation de l'assurance qualité, mais même cela n'est pas vraiment possible car vous avez généralement besoin d'une interface utilisateur fonctionnelle pour enregistrer ou créer des tests automatisés. Je n'ai que des storyboards qui continuent d'évoluer à mesure que je développe des fonctionnalités et découvre de nouvelles exigences.
Dans mon cas, je développe une nouvelle application de bureau. Les applications de bureau ne se prêtent généralement pas très bien aux tests automatisés. J'ai quelques tests unitaires automatisés, mais ce ne sont pas les tests manuels fonctionnels/d'intégration qu'un professionnel de l'assurance qualité effectuerait.
Donc, où j'en suis maintenant, c'est que mon sprint se termine demain, j'ai encore du codage à terminer, et mes gens de QA n'ont encore rien à tester, et aucune idée de comment tester tout ce que je leur donnerais sans que je leur tienne la main.
Je suis sûr que je ne suis pas la première personne à avoir ce dilemme.
Dans le passé, j'ai fait un pipeline: dans le sprint actuel, l'équipe de test teste les fonctionnalités qui ont été implémentées lors du sprint précédent. Dans mon travail actuel, le PM fait référence à cette approche en tant que "cascade", et en tant que telle, inacceptable.
Si vous ne testez pas une user story (US) et vérifiez que les critères d'acceptation sont remplis, cette story n'est pas terminée. Si ce n'est pas fait, les États-Unis vont bien sûr au prochain sprint. Et si tous vos États-Unis sont dans cet état, votre sprint s'est terminé sans aucune valeur ajoutée au projet. Du point de vue du client, je ne peux pas distinguer cela de toute l'équipe de développement en vacances.
L'un des principes lean (l'agile ne se termine pas avec la mêlée) dit que "la qualité est intégrée". Quelque chose n'est fait que s'il répond aux critères de qualité que vous définissez. Ceci est crucial pour avoir un véritable processus agile, la fin du printemps avec une valeur nulle ou des tests séparés du développement sont les symptômes d'un gros problème.
Il y a beaucoup de choses que vous pouvez faire:
l'automatisation est la clé du succès. Au moins au niveau du test unitaire, et certaines autres pratiques comme le CI sont également importantes. Ce n'est pas suffisant, mais s'ils sont bien effectués, ces types de tests entraînent peu ou pas de bogues découverts lors des tests manuels (généralement des choses d'interface utilisateur mineures). Si vous avez des personnes QA dédiées, ce sont elles qui peuvent automatiser les tests d'acceptation, et une partie de cette automatisation peut commencer avant la fin d'un sprint.
Regardez la taille de vos User Stories. Si vous avez un US qui est terminé les deux premiers jours du sprint le troisième jour, une personne QA peut le tester. À mon avis, avoir de petits antécédents d'utilisateurs (SMART) est l'une des choses les plus importantes pour réussir un développement agile, et beaucoup de gens ne semblent pas s'en rendre compte.
La collaboration entre le testeur et les développeurs est un autre élément clé du succès. Dans mon projet précédent, lorsque les États-Unis sont terminés par un développeur, une personne chargée de l'assurance qualité fait des "tests de paire" avec le développeur (peut être manuel, via le lancement de certains automatisés, ou mieux, les deux), cela fonctionne plutôt bien.
Le problème essentiel est que vous avez des programmeurs qui codent mais ne testent pas et des testeurs qui testent mais ne codent pas.
Résolvez ce problème et vous n'aurez pas ce problème, et une équipe sans doute plus efficace.
Une façon qui a fonctionné pour moi dans le passé était de suggérer aux codeurs et aux testeurs de coupler des histoires avec la tâche explicite de livrer une histoire entièrement testée. Parallèlement à cela, j'ai effacé toutes les formes de pensée "dev complete": pas de colonnes "dev complete" sur le tableau scrum/kanban/trello, pas d'attitude "dev done" par les codeurs.
Ce qui s'est passé était:
Les paires étaient responsables de la livraison des histoires et elles échoueraient toutes les deux si une histoire n'était pas terminée. Ils ont été traités comme des professionnels responsables chargés de fournir des logiciels et ils l'ont fait, dans la plupart des cas.
Le travail de test a été beaucoup moins effectué car les testeurs ont été exposés à des tests unitaires et d'intégration, de sorte qu'ils n'ont pas répété le même test manuellement.
Certains tests ont été automatisés lorsque les développeurs ont mieux compris ce dont les testeurs avaient besoin.
Certaines personnes se sont fâchées.
Les histoires ont été livrées plus rapidement en moyenne parce que le cycle de validation du code-validation est devenu presque instantané
Bien sûr, ce n'est que mon expérience anecdotique, mais vous voudrez peut-être essayer vous-même si vous le pouvez.
Dans votre cas, étant donné votre commentaire selon lequel les testeurs et les développeurs sont séparés de manière autorisée dans votre entreprise, le message me semble clair. Il y a un obstacle évident à la communication et à la collaboration mis en place par les règles de l'entreprise.
Il s'agit d'un problème de communication , pas d'un problème agile . L'adoption d'une méthodologie agile la rend tout simplement évidente. Les équipes en silo sont un anti-pattern de gestion conn , alors adoptez la non-adaptabilité de l'agile dans ce cas!
Le rôle réel de votre AQ est proche des tests d'acceptation. J'imagine que cela devrait être fait par une équipe distincte, qui agit davantage en tant que chef de produit plutôt qu'en tant que membre de l'équipe de développement.
Exemple: lors d'un sprint, vous devez ajouter une fonctionnalité qui permet de filtrer les résultats de la recherche selon différents critères. Votre mécanisme de recherche est déjà implémenté, mais les résultats sont classés par ordre alphabétique.
Pendant le sprint:
L'équipe rédige la conception de la nouvelle fonctionnalité et l'impact sur la base de code réelle.
Les développeurs écrivent des tests unitaires qui garantissent que l'ordre fonctionne comme prévu, et en même temps écrit le code réel.
La nouvelle fonctionnalité est soigneusement testée pour s'assurer qu'elle ne casse rien (test de régression) et qu'elle fonctionne comme prévu (tests unitaires).
Si possible et approprié , ce qui n'est pas le cas dans la plupart des projets, un responsable produit (et donc votre équipe AQ) peut évaluer constamment la nouvelle fonctionnalité afin d'empêcher l'équipe d'aller dans la mauvaise direction. Cela nécessite une intégration continue avec des dizaines de versions chaque jour.
Après le sprint, le propriétaire du produit évalue la nouvelle fonctionnalité pour vérifier qu'elle correspond aux besoins du client. Votre équipe QA est effectivement là, après la fin du sprint.
Je crois que vos problèmes réels sont les suivants:
Portée. Un sprint concerne votre équipe, et votre équipe uniquement, pas votre QA réel qui agit davantage en tant que propriétaire de produit.
Test. Le fait que vous ayez une équipe d'assurance qualité ne signifie pas que tout ce que vous avez à faire est d'écrire du code. Le travail de votre équipe est de fournir une fonctionnalité qui fonctionne comme prévu, de ne pas jeter de code pour que les autres testent. Si vous comptez sur l'équipe QA pour faire les tests pour vous, cela augmentera la coût global, car les bogues seront corrigés une à deux semaines plus tard au lieu d'être corrigés presque instantanément.
si tout ou partie du codage n'est pas fait avant la fin du sprint?
Pourquoi ne finit-il pas plus tôt? Cette limitation clé est la source de vos problèmes, et j'ai vu deux approches réussir. L'un s'intègre bien dans l'approche agile (mais pas dans les autres pratiques courantes) et les autres souillures un peu agiles (mais sont plus courantes).
La première est que vous ne codez pas avant la fin du sprint. En fait, l'écriture de code est une partie relativement petite du développement. Si vous terminez à mi-chemin du sprint, cela donne suffisamment de temps au QA pour faire son travail. Cela vous laisse également beaucoup de temps pour rédiger la documentation, nettoyer la dette technique, faire la conception des éléments de backlog ... Toutes les autres choses que vous devez faire pour un produit de qualité. Le seul inconvénient de ce que j'ai vu, c'est qu'il est presque impossible d'obtenir la fonctionnalité et les tests unitaires effectués aussi rapidement. Personnellement, je pense qu'il est tout à fait correct de faire des tests unitaires après laissant QA commencer à jeter un œil à la fonctionnalité, mais les partisans de TDD (et d'autres) seront en désaccord.
La deuxième option est d'avoir QA opérer un sprint derrière le personnel de développement comme votre PM déteste. J'ai également tendance à ne pas aimer cela. Il élimine le concept de "produit libérable" à la fin du sprint , même si vous avez un processus d'escalade pour vos versions. Pire encore, les développeurs se concentreront sur de "nouvelles" choses lorsque le contrôle qualité leur posera des questions ou des bugs de test. Les développeurs ont également plus de chances de corriger les bugs dans cet arrangement. Mais je ' Je l'ai vu produire à temps des logiciels de qualité.
Le Scrum Guide exige que les équipes soient interfonctionnelles. Tous les membres de l'équipe sont considérés comme des développeurs, quelle que soit leur spécialisation individuelle. Les individus en silo (codeur, testeur, qa, ux, etc.) sont inutiles dans Scrum. Les membres de l'équipe s'entraident partout où ils le peuvent. Il n'y a aucun concept de "passer l'élément à qa".
Dans votre situation, il semble que vous ayez un problème d'estimation. Lors de l'estimation des éléments de backlog de produit, vous devez prendre en compte les activités toutes, à savoir: le codage, les tests, la revue par les pairs, le déploiement, l'intégration - quelle que soit votre définition des demandes effectuées.
En règle générale, attendez-vous à apporter entre 5 et 15 éléments de backlog de produit dans un sprint. Cela vous donne une idée de la taille de chaque élément de backlog de produit. Cela vous donne également une excellente chance de faire le travail dans le sprint.
Enfin, la tâche de l'équipe consiste à déplacer un élément de backlog de produit vers "terminé", puis à passer au suivant. Parfois, cela signifie que les gens marchent les uns sur les autres et il est donc logique de générer plus d'un carnet de commandes de produits à la fois. Cependant, votre ligne directrice devrait être de réduire votre travail en cours (WIP) et de déplacer les éléments du carnet de commandes de produits vers terminés.
Les tests et le codage vont de pair. Vous pouvez le planifier module par module. Une fois le module terminé, vous pouvez le fournir aux testeurs. Tout ce scénario dépend également de la phase de test sur laquelle vous travaillez. modèle Spiral SDLC semble bon. En cela, les tests et le codage simultanés sont pratiques. Une autre approche pourrait être modèle V .
Ma réponse, qui est probablement assez étrange au début, serait: vous ne trouvez pas le temps de tester car vous pensez que les tests doivent être effectués sur les effets secondaires de code. Et avec effet secondaire, je veux dire le terme informatique :
une fonction (...) est réputée avoir un effet secondaire si, en plus de renvoyer une valeur, elle (...) a également une interaction observable avec (...) le monde extérieur.
J'ai évoqué la citation pour souligner la partie "interaction avec le monde extérieur": vous voulez que les tests se déroulent sur l'interface utilisateur telle qu'elle est imprimée à l'écran ("[pour commencer les tests] n'est pas vraiment possible car vous avez généralement besoin d'une fonctionnalité Interface utilisateur pour enregistrer ou créer des tests automatisés à partir de ").
D'autres réponses vous ont dit d'automatiser ce "test d'acceptation", afin qu'il puisse se produire rapidement. C'est vrai, mais cela ne résout pas complètement votre problème d'origine: que se passe-t-il s'il n'y a pas assez de temps pour écrire ces tests d'acceptation?
Vous devez abandonner votre vision des tests une fois que le code a interagi avec le monde extérieur, c'est-à-dire qu'il a imprimé quelque chose et attend une entrée. Le problème avec les effets secondaires est qu'ils ne sont en fait pas testables. Cela m'est apparu en lisant une interview avec Guido van Rossum, où il a dit qu'une déclaration qui éteint l'ordinateur ne peut être prouvée que par son exécution.
La solution à cette "non-testabilité" est de comprendre que, si vous avez prouvé une fois que la déclaration fonctionne, vous pouvez l'utiliser partout et compter sur elle pour faire son travail. Isolez-le dans une fonction et testez tout le reste.
En rapprochant cet exemple de votre question, la fonction est maintenant probablement une bibliothèque ou un framework complet, et au lieu d'arrêter l'ordinateur, elle imprime quelque chose: une interface utilisateur. Gardez les appels à elle aussi stupides et aussi stables que possible, car une fois que vous entrez dans cette partie de votre application, vous ne pouvez tester que via des tests d'acceptation coûteux, c'est-à-dire une sorte d'observation externe.
Considérer l'interface utilisateur en tant que "territoire étranger" est en fait un point de vue correct, car vous n'avez pas besoin de tester la logique d'une bibliothèque qui n'est pas fournie par vous, et peut-être surprenant, c'est un point de vue réaliste: avez-vous vraiment attendez-vous à jamais tester cet appel, par exemple MyWidget.draw() fait ce que vous attendez, au niveau d'un seul pixel?
Cela ne veut pas dire que les tests d'acceptation ne sont pas importants ou qu'ils peuvent être ignorés. Il est là pour rester et l'automatiser, comme d'autres réponses le suggèrent, présente d'énormes avantages. Mais si vous voulez trouver le temps de tester et de coder dans le même sprint, essayez de garder votre code aussi libre d'effets secondaires que possible.