Questions en entretien

Introduction

Je suis régulièrement contacté pour des conseils ou des informations sur les questions en entretien d’embauche (que je préfère appeler entretien de collaboration) et sur ce qu’il faut faire/réviser pour le préparer.

Je réponds en général qu’il faut être soi même et bien réviser son vocabulaire ISTQB!

Même si je considère que cette réponse est une réponse « juste » je conviens parfaitement qu’elle est trop courte et n’aide pas forcément suffisamment les candidats! Le but de cet article est donc de proposer une réponse plus longue et d’expliciter ma réponse usuelle à travers des questions qui peuvent être posées en entretien.

Exemples de questions

Quelles sont vos qualités et vos défauts ?

Je n’aime pas cette question et ne la pose pas en entretien. Néanmoins elle elle pour but d’essayer de mieux connaître la personne et savoir si ses « soft skills » sont en adéquation avec ce que je recherche. Il est donc important d’être honnête lorsque l’on répond à cette question (car être engagé sur des qualités qui ne sont pas les notres peut vite devenir problématique) mais aussi savoir sélectionner les qualités que l’on attend de moi sur le poste. Les qualités attendues d’un testeur sont assez nombreuses et il est impossible de toutes les avoir. Néanmoins, certaines qualités ne sont pas forcément attendues et il peut être préférable d’en mettre d’autres en avant.

D’un certain point de vue cela peut être perçu comme un exercice de sélection et de priorisation comme ce que doit faire un testeur dans son quotidien avec les tests.

Quels tests feriez-vous si vous deviez tester cela ?

Je me rappelle d’une fois où j’ai eu la question en entretien sur un écran de login.

J’avais fait une liste assez longues (quelques minutes sans s’arrêter) avant de finir par la question « vous en voulez d’autres ? ». La personne m’ayant fait passer l’entretien m’avait répondu non mais aussi que personne n’avait répondu autant de tests à ce jour.

Je pense que pour mon niveau d’expérience ma réponse de l’époque était loin d’être mauvaise. J’avais montré que j’avais pas mal d’imagination sur la conception des cas de test et que j’avais compris le principe de l‘impossibilité de d’exhaustivité des tests. J’avais également montré, à travers mes exemples de test, mon expérience sur mobile avec de nombreux tests non fonctionnels liés à des environnement différents.

Néanmoins, cette réponse ne me satisferait pas du tout de la part d’un testeur ayant 5 ans ou plus d’expérience! En effet, les tests dépendent du contexte. J’attends de la part d’un testeur avancé, qui sera amené à se débrouiller seul dans une équipe Agile ou encadrer des débutants d’être capable d’aller plus loin. Par aller plus loin j’entends poser des questions! Définir un contexte pour pouvoir proposer une orientation des tests en fonction!

Quel est pour vous le rôle principal du testeur ?

Je faisais du test depuis environ 1 an lorsque l’on m’a posé cette question. A l’époque j’avais répondu: découvrir les bugs avant les utilisateurs! Même si je répondrai maintenant sur l’apport d’information, cette réponse montrait que, tel le chasseur de champignons qui cherche des champignons, le testeur cherche des anomalies. De même cela montrait bien que le testeur n’a pas pour vocation de corriger les anomalies.

Cette réponse reste, de mon point de vue, très bonne pour un testeur débutant. Elle ne me satisfait cependant pas de la part d’un testeur ayant acquis de l’expérience! Là encore, la réponse attendue dépend du contexte!

Qu’est-ce qu’un plan de test ?

C’est une question que j’affectionne car la réponse donne de l’information sur du vécu et du savoir.

Le nombre de personnes étant certifié ISTQB fondation est maintenant très important. Néanmoins, être certifié et avoir vraiment intégré les concepts ce n’est pas la même chose. Lorsque l’on met en avant sa certification et sa connaissance du test il faut être capable de parler d’un plan de test dans le sens de l’ISTQB!

