Comment puis-je commencer les tests dans une anticulture de tests? [fermé]

J'ai une confession à faire: les tests automatisés formalisés n'ont jamais fait partie de mon expérience en programmation. Je travaille maintenant dans une très grande entreprise avec de nombreux développeurs (la plupart d'entre eux sont des développeurs Web d'une sorte ou d'une autre), et il est évident que la plupart d'entre eux ne testent pas * non plus. (* Je ne vais pas continuer à le dire formellement ; veuillez en déduire.)

Si j'attends d'avoir le soutien de mon organisation pour commencer les tests, cela n'arrivera jamais. Si j'essaie de «changer les choses de l'intérieur» en poussant les tests à la direction, je serai à bout de souffle avant que le changement ne se produise. Je dois commencer les tests maintenant.

Mais avec TDD et ses semblables, je vais finir avec beaucoup de code de test en même temps que le code de production. Nos systèmes de contrôle de version (tous centralisés) ne sont pas organisés pour stocker le code de test. Je vais devoir trouver une place pour tout ça sur mon poste de travail.

Est-il possible de commencer une pratique personnelle de tests de logiciels dans une culture qui ne valorise pas ou ne fournit pas les outils pour cela? Quelles techniques et outils utilisez-vous pour vous permettre de tester lorsque les outils et l'organisation officiels n'ont pas de place pour les tests, les frameworks et les automatisations?

J'ai personnellement fait cela avec un succès considérable. Les facteurs clés de succès:

• Obtenez un support de gestion (provisoire). Les avantages des tests automatisés sont bien documentés et devraient convaincre tout gestionnaire de l'essayer. Cela comprend la recherche d'une place dans le VCS et un serveur de build, car
• Les tests automatisés ne fournissent leur pleine valeur que s'ils sont exécutés fréquemment et automatiquement afin que vous soyez au courant des problèmes rapidement et que vous n'ayez pas à compter sur des personnes qui n'oublient pas de les exécuter. Vous avez besoin d'un serveur de build qui les exécute au moins quotidiennement. Il peut s'agir d'un ancien poste de travail. Jenkins prend très peu de travail pour démarrer.
• Mener par l'exemple. Écrivez des tests, parlez des avantages qu'ils vous offrent et, lorsqu'ils révèlent des erreurs introduites par d'autres développeurs, parlez-en en termes de protection contre une gêne potentiellement beaucoup plus grande.
• Optez pour les fruits bas. Certaines parties de l'application seront difficiles à tester, d'autres faciles. Certains seront robustes, d'autres cassants. L'écriture de tests pour des pièces fragiles mais faciles à tester fournit le plus de valeur dans les plus brefs délais.
• Voyez si vous pouvez écrire des tests réutilisables, par exemple des conventions de test ou des fonctionnalités que tous les modules (pages Web, services REST, etc.) doivent avoir mais qui sont souvent oubliés.

Sans aide à la gestion, vous êtes mort dans l'eau. La direction prétendra que vous ne faites pas de travail utile, vous serez pénalisé dans vos commentaires et finalement vous serez licencié. Il existe des moyens d'amener la direction à voir que les tests précoces leur coûtent moins cher et tout cela. Il est possible de changer la culture mais vous mettez votre cou sur le bloc de coupe.

Je suggérerais de lire le chapitre de Machiavel le Prince sur la façon d'introduire le changement avant de faire quoi que ce soit.

D'après mon expérience, si la culture est anti-test, vous ne pouvez pas raisonnablement l'introduire. Soit les tests seront vus comme une perte de temps et vous serez réprimandé pour avoir "perdu du temps" ou "pris trop de temps", soit le code s'est débarrassé d'années de ne pas être écrit de manière testable (par exemple pas d'interfaces, tout étroitement couplé) et vous devrez passer beaucoup de temps à refactoriser et / ou réécrire le code (ce qui risque de "prendre trop de temps" et de "perdre du temps") pour le rendre testable afin que vous puissiez écrire des tests en premier lieu .

Vous pourriez avoir une chance si vous faites des trucs greenfield qui n'ont qu'à interagir avec des choses existantes (créer une belle enveloppe autour des mauvaises zones) ou si vous pouvez le faire en petites quantités où cela ne causera pas de problèmes ou vous obligera à "travailler sur des tâches qui ne vous sont pas assignées" qui peuvent vous mettre dans la niche.

Je ne pense pas que vous irez très loin jusqu'à ce que vous puissiez prouver suffisamment qu'il existe un problème (qui peut ne pas être actuellement reconnu) que les tests automatisés peuvent résoudre.

S'il existe une culture de tests manuels par rapport à des scripts définis, il y a un coût d'exécution de ces scripts associé à un risque de résultats incomplets ou inexacts. Il peut y avoir une histoire (documentée ou sous forme de «récit de guerre») de cela. Suggérer un projet pilote pour automatiser certains de ces tests manuels en vue de réaliser une économie de coûts à long terme.

S'il n'y a même pas de fonction de test manuel, je dirais que l'entreprise ne perçoit pas qu'un quelconque type de test formel, automatisé ou non, a de la valeur. Dans ce cas, je considérerais que le chemin à parcourir est long et fortement ascendant, mais encore une fois, il faudra probablement une démonstration claire que l'entreprise peut bénéficier d'une approche moins décontractée de la qualité logicielle. Si vous ne pouvez pas faire cela, il est difficile de voir comment il pourrait y avoir un soutien pour l'idée sur des bases commerciales.

Une idée est que vous visiez à écrire un test qui prouve que le code que quelqu'un d'autre a écrit est défectueux. Devrait vendre le concept.