Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Patrick Ruiz

121PARTAGES

11  0 
Comment votre entreprise organise-t-elle les tests de ses logiciels ?
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 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de pboulanger
Membre confirmé https://www.developpez.com
Le 06/11/2017 à 12:01
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...
14  0 
Avatar de Mat.M
Expert éminent sénior https://www.developpez.com
Le 06/11/2017 à 11:14
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
11  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 06/11/2017 à 13:55
Citation Envoyé par Patrick Ruiz Voir le message
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.
10  0 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 06/11/2017 à 11:16
Citation Envoyé par Patrick Ruiz Voir le message
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.
6  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 06/11/2017 à 14:59
Citation Envoyé par captaindidou Voir le message
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é.

Citation Envoyé par captaindidou Voir le message
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.

Citation Envoyé par captaindidou Voir le message
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.
6  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 08/11/2017 à 15:44
Citation Envoyé par Marco46 Voir le message
Ah mais c'est certain que mal faire de l'agile c'est pareil que faire du mauvais waterfall et que ça peut pas être mieux que du waterfall bien fait ! Ceci dit ce que tu décris ne correspond pas à de l'agile, c'est du n'importe quoi.
Sauf que c'est 90% du "agile" en entreprise, ce n'importe quoi. Le vrai agile est rarissime. La seule fois ou j'en ai fait, personne dans la salle ne connaissait le terme. J'ai juste fait neuf versions du programme dans la journée(un samedi, qui plus est), et les gens en face 9 versions de la spec. Et à la fin, ça marchait comme ils voulaient.

De même que du bon waterfall, avec des gens intelligents, qui savent s'adapter en cas de de pépin, ça marche en fait pas mal du tout(mais c'est fort rare, et plus ancien, d'ou une réputation encore plus pourrie que l'agile, souvent à raison, hélas). J'ai connu un projet de 18 mois et 60 personnes, ou la spec avait été signée par un grand chef, et n'avait donc plus le droit d'être modifiée. Alors même qu'elle avait deux ans et n'était plus adaptée. 6 ans plus tard, ils sont repartis de zéro(oui, ça fait 6*60 = 360 années hommes jetées à la poubelle - et c'était prévisible depuis le jour un, d'ailleurs, je l'avais annoncé en me barrant par la petite porte, les autres n'avaient pas osé parce qu'ils n'avaient pas de porte de sortie). A ce niveau de stupidité, quelle que soit la méthode, on va dans le mur. Et on accusera la méthode.

Mais non, l'effort de test(hors tests unitaires, qui font partie intégrante du développement) n'est pas à laisser à l'appréciation des développeurs. C'est une décision stratégique. Souvent prise de travers par des crétins qui n'y pigent rien, mais n'est-ce pas le cas de toutes les décisions stratégiques? Moi, je peux te dire que tout ce que nous faisons ici comme tests passé le développement, le chef développeur était vent-debout contre. Et on à recalé environ une release sur deux. La grande chef a décidé qu'il y aurait de l'effort de test, et elle a eu raison. Après, c'est délicat à doser. Les retours sur investissement diminuent, comme souvent. Un effort léger aura des effets déjà sympathiques, un effort important attrapera un peu plus de bugs(et en laissera passer beaucoup moins, en proportion), laissant le client bien plus satisfait, et un effort démesuré est nécessaire en aérospatial.

Toi, ce que tu prônes, c'est le pouvoir entier aux développeurs. C'est malsain. Certes, le monde modenre a donné tout le pouvoir aux commerciaux, et c'est pas mieux, mais il y a des contraintes marché réelles, et laisser les développeurs se faire plaisir avec un test infini, ou au contraire pas de test du tout("on est les meilleurs, on en a pas besoin", c'est néfaste à la bonne marche de l'entreprise.
6  0 
Avatar de wolinn
Membre éprouvé https://www.developpez.com
Le 06/11/2017 à 13:06
Citation Envoyé par Patrick Ruiz Voir le message
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.
5  0 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 06/11/2017 à 14:25
Citation Envoyé par transgohan Voir le message

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.
5  0 
Avatar de Kikuts
Membre éclairé https://www.developpez.com
Le 06/11/2017 à 18:43
Citation Envoyé par Marco46
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.
Je trouve ta réponse un peu trop stricte ou alors pas assez complète.

Effectivement, la couche d'accès à la DB, tout ce qui est logique métier etc s'automatise et je pense que ça revient moins cher que de faire tester manuellement le soft.

Par ailleurs, je vois très très mal un développeur réaliser les tests d'un logiciel de compta super pointue à moins qu'il possède une formation d'expert comptable... Pour avoir bosser sur un projet comme ça je te jure que ce n'est pas évident car si tu as la chance d'avoir des cahiers des charges complets, qui n'évolueront pas et qui couvre tous les besoins et les non besoins, ce n'est clairement pas la majorité des cas et ça ne signifie pas que tu as compris le métier à 100%. Comme on dit, à chacun son métier.

Ensuite, tu parles de coûts. Alors c'est simple : je ne connais personne capable d'écrire des UI tests multi plateformes qui ne casseront pas, qui ne pénaliseront pas toute la chaine : un UI test qui est cassé empêche toute Pull Request. Du coup tu pénalises tous les développeurs. Ces derniers vont devoir créer une branche, faire un tas de manip pour contourner le problème. De plus, il va falloir corriger le problème puis tout rebasculer, vérifier que tout est bon. Tout ce temps passé est vite énorme. Ca te couvre le prix de plusieurs testeurs manuel à l'année. Si tu externalises les tests dans un pays de l'est, tu peux t'offrir 10 testeurs pour le prix d'un UI test :p

