Discussion :

[Patrick Ruiz]

Doit-on abandonner la responsabilité du test d’un logiciel à celui qui écrit ses lignes de code ?
Votre précieux avis est attendu

L’un des principes du test de logiciels stipule que l’absence de bogues est une utopie. Avec la complexité des logiciels qui va croissant, ce principe prend chaque jour un peu plus de force et avec lui, le rôle du « testeur de logiciels » au sein de l’entreprise. Les formations liées à ce rôle émergent et on évolue chaque jour un peu plus vers une terminologie « métier » à propos de ce dernier. C’est dire que dans certaines entreprises, les questions de qualité du logiciel sont de plus en plus laissées à des personnes avec ce « background ».

Laisser les questions liées au test de logiciels à des personnes ayant reçu une « formation spécifique » implique généralement deux choses. Premièrement, la matérialisation des fonctions d’une application consignées dans un cahier des charges est définie comme étant du ressort exclusif de ceux qui écrivent les lignes de code. Secundo, une équipe de « spécialistes en tests » veille au grain, c’est-à-dire s’assure que le maximum de bogues soient découverts et remontés à l’équipe précédente avant une mise en production.

« Nous avons décidé que nos développeurs seront également responsables du test de leur propre travail. Nous n’avons pas besoin d’avis additionnels sur la question », a déclaré Oliver Brennan, directeur de l’équipe de développement du site Web de The Iconic, une entreprise spécialisée en commerce électronique. La question divise donc et, semble-t-il, relève plus des aspects organisationnels de chaque entreprise. Dans le cas de The Iconic, des dispositions sont prises en interne pour que le développeur soit au centre du processus d’assurance qualité du logiciel. D’après Oliver Brennan, la mesure a pour objectif de mettre les nouvelles releases du site le plus rapidement possible à la disposition des visiteurs.

La question est donc beaucoup plus complexe qu’il n’y parait et dans le fond peut être reformulée autrement : « à qui abandonne-t-on la phase de test du logiciel ? » Répondre à cette dernière ne saurait se faire sans évoquer la question du « background » soulevée d’entrée de jeu. Le propos d’Oliver Brennan pourrait mener à la conclusion selon laquelle le testeur idéal est quelqu’un qui a d’excellentes aptitudes en programmation. Mais comme le rapportent certains responsables d’équipes de développement, le meilleur testeur peut aussi s’avérer être ce « trou » en programmation informatique.

D’avis d’experts, le test de logiciel relève plus de l’aptitude à se comporter comme l’utilisateur final d’un produit pour arriver à dénicher des bogues. La France compte de plus en plus de centres qui axent la formation de leurs apprenants sur cet « état d’esprit ». Généralement intitulées « formation à la qualification logicielle », elles sont destinées à des personnes issues de tous horizons (entendez ici sans formation en programmation informatique) dans le but d’en faire des testeurs opérationnels et efficaces.

Source

itnews

Votre avis

Peut-on vraiment être un excellent testeur de logiciels sans connaissances en programmation informatique ?

Voir aussi

Trolldi : la phase de tests dans le cycle de vie d'un développement logiciel expliquée en images, comment organisez-vous vos tests ?

[Mat.M]

bonjour d'une part

1-les tests logiciels c'est une étape super importante dans le développement d'un projet logiciel.
Malheureusement de par mon expérience dans les entreprises de taille moyenne et petite qui font du développement informatique c'est une phase trop souvent négligée....c'est bien connu les utilisateurs ( qui paient pour le logiciel) s'occupent de corriger les bugs

2-ensuite pas besoin de connaitre forcément la programmation ça peut aider.
Mais le plus important c'est de connaitre les fonctionnalités métier et de faire des scénarios de test qu'un développeur ne saura pas forcément faire
Par exemple sur un logiciel de compta ou de gestion financière il vaut mieux être comptable pour faire des tests parce que le comptable connait mieux son métier qu'un développeur

[Marco46]

Peut-on vraiment être un excellent testeur de logiciels sans connaissances en programmation informatique ?

