Responsabilité de reproduire les bogues

Je développe un programme en utilisant une bibliothèque créée par un autre programmeur (il travaille dans la même entreprise). Récemment, j'ai découvert une fuite dans la bibliothèque, qui se produit dans certaines conditions réseau après quelques heures de fonctionnement. J'ai déposé un bug avec une description des conditions pour que cette fuite se produise. Ce développeur a répondu que "cela ne suffit pas", "ce n'est pas sa responsabilité de reproduire les bogues" et je dois créer un test unitaire pour reproduire ce bogue, sinon il ne fait rien.

1. A-t-il raison?
2. Que puis-je faire dans cette situation? La création d'un test unitaire est impossible, car elle dépend de certains synchronisations aléatoires du réseau.

Est-il juste est probablement une question à laquelle on ne peut pas vraiment répondre sans connaître votre entreprise. Cependant, il n'est certainement pas très utile.

Je soulèverais le bogue avec lui (ce que vous avez fait), si cela pose un problème avec votre projet, je le soulèverais en tant que bloqueur avec votre chef de projet et préciserais clairement que vous avez soulevé le bogue avec les personne, mais cela aura un impact sur votre projet s'il n'est pas corrigé rapidement.

Je voudrais également aller parler au développeur et expliquer pourquoi il est impossible de créer des tests unitaires, mais vous seriez heureux de le montrer sur votre machine (en supposant que cela soit possible?).

Il a raison à 100% que vous devez fournir suffisamment d'informations pour rendre le bogue reproductible - sinon, il n'y a aucune chance de savoir si un correctif qu'il fournit fonctionnera vraiment.

Mais - il est IMHO 100% faux que cela doit être sous la forme d'un test unitaire. Si vous pouvez décrire un scénario de test de manière à ce qu'il puisse reproduire l'échec (au moins avec une forte probabilité dans un délai raisonnable ou par des tests manuels), vous avez une preuve que le problème existe - ce qui devrait régler votre collègue dans la responsabilité de le réparer. Bien sûr, si vous êtes capable de créer un scénario qui reproduit le bug plus rapidement, cela lui serait utile. Idéalement, on ferait un test automatisé à partir de cela, et cela dépend de votre organisation qui en a la responsabilité.

Les deux parties devraient déployer des efforts.

Le développeur de bibliothèque doit faire un effort supplémentaire même sans tests unitaires, car certains problèmes ne peuvent pas être reproduits avec des tests unitaires. Parfois, c'est du matériel, parfois c'est une séquence spécifique d' actions correctes du reste du programme qui fait que la bibliothèque produit de mauvais résultats.

Vous devriez faire un effort supplémentaire, car après tout cela, je ne serai pas un bogue dans la bibliothèque, mais le résultat d' actions incorrectes du reste du programme (par exemple, un tas corrompu peut rendre toute bibliothèque se comportant bizarrement). Il est donc logique de réduire autant que possible le code non-bibliothèque impliqué dans la reproduction des bogues. Et vous le ferez probablement plus rapidement et plus proprement qu'une personne qui ne connaît pas le code de votre application.

Si l'auteur de la bibliothèque n'est pas en mesure de reproduire le bogue sur la base de votre rapport, il est déraisonnable de s'attendre à ce qu'il y consacre beaucoup de temps, sans parler de le corriger.

Mais vous avez également un temps limité à travailler sur un produit périphérique à votre intérêt. Malheureusement, cela peut signifier que le bogue continue d'exister et qu'aucun travail n'est effectué pour le résoudre.

Heureusement, ce n'est pas nécessairement une catastrophe - alors que dans un monde idéal, tous les logiciels seraient exempts de bogues, ce n'est pas le cas, et nous devons donc établir des priorités en fonction des problèmes qu'il nous cause.

Cela signifie qu'il est en effet de votre responsabilité de développer un cas de test reproductible SI VOUS VOULEZ LE FIXER. Peu importe que cela soit réparé, et dans ce cas, vous avez fait tout ce qui peut et devrait être attendu de vous. Vous voudrez peut-être le réparer, mais pas assez pour consacrer du temps à le rendre reproductible à ce moment. C'est parfaitement acceptable.

Signaler un bug au mieux de vos capacités dans le temps que vous avez à le traiter est tout simplement une bonne citoyenneté, vous n'avez pas besoin d'aller au-delà de cela, sauf si cela est nécessaire pour votre programme. Et vous ne voudrez peut-être pas le faire même alors, il peut y avoir une autre bibliothèque que vous pourriez utiliser, ou il peut être possible de lancer la vôtre dans un délai raisonnable. Fondamentalement, c'est à vous de décider ce que et quel genre d'effort cela vaut pour vous.

Je serais enclin à laisser mentir les chiens endormis pour l'instant - vous avez soulevé la question et elle lui est attribuée. Vraisemblablement, des processus sont en place pour suivre les bogues en suspens et les poursuivre?

