Casse tête d'analyste

bonjour

Nous avons décidé de partir sur du SCRUM pour une fonctionnalité importante à placer dans notre logiciel (qui est déjà en production).

le problème c'est que pour l'instant nous étions sur un cycle traditionnel en V. le passage de V à SCRUM risque d'être délicat notamment pour une des personnes qui a en charge de réaliser les SFD et les tests d'intégration.

D'après ce que j'ai pu voir sur l'agilité la composition d'un sprint est : Conception des Tests --> Réalisation des tests --> réalisation des Développement des US --> tests Technique (TDD) --> Tests Fonctionnels (ATDD).

Que devient cette personne en charges des SFD et de la réalisation des Test d'intégration dans ce contexte ?

Si elle doit travailler en Amont avec les PO pour établir les scénarios d'acceptances, elle réceptionne les USER STORY qu'à la sortie du sprint afin des les valider fonctionnellement alors comment gère-t-on les anomalies ? car le sprint est Terminé !

- Faut-il faire un retour arrière car les US ne sont pas valides et donc pas de transmission de US valorisées ?

- Faut-il livrer et placer les anomalies au prochain sprint donc le sprint en cours n'a rien délivré en terme de valeur et est donc nul ?

Si elle travaille dans le sprint je ne sais pas ce qu'elle peut faire ?
- Spécifier les écrans qui ne sont pas facile, spécifier les scénarios de test, concevoir les scénario de test avec un outil type TOSCA, Mais dans ce cas que fait l'équipe de développement en attendant ?

Dans le découpage de sprint (cf plus haut) je ne voit pas ce type d'approche

je suis désolé mais je suis complétement perdu qu' à la place de cet analyste dans SCRUM

merci de m'aiguiller

cordialement

:oops:

Hello

Désolé, mais il y a beaucoup d'idées reçues ou inexactes dans ce que tu écris.

• Pas SCRUM mais Scrum (ce n'est pas un acronyme)
• Scrum ne définit pas d'ordre ou de découpage au sein d'un sprint au niveau test et QA. L'équipe s'auto-organise pour livrer un incrément logiciel qui marche en fin d'itération, peu importe comment, c'est tout ce qui compte.
• Mettre "tests Technique (TDD)" après "réalisation des Développement des US" est absurde puisque TDD est justement une micro-boucle de réalisation (où on écrit 1 test en début de boucle).

Pour répondre à ta question, cela relève de la pratique et n'est défini dans aucune méthode agile, donc peu formalisé, même si des bouquins sont sortis sur le sujet. Je te donne ce qu'on fait dans mon équipe actuellement et que j'ai aussi vu pratiquer ailleurs :

Cette personne (je préfère "testeur" au terme "analyste" qui ne correspond pas trop à la réalité) est intégrée à l'équipe, la qualité est l'affaire de tous et n'est plus son domaine exclusif.
Quand on l'estime nécessaire, c'est à dire soit en avance de plusieurs sprints, soit pendant le sprint planning, voire exceptionnellement en cours de sprint, tout ou partie de l'équipe se met d'accord avec le Product Owner pour définir des critères d'acceptation pour une User Story du sprint. L'équipe écrit ensuite les tests d'acceptation qui seront utilisés pour déterminer si une Story est Done ou pas. Tout le monde doit être capable de les écrire et surtout de les jouer. Tout le monde doit avoir les critères d'acceptation à portée de main au début du sprint, de façon à pouvoir commencer à travailler directement. Une Story qui ne passe pas ces tests en fin de sprint sera rejeté (sauf avis contraire du PO).

Quel est le rôle du testeur dans cette équipe pluridisciplinaire ?

Il apporte sa rigueur et son expertise au moment de la définition des critères d'acceptation. Il est responsable de l'automatisation des tests d'acceptation quand c'est possible. Lorsque ce n'est pas le cas, il effectue une repasse manuelle de tous les critères d'acceptation lorsqu'une User Story devient "ready for test". Il peut aussi écrire des scénarios de test plus complets lorsque la complexité des cas d'utilisation le justifie.

Que fait le testeur quand ses petits camarades sont en train de réaliser les US ?

- Il automatise les AT
- Il prépare des jeux de données de test si nécessaire
- Il prépare des scénarios de test si nécessaire
- Il teste les éventuelles US déjà finies (personne n'a dit que toutes les US devaient s'étaler sur un sprint entier, ou alors c'est inquiétant...)

Par ailleurs, nous avons adopté une pratique où les développements s'arrêtent 1/2 journée avant la fin du sprint. Pendant ce temps, l'équipe de développement prépare les démos de fin de sprint et le testeur peut terminer de valider les dernières US.

Les anomalies sont corrigées dans le sprint lui-même (d'où l'intérêt d'être co-localisés pour la rapidité des échanges), faute de quoi la User Story est repoussée au sprint suivant, ce qui n'est pas grave en soi.