Est-ce qu'on a pas dans la question une confusion sous-jacente entre tester une application et rapporter des bugs ?

Un test qui n'est pas automatisé ne sert à rien. Le testeur ne peut être qu'un développeur qui programme les tests à effectuer et corrige les tests existants. Le test manuel coute beaucoup trop cher et est beaucoup moins fiable. Sans parler de l'impact sur le TTM.

[pboulanger]

De part mon expérience, le développeur est trop souvent un mauvais testeur: il teste la façon de faire qu'il a programmée et pas la façon dont le client va l'utiliser... Chez Sungard pour Ubix, les testeurs n'étaient pas des développeurs mais des gens du métier qui travaillaient régulièrement avec les clients pour comprendre comment ils utilisaient le logiciel...
Si les tests automatisés sont utiles (pour les tests unitaires), pour les tests fonctionnels ils ne peuvent malheureusement pas couvrir tous les cas d'utilisations et c'est là qu'un testeur va tester des points comme les raccourcis-claviers ou des valeurs limites, etc...
Sur un gros logiciels, il faut avoir les 2 types de tests... avec des testeurs qui ne sont pas des développeurs du logiciel...

[Ryu2000]

Peut-on vraiment être un excellent testeur de logiciels sans connaissances en programmation informatique ?

Ça dépend pour quel type de test !
(et en réponse blague, on peut dire que les tests en boite blanche doivent forcément être fait par un développeur)

Parce que normalement on dit que pour être testeur il faut d'abord être un bon développeur, et c'est vrai que c'est super utile de comprendre comment ça fonctionne dans le code pour imaginer des scénarios de problèmes. L’expérience du développeur lui a fait rencontrer des tas de soucis, il peut essayer de les reproduire sur le logiciel qu'il test.

Après ce qui est top, c'est de faire tester le logiciel par le client pendant l'intégralité du développement.
Parce que là il peut remonter tous les problèmes, par exemple :
- "on a demandé une fonction dans le cahier des charges, mais en fait elle nous sert à rien" ou inversement "on a besoin d'une fonction qui n’apparaît pas dans le cahier des charges"
- "avec ces données en entrées ou devrait avoir d'autres résultats en sortie"
- et tous ce qui concerne la "mauvaise" utilisation du logiciel, parce que les clients peuvent faire des actions qui n'ont pas de sens pour le développeur

Ce qui ne va pas c'est quand la même personne s'occupe de tout : conception, développement, test, validation, etc.
C'est mieux quand il y a plusieurs personnes, il faut que le testeur soit une personne différente du développeur.

[MikeRowSoft]

[...]
Peut-on vraiment être un excellent testeur de logiciels sans connaissances en programmation informatique ?
[...]

Bien qu'être développeur aide beaucoup pour des modifications en "live" du code source, certaine chose, principalement hors usage d'un outils de débogage, ne peuvent être mise en évidence que par les utilisateurs ne s'y connaissant pas dans le cas de logiciel grand public et non progiciel .

Il y a au moins deux familles de bogues à rechercher lors des tests et en fonction de la personne qui fait passé le test. Sachant que quelques fois un bogue évite le retour de l'application pour cause de changement de cahier des charges (modèles d'informations en BDD ou autres).

Le cas des personnes n'ayant jamais appris à se servir d'une souris et de ce qui est appelé la "fracture numérique" devrait beaucoup vous surprendre par son nombre... Si vous en tenez un ou une, présenté lui un numéro de téléphone, cette personne le reconnaitra, présenté lui une adresse MAC en lui disant que c'est un numéro de téléphone, ça marche toujours malgré l'hexadécimal. Les chances que cette personne vous rappel le filtre de saisi nécessaire est très élevé.

[wolinn]

Doit-on abandonner la responsabilité du test d’un logiciel à celui qui écrit ses lignes de code ?
...

