Affichage des résultats du sondage: Dans quel environnement rencontrez-vous les bugs les plus coûteux à corriger ?

Votants
11. Vous ne pouvez pas participer à ce sondage.
  • Développement

    4 36,36%
  • Tests

    0 0%
  • Contrôle qualité (QA)

    0 0%
  • Pré-production

    0 0%
  • Production

    5 45,45%
  • Autres (à préciser)

    1 9,09%
  • Pas d'avis

    1 9,09%
+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Consultant
    Inscrit en
    juillet 2013
    Messages
    1 453
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 1 453
    Points : 41 364
    Points
    41 364
    Billets dans le blog
    2

    Par défaut 43 % des développeurs passent entre 10 et 25 % de leur temps à déboguer des erreurs détectées en production

    ClusterHQ : 43 % des développeurs passent entre 10 et 25 % de leur temps à déboguer des erreurs
    détectées dans des applications en production

    ClusterHQ a mené une enquête qui a permis de révéler que 43 % des développeurs d'applications passent entre 10 et 25 % de leur temps à déboguer des erreurs découvertes dans les applications en production. Il s’agit donc d’une bonne partie de leur temps perdue qui aurait pu servir à développer de nouvelles fonctionnalités pour les utilisateurs.

    Cette enquête de ClusterHQ a enregistré la participation de 386 professionnels de l’IT, dont des membres d’équipes DevOps (41 %), des développeurs (37 %), des ingénieurs assurance qualité (QA : 5 %) ou encore des professionnels de la sécurité informatique (2 %), entre autres.

    La majorité des personnes interrogées a affirmé que la production est l’environnement où la correction de bugs s’avère la plus coûteuse. Au cours de l’enquête, 62 % des répondants ont en effet choisi la production comme l'étape la plus coûteuse pour corriger les erreurs. Ensuite viennent la phase de développement (18 %), la pré-production (7 %), l’étape de contrôle qualité (7 %) et la phase des tests (6 %).


    Il a ensuite été demandé aux répondants la fréquence à laquelle des bugs sont rencontrés en production. À cette question, 11 % ont répondu qu’ils rencontrent des bugs en production tous les jours, alors que 13 % disent en rencontrer deux à trois fois par semaine. Autrement dit, près d’un quart (24 %) des répondants rencontrent des bugs en production plusieurs fois dans la semaine.

    On note encore que 12 % de ceux qui ont été interrogés rencontrent un bug en production en moyenne une fois par semaine, ce qui porte à un tiers (36 %), le nombre de développeurs qui rencontrent un bug en production au moins une fois dans la semaine.


    Avec la fréquence des bugs rencontrés, ClusterHQ s’est également intéressé au temps que les développeurs consacrent au débogage des erreurs découvertes dans les applications en production. Ici, 34 % des personnes interrogées ont répondu qu’ils y consacrent moins de 10 % de leur temps, alors que 43 % disent passer entre 10 et 25 % de leur temps à déboguer les erreurs dans les applications en production.


    Dans un effort pour découvrir pourquoi les bugs dans la production sont si courants, les personnes interrogées ont été également invitées à identifier les causes les plus courantes. D’après les résultats, l’incapacité à recréer parfaitement les environnements de production lors des tests était la principale cause des bugs découverts en production avec 33 %. Ensuite viennent les causes suivantes :

    • l’interdépendance avec les systèmes externes, rendant les tests d'intégration difficiles : 27 % ;
    • tester avec des données irréalistes avant de passer à la production : 26 % ;
    • la difficulté à partager les données de tests entre différentes équipes : 10 % ;
    • la difficulté à créer des environnements de pré production pour le test : 4 %.


    Commentant les derniers résultats, ClusterHQ explique que le fait que recréer des environnements de production a été cité comme la principale cause de bugs apparaissant en production montre que faire « les tests sur un ordinateur portable est comme ‘‘voler’’ dans un simulateur de vol - l'expérience peut être très différente lorsque vous vous élevez dans les hauteurs », explique la société, qui justifie également la deuxième place de l'interdépendance avec les systèmes externes par le fait que cela rend les tests d’intégration plus lourds.

    Source : ClusterHQ, Market Wired

    Et vous ?

    Que pensez-vous de ces résultats ?
    Dans quel environnement rencontrez-vous les bugs les plus coûteux à corriger ?
    Quelle est la fréquence à laquelle vous rencontrez des bugs dans des applications en production ? Quelles en sont les causes ?
    Pensez-vous que vous passez trop de temps à déboguer ces erreurs ?
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

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

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 619
    Points : 19 041
    Points
    19 041

    Par défaut

    Je suis surpris de la faiblesse de ces chiffres. Les bugs de production sont légion pour tout un tas de raison, qui n'ont pas toutes de coupables. Bon, certaines en ont(J.S.C., si tu nous lis, tu aurais pu tester au moins une fois ta correction du nombre de factures par jour, qui n'a jamais marché).

    Pour le reste, euh, le ciel est bleu, mais il est bon de le rappeler à certains.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #3
    Membre émérite
    Inscrit en
    janvier 2011
    Messages
    648
    Détails du profil
    Informations personnelles :
    Localisation : Autre

    Informations forums :
    Inscription : janvier 2011
    Messages : 648
    Points : 2 299
    Points
    2 299

    Par défaut

    J'aurais tendance à dire que plus on s'éloigne de la phase de dev, plus les bugs sont longs à réparer puisqu'il faut que le développeur se remette dans le contexte en question, éventuellement se remonte un environnement pour débugger, relivre, etc.

    Après, je n'ai jamais remarqué de pattern dans la complexité de résolution intrinsèque des bugs selon leur environnement de détection.

  4. #4
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    497
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juillet 2007
    Messages : 497
    Points : 792
    Points
    792

    Par défaut

    Certes les bug en productions coûtent plus cher à corrigé mais surtout peuvent provoquer d'autres coûts. Et ce sont ces autres coûts qui déterminent de l'importance de les détecter avant la mise en productions. Si l'on peux se permettre de mettre en production (ou preprod) une solutions pas trop tester (pour un environnements peu critique), on fait de sérieuses économies. Et ce car les bugs sont beaucoup plus visible sur le terrain et surtout une applications est en pratique évolutive. La livrer non-fini permet de l'adapter facilement aux besoin qui apparaissent sur le terrain.

    Et il est là le chalenge, livré fini ou presque livré évolutif. Plus l'environnement est critique et pus le processus de mise en prod est complexe et plus l'on doit tester mais moins on sera évolutifs. Je ne suis pas en train de me faire l'avocat du travail baclé mais l'avocat du compromis afin de ne pas tomber dans les raccourcis "Tester toujours plus pour faire du travail propre".

    Un logiciel est comme un maison ou un jardin. On veux bien faire mais ce n'est jamais fini cela évolue sans cesse. Il y a un moment ou il faut en profiter même si tout n'est pas parfait.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  5. #5
    Membre confirmé
    Profil pro
    Inscrit en
    décembre 2006
    Messages
    542
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2006
    Messages : 542
    Points : 552
    Points
    552

    Par défaut

    Rien d'étonnant en soi, pour peu qu'on s'intéresse un peu à la qualité (oui je sais, c'est pas le lieu…*:p ). Paradoxalement, c'est peut-être justement en ayant une politique qualité qu'on risque de voir ce schéma là. C'est quand même une certaine culture de mener un projet destiné à la mise en prod' et non à l'AQ…

  6. #6
    Membre éprouvé Avatar de marsupial
    Homme Profil pro
    DevOp, Tech leader
    Inscrit en
    mars 2014
    Messages
    564
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : DevOp, Tech leader

    Informations forums :
    Inscription : mars 2014
    Messages : 564
    Points : 1 268
    Points
    1 268

    Par défaut

    Après, je n'ai jamais remarqué de pattern dans la complexité de résolution intrinsèque des bugs selon leur environnement de détection.
    Je ne sais si je vais réussir à faire passer mon avis sur la question car cela demande un changement complet de mentalité dans la manière d'aborder la réalisation d'un projet.
    La philosophie habituelle et classique a toujours été de réaliser le cahier des charges puis de traiter les erreurs. C'est-à-dire :

    try

    le code qui fonctionne

    catch

    les erreurs


    Alors que vue de la sécurité, la problématique est de traiter tous les bogues sans exception. C'est-à-dire :

    try

    les erreurs

    catch

    le code qui fonctionne


    Cela reste un avis à moduler suivant les contraintes de rendement, restant conscient du besoin de productivité et de fournir un code fonctionnel et optimisé. Cela demande une évidente maîtrise de la technologie utilisée dans l'environnement donné. Donc un degré d'expertise élevé.

    edit : moralité, choisir une technologie open source et documentée permet d'accéder plus facilement au degré d'expertise nécessaire.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  7. #7
    Membre habitué
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    mai 2016
    Messages
    65
    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 : 65
    Points : 185
    Points
    185

    Par défaut

    Un logiciel contrôlant des aiguillages ferroviaires n'a pas tout à fait les mêmes contraintes qu'un logiciel grand public de retouche de photos...
    On ne sait même pas de quel type de logiciel parle cette étude. Si les sondés représentent tous les secteurs d'activités et des logiciels absolument pas comparables, la valeur informative de l'étude ne me parait pas évidente.

  8. #8
    Membre éprouvé Avatar de marsupial
    Homme Profil pro
    DevOp, Tech leader
    Inscrit en
    mars 2014
    Messages
    564
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : DevOp, Tech leader

    Informations forums :
    Inscription : mars 2014
    Messages : 564
    Points : 1 268
    Points
    1 268

    Par défaut

    Citation Envoyé par wolinn Voir le message
    Un logiciel contrôlant des aiguillages ferroviaires n'a pas tout à fait les mêmes contraintes qu'un logiciel grand public de retouche de photos...
    +1 car très bon exemple de besoin à comparer.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  9. #9
    Membre expert Avatar de ManusDei
    Homme Profil pro
    vilain troll de l'UE
    Inscrit en
    février 2010
    Messages
    1 487
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France

    Informations professionnelles :
    Activité : vilain troll de l'UE

    Informations forums :
    Inscription : février 2010
    Messages : 1 487
    Points : 3 751
    Points
    3 751

    Par défaut

    En général je perd un temps fou à corriger les bugs en prod, mais c'est parce que le client me donne que la moitié du contexte d'exécution.
    Donc je passe beaucoup de temps à chercher, expliquer qu'il me manque des infos, récupérer un bout des infos qui manquent, et on recommence.
    http://www.traducteur-sms.com/ On ne sait jamais quand il va servir, donc il faut toujours le garder sous la main

  10. #10
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 148
    Points : 357
    Points
    357

    Par défaut

    Le plus souvent le développeur qui a développé la fonction fautive n'est plus dans l'entreprise depuis plusieurs mois (la prestation n'a pas que du bon ... :o)) donc il faut pour l'équipe de TMA beaucoup de temps pour comprendre quelle était le besoin métier et ce qu'à voulu faire le développeur pour y répondre. Ensuite lorsque tout se passe bien il faut encore du temps pour trouver une solution qui ne va pas mettre en péril d'autres fonctionnalités qui ne présentent pas de pb de fonctionnement (du moins pas encore !). Bon en réalité comme personne ne comprend ce que fait l'équipe technique en mesure de résoudre le pb, celle ci fait ce qu'elle peut avec les connaissances et les moyens du bord.

Discussions similaires

  1. Réponses: 6
    Dernier message: 08/04/2014, 09h13
  2. Obtenir des enregistrements compris entre 2 dates
    Par rangernoir dans le forum Access
    Réponses: 2
    Dernier message: 29/09/2005, 13h56
  3. Export DLL et noms des points d'entrée
    Par Dozer dans le forum MFC
    Réponses: 5
    Dernier message: 03/06/2005, 09h49
  4. Requete de sélection des 5 dernièrs entrées.
    Par WriteLN dans le forum Administration
    Réponses: 4
    Dernier message: 22/03/2004, 21h40

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