Nous embauchons une personne chargée de l'assurance qualité et je suis censé proposer des questions d'entrevue. La vérité est que je ne sais pas grand-chose sur ce qu'un bon ingénieur en assurance qualité devrait savoir, et encore moins sur les bonnes questions d'entrevue. Quelqu'un a-t-il des suggestions?
Quelques informations: L'environnement est deux applications Web distinctes (mais entrelacées) pour la pile Microsoft (ASP.NET, SQL Server, IIS).
Réponses:
À moins que vous n'ayez beaucoup d'expérience avec les testeurs, lisez les premiers chapitres du "Test du logiciel informatique" de Cem Kaner pour avoir une idée des types de termes que vous souhaitez entendre: test des limites, test des erreurs, test du chemin heureux, fonctionnel, performance, sécurité, intégration, etc. Si vous ne parlez pas la langue, vous ne pourrez pas mener une bonne interview.
Donnez-leur une spécification pour un petit morceau de votre système. Demandez-leur de le tester. Vous recherchez une organisation de la pensée et sa capacité à proposer des tests intéressants. Vous voulez les voir séparer les zones de test de manière ordonnée, puis explorer chaque zone, en créant des cas de test de plus en plus intéressants. De très bons testeurs peuvent le faire pendant des heures avec tous les problèmes, sauf les plus triviaux, vous devrez donc peut-être les couper et les faire passer à une autre catégorie pour avoir une bonne idée de leur façon de penser.
Décrivez le comportement causé par un vrai bug dans votre système qui était assez difficile à comprendre. Demandez-leur ce qu'ils feraient s'ils voyaient ce bogue pendant les tests. Ici, vous recherchez une réduction de bogue - la possibilité de trouver l'ensemble de circonstances le plus simple pouvant reproduire un bogue. Cela facilite le débogage pour les développeurs, car ils ont une meilleure idée de la cause du problème et démontrent une capacité claire à résoudre les problèmes et une compréhension claire des facteurs qui peuvent interagir pour provoquer des bogues. Avec votre produit spécifique, discuter d'une condition de concurrence peut être amusant.
Donnez-leur un simple programme en ligne de commande que vous avez piraté ensemble (peut-être semé de bugs) et une spécification simple, et laissez-les s'asseoir devant l'ordinateur et jouer avec, dans le but de trouver des problèmes. Ici, vous recherchez la créativité et la capacité de cibler les zones à problèmes. Ils devraient tester des choses comme de grandes entrées, de petites entrées, des entrées étranges, des entrées vides. S'ils trouvent un bug, demandez-leur d'essayer de déterminer exactement quand ce bug se produit (encore une fois avec la réduction du bug!).
Demandez-leur ce qu'ils feraient si un SDE répond à un bogue avec "Pas de repro" ou "Ne pas corriger", s'ils pensaient que le bogue est important. Ici, vous cherchez quelqu'un qui ne sera pas seulement un jeu d'enfant, mais qui ne sera pas non plus antagoniste. Les réponses raisonnables incluent l'ajout d'exemples de scénarios qui démontrent plus clairement la gravité du bogue, puis la réouverture du ticket, en discutant avec le développeur pour essayer de comprendre pourquoi les choses ont été résolues de cette façon avant de fermer, etc.
Parlez-leur de votre candidature à un niveau élevé. Demandez-leur quels types de tests ils souhaiteraient effectuer. Ici, vous recherchez des domaines généraux de test tels que les tests de composants fonctionnels, les tests d'intégration, les tests de performances, les tests de sécurité.
S'il s'agit d'un ingénieur SDET / automatisation, posez-leur des questions d'entrevue pour les développeurs ayant environ 1/3 à la moitié de leurs années totales d'expérience.
S'il s'agit de votre première personne chargée de l'assurance qualité, assurez-vous qu'elle peut démarrer d'elle-même. Demandez-leur à quoi ils imagineraient leur première semaine ou leur premier mois de travail. Ils devraient dire quelque chose sur la collecte des exigences et la configuration des outils, puis décrire une approche raisonnable pour commencer les tests. Vous cherchez quelqu'un qui n'a pas besoin d'un patron pour lui dire comment commencer les tests et qui peut s'autogérer. Si vous avez déjà du personnel d'AQ, cela est moins important.
Ce que je fais lorsque j'ai interviewé des candidats AQ, c'est de leur demander d'esquisser une stratégie de test pour une candidature. Je leur donne généralement mon téléphone et je choisis une application avec des fonctionnalités limitées - ou je les laisse choisir quelque chose qu'ils connaissent mieux. Quand ils listent une stratégie de haut niveau (certains ne le peuvent pas), je pourrais leur demander d'explorer et de lister quelques cas de test.
Une fois cela fait, je pourrais leur donner un scénario où nous avons des ressources limitées et voir comment ils hiérarchisent.
Je leur demande également quand un logiciel est assez bon pour être expédié, comment gérer les situations où PM ou dev ne sentent pas qu'un bogue est important mais ils le font. Scénarios de développement de produits typiques.
Ce sont pour les positions QA non codantes. Codage des postes QA Je leur donne une interview combinée dev / test.
Demandez-leur comment ils conçoivent les plans de test. Demandez-leur s'ils ont de l'expérience dans l'utilisation des tests de régression et comment ils l'ont fait dans l'affirmative. Demandez-leur comment ils testent une interface utilisateur. Demandez-leur comment ils procéderaient pour tester les importations de données qui ne passent pas par l'interface utilisateur (si vous faites de telles choses). Demandez-leur comment ils communiqueraient leurs problèmes aux développeurs et comment ils vérifieraient la résolution du problème. Je leur demanderais quel est le bug le plus intéressant (ou le plus difficile à trouver) qu'ils ont trouvé et comment ils l'ont trouvé.
Avant de commencer l'interview, recherchez quelques livres sur les tests et approfondissez un peu ce que devrait faire une personne chargée de l'assurance qualité. Cela vous aidera à évaluer leurs réponses.
De plus, vous recherchez également un bon ajustement de personnalité. Vous ne voulez pas d'une personne chargée de l'assurance qualité qui est un jeu d'enfant, mais vous ne voulez pas non plus d'un intimidateur ou d'un imbécile. Mais vous voulez quelqu'un qui résistera à la direction lorsque les choses vont mal et pas seulement tout approuver parce que la direction veut respecter un délai. Vous voulez quelqu'un qui travaille efficacement avec les développeurs et qui comprend les exigences de ce qu'ils testent. Quelqu'un avec une certaine expérience dans le type d'application que vous testez peut être bon. Un testeur ayant une expérience des soins de santé saura des choses à tester dont une personne venant d'un autre domaine peut ne pas être au courant.
Je suppose que vous ne pouvez pas vous attendre à ce qu'ils aient une connaissance sérieuse de la technologie - quiconque a probablement refusé de travailler comme testeur ordinaire.
Le mieux que vous puissiez faire est de rechercher des choses courantes comme l'attention aux détails, l'esprit curieux, l'enthousiasme pour l'expérimentation, etc.