Il se trouve que je connaissais un administrateur système et selon lui, les gars de test n'ont pas de préférences dans une organisation par rapport aux développeurs. Sans doute, les versions logicielles ne sont pas possibles sans testeurs, mais je n'ai jamais mis la main sur les tests, donc je n'en suis pas très conscient. Aucune infraction prévue.
Réponses:
D'après mon expérience, malheureusement, ils sont souvent traités comme des employés de deuxième classe et pire encore, un avantage frivole pour les programmeurs.
Cela découle d'un certain nombre de choses:
Lorsque les testeurs font leur travail correctement, il est facile pour tout le monde, mais les programmeurs d'oublier qu'ils existent même. Tout comme un administrateur de réseau, vous ne les remarquez que lorsqu'ils ne font pas leur travail ou qu'ils le font mal. Du point de vue du reste de l'organisation, on ne se souvient d'eux que pour leurs erreurs.
Il est considéré à tort comme un travail d'entrée de gamme pour les personnes qui aspirent à devenir programmeurs, mais qui ne sont pas encore qualifiés pour ces emplois. En fait, dans une entreprise dans laquelle je travaillais, on leur a donné des titres de poste de programmeur junior malgré leurs demandes d'obtenir un titre de poste de Q&R. Même le fait qu'ils étaient dans un service d'assurance qualité n'a pas suffi à faire bouger les RH à ce sujet.
En raison de # 2, il est supposé que les testeurs sont tous des gens d'entrée de gamme et devraient être payés en conséquence.
Personne n'aime être critiqué, et il est trop courant que les programmeurs défensifs n'aiment pas les testeurs car leur travail les oblige à signaler toute la journée des erreurs de programmeurs. En tant que manager, j'étais constamment en mission de relations publiques pour rappeler aux programmeurs que l'équipe QA était là pour leur donner une belle apparence, pas pour les dénoncer.
C'est généralement un travail que les gens décident par accident et non par choix, du moins au début. Je ne me souviens d'aucun plan de diplôme dans l'une des écoles que j'ai fréquentées qui a préparé les gens aux questions et réponses sur les logiciels. Ils existent, mais généralement dans les écoles professionnelles inférieures, ce qui ne fait que contribuer à l'idée qu'ils sont des professionnels moins qualifiés.
Les emplois de test sont beaucoup plus susceptibles que les emplois de programmation d'être envoyés à l'étranger. Au moins, les programmeurs peuvent affirmer qu'il est plus efficace de communiquer les besoins de conception localement et qu'il est utile de garder la connaissance du fonctionnement de l'application phare de l'entreprise au sein de l'entreprise. Les tests, cependant, sont beaucoup plus faciles à modulariser et donc plus faciles à externaliser.
Pour toutes les raisons ci-dessus, les testeurs ont tendance à voir l'écriture sur le mur et à passer à d'autres tâches (comme la programmation), en particulier les très bonnes. Cela signifie que la plupart des emplois de test ont tendance à être dotés de plus de personnes débutantes qui ne l'ont pas encore épuisé ou qui sont passées à d'autres choses, ce qui renforce malheureusement plusieurs des idées ci-dessus.
Cela dépend de l'entreprise, mais généralement. Ils sont souvent considérés comme des citoyens de seconde zone, et dans de nombreuses entreprises, les tests sont considérés comme un poste d'entrée de gamme à partir duquel vous pouvez ensuite devenir un véritable développeur.
C'est, bien sûr, de la merde. Ayant travaillé avec de bons testeurs, je peux dire qu'ils sont à la fois précieux et difficiles à trouver. Quelqu'un avec un esprit suffisamment créatif pour trouver des bugs non évidents et suffisamment méthodique pour faire un travail approfondi.
Une exception cependant: j'ai connu quelques testeurs de Microsoft, et j'entends dire que les testeurs sont des citoyens de première classe.
Je travaille depuis un an comme testeur fonctionnel sur un projet assez important. Chaque équipe d'environ 10 membres comptait 2-3 testeurs. Je dois dire que nous avons été traités comme aussi importants pour le projet que les développeurs.
Trouver des bogues n'est pas facile. Tout d'abord, les testeurs doivent comprendre ce que le code est censé faire. Cela signifie lire et comprendre les exigences. La clé ici est de comprendre les exigences - si les testeurs ne comprennent pas suffisamment les exigences pour savoir comment écrire des cas de test positifs, vous devriez vous inquiéter. Cela signifie que les développeurs ont écrit du code qui fait ce qu'ils ont supposé faire. Cette hypothèse est-elle la bonne? Vous ne savez pas jusqu'à ce que vous ayez réglé les exigences, et vous pouvez remercier vos testeurs d'avoir trouvé cette faille.
Deuxièmement, les testeurs doivent écrire de faux cas de test, ce qui garantit que le code ne fait pas ce qu'il n'est pas censé faire. Une règle de base raisonnable est que vous écrivez 5 à 10 faux cas de test pour chaque cas de test positif. Cela signifie comprendre encore plus les exigences, et souvent celal'information est, ou était au moins dans notre projet, confuse et ambiguë. (Et ce n'était pas à cause d'un faible effort de collecte des exigences - nous avions quelque chose comme 13 000 dans notre équipe seule.) Encore une fois, les développeurs auront écrit leur code en utilisant leurs hypothèses, ou pire encore, ne l'auront même pas considéré du tout. Que fait donc le code dans ces conditions qui ne sont pas normales? Vous ne savez pas jusqu'à ce que vous l'ayez testé. Peut-être que le programme ne répond pas; peut-être que ça plante juste; peut-être que cela détruit les données; il permet peut-être à l'utilisateur d'exécuter des commandes en tant qu'utilisateur root. Quoi que cela fasse, vous voulez savoir. Sinon, vous pourriez vous retrouver un jour à lire le titre suivant dans le journal - INFORMEZ-VOUS DANS LE PROGRAMME PHARE DE [LE NOM DE VOTRE ENTREPRISE] QUI FUIT LES NUMÉROS DE CARTE DE CRÉDIT DES CLIENTS.
Alors, traitez bien vos testeurs. Traitez-les bien. Après tout, ce sont eux qui éliminent les bogues de votre logiciel et vous facilitent la vie, ainsi que la nôtre.
Les bons testeurs qui peuvent analyser les problèmes efficacement et peuvent faire une automatisation de test décente valent leur pesant d'or car il y a tellement de testeurs de cowboy là-bas (lors de l'interview d'un "testeur" une fois qu'il a éclaté de rire en réalisant que nous savions qu'il faisait bourrer sur place tout en étant interrogé sur son CV).
Dans mon équipe, le testeur est traité sur un pied d'égalité - ce qui inclut la responsabilité et le salaire. Si vous voulez un testeur qui clique toute la journée - sous-traitez-le dans un endroit bon marché (nous le faisons également).
Mise à jour après avoir lu d'autres réponses: il y a beaucoup de professionnels de l'AQ qui aiment le travail qu'ils font. Juste pour donner une autre perspective si vous n'avez rencontré aucun poste d'assurance qualité respecté, un exemple ici: applications intégrées / tests d'applications mobiles pour les principaux constructeurs automobiles. Ils s'assurent que les exigences commerciales sont entièrement satisfaites avant qu'un véhicule ne soit mis sur le marché et qu'aucun utilisateur ne subisse un tableau de bord de voiture lent ou ne répondant pas. Ils travaillent en étroite collaboration avec les gestionnaires et les gestionnaires de niveau supérieur, ainsi qu'avec les développeurs, depuis la planification du processus d'assurance qualité jusqu'aux tests pratiques en direct sur les simulateurs dans l'installation de conception. Je ne peux pas penser qu'ils soient discrets, ils assument des responsabilités et une propriété énormes et ils sont parmi les meilleurs ingénieurs.
maintenant ma réponse précédente, le revers:
J'ai observé que les diplômés en ingénierie détestaient être affectés à des unités de test (contexte: Inde, grandes sociétés de services logiciels où tout est dicté par des `` exigences commerciales ''), car ils considèrent que c'est un environnement de travail non technique. Ils reçoivent des feuilles Excel avec des instructions comme `` cliquez sur tous les liens de la page Web et vérifiez '', sont obligés de travailler avec des diplômés de filières non techniques (sciences, arts) qu'ils considèrent comme une humiliation et ont l'impression que leurs compétences technologiques ne le sont pas. utilisé. Ces allocations sont purement basées sur les besoins de l'organisation, et une nouvelle, la plupart du temps, n'a pas le pouvoir de négocier son cheminement de carrière. Donc, si vous êtes un demandeur d'emploi visant une si grande entreprise informatique, vous avez été prévenu. Vous ne pouvez pas faire grand-chose, pratiquement, sauf quitter l’entreprise au bon moment.
À moins qu'il y ait des opportunités d'apprendre des tests automatisés, des tests de charge / performance, etc., la carrière stagne dans une certaine mesure. mon organisation que toute autre unité. Ils fonctionnent avec tous les secteurs de l'industrie comme enduit ou colle, car les tests sont inévitables dans les projets dans tous les domaines.
Si vous êtes sûr de pouvoir conduire votre carrière comme vous le souhaitez, les tests ne sont rien de bas. Avec 4-5 ans d'expérience et un peu de chance, vous pouvez obtenir une très bonne exposition, interagissant parfois avec les utilisateurs professionnels de haut niveau. Vous pouvez également avoir une bonne compréhension de l'industrie / du domaine dans lequel vous travaillez (par rapport à un développeur qui se concentrerait principalement sur une partie du système). À ce stade, on peut également choisir de passer à un rôle d'analyste commercial.
Je connais des entreprises où l'équipe QA est responsable des versions. Cela signifie qu'ils ont le pouvoir de bloquer une publication en raison d'un manque de qualité. Si un problème est signalé sur le terrain, ils sont les premiers sur la ligne de tir (bien après l'ingénieur de terrain).
En règle générale, ils ont une meilleure connaissance du domaine. Ils ont tendance à mieux connaître la fonctionnalité globale du produit tandis que les développeurs se concentrent sur leur module / fonctionnalités.
Je connais également des organisations QA où elles doivent écrire leurs propres outils de test. Sans parler de l'automatisation du tout. Je suis développeur et j'ai toujours apprécié les gars de QA qui testent mes fonctionnalités.
Au moins dans mon organisation, l'AQ est traitée de manière égale avec les développeurs. Je pense que c'est à cause du domaine (télécom) où la connaissance du protocole et de l'architecture de réseau est également valorisée avec des compétences en programmation.
Oui. Qu'on le veuille ou qu'on le laisse, ils sont tout aussi importants mais sont toujours moins préférés. Peut-être parce qu'ils sont faciles à remplacer.