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, Chroniqueur Actualités
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Mat.M 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
Avatar de Marco46 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.
Avatar de pboulanger pboulanger - Nouveau membre du Club 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...
Avatar de Ryu2000 Ryu2000 - Expert confirmé https://www.developpez.com
le 06/11/2017 à 12:02
Citation Envoyé par Patrick Ruiz Voir le message
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.
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 06/11/2017 à 12:59
Citation Envoyé par Patrick Ruiz Voir le message
[...]
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é.
Avatar de wolinn wolinn - Membre actif 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.
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 06/11/2017 à 13:10
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...
Avatar de el_slapper 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.
Avatar de transgohan transgohan - Expert éminent https://www.developpez.com
le 06/11/2017 à 14:03
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.
Avatar de Marco46 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.
Contacter le responsable de la rubrique Accueil