L’approche par les systèmes
Peut-être que la plus grande chose que j’ai appréciée en passant de mes poursuites académiques au développement de logiciels open source, c’est l’importance des tests et de l’automatisation des tests. En academie, il n’est pas exagéré de dire que nous enseignons aux étudiants à tester seulement dans la mesure où nous avons besoin de cas de test pour évaluer leurs solutions, et nous faisons exécuter des bancs de tests aux étudiants de troisième cycle pour collecter des données quantitatives pour nos articles de recherche, mais c’est à peu près tout. Il y a certainement des exceptions – par exemple, les programmes axés sur l’ingénierie logicielle – mais mon expérience est que l’importance accordée aux tests en academie est mal alignée avec son importance dans la pratique. Une grande partie de la bande passante de l’équipe de l’approche par les systèmes a été consommée ces derniers mois par des efforts pour accroître la robustesse et l’utilisabilité d’Aether, une plateforme de bord pour le déploiement de services 5G privés. Et bien sûr, vous ne pouvez pas avoir une plateforme robuste et utilisable sans tests, ce qui s’est avéré être un point douloureux. C’est donc ce qui a fourni l’inspiration pour cette dernière colonne, alors que nous essayons d’apporter la vision des systèmes aux tests. J’ai dit que j’appréciais le rôle des tests logiciels, mais je ne suis pas sûr de les comprendre avec suffisamment de clarté et de profondeur pour les expliquer à quelqu’un d’autre. Comme c’est la nature de notre état d’esprit de l’approche par les systèmes, j’aimerais mieux comprendre les « pourquoi », mais surtout ce que je vois et entends, c’est beaucoup de jargon: tests unitaires, tests de fumée, tests de trempage, tests de regression, tests d’intégration, etc.
