Depuis le premier programme écrit pour un ordinateur, les utilisateurs se sont trouvés confrontés à des dysfonctionnements potentiels, d’abord attribués à de fantomatiques insectes cachés dans les tréfonds de nos machines, les soi-disant « bugs », puis à une obscure histoire d’interface entre la chaise et le clavier. Il a fallu admettre que parfois, peut-être, le travail du développeur n’était pas parfait au premier essai.
Ce jour-là est né le plus terrible ennemi du développeur : le testeur !
Examinons donc la relation entre ces deux êtres que tout sépare et dont le seul lien est leur intérêt pour une même solution logicielle.
Le développeur
Il est celui qui conçoit le logiciel ou le fonctionnel, peu importe en fait ce qu’il utilise pour atteindre son résultat. Son rôle est de traduire un cahier des charges ou à défaut une expression de besoin, en un « traitement automatisé de données ».
Le développeur peut-il être un testeur ?
Pour ses propres œuvres, la réponse est clairement non et encore non : outre sa tendance naturelle à avoir les yeux de Chimène pour son travail, sa logique de test suivrait sa logique de développement, en évitant les chemins détournés que visiterait sans scrupule un utilisateur.
Et finalement son contexte de travail, en général parfaitement à jour, le détournerait des configurations exotiques de la vraie vie, celles qui fonctionnent par miracle ou en s’appuyant sur des composants ancestraux.
Alors voyons donc ce que peuvent nous apporter les testeurs.
Le degré 1 du testeur
Il va suivre le mode opératoire à la lettre probablement de façon infiniment plus rigoureuse que ne ferait un vrai utilisateur et sans jamais y déroger.
Il ne se posera pas de questions d’ergonomie ou d’utilisabilité dans la mesure où il va exécuter pas à pas un protocole rigide.
Ce type de test a assez peu d’intérêt finalement, hormis le fait de sortir de l’environnement du développeur et de passer d’un mode de test unitaire (chasse normalement gardée du développeur) à un test global de la solution.
Le Monkey test
Le nom vient de la façon dont un singe se sert d’un clavier (je ne vous fais pas un dessin). Même si aujourd’hui on ne peut plus utiliser de vrais singes, ce type de test permet de valider les contrôles du typage des saisies et de dépassement de tampon ou la gestion des messages clavier.
Le test d’ergonomie
Il valide la lisibilité des écrans et les enchaînements fonctionnels, tant d’un point de vue de logique que de performances. Ce type de test devra être d’autant plus approfondi que la population sera large et peu formée.
Le testeur créatif
Voila donc le vrai ennemi du développeur, un brin sadique, car il va chercher à mettre la solution dans des cas non prévus. Le développeur le perçoit comme un coupeur de cheveux en quatre, mais sur le fond ce testeur ne fait qu’anticiper des incidents dus, soit à des données non prévues, soit à des tentatives de l’utilisateur de faire rentrer des ronds dans des carrés.
Maintenant que vous connaissez les différents profils de testeurs, il me restera à vous parler de tests d’intégration, de sécurité ou encore d’intrusion. C’est un sujet plus technique qui sera abordé dans un futur billet.
Olivier Piochaud, Président Directeur Général d’Apsynet
