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é]

12

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?

Abbaye de Macy
la source
1
Mon premier emploi était QA. Je détestais ça, mais j'ai vraiment compris l'importance de l'assurance qualité.
Job
Je n'ai pas pleinement apprécié la créativité derrière l'AQ avant de lire le classique de Glenford Myers, The Art of Software Testing .
Macneil
5
J'ai rencontré de nombreux ingénieurs logiciels qui croient qu'ils sont en quelque sorte supérieurs à tous les autres sur la planète ;-)
Steven A. Lowe
Trop vrai Steven.
Macy Abbey
1
Je suggérerais plutôt de demander si c'est une bonne idée pour les ingénieurs logiciels de faire des choses d'AQ, plutôt que de penser qu'une entité non identifiée va les y forcer.
David Thornley

Réponses:

13

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.

Thomas Owens
la source
Merci Thomas, c'est une réponse très instructive et réfléchie.
Macy Abbey
6

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).

JeffO
la source
C'est vrai Jeff, mais je pense que la première approche ne leur enseigne pas nécessairement les outils dont ils ont besoin pour devenir des programmeurs plus efficaces / robustes. Cela met cependant la pression, ce qui est bien.
Macy Abbey
En outre, l'un des inconvénients de cette approche est de perdre un programmeur pendant une certaine période de temps, une semaine ... deux semaines, un mois? Et je ne pense pas que ce soit une bonne idée de leur faire faire des travaux qui ont très peu à voir avec leur travail actuel ... (frotter les toilettes: P)
Macy Abbey
6

"... 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.

l'homme d'étain
la source
Bonjour Greg, j'ai posé la question en pensant à un ingénieur logiciel qui est nouveau dans le domaine, ne comprend pas la valeur de l'assurance qualité et qui n'a pas beaucoup d'expérience en développement vers un ensemble de critères d'acceptation bien définis. La raison pour laquelle j'ai choisi de "devoir" est parce que, comme vous l'avez dit, je ne pense pas que de nombreux ingénieurs logiciels choisissent de travailler en tant qu'ingénieur assurance qualité (comme leur seul devoir) parce qu'ils ont clairement choisi d'être un développeur de logiciels. J'apprécie et partage certainement votre point de vue sur ce que devrait être l'attitude et la relation d'un développeur de logiciels avec l'AQ.
Macy Abbey
Pensez-vous qu'avoir un nouvel ingénieur logiciel en tant qu'ingénieur QA les aiderait à atteindre le point où vous en êtes actuellement?
Macy Abbey
1
Absolument pas. Assurez-vous qu'ils comprennent le fonctionnement des équipes; Développer une attitude d'appropriation des problèmes; Culture une atmosphère ouverte qui encourage les gens à travailler en équipes ad hoc pour discuter et résoudre les problèmes. Trop de personnes et d'entreprises encouragent des silos de connaissances et une attitude «nous contre tous». Honnêtement, le «nous contre tous» doit disparaître à l'intérieur des murs de l'entreprise, car cela fait du mal à tout le monde.
The Tin Man
2
@Macy Abbey, une tactique à envisager pourrait être de faire travailler les développeurs de concert avec l'équipe QA pour développer les scénarios de test. Les tests unitaires peuvent être écrits et conçus en tandem, ou l'équipe QA peut ajouter leurs tests au dossier "tests" où le développeur a des tests unitaires. Certaines personnes pensent qu'il devrait y avoir une séparation entre dev et QA, mais cela favorise la concurrence. Si les deux groupes utilisent leurs globes oculaires et testent leurs astuces ensemble, ils peuvent peut-être détecter les bugs et les fonctionnalités manquantes encore plus rapidement.
The Tin Man
@Greg Merci Greg, cela ressemble à une bonne tactique. Je crois que vous m'avez convaincu qu'un mélange d'autres tactiques est meilleur que ce que j'ai proposé initialement.
Macy Abbey
5

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.

Michael Shaw
la source
1
Merci Ptolémée, je fais cette suggestion avec un petit laps de temps à l'esprit car je suis conscient que quelqu'un qui travaille dans un poste qui n'est pas celui pour lequel il est embauché est définitivement une recette pour perdre ce développeur.
Macy Abbey
Ce n'est pas seulement qu'ils ne travailleraient pas dans un poste pour lequel ils ont été embauchés, ils ne seraient pas non plus dans un poste pour lequel ils ont choisi leur profession et pour lequel ils sont allés à l'école. C'est une gifle majeure pour beaucoup de gens qui mettent leur cœur dans leur carrière. Pour ceux qui considèrent uniquement un emploi comme un chèque de règlement, ce sera parfait.
The Tin Man
@Greg: Ceux qui y participent pour le chèque de paie ne l'aimeront pas non plus. Leur CV sera plus précieux avec X + 1 ans de génie logiciel que X ans de génie logiciel et un an d'AQ, au moins tôt. Sans oublier que vous devez payer vos employés en assurance qualité ainsi que vos employés en logiciels, car personne pour un chèque de paie n'acceptera volontiers une réduction de salaire.
David Thornley
Euh, cela suppose que vous travaillez dans un endroit qui paie moins les gens qualifiés en assurance qualité que les développeurs. Je sais que certains endroits le font, mais cela ne reflète pas mon expérience - quand j'ai connu les salaires des gens, ils ont généralement été comparables.
testerab
1
Dans les premières années de la programmation, votre salaire dépend beaucoup du nombre d'années d'expérience en programmation que vous possédez. Donc, avoir 2 ans C # et 1 an QA vous donne un salaire C # 2 ans plutôt qu'un salaire C # 3 ans.
Michael Shaw
3

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.

Roopesh Shenoy
la source
True Roopesh, même si je pense qu'il y a certainement une intersection entre les deux ensembles de compétences, où travailler en tant qu'AQ pour un petit temps augmentera la vitesse à laquelle quelqu'un améliore ses compétences de test.
Macy Abbey
1

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.

testerab
la source
0

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.

Omega Centauri
la source
Cette anecdote ne semble contenir aucune réponse à la question.
personne le
-2

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.

Panjiyar Rahul
la source