Quand automatiser les user stories?

Si vous avez travaillé dans un environnement agile en tant que QA, vous auriez probablement rencontré une sorte d'automatisation des tests. Je ne parle pas de l'automatisation des tests unitaires, qui est généralement une activité centrée sur les développeurs, mais de l'automatisation des tests d'acceptation fonctionnelle qui est normalement effectuée par le contrôle qualité ou le nouveau rôle sophistiqué de développeur de logiciels dans les tests.

Tout d'abord, examinons certains critères et raisons pour lesquels l'automatisation des tests devrait répondre à la question «Pourquoi les tests devraient / ne devraient pas être automatisés»



Répétabilité

Les tests automatisés doivent être répétables et la sortie doit être cohérente à chaque exécution afin que les développeurs puissent se fier aux résultats des tests. Cela signifie également que nous n’automatiserions normalement pas un test s’il n’est exécuté qu’une seule fois; la seule exception à cela est si vous exécutez un test sur un très grand nombre de données, comme la vérification d'un script de redirection de lien avec de nombreux liens.




Fiabilité

Les tests automatisés devraient vraiment vérifier les vérifications correctement et être en mesure de déterminer les résultats réels par rapport aux résultats attendus valides. Cela signifie également que si les résultats ne peuvent pas être déterminés facilement ou que les tests automatisés sont sujets à des problèmes d'environnement pouvant entraîner des faux positifs dans les résultats des tests, les tests ne peuvent pas être fiables.



Temps

Les tests automatisés devraient également nous faire gagner du temps. Si un test simple prend 10 minutes à compléter mais que le même résultat peut être déterminé manuellement en 1 minute, il est préférable de ne pas automatiser ces tests.




Filet de sécurité

Les tests automatisés devraient fournir un filet de sécurité aux développeurs afin que tout écart par rapport à un bon code de travail, résultant de modifications apportées à la base de code, soit rapidement mis en évidence et signalé aux développeurs.



Quand les stories doivent-elles être automatisées?

Dans un sprint typique, disons qu'il y a 7 histoires qui sont engagées dans un sprint dont 5 sont de bons candidats pour être automatisées en fonction des critères ci-dessus. Mais quel est le meilleur moment pour automatiser ces histoires? Devrions-nous écrire les tests automatisés au fur et à mesure du développement des fonctionnalités? Doit-on attendre qu'une fonctionnalité soit développée et ensuite écrire les tests automatisés? Doit-on attendre la fin du sprint pour ensuite automatiser les histoires?

Dans certains cas, lorsque les histoires sont des corrections de bogues ou une légère modification ou amélioration d'une fonctionnalité existante, il est tout à fait logique d'écrire les tests automatisés lorsque la fonctionnalité est modifiée par les développeurs. Il peut même y avoir un test automatisé existant pour la fonctionnalité en cours de modification dans lequel il vous suffit d'ajuster le script pour s'adapter aux nouvelles modifications.

Dans d'autres cas, lorsque l'histoire concerne la mise en œuvre d'une nouvelle fonctionnalité dans l'application, comment savoir à quoi ressemblera le produit final pour pouvoir écrire des tests à l'avance? Ici, je ne parle pas des fichiers de fonctionnalités qui décrivent les tests d'acceptation à l'avance, mais des montages réels ou des tests de sélénium (la mise en œuvre des tests) qui s'exécutent sur le code livré.


L'essentiel est que tout test qui sera effectué plus d'une fois doit être automatisé. Et quels tests allons-nous exécuter plus d'une fois? Tests de régression. Et que sont les tests de régression? Tests qui déterminent si l'application a régressé dans ses fonctionnalités suite aux nouvelles modifications et fonctionnalités.

Mais, vous ne pouvez écrire de bons tests de régression automatisés que sur un système stable, bien compris et déterministe en termes de comportement avec des entrées et des sorties connues.

Le problème en essayant d'écrire des tests automatisés sur une fonctionnalité au fur et à mesure de son développement est que vous pourriez potentiellement passer beaucoup de temps et beaucoup d'efforts à écrire des scripts automatisés contre quelque chose qui est volatile et sujet à des changements constants au cours du sprint. De plus, combien de fois avons-nous vu une histoire engagée dans un sprint, puis retirée du sprint? Ensuite, nous avons perdu du temps à écrire quelque chose qui n’a pas été intégré au système.

Certaines organisations imposent même une règle stricte selon laquelle une histoire n'est pas «terminée» tant qu'elle n'est pas entièrement automatisée! Allons-nous arrêter la publication d'une fonctionnalité importante parce que le contrôle qualité n'a pas ou n'a pas pu fournir d'automatisation à temps pour diverses raisons? Ou une histoire n'est pas «terminée» parce que nous n'avons pas de script automatisé pour vérifier l'existence d'un bouton sur une page. Sérieusement?


Le meilleur objectif des tests d'automatisation est les tests de régression et les tests de régression sont toujours exécutés sur un état connu et un système déterministe pour pouvoir détecter les changements dans la ligne de base, et pour obtenir un résultat significatif d'un test automatisé, ce n'est que lorsque le test a été exécuté. et passé manuellement au moins une fois, afin que vous puissiez comparer les résultats de l'exécution automatisée à l'exécution manuelle.

Selon cette définition, les histoires doivent être automatisées (la mise en œuvre) dans le sprint et uniquement lorsque la fonctionnalité est entièrement vérifiée manuellement. Une fois que l'histoire est terminée et qu'elle est d'abord vérifiée manuellement, il s'agit d'une fonctionnalité fiable et d'un système stable sur lesquels vous pouvez ensuite concevoir et écrire des tests automatisés. Une fois le test automatisé mis en œuvre, il est ensuite ajouté à la suite de tests de régression pour surveiller et détecter les défauts de régression au fur et à mesure que les fonctionnalités suivantes sont développées.