À quelle étape d'Agile (SCRUM) devons-nous commencer à créer des tests d'automatisation?

9

Un peu de fond de moi - Je suis un testeur manuel depuis près de 2 ans dans un environnement Agile utilisant SCRUM (1-2 semaines de sprints). Je souhaite donc introduire les tests d'automatisation dans mon travail à l'aide de Selenium WebDriver (avec Java).

Ma question est de savoir quand dois-je tester les fonctionnalités manuellement et quand dois-je les convertir pour les tests d'automatisation?

J'ai lu et obtenu différentes approches, telles que:

Lorsqu'un nouveau sprint démarre, convertissez les user stories en scripts automatisés du sprint précédent, OR;
Convertissez les user stories dans le même sprint.

Tout conseil / s serait très apprécié. Merci d'avance.

— Geai
source

4

Veuillez ne pas poster la même question sur deux sites d'échange de pile différents. Veuillez en supprimer un.

— R Sahu

2

Cross publié sur sqa.stackexchange.com/questions/27017/… .

— R Sahu

13

L'automatisation des tests (et tous les autres tests) devrait faire partie de la définition de terminé . Ceci afin de faire un produit potentiellement livrable. Pouvez-vous expédier s'il n'a pas été testé?

Les tests doivent également être une approche d'équipe, donc l'automatisation des tests n'est pas la responsabilité des testeurs. Commencez à penser aux tests dès que possible dans le processus.

L'automatisation des tests est si importante dans Agile car:

L'agilité organisationnelle est limitée par l'agilité technique

En d'autres termes, lorsque vous tardez à apporter des modifications à votre produit, peu importe la façon dont vous structurez vos équipes, votre organisation ou le cadre que vous adoptez, vous serez lent à répondre aux changements.

https://less.works/less/technical-excellence/index.html

Si vous retardez les tests jusqu'à une autre itération, vous serez toujours à la traîne. Il est plus difficile de changer la direction du produit car il est plus difficile de refaçonner et de protéger le comportement extérieur du produit. Avoir des tests manuels répétitifs est la clé pour vous ralentir, automatisez-le!

De nombreux testeurs vous diront que vous ne devez pas commencer à tester de bout en bout avant que l'interface du produit ne se soit stabilisée. N'attendez pas, utilisez plutôt PageObjects et assurez-vous que vos tests sont maintenables et faites-en la responsabilité du développeur de les créer et de les corriger.

— Niels van Reijmersdal
source

Je ne suis pas d'accord sur le premier "devrait". La définition de fait est quelque chose que l'équipe Scrum doit déterminer par elle-même. Si l'équipe considère que les tests automatisés sont importants, elle les inclura dans leur définition. Cependant, le processus lui-même ne dit pas qu'ils doivent, ni même qu'ils devraient. C'est quelque chose qui appartient entièrement à l'équipe, et il n'y a pas de bonne, de mauvaise ou de réponse préférée.

— 2017 à 13h17

@aroth, je suis d'accord avec vous, mais dans presque tous les cas, vous créez un logiciel plus grand que vous souhaitez ajouter des tests au DoD. C'est pourquoi je pense qu'il est bon de dire aux gens que vous devriez, au moins y réfléchir sérieusement. En tant que testeur, je pense que le test final par une équipe distincte est le premier pas vers Wagile. Mais oui, il existe des situations et / ou des cas où les tests peuvent même ne pas être nécessaires.

— Niels van Reijmersdal

2

L'essentiel est que vous ne marquiez pas une histoire comme terminée à moins d'avoir écrit des tests automatisés pour cette histoire.

Donc, 1 semble être absent, car vous écrivez des tests pour une tâche terminée dans un sprint précédent. que faire si les tests échouent?

— Ewan
source

Donc, si au cours de la première semaine d'un nouveau sprint, aucune histoire d'utilisateur de ce sprint n'est en état de pouvoir être testée par régression, vous suggérez que l'OP devrait rentrer chez lui et ne rien faire? Cela ne me semble pas très efficace ;-)

— Doc Brown

Le testeur devrait utiliser cette première semaine pour remettre en question la spécification "hmmmm en tant qu'utilisateur, je m'attendrais à une musique de fond sur ma page Web .." trouver des bugs dans des histoires incomplètes et généralement créer des problèmes. Les développeurs sont autorisés à dire qu'ils ne peuvent pas commencer jusqu'à ce que les plans de test soient écrits

— Ewan

