Pensez-vous que c'est une bonne idée pour les ingénieurs logiciels de devoir travailler en tant qu'ingénieurs d'assurance qualité pendant une certaine période? [fermé]

Je le crois. Pourquoi?

1. J'ai rencontré de nombreux ingénieurs logiciels qui pensent qu'ils sont en quelque sorte supérieurs aux ingénieurs QA. Je pense que cela peut aider à étancher cette croyance s'ils font le travail d'un ingénieur QA pendant un certain temps et réalisent qu'il s'agit d'un ensemble de compétences unique et précieux.

2. Plus un ingénieur logiciel est en mesure de tester ses propres programmes, moins son code coûte de temps à se frayer un chemin à travers le reste du cycle de vie du développement logiciel.

3. Plus un ingénieur logiciel passe de temps à réfléchir à la façon dont un programme peut se casser, plus il doit souvent considérer ces cas lors de leur développement, réduisant ainsi les bogues dans le produit final.

4. La définition de "complet" d'un ingénieur logiciel est toujours intéressante ... s'il a passé du temps en tant qu'ingénieur AQ, cette définition correspondra peut-être mieux au concepteur du logiciel.

Remarque Je fais la suggestion ci-dessus avec un petit laps de temps à l'esprit car je suis conscient que le fait que quelqu'un travaille dans un poste qui n'est pas celui pour lequel il est embauché est définitivement une recette pour perdre ce développeur.

Qu'en pensez-vous tous?

1. J'ai rencontré de nombreux ingénieurs logiciels qui pensent qu'ils sont en quelque sorte supérieurs aux ingénieurs QA. Je pense que cela peut aider à étancher cette croyance s'ils font le travail d'un ingénieur QA pendant un certain temps et réalisent qu'il s'agit d'un ensemble de compétences unique et précieux.

Une bonne ingénierie logicielle a une formation en qualité, y compris les tests, les métriques et les statistiques. Toute personne effectuant n'importe quel type de développement logiciel doit être consciente (si elle n'est pas familière) de maintenir un code source de qualité et de produire / maintenir des cas de test efficaces. Au fil du temps, je soupçonne que n'importe quel développeur de logiciels gagnerait à comprendre les différentes facettes de la qualité - la qualité du code, la portabilité, la maintenabilité, la testabilité, l'utilisabilité, la fiabilité, l'efficacité et la sécurité.

Les ingénieurs logiciels peuvent se concentrer sur un aspect particulier du cycle de vie - l'ingénierie des exigences, l'architecture et la conception, la construction, les tests et la maintenance. Cependant, quel que soit votre objectif (en tant que travail ou à la phase actuelle du projet), il est important de se souvenir de la qualité.

2. Plus un ingénieur logiciel est en mesure de tester ses propres programmes, moins son code coûte de temps à parcourir le reste du cycle de vie du développement logiciel.

C'est peut-être vrai. Mais certains problèmes seront mieux vus plus tard dans le développement. Par exemple, les problèmes de performances et d'efficacité peuvent ne pas apparaître avant l'intégration. Avoir un bon code solide et des tests unitaires efficaces ne sont qu'un début. La qualité doit commencer par les exigences et suivre tout au long des activités de maintenance.

3. Plus un ingénieur logiciel passe de temps à réfléchir à la façon dont un programme peut s'arrêter, plus il doit tenir compte de ces cas au fur et à mesure qu'il les développe, réduisant ainsi les bogues du produit final.

C'est une affirmation totalement vraie. Mais là encore, c'est aussi aux ingénieurs des exigences de vérifier qu'il n'y a pas de conflits dans les exigences, aux architectes de s'assurer que la conception répond réellement aux exigences, etc. Tout le monde devrait essayer de percer des trous dans leur travail, puis travailler avec les personnes appropriées pour les sceller bien et serrés.

4. La définition de "complet" d'un ingénieur logiciel est toujours intéressante ... s'il a passé du temps en tant qu'ingénieur AQ, cette définition correspondra peut-être mieux au concepteur du logiciel.

"Complet" ne peut être mesuré que par rapport aux exigences. Soit les exigences sont satisfaites et le projet est terminé, soit il existe des exigences incomplètes et le projet n'est pas terminé. Toute autre mesure de complet est inutile.

Rendre les programmeurs responsables de leur code et les obliger à corriger leurs propres bugs peut s'en occuper. Cela et une perte de bonus et / ou d'emploi.

Non pas que cette expérience n'aiderait pas, mais jusqu'où pouvez-vous aller avec cette ligne de pensée? Support technique, Ventes, Utilisateur Beta, frottez les toilettes (ce serait une expérience humiliante).

