Quelles différences dans le pilotage d’une TRA (Tierce recette applicative) ou d’une TMA (Tierce maintenance applicative) ? Plus globalement, quelles sont les différences entre le métier de développeur et celui de testeur ?
Afin de répondre à ces questions, nous avons interrogé deux directeurs de projets en charge de projets à engagements de résultats, le fameux « Delivery ». Tous deux issus d’un parcours de développeurs puis de chef de projets de développement, ils ont récemment pris en charge le pilotage d’une ou plusieurs TRA.
En quelques mots, pouvez-vous vous présenter ?
Cédric : Issu d’une formation universitaire en ingénierie mathématiques puis, plus récemment, d’un Master MIAGE, j’ai débuté ma carrière dans l’informatique en tant que développeur mainframe suite à une reconversion. J’ai ensuite évolué vers un poste de chef de projet MOE en assurance IARD en régie pour ensuite intégrer plusieurs centres de services (cycle en V ou Agile). A la suite de cela, j’ai pu intégrer la direction « Solution et Delivery » en tant que directeur de projets, en charge aujourd’hui des projets en mode CDS, CDC ou ATG sur les comptes de deux de nos clients du monde de l’assurance (Pacifica, MOE et TRA, CAMCA Recette MOA, La médicale Recette, CAAS Tests/Open/Décisionnel/Agile & CDS prévoyance, CDS dev applicatif java/mainframe). La découverte du métier de la recette de par mes activités de pilotage m’a permis de passer la certification ISTQB Fondation.
Sébastien : Diplômé d’un DESS en ingénierie mathématiques et traitement du signal, j’ai entamé en 2006 une reconversion afin de devenir ingénieur développeur mainframe. Après plusieurs années passées en TMA et en clientèle, j’ai pu acquérir les compétences nécessaires afin de m’orienter vers la gestion de projets en tant que chef de projet. A ce jour j’occupe un poste de Directeur De Projets au sein de la BU S&D et ai en charge la gestion de plusieurs CDS et d’une TRA pour des comptes du domaine bancaire, de l’assurance et de l’assurance-crédit.
Après plusieurs mois, voire années de pilotage de Tierce Recette Applicative et Tierce Maintenance applicative, que pouvez-vous nous dire du métier de testeur versus celui de développeur ?
Cédric & Sébastien : Notre réflexion n’est pas d’opposer les 2 métiers mais de voir leurs spécificités et points communs. Nous pourrions penser qu’un développeur connait déjà le test car il est amené à tester son propre code. Notre expérience nous a montré que ce n’est pas forcément la première préoccupation du développeur et que celui-ci ne possède pas forcément la méthodologie associée !
Cédric : J’avais parfois eu l’impression que le testeur était un inspecteur des travaux finis. Avec le recul, je vois désormais les choses différemment. En effet, le testeur est le dernier rempart avant la mise en production. Son travail permet de prendre la décision de déployer ou non le nouveau logiciel.
Sébastien : Il est vrai que le développeur livre une application, il produit quelque chose d’utilisable. Je n’avais pas l’impression que le testeur produisait effectivement quelque chose.
Pouvez-vous en dire un peu plus sur les particularités de chacun de ces métiers?
Cédric : Le temps de la montée en compétences pour un testeur est de l’ordre 6 mois. Il acquiert, pendant cette durée, le fonctionnel métier et maitrise une grande partie des techniques de conception de tests utilisées ainsi qu’un outil de gestion de tests. Il est relativement aisé d’intégrer un nouveau collaborateur dans une TRA. Il peut commencer par exécuter des tests de non-régression, puis exécuter des tests plus complexes pour arriver sur la conception des tests voire sur la stratégie de tests. Un développeur atteint un premier stade de maturité autour de 2 ans.
Sébastien : Souvent, le testeur a une vision assez large de l’applicatif car son travail exige une compréhension globale des fonctionnalités. Cela lui ouvre la porte d’entrée sur des métiers AMOA. Sur certaines de nos TMA, c’est le testeur qui est devenu le référent fonctionnel.
Cédric : Cela exige une très bonne capacité de communication de la part du testeur. Il peut en effet être amené à rencontrer directement les « métiers ». J’ai constaté qu’il y avait souvent plus d’interlocuteurs dans une TRA qu’une TMA.
Sébastien : Je rajouterai que le testeur doit faire preuve d’une certaine souplesse. En effet, son travail implique une grande dépendance sur la qualité et le nombre des entrants. Ainsi le testeur est dépendant des spécifications, du livrable, de la disponibilité des environnements et de jeux de données.
Le chef de projet d’une TRA a-t-il des compétences particulières ?
Cédric : J’ai constaté qu’il était souvent plus difficile de trouver un bon chef de projet tests qu’un chef de projet de développement. Le chef de projet tests a une vision très fine de l’avancement des projets. Il descend très souvent jusqu’au niveau « cas de tests ». Le chef de projet tests doit être capable d’échanger avec des interlocuteurs très variés, n’ayant pas le même langage que lui (métier, MOA, MOE, production), ne connaissant pas du tout son métier et le sous-estimant souvent.
Sébastien : Un chef de projets tests doit maitriser le savoir-faire tests et, la plupart du temps, il doit avoir une expérience dans le fonctionnel demandé pour le projet. C’est souvent moins vrai pour un chef de projet technique pour laquelle l’expertise technique est prépondérante.
Que pouvez-vous dire des automaticiens ?
Cédric : L’automaticien est un peu à la croisée des métiers du développeur et de celui du testeur. D’une part, il doit posséder un bagage technique solide et d’autre part, il doit comprendre le fonctionnel des tests à automatiser avec la méthodologie test associée.
Sébastien : Effectivement, une des raisons d’échec des projets d’automatisation est liée à la non-compréhension des fonctionnalités à automatiser. Souvent, il est nécessaire que l’automaticien passe quelque temps à réaliser les tests manuels afin de bien assimiler le fonctionnement de l’application.
Et pour conclure ?
Cécric & Sébastien : La réussite de nos projets à engagement se repose en grande partie sur la collaboration efficiente des développeurs et des testeurs. D’ailleurs, la méthode agile favorise grandement cette coopération.