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: 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%
Débats sur le développement - Le Best Of Discussion :

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


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Data Consultant
    Inscrit en
    Juillet 2013
    Messages
    2 939
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : Côte d'Ivoire

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

    Informations forums :
    Inscription : Juillet 2013
    Messages : 2 939
    Points : 88 211
    Points
    88 211
    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 ?

  2. #2
    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 102
    Points
    32 102
    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.

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

    Informations forums :
    Inscription : Janvier 2011
    Messages : 805
    Points : 2 919
    Points
    2 919
    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 chevronné
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Juillet 2007
    Messages
    889
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    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 : 889
    Points : 2 042
    Points
    2 042
    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.

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

    Informations forums :
    Inscription : Décembre 2006
    Messages : 614
    Points : 714
    Points
    714
    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
    Expert éminent Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    Mars 2014
    Messages
    1 789
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Mars 2014
    Messages : 1 789
    Points : 7 276
    Points
    7 276
    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.

  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
    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
    Expert éminent Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    Mars 2014
    Messages
    1 789
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : Mars 2014
    Messages : 1 789
    Points : 7 276
    Points
    7 276
    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.

  9. #9
    Expert confirmé Avatar de ManusDei
    Homme Profil pro
    vilain troll de l'UE
    Inscrit en
    Février 2010
    Messages
    1 619
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France

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

    Informations forums :
    Inscription : Février 2010
    Messages : 1 619
    Points : 4 352
    Points
    4 352
    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.

  10. #10
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2007
    Messages
    187
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France

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

    Informations forums :
    Inscription : Janvier 2007
    Messages : 187
    Points : 488
    Points
    488
    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