Ca dépend bien du type de logiciel, du contexte, du niveau de compétence des personnes.
Il est évident qu'on ne teste pas de la même façon un programme pilotant un lanceur spatial et un site web, parce que les conséquences d'une défaillance ne sont pas les mêmes.
J'hésiterais bien à prendre l'avion si j'apprenais que les programmes qui tournent sur les avions de ligne n'étaient testés que par les programmeurs.
Donc : pas de réponse universelle à plaquer de force sur toutes les situations.

[MikeRowSoft]

L'avis sur les logs ? Y a t-il une application même commercial qu'y n'en n'ai pas après avoir été vendu ?
Le prototype qui décolle, je le crains bien...

Transmettre les log du navigateur au site web en cas de bogue une réalité, même ci le développement est clos...
Optimisation pour la qualité de service, le navigateur ayant aussi les siens et ne pouvant parfois pas réalisé de miracle avec ce qui lui est proposé comme système logiciel, environnement partagé et support matériel...

Sachant que les données sont typés, une partie des erreurs de sens sont évités, comme les additions entre un nombre et un caractère... Euh, merci le compilateur...
Utiliser une variable à la place d'une autre... C'est souvent ne pas avoir compris l’algorithme local à une fonction ou confondre deux noms de variables trop proches...
Je vous fais grâce des erreurs de compréhension du modèle...

[el_slapper]

Peut-on vraiment être un excellent testeur de logiciels sans connaissances en programmation informatique ?

Voui monsieur.

Le tests manuel et le test automatiques sont complémentaires. Le test manuel doit suivre le développement au plus près, pour aider les développeurs à visualiser leurs manques au plus vite. Le test automatique, lui, ayant l'avantage d'être répétable, et l'inconvénient d'être parfois long à écrire, est super-utile pour valider les fonctions qui ne bougent plus trop..... mais toujours vulnérables à une maintenance qui bave.

Évidemment, en test manuel, pas besoin d'être développeur. Ma collègue qui s'y colle a fait ses classes en faisant des analyses sanitaires sur de la pâtée pour chien, et elle trouve - manuellement - un nombre hallucinant de bugs sur notre nouvelle appli. Elle a un regard utilisateur digne d'un œil de lynx, et les programmeurs la craignent. Ils rajoutent des tests automatiques unitaires sur tout ce qui leur vient à l'esprit, mais aussi sur tout ce qu'elle trouve.

Moi, je fais des tests automatiques à un autre niveau : celui de l'interface. C'est de la programmation, mais très différente de la programmation d'application. Ca nécessite une appli un minimum stable(donc j'attends que l'ensemble soit stabilisé, je passe bien après ma collègue dans le cycle de vie do logiciel). Et je me concentre sur le plus canulant : la non-régression. Et, parfois, je ramasse des trucs imprévus. Jamais je n'ai attrapé le bug que j'avais imaginé attraper, mais j'en attrape des rigolos, parfois. des trucs que les devs n'ont pas couverts dans leurs tests autos unitaires.
Ou que des tests unitaires ne peuvent pas voir.