@DocBrown: dans la première semaine d'un nouveau sprint, le testeur a une quantité incroyable de travail à faire. Ils doivent comprendre ce que les développeurs construisent en travaillant avec le propriétaire du produit et les développeurs. Ils doivent travailler avec le développeur pour s'assurer qu'ils rendent le code testable. Ils peuvent commencer à travailler sur un plan de test automatisé. Ils peuvent même commencer à écrire des tests. Si vous disposez d'un framework de test approprié où vos tests sont écrits à un niveau d'abstraction élevé, vous pouvez les écrire avant que le code ne soit prêt.

— Bryan Oakley

1

Idéalement, vous devriez écrire des tests automatisés dans le même sprint que le code est écrit. Le code ne doit pas être considéré comme «terminé» tant que les tests automatisés n'ont pas été écrits, et vous devez mettre le code à l'état «terminé» à la fin d'un sprint.

Vous devez démarrer le processus le premier jour du sprint en travaillant avec le développeur pour comprendre le code et pour l'aider à comprendre vos besoins en tant que testeur. Par exemple, si vous créez des pages Web, vous pouvez les aider à comprendre la nécessité d'ajouter des identifiants uniques pour chaque élément de page avec lequel vous devez interagir.

N'oubliez pas qu'en scrum, votre travail n'est pas d'écrire des tests. Votre travail consiste à travailler avec l'équipe pour atteindre les objectifs de sprint. Cela signifie la communication et la collaboration, ce qui devrait se produire très tôt dans le sprint. Vous pouvez commencer à travailler sur les conceptions et les plans de test bien avant que le code ne soit prêt à être testé.

— Bryan Oakley
source

0

Si vous allez tester automatiquement, vous pourriez aussi bien créer les tests à l'avance. Cela vous aidera à définir quel comportement vous attendez et vous stimulera à penser comme un client, cela devrait rendre votre logiciel plus utilisable à la fin. Et vous bénéficierez immédiatement du test lorsque vous implémenterez la fonctionnalité.

— Martin Maat
source

1

Cela ne fonctionne pas avec les outils de test d'interface utilisateur comme Selenium. Vous avez besoin d'une interface utilisateur fonctionnelle et stable pour pouvoir créer les tests.

— Doc Brown

@DocBrown: Je ne pense pas que ce soit nécessairement vrai. Si vous me donnez une spécification pour une nouvelle page Web, je peux commencer (et peut-être terminer!) Écrire des tests automatisés avant que la page ne soit écrite. Il vous suffit de collaborer avec le développeur pour que vous soyez tous les deux d'accord sur la structure de la page, les identifiants des éléments, etc.

— Bryan Oakley

0

Vous pouvez faire l'une ou l'autre, mais vous souhaitez généralement cibler les tests de régression avec des tests d'automatisation. Cela signifierait que je ferais du manuel jusqu'à ce que vous soyez sûr qu'il est suffisamment solide pour être un test de régression. Cela peut être au milieu d'un sprint pour certaines fonctionnalités et peut être dans un futur sprint pour d'autres fonctionnalités.

— cabot
source

0

Comme cela a été indiqué dans une autre réponse , lorsque les tests ont lieu, cela devrait faire partie de la définition de fait . Cependant, je ne suis pas d'accord avec certaines de ces réponses, donc je voulais développer les expériences que j'ai rencontrées.

Dans un environnement vraiment agile, tout le monde peut tout faire. Il n'y aurait pas quelqu'un à 100% dédié aux tests, vous développeriez également des compétences pour vous aider dans certains travaux de base sur l'interface utilisateur, ou autre chose. Cependant, nous vivons rarement dans un monde idéal.

Ce que je recommanderais serait de faire un peu une approche hybride. Pour votre définition de Terminé, je dirais que les tests manuels devraient faire partie du Sprint dans lequel le travail est codé. une. En vous concentrant sur les tests manuels, vous vous familiarisez avec ce que le code est censé faire. Au début du prochain Sprint, lorsque vous n'aurez peut-être pas autant à faire, vous pouvez configurer vos tests automatisés qui peuvent s'exécuter dans le cadre du processus de génération pour éviter les erreurs de régression.

— krillgar
source

Je n'ai jamais vu de sprint où il n'y avait pas encore beaucoup à faire sur les objectifs de sprint actuels le premier jour. Écrire des tests automatisés nécessite une collaboration et une planification, et cela devrait commencer dans la première heure du premier jour du sprint.

— Bryan Oakley