Qui réalise les UI tests ? Des développeurs.
Qui n'aiment pas tester / écrire des tests ? Beaucoup de développeurs !
Donc ça ne m'étonnerait même pas que la productivité d'un développeur chute lorsqu'il doit réaliser moulte tests unitaires.
Pendant que tu codes un UI test, tu n'avances pas sur les features, le projet stagne en qq sorte (du point de vue de l'utilisateur en tout cas. Même si de notre point de vue de développeur, on avance, on est plus solide etc !)
Du coup, pour compenser ça, tu vas embaucher d'autres développeurs (peut être moins bon, qui écriront du moins bon code / de moins bon tests unitaires). C'est le serpent qui se mord la queue

Deuxième remarque : pendant que je réalise des UI tests que des collègues casseront tôt ou tard / pendant que je fixe mes UI tests qui cassent, je ne développe pas, je ne fixe pas de bug. Parfois faire un UI test va m'obliger à changer mon archi juste pour pouvoir mocker des données. Il va falloir faire une réunion avec le chef de projet, chef technique etc, justifier tous ça, écrire des tonnes de mails etc. Alors pour tester que le bouton "à propos" affiche bien un popup avec le nom de l'entreprise, ça peut vite couter un mois. Ah merde l'iphone X est sorti entre temps avec des nouveaux ratio... Certains de mes UI tests ne passent plus sur iOS... Zut de zut !!! Est-ce qu'ils fonctionnent encore sur les autres plateformes ? Oui ? Non ? Pourquoi ? Vont-ils casser ? Bon ça m'a saoulé, je désactive les tests dans mon intégration continue "temporairement" : je les "fixerai"... "plus tard" !

Autre exemple : tu as une appli Android, une appli iOS, un site web, un client lourd UWP pour l'admin. Je pense qu'il y a vite moyen que le coût des tests unitaires dépassent le coûts du projet en développement.

Les tests c'est bien quand ça cible des path critiques, ce qui a sous le capot de l'appli.
De plus, tout se test : "quand y en a plus, y en a encore" c'est une bataille sans fin !

Pour finir, je dirais que rien ne remplacera un testeur humain non développeur. Il testera les choses différemment, peut être il va galérer à tester telle ou telle fonctionnalité, manquera d'info etc.
Ces retours sont parfois presque plus important que de trouver un petit bug
Car tester un logiciel, c'est plus que vérifier que ça ne crash pas ou que le résultat est bon ! C'est aussi s'assurer que les wordings sont correctes, que la charte graphique est respectée, que l'appli respecte les normes high contrast (d'ailleurs je meure d'envie de connaître le % de site web High Contrast Compliant ), qu'il est utilisable avec la loupe, le narrateur etc. Oui oui, ce sont des choses qui peuvent être obligatoire (exemple : il me semble qu'une école ne peut acheter des softs qui ne respectent pas ces conditions)

De toute façon, tester, c'est douter
5  0 
Avatar de LSMetag
Expert confirmé https://www.developpez.com
Le 07/11/2017 à 10:33
Il y a le testing de la part des développeurs (certes automatisé et manuel mais souvent basique), mais surtout la recette côté client, qui connaît mieux le métier, et qui est plus doué pour trouver des cas d'utilisation tordus et des erreurs fonctionnelles.

Nous avons bien vu que les tests des développeurs seuls étaient insuffisants, et que certains clients ne faisaient pas correctement leur recette (quand ils ne passaient pas directement du dev à la prod) et nous avons maintenant un testeur attitré qui fait la passerelle. Ce testeur est un ancien développeur peu expérimenté (1 an ou 2) qui a voulu passer dans le fonctionnel. Il faut être très méticuleux, savoir s'imprégner du métier et avoir le sens du contact. Il n'effectue que des tests manuels. Depuis qu'on l'a on ne peut plus s'en passer.

C'est aussi un tremplin pour passer chef de projet puisque la personne discute beaucoup avec les clients et les développeurs, fait des rapports, participe aux livraisons,... Après 1 an, cette personne cumule les rôles de testeur et chef de projet.

Il y a 2 écoles :

1) La nôtre : On fidélise les clients (et faisons marcher le bouche à oreille), certes en étant plus cher ou en prenant du retard (nous travaillons en méthode agile), mais nos livraisons sont de qualité, performantes et robustes. Elles ne requierent que peu de TMA, que l'on effectue nous-même. Les clients fidélisés nous commandent d'autres projets, et d'autres clients arrivent. Nous avons également carte blanche sur la technique, qui nous permet de rester à la pointe.

2) Les prestations sont faites dans un soucis de coût minimum et de rapidité. En gros un appel d'offre par prestation, on prend le moins cher (qui n'est pas forcément en France). Les résultats sont souvent médiocres, testés à la va-vite par les développeurs, puis des mois plus tard par une MOE puis une MOA. Les SS2I (qui ne font souvent que de la TMA) s'enchaînent ensuite, et se battent pour ne pas être remplacées. C'est comme monter une maison pas cher et appeler sans cesse SOS Plomberie. C'est le mode de fonctionnement de la SNCF par exemple. Tu fais ce qu'on te dit à un instant t (tu es mal vu si tu objectes qu'il va y avoir des problèmes), une fois ta tâche terminée, on relance un appel d'offre. Là bas, il n'y a pratiquement QUE de la TMA active, et ce pendant des années et des années.
En tant que client, on voit les résultats...
5  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web