Comment rendre les tests automatisés populaires? [fermé]

Notre base de code augmente depuis 20 ans maintenant. Nous sommes environ 10 développeurs + sqa travaillant avec 500kloc. Il y a quelque temps, une petite équipe d'entre nous (2 développeurs, un de sqa) a commencé à travailler sur un programme de test automatisé. Actuellement, une exécution prend 11h et est en quelque sorte un test d'intégration. Nous y travaillons pour réduire cela et réduire les faux positifs et nous progressons bien dans ce domaine. Mais les détails ne devraient pas avoir d'importance.

Cela fonctionne bien et nous continuons de l'améliorer. Nous (la petite équipe) l'aimons beaucoup. Si nous cassons quelque chose, nous remarquons un jour plus tard et non 2 mois plus tard que sqa jette un œil. De plus, nos managers (dev + sqa) aiment l'idée. Mais les autres membres de l'équipe ignorent simplement les résultats des tests. Dans leur esprit, si les tests échouent après un checkin, c'est un problème de test et non de changement de code et c'est juste notre projet de jouet. Nous avons eu plusieurs discussions si un échec de test est une vraie erreur. La plupart du temps, c'est le cas.

Nous ne pouvons pas et ne voulons pas imposer quelque chose. Comment montrer que les tests automatisés sont une chose?

Avertissement

Bien que je puisse ressembler à un manager, j'ai écrit cela en tant que développeur qui devait également être convaincu que les tests automatisés sont bons.

Vous devez comprendre la psychologie de base des développeurs. C'est un besoin intrinsèque des développeurs de valider du code. Tout ce qui les en empêche est une très, très mauvaise chose. Un test échoué est certainement quelque chose qui les empêche de le faire, ergo c'est une mauvaise chose. D'où la résistance.

Ce que vous devez souligner, c'est que, si les tests automatisés les ralentissent à court terme, à long terme, cela leur évitera beaucoup de chagrin et les accélérera, car ils pourront se concentrer davantage sur le développement de de nouvelles choses, et perdra moins de temps à faire autre chose que les développeurs détestent faire: corriger les bugs.

Et oui, vous devez l'appliquer. Vous devez obtenir le soutien inconditionnel de la direction et rendre l'écriture de tests automatisés obligatoire et non négociable. Au fil du temps, les développeurs s'y habitueront. Ce qui peut vous aider, c'est si vous pouvez concevoir des mesures qui montreront combien de nouveaux développements ont été effectués et de combien le nombre de bogues a été réduit depuis que vous avez introduit les tests automatiques. Les mots sont volatils. Les chiffres sont solides. Et les chiffres sont quelque chose qu'un développeur moyen comprend mieux que les mots. Si vous pouvez prouver en utilisant des nombres solides que les tests automatisés sont bons, vous y obtiendrez peu ou pas de résistance.

Dans leur esprit, si les tests échouent après un checkin, c'est un problème de test et non de changement de code et c'est juste notre projet de jouet. Nous avons eu plusieurs discussions si un échec de test est une vraie erreur. La plupart du temps, c'est le cas.

Voilà votre problème. Si vos tests sont irréguliers (même s'ils sont fiables «la plupart du temps»), alors les gens auront tendance à ignorer les résultats. Votre équipe d'automatisation doit se concentrer sur l'élimination de ces faux négatifs. Ce n'est qu'alors que le reste de l'équipe gagnera suffisamment de confiance dans les résultats pour lui faire réellement confiance.

Nous ne pouvons pas et ne voulons pas imposer quelque chose.

Vous devez absolument l'appliquer! Si quelqu'un pousse un nouveau code et que les tests échouent, le code doit être rejeté! C'est le seul moyen de gérer de manière fiable un projet logiciel plus important.