Et si on prenait le problème à l'envers ?
Pour résumer la flopée de réactions - plus pertinentes les une que les autres - on pourrait dire :
- Le logiciel fiable n'existe pas.
- Les budgets pour tester sont inexistants.
- Les Chefs de projets ont d'autres chats à fouetter (les développeurs ?)
- Les développeurs ont d'autres chats à fouetter (leurs compilateur ?).
- Les clients sont des crétins incapables d'exprimer leurs besoins correctement.
- Les outils sont déjà buggés à la base (certes c'est pas forcément faux).
- Le développement en n-tiers devient inextricable (hélas ce n'est que trop vrai).
- etc.
Est-ce une raison pour baisser les bras ? Est-on condamné à ne plus jamais fournir un logiciel fonctionnant correctement et suffisamment solide pour résister aux attaques de base ( j'écarte les attaques ciblées qui nécessitent des moyens différents) ?
Non !! ai-je envie de répondre et , comme je le dis dans le titre du message, tentons de prendre le problème à l'envers...
Comme il apparait plutôt difficile de "dresser" les étages supérieurs (direction de projet - client - etc.) replions-nous sur nous même et mettons en œuvre des moyens, les plus simples possibles pour, à minima, mettre en évidence que les dysfonctionnements ne sont pas de notre responsabilités (note : si chacun se met dans cette situation, quelle que soit sa position et sa responsabilité, ça devrait finir par porter ses fruits - expérience(s) vécue(s)).
Commençons par "en bas" : les développeurs :
Dernier maillon de la chaine - parfois , hélas, seul maillon de la chaine - c'est sur lui que ça finira par retomber; donc, ami développeur et tête de Turc, source de tous les ennuis de la planète, de l'univers et au delà, que faire ?
Et bien, utilisons un truc plutôt pratique et sécurisant : les tests unitaires ! Non ! ne partez pas tout de suite, je vais essayer de vous prouver que :
- Ca ne prend pas plus de temps d'en faire que de ne pas en faire.
- Ca va aider à faire le nécessaire et RIEN QUE le nécessaire.
- Ca va permettre de prouver que ce que vous avez fait est ce que l'on vous a demandé en rien d'autre.
- Les "merdes" ne sont pas de votre responsabilités.
- Si les spécifications changent, vous êtes prêt a les prendre en compte.
- Ca va sortir dans les temps.
- Cerise sur la gâteau, ça sera testé.. sérieusement
Allons au fait : les tests unitaires, c'est quoi ?
Pour faire simple, un test unitaire est un bout de code, généralement exécuté dans un environnement particulier, qui va torturer un autre bout de code, bien souvent dans des conditions non conformes aux spécifications, qui a pour but de s'assurer de deux choses :
- Dans les cas prévus, le bout de code fonctionne correctement.
- Dans tous les autres cas, le bout de code ne s'exécute pas et réagi d'une façon ou d'une autre pour prévenir l'appelant que ça ne s'est pas passé comme prévu.
Notez bien, le "Dans tous les autres cas", c'est ça qui est important, la méthode pour faire du "soviétique" est de dire : c'est prévu pour marcher comme ça et rien de plus, on ne se pose pas de question du genre : "et si...."; c'est pas prévu ? on refuse de traiter le problème, et on passe à la suite.
Un exemple : Qu'est ce qu'un code postal français ?
réponse : un champ alphanumérique de 5 caractères ne comportant que des chiffres. (accessoirement, on peut ajouter "existant dans la liste de référence de la poste disponible auprès des services pro de la poste").
Donc, la validation (initiale) d'un champ code postal passera par la vérification qu'une donnée genre "44600" est acceptée puis :
- "1234" est refusé car un caractère trop court
- "123456" est refusé car un caractère trop long
- "A2345", "1A345", "12A45" "123A5" "1234A" sont refusé car un caractères n'est pas numérique, cette multitude de tests pour la même raison est importante, elle va permettre de tester le code sans faire d'hypothèse sur la structure du code.
Si on se projette dans un développement orienté objets, le fameux champ code postal sera sans doute une propriété d'une structure d'adresse et il existera une méthode setCodePostal(..) ou assimilée qui sera donc torturée par une série de 8 tests unitaires.
Et oui, 8 test unitaires pour un si petit bout de code de rien du tout... et pourtant, à coup de copier/coller dans votre EDI préféré, il y en a pour moins de 5 minutes, et au moins, le setCodePostal sera bétonné, si un fourbe vient à pourrir le corps de la méthode, il sera découvert sur le champ !
Bien sûr, le top serait que celui qui fait les spécifications soit capable de faire le jeu de tests, ça viendra petit à petit.
Ce qu'il faut se rappeler, quand on écrit les tests, c'est que l'on est dans la peau de l'utilisateur de la fonction qu'on teste, si on éprouve des difficultés à écrire les tests, c'est que la méthode est mal définie, inappropriées, hors sujet ou, plus souvent, l’œuvre d'une personne qui à imaginé un problème ou une fonctionnalité qui n'existe pas; Une fonction difficile à tester est une fonction qui va générer des problèmes a court ou moyens termes.
Je vais arrêter là pour le moment, entrainez vous à écrire des tests, quand vous serez à 20% de couverture, vous serez déjà au Nirvana... arrivé à 100% ce sera RTT à temps plein !! :lol: