Comment adapter les tests dans les sprints Scrum et comment écrire des user stories dans Scrum
Je suis le chef d'équipe de développement d'un nouveau projet dans mon entreprise. Il s'agit du premier projet où l'entreprise utilisera Scrum. Nous avons une cascade/SDLC itérative. Les BA rédigent des documents sur les exigences, passent la main au développeur et au test, le développeur commence à développer et publiera les tests en itérations. Les testeurs prennent beaucoup de temps pour tester une version par laquelle les développeurs continuent le développement, mais aussi des corrections de bugs pour la version actuelle. J'ai quelques questions
- Dans un sprint avec disons 5 histoires quand sortez-vous pour le test? Est-ce dès qu'une histoire est terminée par le développeur ou après que toutes les histoires sont terminées, mais avant la fin du sprint, donnant au test le temps requis pour le tester.
- Si le BA écrit des user stories, quels devraient être les détails. Traditionnellement, il faut beaucoup de temps pour écrire une spécification avec l'ensemble de la mise en page, du comportement, du texte, etc. de l'interface utilisateur à finaliser. Je suppose que ma question est de savoir comment écrire des histoires qui sont implémentables et testables.
- Notre équipe de test n'est pas technique. Combien il est important d'avoir des tests d'interface utilisateur automatisés pour Scrum. L'interface utilisateur est basée sur WPF.
J'ai une solide expérience en développement en utilisant des méthodes agiles (TDD, revues de code, refactoring, etc.) mais nouveau dans Scrum.
modifier: Par itérations, je veux dire que s'il y a 100 exigences, nous pouvons passer aux tests lorsque nous avons terminé 30, 35, 35 exigences plutôt que d'attendre que les 100 exigences soient terminées.
Si les tests sont distincts du développement, vous avez deux équipes Scrum distinctes. C'est une mauvaise idée de travailler d'une main sur l'autre.
Vos développeurs doivent écrire leurs propres tests, séparés de cette autre équipe. Vous devez traiter cette autre équipe de "test" comme vos clients.
Dans un sprint ... quand sortez-vous pour les tests?
Quand le sprint est terminé. Complètement fait. Cela signifie que vous avez fait vos propres tests unitaires et êtes sûr que cela fonctionne. Une fois votre équipe de développement terminée, vous la communiquez à d'autres équipes pour "test" ou "déploiement" ou tout autre événement dans l'organisation.
Je suppose que ma question est de savoir comment écrire des histoires qui sont implémentables et testables.
Cela varie d'une équipe à l'autre. Le BA fait partie de l'équipe de développement. Vous devez y travailler en équipe (BA plus développeurs) pour obtenir la bonne quantité de détails. C'est un effort d'équipe pour obtenir les bonnes informations de BA au reste de l'équipe.
Combien il est important d'avoir des tests d'interface utilisateur automatisés pour Scrum.
Essentiel. Complètement requis pour tout développement d'interface utilisateur. Les développeurs doivent faire tous les tests eux-mêmes avant c'est donné à "l'équipe de test". S'il y a une interface utilisateur, ils doivent la tester. S'il n'y a pas d'interface utilisateur, les tests d'interface utilisateur automatisés ne sont pas nécessaires. Un test est requis et une interface utilisateur doit être testée. Les tests automatisés sont la meilleure pratique actuelle.
Conclusion. Une équipe de "test" séparée et un BA qui écrit chaque petit détail n'est pas une organisation optimale pour Scrum. Scrum signifie que vous devez repenser votre organisation ainsi que vos processus.
La plupart des réponses que je vais donner concernent une méthode Agile de développement logiciel par rapport à une méthode Iterative Waterfall. Scrum se trouve être une implémentation Agile populaire.
Dans Scrum typique, il n'y a pas de phase de test séparée, car des tests formels doivent avoir lieu tout au long du sprint. Lorsqu'un développeur termine une User Story, la ressource QA doit déjà avoir ses cas de test préparés et commencer les tests à ce stade. Si leurs cas de test réussissent, ils acceptent la user story et passent à la suivante. Une fois toutes les User Stories terminées et acceptées, le sprint est terminé et vous commencez la suivante. Tout cela dépend bien sûr de l'intégration continue, donc les changements de développement sont immédiatement disponibles pour QA. Les développements ultérieurs doivent suivre les directives TDD pour garantir que les tests de régression sont aussi rapides et indolores que possible.
C'est une bonne idée pour les BA d'écrire des user stories, mais pour un contrôle plus détaillé et spécifique, les User Stories peuvent accompagner les documents formels des exigences. La User Story doit être écrite du point de vue d'un seul utilisateur par rôle. Il exprime un besoin du point de vue de l'utilisateur, donc tout naturellement si le logiciel satisfait actuellement tous les aspects de ce besoin, alors l'histoire de l'utilisateur est satisfaite. Les user stories peuvent être composées de user stories enfants et de tâches assignables. Il peut y avoir un chevauchement dans les tâches pour plusieurs user stories.
Les tests automatisés de l'interface utilisateur peuvent être une bonne chose, mais je pense personnellement que plus d'efforts sur les méthodes TDD et la couverture à 100% des tests unitaires de toute la logique applicative sont plus importants. La plupart des équipes de développement de logiciels ne semblent pas atteindre une couverture à 100% de Business Logic, donc à mon avis, les tests automatisés de l'interface utilisateur seraient une perte de temps précieux qui pourrait être utilisée pour écrire plus de tests unitaires pour BL. C'est un luxe pas un besoin à mon avis.
Dans Scrum, vous êtes censé produire un incrément logiciel potentiellement livrable à la fin de chaque sprint. En conséquence, Scrum promeut le concept de équipe entière ou équipe interfonctionnelle où chaque compétence requise pour mener une user story donnée à faire doit être présente dans l'équipe.
Dans mon projet actuel, étant donné qu'une histoire entièrement testée fait partie de notre définition du fait, nous avons intégré des testeurs dans les équipes. Pendant les premiers jours d'un sprint, pendant que les développeurs commencent à travailler sur les premières user stories, les testeurs prépareront des scénarios de test et configureront certaines données de test. Dès que le développement de l'une des user stories est terminé, ils le testent.
C'est l'une des plus grandes difficultés de Scrum IMO. Vous devez trouver la bonne quantité de spécifications nécessaires pour obtenir une histoire d'utilisateur implémentable et testable. Une analyse, une documentation et des spécifications trop poussées aboutiront à un plan rigide qui se révélera inévitablement faux au cours du sprint. Inversement, une user story qui n'a pas été clairement définie et exprimée par le Product Owner entraînera une bande passante de communication saturée entre les développeurs et le PO pendant le Sprint et des retards de développement tandis que le PO prend des décisions sur les user stories à mi-parcours du sprint. .
Dans notre cas, nous avons défini la bonne quantité de détails pour une user story comme 1/une description sous la forme "comme ... je veux ... pour que ..." et 2/une série d'acceptation Critères. Nous faisons rarement des maquettes de l'interface utilisateur à l'avance, cela peut se produire pendant les plannings de sprint, mais ce sont davantage des esquisses qui sont rejetées par la suite.
D'après mon expérience, les tests automatisés de l'interface utilisateur prennent beaucoup de temps et sont extrêmement fragiles. Il y a façons de le faire dans WPF mais je réfléchirais soigneusement au coût d'entretien de ces tests avec les avantages avant de procéder de cette façon.
Travailler dans des itérations de plus en plus courtes rend tous ces transferts de plus en plus coûteux. Vous pouvez réduire ces coûts en suivant une règle stupide et simple: réduire de moitié la taille des lots, changer la façon dont vous travaillez pour le rendre confortable, répétez jusqu'à ce que vous soyez heureux.
Prenez votre exemple de sprint à 5 étages. Si vos équipes sont habituées à écrire le code pour les 5 histoires, puis à tester les 5 histoires, la taille du lot est de 5 histoires. Coupez ça en deux. Dans le prochain sprint, travaillez d'abord sur les 3 histoires les plus urgentes, en les préparant pour les tests le plus tôt possible. Pendant que les testeurs testent ces 3 histoires, les autres peuvent préparer les 2 histoires restantes pour le test. Cela provoquera des douleurs de croissance. Changez votre façon de travailler afin de rendre cela plus confortable.
Par exemple, plus de personnes travailleront ensemble sur chaque histoire, alors essayez plus de jumelage et voyez si cela vous aide à travailler plus régulièrement. Ou, peut-être, les testeurs trouveront des problèmes dans l'histoire 2 qui distraient certains programmeurs pendant qu'ils essaient de travailler sur l'histoire 5, alors encouragez les programmeurs et les testeurs à sprinter à discuter plus tôt comment tester l'une des histoires du "premier lot" "afin que les programmeurs soient moins susceptibles de faire une erreur qu'un testeur peut facilement détecter avec un test.
Cela peut prendre quelques sprints pour résoudre les gros problèmes associés aux testeurs testant un petit lot d'histoires tandis que les programmeurs travaillent sur le prochain lot d'histoires. Une fois que cela devient confortable, coupez à nouveau la taille du lot de moitié. Et encore. Dans un an environ, l'équipe testera confortablement les histoires car les programmeurs pensent qu'ils ont fini avec eux et faisant probablement moins d'erreurs en cours de route. Chaque histoire se fera plus tôt.
Bien sûr, à ce stade, vous pouvez maintenant faire la même chose avec les lots que l'équipe reçoit des propriétaires de produits ou que l'équipe expédie à l'organisation des opérations. Etc. À ce stade, vous pouvez aborder la question "combien de détails les BA devraient-ils écrire pour les histoires?" problème.
Soit dit en passant: pour que les testeurs puissent réduire leur délai d'exécution, ils devront adopter une certaine automatisation, par une combinaison d'apprentissage de l'automatisation et de programmeurs les aidant à automatiser. Lorsque vous essayez de réduire la taille des lots, vous découvrirez quand vous devez résoudre ces problèmes. N'ajoutez pas d'automatisation simplement parce qu'un livre en dit que vous en avez besoin.
J'espère que cela vous aide.
Je veux juste partager quelques expériences comme ci-dessous, j'espère que cela vous sera utile.
Dans un sprint avec disons 5 histoires quand sortez-vous pour le test? Est-ce dès qu'une histoire est terminée par le développeur ou après que toutes les histoires sont terminées, mais avant la fin du sprint, donnant au test le temps requis pour le tester.
Pour chaque grande histoire d'utilisateur, elle doit être décomposée en plusieurs sous-tâches et lorsque les sous-tâches sont entièrement effectuées par le développeur, elles doivent être publiées sur QC pour être testées immédiatement. Le défaut doit être corrigé après le test pour ces sous-tâches terminer le test.
Si le BA écrit des user stories, quels devraient être les détails. Traditionnellement, il faut beaucoup de temps pour écrire une spécification avec l'ensemble de la mise en page, du comportement, du texte, etc. de l'interface utilisateur à finaliser. Je suppose que ma question est de savoir comment écrire des histoires qui sont implémentables et testables.
Dans Scrum, les user stories doivent être dans n'importe quel format tant que les conversations entourant les stories se produisent et ne devraient pas être terminées ou statiques. Une petite histoire, appelée simplement une histoire d'utilisateur, est une histoire bien comprise et qui peut être mise en œuvre dans un sprint. La priorité d'une histoire peut être basée sur le retour sur investissement, la valeur commerciale ou tout autre élément que l'utilisateur juge important. Il s'agit des activités de PO.
Notre équipe de test n'est pas technique. Combien il est important d'avoir des tests d'interface utilisateur automatisés pour Scrum. L'interface utilisateur est basée sur WPF
L'application des tests d'automatisation dans Scrum est une activité assez difficile. Parce que toutes les fonctions sont implémentées de manière incomplète et pas vraiment stable pour permettre à QC d'implémenter le cas de test par un outil de test automatique. Cela devrait être fait pour un sprint appelé: régression.