"... doivent travailler comme ingénieurs QA ..."? Vous dites que c'est une accusation ou une punition.

Je suis développeur de logiciels. Je considère que cela fait également partie de mon travail d'être ingénieur AQ, même si nous avons un département AQ. C'est mon travail de livrer un logiciel qui accomplit certaines choses, et pour ce faire, je dois écrire des tests unitaires et m'assurer que le logiciel les réussit.

Je suis en partenariat avec notre département QA. Mon objectif est de faciliter leur travail, tout comme leur travail est de m'aider à atteindre mon objectif de fournir des logiciels qui font ce qu'ils devraient, ce qui me rend la vie plus facile. Je les considère comme ma deuxième paire d'yeux et un peu comme un filet de sécurité, tout comme je fais mes tests unitaires.

Je choisis de développer des logiciels et je souhaite développer des logiciels. Si un gestionnaire venait me voir et me disait que je ne pouvais pas faire ça et que je devais faire de l'AQ, je leur dirais qu'ils doivent trouver un nouveau développeur de logiciels ET une personne AQ parce que je ne travaillerai pas là-bas. Je suis anal comme cela peut être avec mon code mais le processus créatif et le puzzle / défi de programmation sont extrêmement importants pour moi. Je préférerais revenir à la conduite de chariots élévateurs si je ne peux pas écrire de code, car être dans un environnement d'entreprise sans l'avantage d'être créatif et d'être mis au défi comme je le serais serait un enfer absolu pour moi.

En général, les options que vous présentez semblent très contradictoires et je me demande si vous avez eu de très mauvaises expériences avec de terribles développeurs. Dans mon esprit, un développeur doit TOUJOURS être conscient des problèmes de qualité et des tests et doit être assez fier de son travail pour ne pas le considérer comme terminé jusqu'à ce qu'il passe avec succès des tests rigoureux dans ses tests unitaires comme ce que le département officiel de l'assurance qualité utilisera. Si j'avais un pair, ou que j'étais technicien dans une équipe et que j'avais un développeur qui montrait une quelconque "tude" envers le QA, il me trouverait en train de le transporter pour une correction d'attitude. Si les deux côtés de la médaille de la livraison de logiciels ne peuvent pas coopérer et agir en équipe, il y a un vrai problème de culture. Je ne voudrais pas travailler là-bas et les RH, ainsi que la haute direction, devraient être informés.

Faire travailler les programmeurs en tant qu'ingénieurs QA est une recette pour perdre vos meilleurs développeurs. La programmation et l'AQ nécessitent des compétences et des processus de pensée différents.

Cependant, il est important que vos programmeurs soient qualifiés dans l'art de tester et de valider leur propre travail avant de le transmettre à l'équipe QA. Les développeurs et l'AQ ont accès à différents outils, connaissances et compétences. Les développeurs doivent être qualifiés pour parcourir leur code à la recherche d'un comportement inattendu, tester les conditions de limite, mettre l'accent sur le code fileté à la recherche de conditions de concurrence, etc., c'est-à-dire tester du point de vue du développeur.

QA fait ses tests du point de vue de l'utilisateur. Penser comme différents types d'utilisateurs, inventer des cas de bord étranges et rendre les problèmes obscurs reproductibles sont des compétences en AQ.

Pas nécessairement - les programmeurs et les testeurs doivent avoir des compétences différentes. Ce n'est pas parce que vous êtes un bon programmeur que vous pouvez être un bon testeur (beaucoup de gens ne le comprennent pas, mais être programmeur ne vous qualifie pas automatiquement pour être un testeur).

Un bon testeur doit avoir des compétences vraiment diaboliques, être capable de faire des choses que le logiciel n'a pas été conçu pour faire, mais peut s'attendre à ce que l'utilisateur le fasse dans le monde réel. Cela demande de l'habileté, de la patience, la capacité de voir ce qui peut mal se passer où, une compréhension de la mentalité de l'utilisateur et tant d'autres facteurs.

Notez que j'utilise les mots programmeur et testeur - mais si vous êtes ingénieur logiciel et que vous n'avez pas encore décidé si vous voulez être programmeur ou testeur, cela englobe ces deux choses et donc oui, vous devez avoir une expérience dans les deux au moins dans les premières années de votre vie avant de prendre la décision.

Cela ne signifie pas que vous prenez un programmeur expérimenté et lui faites tester pendant un certain temps juste pour lui faire comprendre à quel point les ingénieurs QA travaillent dur.

Voici quelques problèmes potentiels que je vois avec votre proposition:

