sept
10
Les développeurs sont-ils trop stupides pour les tests fonctionnels ?
Filed Under Chiffres | Leave a Comment
Une récente enquête de Methods & Tools a cherché à évaluer le degré d’automatisation des tests fonctionnels. La comparaison était intéressante avec un sondage similaire fait en 2005.
| 2009 | 2005 | |
| Mon entreprise n’a pas d’outils | 37% | 38% |
| Mon entreprise a un outil, mais je ne l’utilise pas | 19% | 26% |
| J’utilise un outil pour les tests fonctionnels | 44% | 36% |
Participants : 268 (147)
Date de fin : août 2009 (août 2005)
Il y a eu une amélioration dans l’utilisation des outils depuis 2005, mais les résultats me semblent toujours montrer une situation ambivalente : 63% des sociétés ont des outils de tests fonctionnels, mais 56% des participants ne les utilisent pas. Dans ma carrière personnelle de développeur, celui-ci devait être capable de comprendre les besoins fonctionnels des utilisateurs et tester ses réalisations avant de les livrer pour les tests d’acceptation.
En posant des questions à d’autres développeurs sur cette situation, j’ai découvert qu’il y avait plusieurs raisons pour cette non utilisation des outils de test fonctionnels. La première consiste dans l’importance donnée aux activités de test. C’est souvent ce qui se fait en dernier dans un projet et les tests fonctionnels sont encore plus à la fin de la phase de test. L’automatisation de cette activité est aussi coûteuse. En dehors des prix des outils commerciaux, il y a aussi les dépenses que nécessite la mise en place d’un environnement miroir de celui de production (logiciels, données) pour effectuer des tests significatifs. Mais tous les participants au sondage font des tests fonctionnels.
Chaque outil a son propre langage et il n’est ainsi pas facile de transférer ses connaissances d’un outil à l’autre. Il est aussi difficile de maintenir les scripts des outils. Lorsque l’application évolue trop rapidement, les scripts deviennent obsolètes et ne sont plus utilisables. Il faut aussi mentionner que les outils sont parfois achetés pour un projet spécifique et ne sont pas utiles pour des applications basées sur d’autres technologies.
Cependant, la majorité des remarques que j’ai recueillies sur la différence entre les taux d’adoption et d’utilisation des outils mettaient en évidence le fait que les tests fonctionnels marquent la frontière entre les activités de développement et d’assurance qualité. Malgré le fait que l’agilité prône la disparition des spécialisations, il semble exister encore un grand nombre d’organisations où des testeurs spécialisés s’occupent des tests fonctionnels. Ceci pourrait être le résultat de la spécialisation des outils, mais je ne pense pas qu’ils soient beaucoup plus difficiles à maîtriser que les outils de tests unitaires.
Cette spécialisation des tâches peut cacher l’aspect global des projets aux développeurs. Certains disent que les développeurs ne sont pas intéressés à communiquer avec les utilisateurs, mais il faut réaliser que l’on ne crée pas des programmes pour soi-même. Cela me fait penser à l’attitude de certaines personnes de la production qui semblent penser qu’il serait préférable d’avoir des ordinateurs avec seulement un système d’exploitation qui tourne dessus. Ils rendent responsables de tous les problèmes les applications développées en interne pour les utilisateurs de l’entreprise. Les bons développeurs doivent être capables de comprendre ce que veulent les utilisateurs et de tester fonctionnellement leurs réalisations.