Supposons que vos livraisons attendent régulièrement la fin des tests et que vous envisagiez de recruter un spécialiste de l’assurance qualité (QA). Nous recommandons d’ouvrir un poste si vous avez identifié un besoin durable d’automatisation que votre équipe ne peut pas prendre en charge. Si les compétences et le temps existent en interne, attribuez plutôt cette responsabilité. Si vous ne savez pas encore ce qui provoque l’attente, précisez le besoin avant de choisir un profil.
Le recrutement répond à une capacité manquante
Le temps consacré aux tests mérite d’être examiné, mais il ne suffit pas à justifier un poste spécialisé. DORA (Google Cloud) décrit les tests manuels de régression répétés comme une charge susceptible de ralentir les livraisons et le retour aux développeurs. La même source précise toutefois que le rôle de testeur n’implique pas nécessairement un poste à temps plein.
La distinction porte donc sur le travail à prendre en charge. Une exécution manuelle répétitive, la préparation des données et l’entretien de tests déjà automatisés peuvent mobiliser votre équipe, sans appeler exactement la même réponse. Avant de recruter, demandez au responsable technique de désigner les travaux concernés et d’expliquer pourquoi leur automatisation serait adaptée.
L’International Software Testing Qualifications Board (ISTQB) inscrit justement l’applicabilité et la viabilité de l’automatisation parmi les questions de son référentiel stratégique. Nous proposons d’en faire une étape de votre décision : obtenir une explication technique du besoin avant de considérer le recrutement comme sa réponse.
La charge des tests se lit dans les livraisons réelles
Pour préparer cet examen, faites établir un relevé à partir de vos livraisons récentes. Pour chaque livraison examinée, demandez quels tests ont été exécutés, quel travail de préparation a été nécessaire, quels tests existants ont été entretenus et quelles difficultés ont retardé la suite. Consignez le temps consacré à ces travaux lorsqu’il est disponible, ainsi que les conséquences effectivement constatées : attente avant livraison, retour tardif aux développeurs ou autre tâche reportée.
La préparation mérite une place distincte dans ce relevé. DORA recommande de suivre le temps que développeurs et testeurs consacrent à préparer et manipuler les données nécessaires aux tests. L’ISTQB distingue, de son côté, les travaux de mise en place de l’automatisation de ceux de son entretien. Un diagnostic limité au temps d’exécution laisserait donc de côté des travaux que ces sources invitent à examiner.
Rapprochez ensuite ces éléments du calendrier des livraisons. Si la même tâche revient, demandez pourquoi elle se répète et ce qui est susceptible de la faire persister. Si la charge provient d’un changement ponctuel, examinez le travail qui restera après ce changement. La fréquence des livraisons sert ici à comprendre les répétitions, sans constituer à elle seule un déclencheur de recrutement.
Dans une situation hypothétique où l’équipe attend surtout des données utilisables, demandez ce qu’il faudrait modifier pour les obtenir. Si elle consacre plutôt du temps à réparer des tests automatisés, faites préciser les causes de ces réparations. Ces réponses permettent de distinguer les travaux à automatiser des conditions à réunir pour que l’automatisation soit praticable.
Une compétence présente doit pouvoir être mobilisée
Une fois les travaux identifiés, cherchez qui peut les prendre en charge. Le référentiel technique de l’ISTQB attend du spécialiste de l’automatisation des compétences en développement logiciel. Ses objectifs couvrent la conception de solutions, leur entretien, leur intégration aux chaînes de livraison et la restitution des données de test. Ces activités fournissent des points de comparaison avec votre besoin, sans définir le contenu obligatoire de chaque poste.
Demandez à la personne pressentie de présenter un travail pertinent et d’expliquer ses choix. Le référentiel « Testeur logiciel » publié par France compétences comprend notamment une stratégie d’automatisation, des scripts, des données et des connexions à la chaîne de livraison. Vous pouvez vous appuyer sur ce type de pièces pour conduire l’examen, puis demander comment la personne adapterait son travail à vos contraintes. Le document seul ne démontre ni sa maîtrise ni sa capacité à intervenir dans votre situation.
Examinez ensuite sa disponibilité avec son responsable. Quel travail actuel faudrait-il reporter pour lui confier cette responsabilité ? Qui prendra les décisions techniques et qui entretiendra les tests ? Une compétence présente mais déjà entièrement mobilisée ne constitue pas une capacité disponible.
Cet examen doit distinguer un manque de compétence d’un manque de temps ou d’une responsabilité mal attribuée. Si personne ne sait concevoir la solution envisagée, le besoin diffère de celui d’une équipe compétente qui manque de disponibilité. Si chacun pense qu’un autre entretient les tests, commencez par attribuer cette responsabilité avant de conclure qu’un poste supplémentaire est nécessaire.
Le diagnostic conduit à une action précise
Si le besoin d’automatisation persiste et que la capacité interne manque, préparez une description du poste à partir des travaux documentés. Précisez la solution à concevoir ou à reprendre, son entretien attendu et les éléments qui permettront d’examiner le travail réalisé. Indiquez aussi comment le spécialiste collaborera avec les développeurs. DORA recommande que ces derniers restent responsables de la création et de l’entretien des suites automatisées, avec la collaboration des testeurs : recruter un QA ne doit pas conduire à lui confier seul toute la qualité.
Si votre équipe dispose des compétences et d’une disponibilité effective, attribuez les travaux à une personne identifiée, avec le temps et les responsabilités correspondants. Convenez d’un nouvel examen après cette prise en charge. Vous pourrez alors comparer la charge constatée au travail prévu et décider si l’organisation retenue reste suffisante.
Si la difficulté demeure mal définie, demandez d’abord les éléments manquants : une analyse de la faisabilité, une explication des échecs ou un état des disponibilités, selon ce que le diagnostic n’a pas établi. Le choix du profil reste prématuré tant que vous ne savez pas quelle responsabilité lui confier.
Nous proposons ces branches comme un raisonnement de décision, sans seuil universel ni garantie d’amélioration. Avant d’engager l’action choisie, vérifiez que le besoin durable d’automatisation est documenté et que la capacité mobilisable a été examinée. Si l’un de ces éléments manque, complétez le diagnostic avant d’ouvrir le poste.
Sources
DORA (Google Cloud) : Test automation