Mais Wolinn et Ryu2000 ont raison : ça dépend. Ca dépend de la criticité, notamment. Nous, on peut quand même tuer des patients si on sabote les prescriptions des médecins(j'ai déjà chopé des bugs de ce genre, avec mes automates, qui auraient divisé ou multiplié les doses). On peut aussi faire fermer l'hôpital si on sabote ses comptes financiers. On ne peut pas se permettre de faire une confiance aveugle aux développeurs. Je défends ma paroisse parce-qu'elle est évidente dans mon cas, mais d'autres applis auront d'autres exigences.

[transgohan]

Le programmeur est souvent un mauvais testeur.
Chez nous c'est un job à part entière, une personne qui va écrire des tests automatique mais qui va aussi effectuer des tests manuels.
Car oui croire que tout peut se faire en automatique est utopique dans bon nombre de projets...

Chez nous on a même de la non régression en manuel.
Bon après c'est plutôt que si on voulait automatiser cela il faudrait débourser des dizaines de milliers d'euros...
La productivité a un cout mais qui impacte forcément la rentabilité, il faut savoir équilibrer les deux.

[Marco46]

Chez nous on a même de la non régression en manuel.
Bon après c'est plutôt que si on voulait automatiser cela il faudrait débourser des dizaines de milliers d'euros...
La productivité a un cout mais qui impacte forcément la rentabilité, il faut savoir équilibrer les deux.

L'argument financier est probablement le pire qui soit. C'est quand t'es blindé de thunes (ou/et inconscient) que tu confies l'exécution des tests à des employés de bureaux !!

Ça revient à dire que c'est moins cher d'employer des gens pour réaliser une tâche automatisable que de l'automatiser C'est complètement absurde ! Si c'était le cas on n'embaucherait pas de développeurs pour écrire des logiciels, on remplirait des tableaux excel à la main et on ferait les jointures à la main !

Je t'invite à faire la somme des salaires des gens dédiés aux tests manuels sur la durée de vie du projet et tu verras que ça coute une fortune, bien au delà de ce qu'aurait couté une automatisation. Sans parler des couts cachés liés à la durée des cycles de livraisons forcément plus longs avec du manuel de partout.

Alors bien évidemment tout ne peut pas être automatisé et il faut forcément des personnes pour aller fouiller dans les coins. Mais au minimum les "happy path" des applications devraient systématiquement être réalisés par des tests automatisés.

[captaindidou]

La qualité logicielle suggère que celui qui développe le module n'est pas celui qui le teste.
C'est une idée qui n'est pas dépourvu de sens.

Mais d'après moi, ce ne peut pas faire loi universelle. Car qui plus expert pour vérifier son module que celui qui l'a développé ? A moins que celui qui l'a conçu et celui qui l'a développé soient deux personnes différentes.

En revanche, déléguer les tests de robustesse, de sécurité, ... est bénéfique pour la qualité de ces tests. Car la nature humaine et la mienne en particulier est ainsi faite que l'on aime pas trop s'éterniser sur sa création, une fois mise au point. N'est-ce pas ? Se pensant des concepteurs au premier chef, nous estimons, pour une bonne partie d'entre nous, le travail accompli lorsque le module fonctionne remarquablement.

[MikeRowSoft]

D'où la différence entre la pratique scolaire et la pratique d'entreprise.

Je me rend compte que le fichier logs n'est parfois pas aussi complet que l'historique des "marqueurs" de l'outil de débogage...

Un parcours d'arbre des possibilités niveau débogage...
La plus part du temps quand ça "plante pas l'OS" ou n'affiche pas de messages du débogueur tout va bien...

[bizulk]

Sans parler du cas spécifique du test unitaire automatisé (100% couverture, mockage des fichiers etc) qui à mon avis requiert un poste dédié, je dirais que tous les tests sont bon à prendre, et chacun est plus ou moins qualifié à une étape du cycle en V donc pour moi chacun à sa part de responsabilité.

Le développeur teste ses fonctions pour éviter les plantages et réinitialisations impossibles qui sont du plus mauvais effet, la conformité des fonctionnalités implémentées à ce qu'il en attendait, puis à ce qu'en attendait la spec.
Ces tests permettent d'avoir un livrable que le client peut évaluer.
Le client réalise ses tests avec le (dev et/ou chef de projet ), pour vérifier la conformité à ce qu'il demandait et ce dont il avait réellement besoin.
Et ainsi de suite jusqu'au client final....
Avec une méthodologie de dev plus agile, je vois la même chose mais de façon plus itérative.

[el_slapper]

La qualité logicielle suggère que celui qui développe le module n'est pas celui qui le teste.
C'est une idée qui n'est pas dépourvu de sens.

L'idée, c'est de ne pas être à la fois juge et partie. Après, quand moi je développe, j'aime bien de temps en temps mettre ma casquette de testeur, et chercher là ou j'ai pu merder. Mais je suis un profil un peu particulier. Et même avec ce profil, je finis toujours par avoir, certes en attenué, le défaut de tous les développeurs du monde : je teste ce à quoi j'ai pensé.

Mais d'après moi, ce ne peut pas faire loi universelle. Car qui plus expert pour vérifier son module que celui qui l'a développé ? A moins que celui qui l'a conçu et celui qui l'a développé soient deux personnes différentes.

Ben, moi, en tant que testeur, j'espère bien voir arriver des modules déjà passablement dégrossis. donc testés en long, en large, et en détail par le développeur. Qui n'a pas envie de passer pour un idiot auprès des testeurs. Parceque bon, une appli qui crashe au lancement, ou qui met des textes fantaisistes parce que la traduction n'est pas activable, c'est idéal pour le testeur se foutre de la gueule du développeur. En revanche, quand on a un bug, uniquement sur les prescriptions modifiées par le pharmacien, et uniquement sur des calculs de doses compliqués pour des intra-veineuses spécifiques, et uniquement sur des typologies de patients précis(quand ce n'est même pas ça qu'il a modifié, en plus), ben, on peut comprendre que le développeur soit passé au travers. Personne ne lui en voudra...mais tout le monde sera content que quelqu'un soit passé derrière lui.

En revanche, déléguer les tests de robustesse, de sécurité, ... est bénéfique pour la qualité de ces tests. Car la nature humaine et la mienne en particulier est ainsi faite que l'on aime pas trop s'éterniser sur sa création, une fois mis au point. N'est-ce pas ? Se pensant des concepteurs au premier chef, nous estimons, pour une bonne partie d'entre nous, le travail accompli lorsque le module fonctionne remarquablement.

Et crac, ma collègue et moi on trouve la faille. par contre, les tests de non régression, c'est super-chiant, et l'expérience montre que quand c'est fait manuellement, la qualité du test décroit régulièrement. Sur la partie comptable, mon collègue scripteur(je n'étais pas seul, à un moment) a fait un ensemble de scripts qui remplace une semaine complète de tests manuels. Qui étaient faits par une experte métier - qui avait autre chose à foutre, donc qui ne le faisait que rarement. Les rejets comptables ont chuté depuis, chez les clients. La non-régression, c'est le terrain de jeu naturel et privilégié du test automatique. Tout simplement parce-que c'est une tâche à très haute exigence en autodiscipline, et que la plupart des êtres humains n'ont pas ce niveau d'auto-discipline. Les automates de tests, oui.

