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.

[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.

[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...

[koyosama]

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...

Franchement, les tests unitaires c'est la chose obligatoire. Ya même pas d'excuse pour ça. Le fonctionnel devrait être au coeur de la programmation et arrêter de faire des fonction qui fait 10000 trucs.
Un fonction un truc et il le fait bien, c'est très facile à corriger et tester. L'article parle du test d'un logiciel. Après je trouve le TDD limité quand le BDD est mieux pour ce cas là.

On n'ose pas le dire mais je vais le dire. C'est juste que nos entreprises, n'ont pas thunes pour laisser le temps de faire des codes reviews, des tests unitaires.
Tester c'est une reflexion à part, le faire soi-même n'est pas le plus qualicatif que si tu combinais plus que toi, ce serait plus efficaces.

Check cette vidéo.

Croire que le développeur est le meilleur reviewver quand un oeil externe est meilleur. Le développeur sera bon à tester les codes de types "utillity" ou "framework" ou "sdk".
Mais tout code business sera mieux vérifier par une personne qui connait pas le produit ou juste ce qui devrait faire.

J'ai été hanté par les entreprises qui utilisaient leur logiciel avec des bugs et me dire que c'est le quotidien et toujours d'actualité. Après je comprends pourquoi les ricains ont plus de produits logiciels que nous.
J'ai moi-même été pris dans ce piège et je pense tout le monde est humain. Avant j'avais pas le skill pour expliquer les bugs, maintenant je l'ai c'est plus simple et le développeur comprend maintenant sans avoir conflit d'égo et bonus en anglais/français.

Par exemple, j'ai du faire comprendre à un retraité que son interface n'est pas utilisable et le truc qu'il me sort: "Oui mais je l'utilise". Et pendant ce temps, le projet n'avance pas. Des fois le goût du dêveloppeur n'est pas bon et on a du mal à l'admettre. En plus le développeur polyglot pro-code (qui ne s'est jamais intêresser à l'UI) est toujours contre le désign. Combien de gens j'entends, moi je ne veux pas toucher au front ou aux interfaces.

[Ryu2000]

En plus le développeur polyglot pro-code (qui ne s'est jamais intêresser à l'UI) est toujours contre le désign. Combien de gens j'entends, moi je ne veux pas toucher au front ou aux interfaces.

Ouais mais en même temps c'est un autre domaine...
Réaliser une interface pratique et belle ça demande des compétences totalement différentes.
Généralement un développeur ça ne peut pas écrire les tests unitaires, puis les fonctions qui vont avec ces tests et enfin créer l'interface.
À la limite test unitaire + développement ça va ensemble, mais interface + développement ça va pas forcément ensemble.
Maintenant il existe des designers spécialisé dans l'interface utilisateur, mais toutes les entreprises ne peuvent pas ou ne veulent pas en embaucher (que ces entreprises prennent au moins une stagiaire ).

Après moi perso, j'ai toujours adoré faire des interfaces (même si elles étaient moche à chaque fois et qu'elles n'étaient pas demandé).
https://youtu.be/coL-Cm3Ugaw

[Paul TOTH]

Dans un monde idéal on aurait

1) une personne rédige un cahier des charges qui reprend les besoins des utilisateurs (conception)
2) une personne implémente une solution logiciel en suivant ce cahier des charges (développement)
3) une tiers personne s'assure que la solution proposée répond au cahier des charges (testeur)
4) le support qui connait le cahier des charges explique le fonctionnement du logiciel aux clients ou remonte à la première équipe les demandes d'évolution (support)

chaque étape rencontre ses problèmes
1) tirer des utilisateurs leur besoin n'est pas une mince affaire, car leurs besoins ne sont généralement pas formalisés et il faut savoir en faire une synthèse
2) le développeur est parfois confronté à des conceptions alambiquées qui sont liées à une mauvaise connaissance de la technique qui réclamerait un compromis plus pertinent
3) le testeur a un boulot super important mais qui me semble super chiant...il faut donc le payer mieux
4) le support est le contact direct avec le client, comme il ne décide de rien il a souvent l'impression d'être entre le marteau et l'enclume

Dans la vraie vie
l'étape 1 est rarement finalisée alors que tout repose sur elle
l'étape 2 fait du système D surtout si l'étape 3 n'existe pas
l'étape 3 n'existe pas
l'étape 4 appelle le développeur qui sait répondre aux problèmes des utilisateurs sans passer par l'étape 1 (quand elle existe)

et tout par en vrille le jour ou le développeur a un contact direct avec l'utilisateur

[Marco46]

On n'ose pas le dire mais je vais le dire. C'est juste que nos entreprises, n'ont pas thunes pour laisser le temps de faire des codes reviews, des tests unitaires.
Tester c'est une reflexion à part, le faire soi-même n'est pas le plus qualicatif que si tu combinais plus que toi, ce serait plus efficaces.

C'est faux faux faux archi faux je suis totalement opposé à cette interprétation c'est véritablement une falsification de la réalité.

La réalité c'est que nombre de développeurs ne posent pas leurs balls sur la table pour défendre leur métier et agissent comme des moutons. Ce n'est pas à un CPI ou un quelconque manager de se mêler de savoir s'il faut faire ou pas des tests ou des code reviews. C'est un sujet qui est 100% technique et ne concerne que les techniciens. Les managers n'ont pas à se méler de de ça. Les managers donnent en input un besoin aux devs et les devs donnent une estimation ce qui permet d'estimer un cout et une ETA. Point final. Les managers n'ont pas à se méler de comment les devs travaillent ils sont plus qu'incompétents, ils sont "acompétents". C'est en dehors de leur juridiction !!

[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.

[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.

[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 !

[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.