Lors des entretiens avant l'embauche, il est assez facile d'identifier les soi-disant compétences techniques du candidat. Cependant, je n'ai jamais vu de recherche sur le type de compétences non techniques dont un testeur a besoin. Il est assez simple de répertorier certains d'entre eux, ainsi que de vérifier leur niveau d'appropriation lors d'une interview.
Ici, par exemple:
1. La possibilité de poser des questions
Un testeur réussi n'est pas seulement libre de poser des questions. Les questions posées par le testeur devraient viser à obtenir des informations adéquates, à savoir:
a) clarification des termes obscurs dans la documentation
b) clarification de la logique implicitement prescrite du système
c) clarification si le comportement observé du système est un bug, des fonctionnalités ou une inexactitude mineure, qui peut être ignorée
d) la clarification de savoir si le comportement inadéquat détecté du système a été décrit précédemment quelque part (si un défaut a été institué à cette occasion, soit une tâche de correction, ou s'il a été noté dans la documentation technique comme un comportement acceptable)
e) clarification avec qui spécifiquement la question du testeur peut apparaître
f) des précisions sur qui est exactement responsable de résoudre le problème et comment transférer les informations pertinentes à ces personnes, et quelles informations doivent leur être transmises.
Entre autres choses, lorsqu'il pose une question, le testeur doit le faire de telle manière que le répondant souhaite répondre à la question, ce qui signifie une forme nécessairement polie et la présence d'informations dans la question que le testeur pourrait trouver sur son propre sujet.
Toutes ces compétences sont assez faciles à déterminer lors d'un entretien, si vous vous contentez de vérifier ce que ce candidat est capable de poser des questions.
2. La capacité de décrire adéquatement les problèmes détectés, le comportement inadéquat du système ou, tout simplement, les bogues
Cette compétence comprend la capacité, par exemple, d'écrire un titre compétent sur le texte du défaut. Pour enseigner cette compétence, il suffit d'appliquer la méthode développée en journalisme: les informations de base doivent contenir des réponses aux questions de base «qui fait quoi, où». Les journalistes peuvent répondre à un plus grand nombre de questions en écrivant les titres d'articles et les vedettes; cependant, pour rédiger un titre pour un testeur réussi, il suffit de répondre adéquatement à ces trois questions.
En outre, un testeur réussi devrait être capable de décrire correctement le comportement inapproprié du système. Pour cela, le texte de description doit contenir au moins des informations de ce type:
a) une description de la zone dans laquelle le comportement inapproprié du système se manifeste (y compris des informations sur l'environnement du système)
b) des instructions étape par étape sur la façon d'obtenir le comportement du système inadéquat décrit dans l'en-tête
c) une explication de la façon dont le comportement spécifique du système diffère du comportement attendu du système
d) tous les journaux, captures d'écran et autres informations supplémentaires nécessaires doivent être joints, ce qui aidera le développeur à établir plus précisément quelle zone spécifique de son code est associée à l'inadéquation identifiée du comportement. La difficulté est que ces journaux ne sont pas toujours nécessaires.
Vérifier cette compétence lors d'un entretien est également assez simple: vous pouvez simplement demander au candidat d'écrire un message d'erreur typique, à son avis. Toutes les compétences du candidat se manifesteront clairement dans ce qu'il écrit exactement.
3. Capacité à écrire des cas de test algorithmiquement simples
Sur des projets à long terme et complexes, l'équipe de test peut complètement changer plusieurs fois pendant tout le développement du produit. Les cas de test, en fait, des informations importantes sur le déroulement des tests de produits, utiles non seulement pour l'auteur, mais aussi pour les débutants. Des cas de test clairs et simples permettent à un nouveau venu de se familiariser facilement: il suffit de lui donner un ensemble de cas de test et d'accéder à une version plus ou moins stable du système, et en exécutant ces cas de test, le testeur peut se joindre facilement et utilement travail d'équipe.
En conséquence, il est très important que les cas de test soient écrits dans un langage simple et compréhensible et contiennent toutes les informations nécessaires afin qu'ils puissent être remplis par une personne qui ne connaît pas du tout le produit testé et son environnement, ou, au moins, pour un nouveau venu pour effectuer un cas de test était de poser quelques questions à des camarades plus expérimentés.
La capacité d'écrire de tels cas de test est également assez facile à tester pour un entretien avec une tâche simple.
4. La capacité de classer les défauts par importance
En fait, différentes méthodes de classement des défauts en fonction de leur importance sont pertinentes pour les différents systèmes testés. Différents projets ont adopté différents niveaux d'évaluation de l'importance du défaut, parfois il n'y a pas une échelle de classement, mais deux. La question principale est de savoir si le testeur comprend la différence fondamentale entre un défaut de blocage et juste un défaut important, par exemple, les deux sont insignifiants, et s'il peut, en posant les questions nécessaires, déterminer par lui-même quels principes les défauts sont classés sur ce projet particulier .
Un testeur qui ne possède pas une telle compétence, au mieux, attire des compagnons plus expérimentés avec des questions sur l'importance de poser un défaut, dans le pire des cas, il commencera à accorder de l'importance au principe du `` à l'improviste '', ce qui entraînera un nombre considérable de conflits inutiles dans l'équipe de projet.
La capacité de classer les défauts est également assez facile à identifier lors d'un entretien, il suffit de poser quelques questions simples au candidat.
5. Curiosité
Il s'agit d'une propriété de base requise par tout testeur. Un testeur qui n'a pas de curiosité ne pourra pas tester correctement un seul système. Dans le meilleur des cas, il fera bien des cas de test écrits par quelqu'un d'autre et fera des défauts que n'importe qui d'autre pourrait détecter à sa place. Un tel testeur - manquant de curiosité - peut être utile sur un projet s'il a la discipline et la diligence, mais il ne devient jamais une «star».
Il est facile de comprendre si une personne possède cette propriété de la personnalité en observant simplement son comportement lors d'un entretien - en particulier, en observant les questions qu'une personne pose lors d'un entretien et si elle pose des questions.
6. Discipline
Je pense qu'il n'est pas nécessaire d'entrer dans les détails de ce que signifie ce mot. Les cas de test doivent être écrits à temps, les défauts doivent être émis immédiatement après la détection, les défauts doivent être revérifiés dès que le patch correspondant est arrivé sur le banc de test, etc., etc., etc.
Malheureusement, je ne sais pas comment vérifier au cours de l'entretien si le candidat a une telle qualité, mais les gens qui ne l'ont pas sont généralement clairement visibles par le fait qu'ils commencent à parler de leur habileté à se soustraire à l'une ou l'autre action obligatoire dans le passé. projet.
Il est possible de répertorier indéfiniment les compétences générales utiles du testeur, cependant, les six décrites ci-dessus sont précisément ces qualités, dont l'absence apportera beaucoup de maux de tête, appelons cette position, le responsable des tests de projet pendant le travail, en fait, sur les tests de projet.
Je vous souhaite à tous des interviews réussies pour le rôle de testeur et la recherche réussie de personnes hautement qualifiées pour le même rôle. Merci de votre attention sur cet article.