Essayez de modifier votre schéma de travail pour inclure davantage de vos propres tests avant de proposer la fonctionnalité. Cela entraînera la durée des billets plus longtemps qu'ils remarqueront. Une fois interrogé sur l'augmentation soudaine du délai de livraison, répondez simplement que vous passez plus de temps à tester divers scénarios pour vous assurer que vous fournissez un code sans bogue. Auparavant, ce processus était divisé en boucles de tests et de corrections de bogues, mais comme ils veulent avoir une fonctionnalité prête au premier coup, ces boucles doivent être exécutées avant que tout ne soit fait.

Ce changement devrait être correct pour eux ou s'ils insistent pour que vous passiez le même temps à faire une tâche qu'avant le changement et que vous ne payiez pas pour corriger les bogues, la seule option est de partir .

Un autre changement possible dans le flux de travail consiste à améliorer les tâches. Assurez-vous de ne pas commencer à travailler sur la tâche avant d'avoir toutes les données, cela inclut des scénarios du flux de processus (si vous concevez quelque chose comme un système de paiement ou de notification pour l'application), des appareils sur lesquels travailler (pour certains éléments de l'interface utilisateur), etc. sur. Si vous avez tout cela et que le bogue trouvé n'est pas inclus dans le scénario demandé, ce n'est pas un bogue mais une extension de la tâche.

Tout d'abord, vous n'avez pas besoin de les convaincre par un argument. Vous êtes indépendant, alors les choses sont formellement réglementées par votre contrat .

Cela dépend des spécificités de votre contrat, mais si vous êtes indépendant, il est raisonnable de supposer que toute fonctionnalité doit être acceptée pour être considérée comme terminée. Sinon, c'est la première chose à changer.

Une fois que c'est fait, ils DOIVENT payer pour tout changement, y compris les bogues.

Pendant leur exécution, ils DOIVENT payer pour tout bogue causé par des spécifications incomplètes ou erronées, des changements et des causes externes (pilote défectueux, mises à jour du système d'exploitation ...). Cependant, cela peut être difficile à déterminer, voir plus loin.

Vos propres erreurs avant l'acceptation peuvent être dans une zone grise, mais votre contrat EXISTANT devrait clarifier cela. Ils ne peuvent pas changer de contrat unilatéralement plus que vous ne pouvez commencer à facturer un taux horaire différent.

D'après mon expérience, le fait de ne pas facturer de bogues est controversé car la cause fondamentale est souvent jugée alors elle est généralement plus facile pour tout le monde de les compter dans le cadre du processus de développement. N'utiliserait-il pas plus de temps pour implémenter correctement cette fonctionnalité depuis le début? Combien en plus? Est-ce causé par une spécification incomplète ou peu claire? Un nouveau code plante à cause d'un bogue dans l'ancien code? L'ancien code plante à cause du nouveau code? Vous ne voulez certainement pas jouer à ce jeu tous les jours.

Si vous travaillez avec l'interface utilisateur, c'est encore plus évident: une approche bonne et sensée est itérative (avec des sessions de test utilisateur fréquentes) et certains résultats sont à la limite des bogues (même si vous avez littéralement et correctement interprété les spécifications). Je suis sûr que vous avez vécu cela et vous savez ce que je veux dire (par exemple, j'ai tendance à considérer un bogue comme une zone de texte pour entrer un chemin sans saisie semi-automatique, même si les spécifications ne mentionnent pas explicitement cette fonctionnalité ).

Si vous avez besoin d'avoir ce genre de discussions, vous ne les suivrez guère et vous perdrez votre temps et votre argent, traquer un bogue pourrait même prendre des jours.

Ne vous entendez pas là-dessus puis partez IMMÉDIATEMENT, vous aimerez peut-être le travail mais, à moins que vous ne soyez prêt à donner une partie éventuellement importante de votre salaire (ou à vous battre pour chaque bug), vous serez toujours celui qui perdra quelque chose.

Alternativement, en supposant que vous faites de votre mieux pour fournir un logiciel de bonne qualité :

• S'ils veulent renégocier le contrat (et vous êtes prêt à le faire), vous pouvez modifier votre taux horaire pour compenser le temps que vous passerez à corriger les bogues (maintenant vous avez probablement assez de données pour extrapoler un nombre). Cela coûtera plus cher, mais il leur sera toujours facile de planifier ces coûts à partir du taux horaire mis à jour et de la vitesse de développement des projets / codes précédents.
• Vous ne fournissez pas de fonctionnalité tant que vous n'avez pas effectué tous les tests, avec tous les outils, un testeur ferait l'affaire. Bien sûr, vous facturez cela en tant que développeur, pas en tant que testeur. Ils verront que, généralement, il est moins coûteux de laisser trouver certains bogues par les testeurs. Soyez prudent car la définition de ce qu'est un bogue doit être formellement acceptée. Si vous utilisez déjà tous les outils pour fournir raisonnablement du code sans bogue (le fait qu'ils en aient trouvé à l'aide d'un outil automatisé est suspect), cela coûtera beaucoup plus cher à l'entreprise car l'estimation du développement / test / correction est fusionnée et moins prévisible. Ils doivent absolument être conscients de ses implications car ils paient un développeur pour faire le travail de testeur, y compris les tests de singe qui en font toujours partie.

D'après mon expérience, si vous choisissez l'option 2 alors vous intégrerez évidemment aussi l'option 1 (il y aura toujours des bugs et personne ne travaille gratuitement) puis les coûts globaux sont voués à augmenter. Dans la mesure du possible, une relation de confiance, saine et professionnelle devrait éviter les deux.

Remarque: ne vous trompez pas en pensant que vous pouvez trouver tous les bogues qu'un testeur peut trouver. Les tests logiciels sont une expertise différente, un art distinct, qui nécessite du temps pour être maîtrisé et il ne s'agit pas seulement de tests unitaires / d'intégration / de régression / de stress (que vous DEVEZ déjà avoir en place). Bien sûr, vous pouvez apprendre à être un bon testeur, mais cela n'arrivera pas en un jour.

Il y a 2 arguments que vous devriez donner à votre employeur:

1. Vous êtes payé pour le temps travaillé, pas pour le sujet travaillé.
2. S'ils veulent de la qualité, logiciel sans bogue, ils devraient vous payer pour créer un logiciel de haute qualité et sans bogue.

Le premier argument est important pour vous de comprendre. Vous êtes payé pour chaque heure que vous investissez dans ce logiciel. Si votre employeur commence à ne pas payer certaines heures, il ne vous valorise ni vous ni votre travail. En gros, ils vous disent que corriger les bogues vaut moins que créer du nouveau code.

Si vous les laissez évaluer votre temps différemment pour corriger les bogues, quelle est la prochaine étape? La documentation est sans valeur, vous n'êtes donc pas payé. Les tests unitaires ne font pas partie de l'application, vous n'êtes donc pas payé. Nous avons décidé d'exclure cette fonctionnalité de la version, afin que vous ne soyez pas payé pour le temps que vous avez travaillé dessus ... Ne leur permettez pas de démarrer cette spirale. Chaque heure que vous travaillez pour eux vaut la même somme d'argent.

Dites-leur diplomatiquement que votre contrat dit que vous êtes payé à l'heure, indifférent à ce sur quoi vous avez travaillé pendant cette heure. S'ils ne sont pas d'accord, dites-leur que vous définirez vos priorités sur le travail pour lequel vous êtes payé et que les tâches qui ne sont pas payées auront la priorité la plus basse ou ne seront pas exécutées du tout.

Le deuxième argument est important que votre employeur comprenne. Bien payer pour certaines tâches est une incitation à effectuer ces tâches souvent, mais ne pas payer pour une tâche est une incitation à ne jamais faire la tâche. En ne payant pas pour les corrections de bogues, ils vous invitent essentiellement à créer des logiciels bogués.

Dans notre monde moderne plein d'applications pour smartphones et des décennies d'améliorations des logiciels Windows traditionnels, avoir un logiciel bogué nuit gravement à l'image et réputation d'une entreprise. Leur objectif devrait être de décimer le plus de bogues possible. Ils devraient valoriser la correction des bogues au moins autant que l'écriture d'un nouveau code.

L'entreprise essaie de vous arnaquer.

Imaginez que le manager qui a décidé qu'il ou elle ne voulait pas vous payer pour avoir corrigé des bugs avait une personne chargée du contrôle qualité dont le travail à plein temps consiste à examiner chaque partie du travail du manager, chaque décision prise par le manager prend, et trouve un peu de travail et toute décision qui n'est pas parfaite à 100%, puis le gestionnaire est invité à réparer toutes ces choses, sans salaire.

La raison pour laquelle les gens trouvent des bogues dans votre code n'est pas que vous ne faites pas du bon travail, la raison est qu'il y a une équipe d'assurance qualité dont le travail est de trouver des problèmes, et que votre travail est utilisé par des milliers, voire des millions de personnes, qui vont trouver des problèmes.

Imaginez faire entrer dans votre maison un peintre et décorateur qui peint une pièce et pose du papier peint dans une autre pièce, et vous insistez sur un travail parfait à 100% et une fois le travail initial terminé, vous insistez sur le fait que il corrige tous les plus petits défauts que vous trouvez gratuitement. Ce peintre se moquera de vous.

Vous avez le choix de faire beaucoup de travail gratuitement qui devrait être payé, ou de prendre beaucoup plus de temps pour produire du code qui a beaucoup moins de bogues dès le départ, ou de leur donner le choix de vous payer un taux horaire beaucoup plus élevé et vous corrigez les bogues gratuitement, ou ils paient un taux normal, y compris le temps qu'il vous faut pour corriger les bogues. Pensez à ce que vous voulez, puis dites-leur votre décision.

Cette réponse sera impopulaire, mais je pense qu'elle doit être écrite.

Ma suggestion serait pragmatique: évitez simplement de corriger les bogues . Ils ne vous paient pas pour cela, donc rien ne vous incite à le faire.

S'ils vous assignent explicitement à travailler sur un bogue, réaffectez le ticket aux testeurs avec une excuse comme " impossible de reproduire "," besoin de plus d'informations "ou" c'est par conception ". N'expliquez pas ce que vous entendez par là. Vous faites cela pendant votre temps libre, après tout.

Si vous ne pouvez pas éviter de corriger un bogue qui doit être corrigé pour pouvoir implémenter quelque chose de nouveau, faites-le pendant que vous travaillez sur un fonction facturable et enterrer le correctif dans le commit. Pour éviter de vous faire prendre, ne corrigez pas le bogue là où il se produit. Construisez une solution de contournement désagréable dans le code avec lequel vous travaillez ou créez une implémentation entièrement nouvelle de cette fonctionnalité.

Cela conduira-t-il à un bon produit développé en peu de temps? Non, cela conduira à un désordre de buggy maintenu par du scotch qui prendra une éternité à se développer. Mais c'est ce que l'entreprise vous incite à créer avec sa structure de paiement.

En attendant, gardez les yeux ouverts pour un nouvel emploi. Cette société gère mal son développement logiciel. Il n'a pas d'avenir.