1) Si vous suggérez que vous mettriez des ingénieurs logiciels nouveaux sur le terrain dans le département QA pour un court séjour, cela n'aura-t-il pas simplement l'effet inverse? - ils peuvent supposer que l'assurance qualité est quelque chose que vous faites lorsque vous êtes un débutant et que vous ne comprenez pas ce que vous faites - après tout, c'est ainsi que cela a fonctionné pour eux.

2) Être un très mauvais testeur pendant un certain temps ne leur apprendra pas nécessairement quelque chose de précieux. Mais cela peut les rendre inaccessibles plus tard, car ils supposeront qu'ils savent tout sur les tests maintenant, car ils ont passé 6 semaines dans un service de test une fois.

3) Étant donné qu'ils ne seront évidemment là que pour une courte période, et que le service d'assurance qualité le sait, il est également probable qu'ils ne se verront confier que des tâches relativement peu exigeantes et faciles qui nécessitent peu de supervision ou de compréhension, mais qui les occupent. . Cela ne fera que renforcer 1 et 2.

4) Si vous voulez éviter 1, 2 et 3, comment persuaderez-vous votre département de test qu'il vaut la peine d'investir une énorme quantité d'énergie dans l'enseignement et la supervision de quelqu'un qui n'est même pas intéressé par le test? (Je peux vous dire, cela prend un temps et une énergie effrayants de travailler avec quelqu'un qui, rappelons-le, n'a pas été choisi pour ses aptitudes aux tests . Vous n'offrez pas à l'équipe de test des ressources supplémentaires pendant quelques semaines, vous 'leur demande de perdre une de leurs personnes les plus expérimentées pendant quelques semaines, pendant qu'ils enseignent à votre débutant).

Cela dit, je pense que votre objectif général - accroître la compréhension des tests par les nouveaux ingénieurs logiciels - est vraiment fantastique. Je pense que la suggestion de Greg est plus susceptible de le faire - faites en sorte que vos équipes de développement et d'assurance qualité collaborent étroitement ensemble et travaillez à éliminer les barrières entre les équipes. (Je travaille actuellement dans une entreprise où les testeurs et les programmeurs font partie de la même équipe - c'est vraiment génial, et je ne veux plus jamais retourner travailler dans des équipes distinctes.)

Si vous souhaitez toujours que les programmeurs effectuent un séjour en AQ, voici une suggestion: montrez l'exemple. Allez-y d'abord. Peut-être en faire quelque chose que les membres de votre équipe doivent faire quand ils sont déjà bons et veulent obtenir cet avantage supplémentaire, en passant un peu de temps chaque semaine avec d'autres équipes spécialisées dans les domaines qui se chevauchent - test, DBA, etc. Si vous le présentez comme ça, alors vous aurez plus de chances de succès.

J'ai eu en quelque sorte un cheminement de carrière qui est en quelque sorte l'inverse de ce que vous voyez normalement. J'ai commencé comme support logiciel pour une physique scientifiquement exigeante, puis j'ai fini par travailler à l'intersection de l'architecture, de la programmation et des algorithmes pour une société informatique. Après cela, j'ai fait l'optimisation des performances d'un code d'ingénierie majeur pendant plusieurs années, mais même ce travail a manqué. Maintenant que j'approche de l'âge de la retraite, je fais de l'AQ sur le même code. C'est une combinaison de défi et de corvée. Nous avons un nouveau gars vraiment pointu qui travaille à 100% sur les corrections de bugs, et je passe beaucoup de temps à travailler avec lui. C'est un poste difficile et vous pouvez en apprendre beaucoup en le faisant. À ce stade, mon intérêt principal pour le développement professionnel est pour mes jumeaux, qui sont étudiants de première année à l'université. J'ai donc un nouvel intérêt pour apprendre (ou réapprendre) des choses qui seront pertinentes pour leur carrière, en particulier les mathématiques appliquées. J'ai une perspective différente des choses maintenant que je suis préoccupé par l'AQ / la validation, alors que pour le quart de siècle précédent, c'était la vitesse, la vitesse, la vitesse à tout prix.

Les tests de logiciels sont le processus destructeur plutôt que constructif. Mais le programmeur pense constructif à son produit pour s'assurer que le produit est terminé dans les délais et avec le budget. Si les développeurs de logiciels pensent que leur propre produit est destructeur, qui sera le prochain à construire le produit. Ainsi, chaque partie du cycle de développement logiciel doit être effectuée par les personnes affectées à chaque partie du cycle de développement. Si vous vous êtes engagé dans deux ou plusieurs domaines, il est certain que vous ne serez jamais parfait sur aucun d'entre eux, alors faites une chose, soit programmeur ou AQ, soit toute autre option et soyez parfait sur ce point.