Laissez-moi vous raconter mon histoire. Cela pourrait aider quelqu'un qui envisage d'avoir ou de commencer une carrière dans l'assurance qualité.
J'avais exactement 10 ans d'expérience en assurance qualité. J'ai commencé comme ingénieur AQ et j'ai fini comme directeur de l'AQ pendant ces 10 ans, mon salaire a plus que doublé en cours de route. J'ai eu de la chance car mon salaire de départ était élevé. Il se situait dans le percentile de 5 %, et lorsque je suis devenu un directeur chevronné, mon salaire se situait dans le percentile de 2 % pour un directeur de l'assurance qualité et il était supérieur à la moyenne des salaires des directeurs de l'ingénierie. Cela ressemble à une carrière très réussie.
J'ai obtenu mon BS et mon MS en informatique. J'ai obtenu mon BS d'une université oversee et MS d'une université qui fait partie du top 10 des écoles d'ingénieurs aux États-Unis. Tout au long de mes années d'université, j'ai travaillé en tant que développeur indépendant. L'assurance qualité d'il y a 10 ans était peu différente de celle d'aujourd'hui. L'industrie était principalement axée sur le CQ (contrôle de la qualité - pensez aux inspecteurs d'usine) et MS venait de commencer à embaucher de nombreux SDET. Google avait un groupe d'assurance qualité traditionnel, et non un groupe d'ingénierie productif comme c'est le cas aujourd'hui. À mes yeux, l'AQ ressemblait à un marché de niche. Il y avait tellement de développeurs - pour ma part, j'en étais un et j'étais entouré d'eux. Mais pas beaucoup d'AQ et il semblait que la demande était élevée alors que l'offre était loin derrière. C'est aussi à peu près l'époque où Kent Beck a proposé le TDD. Tout semblait très rose.
Je me suis donc promu ingénieur AQ hors de l'école. L'AQ était en hausse et il n'y avait tout simplement pas beaucoup de personnes ayant un diplôme CS en MS qui voulaient être un ingénieur AQ. (Tout le monde voulait être un développeur) Je me suis trouvé un emploi d'ingénieur AQ dans une coentreprise bien financée. J'ai également été très bien payé. Pour un premier emploi à la sortie de l'université, je gagnais environ 20 000 dollars de plus que les personnes qui faisaient des tests manuels depuis des années. Ils étaient appelés "analystes AQ" et j'étais un "ingénieur AQ", les analystes AQ étaient promus ingénieurs AQ. L'automatisation était un nouveau mot à la mode dans l'industrie du logiciel. Le groupe d'AQ auquel j'appartenais a commencé à s'intéresser aux outils d'automatisation. Pendant mes études supérieures, j'ai écrit du code JAVA pour automatiser les tests fastidieux de l'application que mon équipe de projet avait développée. Je ne savais pas que c'était de l'automatisation, mais j'ai réalisé que c'était ce que je faisais dans mon premier emploi. J'ai commencé à coder des scripts de test automatisés. Personne ne pouvait faire ça dans mon groupe... J'ai été promu responsable de l'assurance qualité l'année suivante.
Puis je suis devenu la " personne technique " du groupe. Le poste suivant que j'ai eu était un responsable de l'AQ pratique. Mon équipe est composée d'ex-développeurs ; l'un d'entre eux a été converti de développeur à ingénieur AQ parce que son ancien patron qui voulait vraiment qu'il fasse partie de son équipe l'a convaincu. Et il a convaincu une autre fille de la même école de se convertir. L'automatisation pour notre équipe a été facile. Nous avons simplement créé un cadre de test qui peut s'adapter aux variations des tests et nous l'avons fait. Ensuite, le battage Agile a commencé.
Etre des ingénieurs AQ qui étaient des développeurs dans leurs vies antérieures a de gros avantages. Contribuer à la qualité des produits logiciels expédiés ne consiste pas seulement à trouver des défauts. En régime Agile, c'était encore plus évident. Il n'y avait plus de place pour les tests manuels. Les logiciels devenaient de moins en moins des pièces d'art mais de plus en plus des marchandises à vendre.
J'ai déménagé dans une grande entreprise non technologique le moment venu. La tech n'était pas leur activité principale dans cette entreprise, mais ils voulaient développer l'équipe tech pour soutenir l'entreprise. Il y avait environ 40-50 personnes dans toute l'équipe tech quand je suis arrivé, et c'est devenu environ 180 personnes au moment où j'ai quitté l'entreprise 3 ans après. 30 d'entre elles faisaient partie de mon équipe. Je suis devenu directeur dans l'année qui a suivi mon arrivée. Il y avait environ 20 % de tests manuels et 80 % de tests automatisés. J'avais une équipe de développement dédiée à la construction d'outils (qui étaient de purs développeurs) dans mon département. Tout le monde dans mon équipe était SDET et toute la journée ils créaient des codes de test.
Puis je me suis très très ennuyé. J'ai déménagé dans une entreprise en démarrage en pensant que cela pourrait changer les choses. Cela n'a pas fonctionné. Rien ne me simulait intellectuellement. Et puis j'en ai aussi eu marre des gens qui pensent que l'AQ est une chose si facile que tout le monde peut faire. Ou que l'AQ n'est pas quelque chose d'essentiel pour l'entreprise. Il est bon de l'avoir, mais quand l'argent se fait rare, c'est peut-être l'une des premières choses que l'on peut licencier pour économiser de l'argent. Il y a beaucoup de gens, surtout dans le monde des start-ups, qui pensent que les développeurs peuvent faire des tests alors que les testeurs ne peuvent pas coder. Alors pourquoi ne pas engager plus de développeurs pour faire d'une pierre deux coups ? Pourquoi dépenser de l'argent pour l'assurance qualité ? En tant que responsable de l'assurance qualité depuis longtemps, je sais combien il est efficace pour l'entreprise d'avoir une bonne équipe d'assurance qualité, je peux même le quantifier. Et c'est la raison pour laquelle les entreprises prospères ont un groupe qui se concentre sur la qualité - ils ne s'appellent peut-être pas "QA", mais cela a une certaine nuance qui ne résonne pas avec les développeurs de haut niveau qui pourraient trouver "QA" attrayant. Mais il y a des gens qui ont tout simplement peur de dépenser de l'argent pour l'AQ quand ils pensent qu'ils peuvent dépenser cet argent pour les développeurs - quelle que soit la qualité de ces derniers. J'ai vu de nombreuses occasions où les ingénieurs AQ ont dû dire aux développeurs exactement quelles lignes de code devaient être changées en quoi pour corriger certains défauts qu'ils avaient trouvés. Mais bon, certaines personnes qui n'ont jamais vraiment codé professionnellement ou certains dirigeants qui n'ont jamais vu une équipe d'AQ bien travailler ont ce préjugé envers l'AQ selon lequel AQ égale gaspillage d'argent.
Si vous commencez une carrière d'AQ en tant qu'ingénieur, vous devrez mener les batailles que j'ai menées sans relâche. Et si vous êtes bon, vous vous démarquerez facilement - en fait, il y a tellement tellement de personnes "AQ" qui ne devraient pas faire de l'AQ. L'écart-type est énorme dans l'AQ et il fait baisser la moyenne des salaires et la qualité des ressources de manière significative - il en va de même pour les développeurs, il y a encore plus de développeurs qui ne devraient pas créer de code.
En guise d'aparté cependant, si vous n'êtes pas technique, ne savez pas coder, mais voulez être dans le monde de la tech, il vous sera plus facile d'obtenir un emploi de testeur manuel AQ que de développeur. Mais le métier de testeur manuel d'assurance qualité est en voie de disparition. L'automatisation prévaut et ce n'est vraiment qu'une question de temps pour remplacer les tests manuels par l'automatisation. Je ne serai pas surpris si le terme "QA" devient obsolète dans un avenir proche. Je suppose que les développeurs deviendront également obsolètes, mais l'AQ le sera avant cela. Je vous recommande d'envisager la gestion de produit ; l'AQ et la gestion de produit partagent beaucoup de caractéristiques similaires et vous n'avez pas besoin de coder pour faire du PM ; mais personne n'a besoin de beaucoup de PM. 1 par équipe. C'est donc limité, mais l'accès est facile. Mais une fois que le codage deviendra si commun, le PM devra coder - mais ne vous inquiétez pas : d'ici là, coder sera comme utiliser excel.
J'ai quitté mon emploi de directeur de l'assurance qualité et je réfléchis sur moi-même pour savoir ce que je veux vraiment faire ensuite. J'ai eu une bonne carrière et je ne regrette pas d'avoir suivi le chemin que j'ai emprunté. J'espère que mon histoire - ou un long mémoire - aidera quelqu'un qui envisage l'AQ comme carrière.
.