IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Comment votre entreprise organise-t-elle les tests de ses logiciels ?

Votants
67. Vous ne pouvez pas participer à ce sondage.
  • Elle s’appuie uniquement sur les retours des utilisateurs

    31 46,27%
  • Les tests sont confiés en interne à des personnes calées en programmation

    21 31,34%
  • Autres, précisez dans les commentaires

    18 26,87%
  • Pas d’avis sur la question

    2 2,99%
Sondage à choix multiple
  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    2 073
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 2 073
    Points : 56 174
    Points
    56 174
    Par défaut Doit-on abandonner la responsabilité du test d’un logiciel à celui qui écrit ses lignes de code ?
    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 ?

  2. #2
    Expert éminent sénior
    Avatar de Mat.M
    Profil pro
    Développeur informatique
    Inscrit en
    Novembre 2006
    Messages
    8 396
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Novembre 2006
    Messages : 8 396
    Points : 20 507
    Points
    20 507
    Par défaut
    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

  3. #3
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 609
    Points
    19 609
    Par défaut
    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.

  4. #4
    Membre éprouvé
    Homme Profil pro
    Consultant informatique
    Inscrit en
    Décembre 2008
    Messages
    107
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : Décembre 2008
    Messages : 107
    Points : 913
    Points
    913
    Par défaut développeur=mauvais testeur?
    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...

  5. #5
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 838
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 838
    Points : 18 765
    Points
    18 765
    Par défaut
    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.

  6. #6
    MikeRowSoft
    Invité(e)
    Par défaut
    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é.

  7. #7
    Membre éprouvé
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Mai 2016
    Messages
    313
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2016
    Messages : 313
    Points : 1 240
    Points
    1 240
    Par défaut
    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.

  8. #8
    MikeRowSoft
    Invité(e)
    Par défaut
    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...
    Dernière modification par MikeRowSoft ; 06/11/2017 à 13h40.

  9. #9
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 807
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 807
    Points : 32 103
    Points
    32 103
    Par défaut
    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. #10
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 387
    Points
    9 387
    Par défaut
    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.

  11. #11
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 609
    Points
    19 609
    Par défaut
    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.

  12. #12
    Inactif  
    Profil pro
    Inscrit en
    Août 2008
    Messages
    238
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Août 2008
    Messages : 238
    Points : 620
    Points
    620
    Par défaut
    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.

  13. #13
    MikeRowSoft
    Invité(e)
    Par défaut
    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...

  14. #14
    Membre confirmé

    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Février 2005
    Messages
    464
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Loire (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2005
    Messages : 464
    Points : 646
    Points
    646
    Par défaut tous les tests sont bons à prendre
    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.

  15. #15
    Expert éminent sénior
    Profil pro
    Inscrit en
    Décembre 2007
    Messages
    6 807
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : Décembre 2007
    Messages : 6 807
    Points : 32 103
    Points
    32 103
    Par défaut
    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.

  16. #16
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2011
    Messages
    501
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2011
    Messages : 501
    Points : 1 158
    Points
    1 158
    Par défaut
    Citation Envoyé par Ryu2000 Voir le message
    Ç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.

  17. #17
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par el_slapper Voir le message
    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...)

  18. #18
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    Janvier 2011
    Messages
    3 146
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : Janvier 2011
    Messages : 3 146
    Points : 9 387
    Points
    9 387
    Par défaut
    @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...

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

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

  19. #19
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    Décembre 2008
    Messages
    9 838
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2008
    Messages : 9 838
    Points : 18 765
    Points
    18 765
    Par défaut
    Citation Envoyé par koyosama Voir le message
    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...

  20. #20
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 609
    Points
    19 609
    Par défaut
    Citation Envoyé par transgohan Voir le message
    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.

    Citation Envoyé par transgohan Voir le message
    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 !

Discussions similaires

  1. Réponses: 251
    Dernier message: 23/11/2013, 00h15
  2. Doit-on soumettre les vétérans à des tests de programmation avant embauche ?
    Par Cedric Chevalier dans le forum Débats sur le développement - Le Best Of
    Réponses: 203
    Dernier message: 23/10/2013, 16h13
  3. Réponses: 191
    Dernier message: 18/10/2013, 11h37
  4. [Access2000] test si champ vide qui marche pas ...
    Par michaelbob dans le forum Access
    Réponses: 2
    Dernier message: 17/10/2005, 10h46

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo