Un programmeur est-il censé être autosuffisant?

Sur mon lieu de travail actuel, nous n'avons pas de testeurs, la raison pour cela de la direction étant: "si nous avions des testeurs, vous ne testeriez pas du tout votre propre code". Ce genre de pensée semble nuire à la qualité du produit, car pendant que je teste mon propre code, il y a beaucoup de choses qui me manqueront juste parce que je connais le système à fond et je ne sais pas comment l'utiliser c'est faux". Les tests de la boîte noire ne fonctionnent pas vraiment car j'évite inconsciemment les pièges dans lesquels un testeur dédié tomberait. Une grande partie de mon temps est consacrée à la correction de bogues qui se sont glissés dans le code de production et trouvés par l'utilisateur final.

Le système en question est grand mais est développé uniquement par moi. Cela a également fait tomber certaines tâches de gestion sur mes genoux, telles que la définition des horaires et le travail sur les spécifications.

Ce genre de tâches devrait-il être de ma responsabilité? Je me vois strictement comme un programmeur et rien d'autre. Et si ce sont mes responsabilités, dans quelle mesure? Quand un projet est-il si important qu'il nécessite des testeurs? Un programmeur doit-il affiner les spécifications, s'inquiéter de la gestion du projet ou même fournir un support client?

Remarque

Certains pourraient avoir l'impression que je suis contre l'élargissement de mes responsabilités - ce n'est pas le cas, j'ai hâte d'obtenir un rôle qui implique plus de tâches de gestion, mais actuellement il ne fait pas partie de ma description de travail. Jusqu'à ce que je sois officiellement employé comme tel ou que les tâches supplémentaires commencent à apparaître sur mon chèque de paie, je vais me considérer comme «juste» un programmeur. Malheureusement, en tant que développeur junior, le passage à des fonctions de gestion ne se fera pas très bientôt.

D'excellentes réponses à ce jour, continuez à venir si vous avez quelque chose à ajouter ou des expériences personnelles à partager!

Vous n'avez testeurs. Seulement, vous les appelez «utilisateurs finaux». Cela est préjudiciable pour toutes les raisons que vous décrivez; peu importe à quel point vous êtes un codeur consciencieux, vous ne pourrez tout simplement jamais faire un assez bon travail en surmontant vos propres idées préconçues sur la façon dont le code est «censé» être utilisé pour vous permettre de trouver toutes les façons dont il peut bousiller .

Vous devez rouvrir ce problème avec la direction. À ce stade, il semble que vous ayez des données solides pour étayer votre cas; L'approche pratique actuelle de l'assurance qualité vous fait perdre du temps et compromet l'expérience de vos utilisateurs. Vous devez être prudent dans la façon dont vous présentez cela afin qu'il soit clair qu'il s'agit d'un problème structurel et non pas d' un cas de "Vous êtes nul dans les tests", mais cela ressemble à une discussion qui doit avoir lieu.

Il semble que vous arriviez à un carrefour avec cet employeur. Si vous avez l'intention de rester un programmeur et rien d'autre, vous devrez peut-être commencer à repousser et à demander qu'ils commencent à vous obtenir l'aide dont vous avez besoin pour prendre certaines des tâches de gestion de votre assiette, en faisant venir quelqu'un de nouveau ou en élargir les responsabilités d'un collègue existant. ("Ce n'est pas pour cela que vous m'avez embauché, et ces tâches ne disparaissent pas. Le temps que je passe mal à faire ce genre de choses, c'est du temps que je ne consacre pas à ce que je suis bon.") Mais cela peut ou peut ne soyez pas réaliste. Pensez-vous que vous pourriez gérer le passage à un rôle plus managérial si elles vous donnaient les ressources et l'autorité dont vous auriez besoin pour bien faire le travail?

En ce qui concerne la taille d'un projet avant d'avoir besoin de testeurs, je ne sais pas comment définir précisément cette ligne, mais je pense vraiment que vous l'avez franchie. Vous passez plus de temps que vous ne le souhaiteriez à corriger les rapports de bogues provenant d'utilisateurs réels; pour moi, cela dit qu'il est temps de consacrer plus d'efforts à empêcher les bugs d'arriver aux utilisateurs en premier lieu.

Oui. Si vous le devez , vous devriez pouvoir tester votre code. (Je ne parle pas de tests unitaires, mais de tests d'acceptation et autres.)

Non . Les testeurs sont meilleurs en test que vous. Et comme vous le faites remarquer, tout comme la relecture, il est très difficile de repérer vos propres erreurs. Avoir des globes oculaires supplémentaires aura un impact (bon) majeur sur la qualité de votre programme.

Vous avez beaucoup d'autres questions. Je ne répondrai qu'à une seule:

Un programmeur doit-il affiner la spécification?

Oui! Vous devez implémenter la spécification, vous devez donc vous assurer que la spécification est réellement implémentable. De plus, en tant que programmeur - formé à la pensée claire, à la précision et autres - vous pouvez aider les gens à découvrir ce qui doit réellement être fait et à éliminer les exigences ambiguës ou logiquement erronées.

Ce qu'ils disent et la réalité sont probablement deux choses différentes. La raison la plus probable est:
"Pourquoi dois-je payer le salaire d'un testeur alors que je peux juste faire faire au programmeur un double devoir?"

Bien sûr, ils ne diront pas cela et inventeront toutes sortes d'excuses qu'ils jugent raisonnables. Je peux penser à plusieurs réfutations à leur propos, mais honnêtement, ils ne vont pas aider. J'ai vu cette bataille à plusieurs reprises et ils changeront simplement d'approche chaque fois que vous démystifierez leur raisonnement actuel. Finalement, ils abandonneront et vous demanderont de le faire de toute façon et vous serez étiqueté plaignant.

La meilleure approche à laquelle je peux penser est de ne pas y remédier d'un point de vue qualitatif, ce que la direction ne semble jamais valoriser tant qu'il n'y a pas de problèmes, mais du point de vue des coûts. Les testeurs sont, ou du moins sont perçus comme, moins chers que les programmeurs. Rappelez-leur qu'en vous faisant faire un double devoir, ils paient une ressource mieux rémunérée (programmeur) pour faire le travail qui pourrait être accompli par une ressource moins chère (testeur). Ainsi, ils ne maximisent pas la valeur qu'ils retirent de vos compétences en programmation.

Cette approche a l'inconvénient de s'effondrer si vous êtes salarié et qu'ils n'ont aucun remède à vous faire simplement travailler plus d'heures supplémentaires non rémunérées, mais cela vaut le coup.

Le système en question est grand mais est développé uniquement par moi. Cela a également fait tomber certaines tâches de gestion sur mes genoux, telles que la définition des horaires et le travail sur les spécifications.

C'est suffisant.

Ce genre de tâches devrait-il être de ma responsabilité?

C'est finalement à votre direction de décider.

Je me vois strictement comme un programmeur et rien d'autre.

Vous êtes peut-être alors dans le mauvais travail. Beaucoup de gens aiment se voir confier une responsabilité supplémentaire.

Et si ce sont mes responsabilités, dans quelle mesure?

Si la direction le dit, oui.

Quand un projet est-il si important qu'il nécessite des testeurs?

Lorsqu'il y a trop de travail que les développeurs doivent faire. À ce stade, la direction doit décider si elle souhaite utiliser un testeur dédié ou prendre le risque de lésiner sur les tests. (En fin de compte, les développeurs ne peuvent pas faire grand-chose.)

Il y a des avantages certains à avoir des testeurs dédiés, mais il y a aussi des inconvénients ... en plus du coût d'employer du personnel supplémentaire.

Si un programmeur devait affiner la spécification,

Si nécessaire, oui. En fait, si la spécification doit être affinée et que personne d'autre n'y travaille, l'échec de cette opération risque d'entraîner l'échec du projet.

s'inquiéter de la gestion du projet

Si nécessaire, oui.

ou même fournir un support client?

Si nécessaire, oui.

Il me semble que vous êtes surmené et que vous réagissez à la pression. C'est un problème. Mais prendre la position selon laquelle «ce n'est pas votre travail de faire X, Y, Z» ne va pas aider. Un meilleur plan consiste à indiquer clairement qu'il n'y a que peu de choses que vous pouvez faire et à souligner que cela risque d'entraîner le non-respect des délais, le non-respect de la qualité, un mauvais service client, etc. Mais faites de votre mieux de toute façon ... sans nuire à votre santé, vos relations, etc. dans le processus.

Nous avons des testeurs. Je ne voudrais pas travailler sans eux. Bien que j'écrive des tests unitaires (en utilisant TDD) et des tests d'intégration automatisés pour tout mon code, les testeurs ont toujours une fonction très précieuse.

1. Ils sont hautement qualifiés et ont des compétences différentes des programmeurs.
   1. Ils ont beaucoup d'expérience et de connaissances sur la façon de faire des tests d'AQ et de vérifier que le code qui a été produit correspond vraiment à la fois aux attentes de l'utilisateur et au comportement réel des utilisateurs.
   2. Ils ont rencontré de nombreux bugs et savent très bien penser à des situations susceptibles de casser le logiciel.
   3. Ils ont tendance à être cyniques et systématiques. J'ai observé que les programmeurs sont souvent beaucoup plus optimistes.
2. Ils fournissent de précieuses informations précoces sur la convivialité. Par exemple, lors de la création récente d'une API REST, les zones que les testeurs QA ne pouvaient pas comprendre facilement étaient une bonne indication des zones avec lesquelles l'utilisateur serait également mécontent.
3. Ils testent sur l'environnement réel, en fait de nombreuses configurations du vrai matériel, du système d'exploitation, etc.
4. Ils savent comment construire des bancs d'essai à grande échelle et réalistes et faire des tests de performance, de charge et de stress
5. Ils visent à empêcher les mauvaises versions de sortir. Les programmeurs ont tendance à se concentrer sur la publication du code. Son presque comme, un programmeur publiera le code par défaut, mais un testeur QA aura besoin d'une raison pour le libérer (il a été démontré qu'il fonctionne!)

