Qu'est-ce qu'un développeur en test?
Je parlais récemment avec un recruteur qui veut me mettre dans une entreprise pour un poste de Développeur en Test. Il a essentiellement fait en sorte que cela ressemble à une position où vous pouvez jouer avec de nouvelles techniques de programmation et tester des bogues et des améliorations logicielles, mais où vous n'avez pas à vous soucier des délais standard. Vous devenez très créatif dans votre travail.
Mais cette description était encore un peu vague pour moi. Je suis développeur Web depuis plusieurs années maintenant, travaillant principalement en PHP. J'ai donc voulu savoir si d'autres membres de la communauté en savent plus sur ce que ces postes impliquent généralement.
Je sais que ce n'est peut-être pas un sujet approprié pour ce forum, mais c'était le meilleur ajustement que j'ai pu trouver parmi Stack Exchange et j'apprécierais vraiment si ce n'était pas fermé car il n'y a vraiment aucun autre endroit ici pour poser des questions à ce sujet .
J'ai essayé Google, mais il n'y a pas beaucoup d'informations. Alors, qu'est-ce qu'un développeur en test?
Je suis ingénieur en développement logiciel en test et j'ai travaillé dans 2 entreprises distinctes. Actuellement, je travaille pour Microsoft.
D'une manière générale, Bryan Oakley a raison: vous écrivez un logiciel qui teste le logiciel.
Au-delà, cela dépend de votre niveau d'expérience, de l'étendue de vos responsabilités et du type de logiciel que l'employeur produirait. Un poste SDET peut inclure l'écriture de tout, depuis les bases des tests de vérification au niveau des fonctionnalités, jusqu'à l'écriture et la maintenance de l'infrastructure de test pour exécuter ces tests. Il n'est pas rare non plus que des SDETS se spécialisent dans des tests ciblés pour certains types d'exigences (les tests de sécurité, de performance/d'évolutivité, d'utilisabilité, etc. sont des exemples qui viennent immédiatement à l'esprit).
La description que vous avez reçue du recruteur ressemble à une mauvaise technique de vente.
- Vous ne jouez pas; vous disposez de n jours pour obtenir une couverture de test automatisée sur x fonctionnalités déployées dans y différents environnements pris en charge dans z langues.
- Oh, btw: ces tests doivent être exécutés assez rapidement pour que les développeurs aient un cycle de développement/test rapide parce que ...
- Pas de délais standard? Vous êtes en charge de la qualité du produit et la date de sortie a été fixée par le marketing il y a 6 mois. L'équipe de développement a 6 semaines de retard pour fournir une version stable à votre équipe de test, et la société ne repousse pas (encore) cette date de sortie. Le produit ou le service est-il suffisamment stable pour être diffusé à quelques millions (milliards?) De personnes le même jour?
- ... et si (quand) les clients appellent avec des problèmes ... "Pourquoi (l'enfer) ne l'avez-vous pas attrapé en premier?"
J'espère que cela vous donne un petit exemple de ce qu'est un SDET.
"Développeur en test" signifie généralement que vous êtes dans le département QA ou dans un rôle QA, mais l'accent est mis sur l'écriture de tests automatisés plutôt que sur la création et l'exécution de cas de test manuels. C'est comme écrire un logiciel pour tester un logiciel. Cela peut être un choix de carrière particulièrement difficile car il faut à la fois des compétences en programmation et une bonne compréhension des tests de logiciels.
Cependant, différents titres signifient différentes choses pour différentes entreprises, donc la réponse définitive doit provenir du recruteur.
Un rôle SDET est à peu près ce que vous en faites, comme en témoignent tous ses différents noms: QA/Developer, QA Engineer, Automation Developer. Mon titre actuel est en fait Test Engineer, que je n'avais jamais entendu appeler avant de prendre ce poste. Quel que soit le titre spécifique, il s'agit d'un nouveau poste dans la plupart des entreprises, de sorte que les attentes peuvent être lâches. "Aidez-nous à automatiser nos tests, etc.". Les choses pourraient inclure des outils CI, des tests d'API, des services cloud, l'intégration avec des systèmes internes, etc.
Un autre aspect du travail que je ne vois pas dans ce fil est l'amélioration des processus. Les SDET font généralement de l'AQ depuis un certain temps, et encore une fois, ils sont généralement plus techniques que le reste de l'équipe d'AQ, y compris leur manager. Ils en savent beaucoup sur le système testé, c'est-à-dire "où les corps sont enterrés". Pour ces raisons, les SDET ont tendance à être écoutés par la direction et peuvent avoir beaucoup d'influence sur le processus - pas seulement sur le processus de test, mais sur la façon dont le produit est construit. Ce qui peut être cool, si vous aimez ça.