Si vous souhaitez progresser activement dans cette voie, je vous suggère de parler à votre responsable pour voir s'il existe des outils de test disponibles qui peuvent reproduire le problème de manière fiable.

Du côté du développeur - il serait sérieusement inerte de leur part de ne rien faire étant donné que vous avez fourni les informations requises. Cependant, il est possible qu'ils aient une charge de travail énorme et ne peuvent donc pas consacrer le temps nécessaire pour suivre le problème.

Vous avez trouvé un bug, vous l'avez signalé et il est un imbécile à ce sujet.

Si vous étiez tous deux des amis proches, il aurait fait quelque chose pour vous aider, mais il préférait simplement repousser le problème.

Vous pouvez faire plus, en signalant plus de détails et en essayant de soutenir vos affirmations selon lesquelles il y a une fuite de mémoire. Pourtant, vous avez vos propres responsabilités et devez terminer votre propre travail.

Connectez-vous autant d'informations que possible dans le suivi des bogues et continuez.

Si vous revoyez cette personne à l'avenir. Soyez amical, essayez de parler des intérêts communs et comprenez que de bonnes relations sont beaucoup plus efficaces pour régler les problèmes, puis toute quantité de faits que vous pouvez fournir pour appuyer une réclamation.

Souvent, ce que j'ai rencontré dans des situations similaires est une supposition que tous les bogues doivent être corrigés et bien qu'il soit admirable, c'est certainement un excellent objectif à avoir (admettons-le, nous n'avons jamais décidé d'écrire des bogues!), Il est finalement irréaliste dans tout projet d'une taille décente pour corriger un bogue simplement parce que c'est un bogue (si vous pouvez le trouver!) C'est pourquoi nous avons des méthodologies, des modèles et des pratiques de gestion de projet et de codage, etc.

Donc, une chose que je dirais dans la défense du propriétaire de la bibliothèque (et cela a été le cas lorsque j'ai travaillé sur de grands projets) est que le temps de développement coûte de l'argent et est une ressource limitée, donc la décision sur la façon dont un rapport est traité , qui enquête, quels tests sont produits / nécessaires et, finalement, si (et si oui, quand) un correctif est mis en place est basé uniquement sur l'impact commercial. Quel est l'impact du redémarrage de votre long processus de temps en temps s'il échoue et pouvez-vous facilement automatiser cela à la place (et peut-être ne devriez-vous pas déjà être une mesure de programmation défensive?) Est-ce juste le temps ou est-ce plus? ?

Regardez également de leur point de vue, un rapport de bogue d'un utilisateur d'un problème imprévisible dans un peu de code qui se produit très rarement, uniquement en conjonction avec leur code, éventuellement uniquement sur une machine et uniquement sous un ensemble de timing inhabituel les conditions n'auront tout simplement pas de justification solide pour une grande partie du temps de développement à trouver et à corriger - si c'est même possible. Mais s'il s'agit d'une analyse de rentabilisation suffisamment solide pour que cet utilisateur veuille / doive prendre le temps d'enquêter de manière plus approfondie et de fournir un cas de test / une application fiable ou une description du problème radicalement plus détaillée que leur version initiale, il pourrait s'agir d'un tout autre jeu de balle. .

Il s'agit peut-être d'un problème de communication que le propriétaire de la bibliothèque n'a pas envisagé de formuler ainsi et si vous avez une solide analyse de rentabilisation (comme votre code est coûteux pour l'entreprise, a une exigence de conformité légale, une faille de sécurité ou en a autre effet d'entraînement majeur), il est temps de le donner à la direction et de les laisser se battre.

Vous avez mentionné que «j'ai déposé un bogue avec une description des conditions pour que cette fuite se produise».

Si vous êtes sûr que la description est vraiment suffisante pour reproduire le bug, vous connaissez déjà les conditions exactes. Maintenant, si vous ne pouvez pas écrire de test unitaire après avoir connu les conditions, cela signifie clairement que vous ne pouvez pas vous moquer de certains composants impliqués ou que certaines parties du code sont trop étroitement couplées pour permettre de créer un test unitaire pratique.

Vous devez demander au propriétaire de la bibliothèque de refactoriser le code pour vous permettre de créer un test unitaire. Vous devrez expliquer clairement ce qui se trouve dans la bibliothèque qui vous empêche de créer un test unitaire. Il devra refactoriser le code, sinon admettre que le test unitaire n'est pas possible avec le code actuel. Dans les deux sens, vous gagnez.

Si cela ne fonctionne pas, voici les options que vous avez:

• Vous pouvez reproduire un bug avec plus de preuves.
• Essayez d'impliquer une autorité supérieure et demandez-lui d'évaluer vos preuves.
• Essayez d'utiliser la bibliothèque dans une application prototype avec un environnement simulé à coder uniquement pour reproduire le bogue. De cette façon, vous pourrez prouver au moins qu'un bogue existe.