"si nous avions des testeurs, vous ne testeriez pas du tout votre propre code"

" Si votre voiture avait une ceinture de sécurité, vous la planteriez tout le temps! "

Ce genre de tâches devrait-il être de ma responsabilité? [...] Et si ce sont mes responsabilités, dans quelle mesure?

La réponse est "ça dépend". D'après ce que je comprends, vos employeurs vous considèrent comme le "service informatique individuel". Si tel est le cas, oui, ils le sont (sous votre responsabilité). Si vous avez des responsabilités que vous détestez absolument et que vous souhaitez éviter, recherchez un poste au sein d'une entreprise avec un département informatique plus important.

Quand un projet est-il si important qu'il nécessite des testeurs?

Ce n'est pas (tout à fait) une bonne question à poser. Vous préférez demander "quand la qualité du produit / de l'image de l'entreprise est-elle si importante qu'elle nécessite des testeurs?"

Si un programmeur devait affiner la spécification, [...]

Oui définitivement. La plupart du temps, il y a une grande différence entre ce dont un développeur / implémenteur a besoin et ce que les clients fournissent [comme spécifications].

Plusieurs fois, c'est à vous de trouver des zones grises / non spécifiées et de poser les bonnes questions, de remarquer et de signaler les exigences techniquement impossibles ou contradictoires, etc. (surtout si vous êtes le seul développeur).

[...] vous inquiétez-vous de la gestion du projet ou même de fournir un support client?

Cela dépend des responsabilités que vous avez acceptées lorsque vous avez pris le poste. Par exemple, certains postes nécessitent que vous vous adressiez directement aux clients. Toutes choses étant égales par ailleurs, j'essaierais d'éviter de tels postes (mais c'est à vous de décider et vous n'aurez peut-être pas beaucoup de choix d'emploi).

Tout d'abord, le test, ou mieux dit l'assurance qualité, ne consiste pas seulement à tester la fonctionnalité en cliquant sur l'application. L'assurance qualité concerne les processus . Non seulement pour tester l'application pour trouver les erreurs, elles doivent également empêcher les développeurs de les faire.

1. Spécifications du produit + cas d'utilisation
   Même si tout le monde sait (ou pense le faire) quelle est la fonctionnalité du produit, elle doit être notée. Vous ne pouvez pas tester une application sans une spécification claire. Une spécification définit ce qu'est un comportement correct et ce qu'est un bogue.
2. Tests unitaires, tests d'intégration
   Tests des composants internes difficiles à tester via l'interface utilisateur, états d'application exceptionnels. C'est un must pour tout système plus grand. Les deux types de tests ont également une autre propriété intéressante - ils vous obligent à parcourir chaque partie du code à nouveau et vous réaliserez des bugs / problèmes d'architecture que vous n'avez jamais vus auparavant.
3. Qualité du code et normes de codage L'
   une des tâches que l'AQ devrait effectuer consiste à mesurer la complexité du code. Le code de faible complexité réduit la possibilité d'erreurs (évitant les bogues).
4. Revues de code
   Lorsqu'un projet atteint une taille donnée, ou qu'il est utilisé par de nombreux utilisateurs, les revues de code sont un must. Un autre programmeur trouve toujours des problèmes de code / bogues que vous aviez manqués. Le programmeur est parfois aveugle aux bogues évidents dans son propre code.
5. Documentation
   Documentez votre code et son architecture, il vous aidera à réaliser d'éventuels défauts (ma propre expérience).
6. Testers
   Tester n'est pas un singe qui clique simplement sur l'interface utilisateur. Un testeur prend les spécifications et les cas d'utilisation et crée des cas de test. Il les teste ensuite un par un. Si un bogue est signalé par les utilisateurs finaux, un cas de test doit être ajouté pour cela.

Un programmeur ne doit jamais créer la spécification (1). Vous n'êtes pas là pour décider de la fonctionnalité. Habituellement, ils doivent parler aux utilisateurs finaux, créer des conceptions graphiques, etc. C'est une tâche longue. Si un programmeur décide de la fonctionnalité, il finit généralement par "ça va, mais pourriez-vous tout changer dans cette fenêtre d'ici demain?" "ce n'est pas ce que je voulais" "ça marche mais c'est difficile à utiliser" "il manque la seule fonctionnalité dont nous avions vraiment besoin".

Ce qu'un programmeur peut réaliser, c'est 2, 3 et 5.

Vous avez besoin d'un autre programmeur pour 4. Toute entreprise avec un grand projet informatique et un seul développeur qui connaît les étapes du système sur un terrain très dangereux.

Si vous n'avez pas assez de temps, ne vous embêtez jamais à créer des cas de test (5). Une personne dédiée est généralement nécessaire car cela prend beaucoup de temps. Sans cas de test, le test n'est qu'une blague.