[koyosama]

Ça dépend pour quel type de test !Parce que normalement on dit que pour être testeur il faut d'abord être un bon développeur, etc.
C'est mieux quand il y a plusieurs personnes, il faut que le testeur soit une personne différente du développeur.

C'est la première fois que j'entends ça, j'ai vécu dans trois pays différents, vu des gens du monde entier, passer sur temps sur Quora, reddit et Stackoverflow et j'ai jamais de jamais entendu cette phrase délirante.
J'ai même vu des article ou le développeur c'est le pire testeur qu'il soit. Dans le monde du jeux vidéos on engage pas du tout les développeur pour tester les jeux et ceux dans tous les pays. C'est pour cela que Ubisoft a des problème de bugs .

En Angleterre, il y aun métier detesteur, et même en France. Sauf du peu de souvenir que j'avais, les développeur détestaient les testeurs dans ma boîte (c'est sûre qu'il agace à automatiser en donnant l'impression qu'il branle ou encore donner plus de tickets).

Mais putain, de mon experience, le développeur est le pire testeur qu'il soit parce qu'il connait le défaut de l'application. C'est pas étonnant qu'on a inventé le TDD et la BDD pour rendre le développeur plus responsable et plus enclins à vérifier sa checklist de feature et de bugs. Même cela tu n'es pas exempté de bugs.

D'ailleurs là ou je suis on me demande d'avoir de l'experiences dans le code reviews et ce n'est pas pour rien.

[MikeRowSoft]

Ben, moi, en tant que testeur, j'espère bien voir arriver des modules déjà passablement dégrossis.

Tu en as de la chance... J'ai vue quelques offres d'emplois dans ce domaine, beaucoup de normes et des applications spécifiques.