Il y a aussi des réponses où le plan de test est présenté comme un répertoire de test. Cette réponse montre une non connaissance des termes ISTQB mais une expérience avec des outils de test (ce qui peut valider certaines expériences sur le CV).

Il est évidemment possible de parler des 2 aspects, c’est d’ailleurs ce que j’attends de personnes plus expérimentées.

Enfin, l’absence de réponse ou des réponses « à côté » montre une non connaissance du milieu « habituel » du test… Ce qui peut correspondre à un non testeur ou quelqu’un ayant du faire seul des tests dans son entreprise (comme moi lors de mon stage de fin d’étude)

Comment testeriez-vous cela ?

Par « cela » entendez toute application ou fonctionnalité ou point particulier à la discrétion de l’intervieweur.

Cette question peut être comprise comme celle sur « quels tests feriez-vous » présentée précédemment. C’est justement son piège! Avec cette question on recherche une vision. Cette vision peut être liée à une stratégie de test (élaboration d’un plan de test) ou une mise en place de l’automatisation avec des outils spécifiques…

La réponse attendue dépend de l’expérience de la personne en face mais aussi du poste à pourvoir!

Et pour l’automatisation ?

Le but de cette question, qui peut prendre d’autres formes, est d’évaluer un niveau de compétence en automatisation.

Personnellement lorsque l’on me pose une question semblable je fais tout de suite un point important: je ne suis pas un automaticien. Je ne suis pas capable d’architecturer et d’implémenter un automate de test. Je ne sais que les utiliser!

Un candidat se doit d’être honnête sur ce point. Il y a plusieurs niveaux sur l’automatisation:

• Ne rien savoir
• Savoir utiliser des outils sans script
• Savoir utiliser un framework et lire du code simple
• Savoir maintenir un automate
• Savoir implémenter et architecturer un automate

En fonction du discours on voit tout de suite ce que la personne a fait et sait faire.

Pour vous c’est quoi un testeur Agile ?

Voici peut être la question la plus simple! La plus simple car la réponse attendue est à peu près la même quel que soit le profil. Un testeur Agile c’est avant tout un testeur avec un côté humain! Un « coach » de la qualité en Agile mais aussi un membre d’une équipe qui travaille pour l’équipe et ne se limite pas au test. Le testeur Agile est donc avant tout une personne sur laquelle on peut compter pour

• permettre à l’équipe de s’améliorer principalement (mais pas que) au niveau qualité du produit
• pour faire autre chose que du test si l’équipe en a besoin

Conclusion

Les questions proposées ne sont qu’un échantillon de questions. Il n’y a pas de bonnes réponses toutes faites! La réponse attendue dépend du poste et du niveau d’exigence que l’on a par rapport à la personne en face de soi. Je n’attends pas les mêmes réponses de la part d’un débutant que de la part d’un testeur plus expérimenté. Je n’attends pas les mêmes réponses d’un automaticien que d’un test manager ou encore d’un testeur Agile!

La meilleure chose pour réussir son entretien (attention par réussite je ne parle pas forcément d’obtention du poste) est donc bien, selon moi, de bien connaître ses bases (car une non connaissance des bases ISTQB peut dégrader bêtement son image) ISTQB (particulièrement quand on est certifié) et d’être honnête. Honnête dans ses réponses et sur ces expériences. Nos réponses sont le résultat de nos expériences, elles sont également le reflet de notre état d’esprit et manière de travailler. Il est donc important d’être honnête lors de ces échanges. En effet, cette honnêteté augmentera vos chances d’avoir un poste dans lequel vous pourrez vous épanouir. De plus, réussir à avoir un poste sans avoir été honnête, fera que l’on arrivera dans une équipe qui ne correspond pas forcément à nos attentes (et vice versa) ce qui augmentera fortement les chance de fin de période d’essai mais surtout ne vous fera pas apprécier votre travail.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.