L'expérience scientifique continu... (Surtout quand le développeur ne l'utilise pas quotidiennement...)

[transgohan]

@Marco46

Cela m'énerve quand on me sort un argument aussi déplacé de son contexte... Arrêtons de faire des généralités et acceptons que certains domaines sortent du lot...
J'explique un cas, on me rie au nez en me disant que je suis de mauvaise foi...

Ça revient à dire que c'est moins cher d'employer des gens pour réaliser une tâche automatisable que de l'automatiser C'est complètement absurde !

Il peut être vrai dans certains domaines.
Le test natif ne dérisque pas tous les cas de situation. La simulation peut être une solution mais nécessite un énorme investissement, qui peut aussi dans certains cas être trop coûteux ou bien impossible techniquement.
Donc on passe au test sur cible.
Il est des équipements que l'on doit tester sans intrusion de débug pour être le plus fidèle au déroulement et à son exécution chez le client.
Donc on en vient à devoir créer un robot pour le manipuler, puis reproduire des environnements d'exécution incluant météo et tout le bordel.
Ce qui chiffre très vite.

Après on peut très bien voir à horizon 20ans pour rentabiliser l'investissement, mais les projets s'enchaînant à 5ans il faudrait faire au moins 4 gammes de produits réutilisant tout l'équipement de test pour ne serais-ce que le rembourser. Aucun comptable n'accepterai un tel choix.
Même un chef t'expliquera qu'il est moins dangereux d'embaucher une personne 20ans en ayant la possibilité de le licencier économiquement au bout de 5ans s'il ne vient rien après le premier projet que d'investir dans un tel équipement de test.

Alors bien évidemment tout ne peut pas être automatisé et il faut forcément des personnes pour aller fouiller dans les coins. Mais au minimum les "happy path" des applications devraient systématiquement être réalisés par des tests automatisés.

C'est ce que j'ai dit dans mon premier message en fait. Donc au final j'ai le même raisonnement que toi ?
Mais encore là j’émets un bémol, le happy path n'est qu'une pauvre image de la qualité d'un produit.
On a eu une époque où par manque de budget on n'avait plus de testeur, donc plus de test manuel, que de la non régression automatique.
Eh bah je peux t'assurer qu'un produit peut très bien fonctionner en non reg auto et foirer en moins de 5 minutes chez un client et ce même avec une très grosse base de test et des tests cohérents et bien choisis.

[Ryu2000]

Dans le monde du jeux vidéos on engage pas du tout les développeur pour tester les jeux et ceux dans tous les pays. C'est pour cela que Ubisoft a des problème de bugs .

Non mais le jeux vidéo c'est un domaine à part...
Là je parlais de logiciel, ou de site web.

Il y a une partie des tests qui est souvent réalisé par un développeur, comme les tests unitaires par exemple.
Après si on parle de test du produit final, forcément c'est mieux de passer par des utilisateurs...

[Marco46]

Il est des équipements que l'on doit tester sans intrusion de débug pour être le plus fidèle au déroulement et à son exécution chez le client.
Donc on en vient à devoir créer un robot pour le manipuler, puis reproduire des environnements d'exécution incluant météo et tout le bordel.
Ce qui chiffre très vite.

Mouai enfin t'es quand même dans un cas bien particulier où ton soft s'exécute sur des barres d'or. Moi je te parlais du cas lambda qui concerne la majorité des devs ici à savoir le dev d'applications de bureau ou web.

Mais encore là j’émets un bémol, le happy path n'est qu'une pauvre image de la qualité d'un produit.

Bien sûr, il garantit simplement que les fonctionnalités essentielles seront OK et pas KO. C'est donc bien moins cher d'investir pour avoir un bouton GO/NOGO que d'avoir une armée de testeurs pour check le happy path. Je dis ça parce que je sais très bien que c'est quelque chose qui n'est pas compris par nombre de décideurs.


C'est quand même ton contexte à toi qui est une exception, donc c'est bien à toi de le préciser !