Discussion :

[el_slapper]

Bonsoir, après avoir eu tous les renseignements sur la nature du métier de testeur j'aimerai connaître les conditions de travail. C'est-à-dire:
- horaires
- lieu
- seul ou en équipe
- etc
Merci d'avance pour vos réponses.

C'est, comme la plupart des métiers de l'informatique, quelque chose de très variable. Moi, actuellement, je fais les heures que je veux, en échange de quoi le boulot doit être fait. Je fait rarement du rab, sauf urgence(tiens, j'ai bossé une heure chez moi ce soir et une hier soir). D'autres font des horaires de fous. Le travail nominal est solitaire, mais on fait plein de choses en équipe autour : discussions sur le fonctionnel, organisation du travail, analyse de bugs complexes, et autres réunions en tout genre. Le lieu lui-même est généralement "le bureau à coté de celui des développeurs", mais on peut parfois être noyés parmi eux, ou exilés à l'autre bout de la terre. Sans compter que le télétravail est parfois possible.

Chaque poste est différent. I faut poser ces question non pas en général, mais en particulier. Lors de l'entretien d'embauche. "Et mon bureau, il sera ou? Et la journée de travail, elle s'articule comment? Et on bosse à plusieurs?". Je peux continuer à te détailler mon cas précis pendant des heures, mais ça serait ridicule. J'ai eu, par le passé, des conditions radicalement différentes. Horaires fixes ou variables, bureau de chef ou open space, travail en tour d'ivoire ou intégré à une équipe soudée. Sans cohérence aucune, ça dépendait juste de la situation précise.

[kahouna75]

Mais l'enchainement des missions dépend essentiellement du marché. J'ai enchainé une mission de refonte complète d'un batch en COBOL chez un assureur responsable, des tests automatiques en VB6 chez un éditeur de logiciel français récemment racheté par un géant Allemand, de la maintenance à chaud sur du marketing pour une banque à l'étoile bleue, de l'assistance technique à homologation sur un projet technique massif COBOL chez une assurance-vie, et du test technique et fonctionnel - mais aussi des corrections dans le code VB6 - chez une boite qui fait de la conservation de titres et qui passait ses applis en virtualisé Citrix.

A chaque fois, sans alternative, ou en ayant été rejeté par les alternatives.[/QUOTE]

Bonjour,

Je suis actuellement en formation Qualificateur Logiciel, Pourriez vous me donner des intitulés de projets effectués au sein de la Banque en question svp ?
Egalement, leur déroulements pour avoir une idée concrète.

Merci

[el_slapper]

Bonjour,

Je suis actuellement en formation Qualificateur Logiciel, Pourriez vous me donner des intitulés de projets effectués au sein de la Banque en question svp ?
Également, leur déroulements pour avoir une idée concrète.

Merci

Non à la première question, plus de détail, ça serait trahir le secret professionnel.

Le déroulement, c'est autre chose, c'est un peu toujours le même. Des pontes débloquent du budget et nomment un chef qui remplit son équipe de prestataires, on écrit des specs, les programmeurs essayent d'en faire un truc, les homologateurs se plaignent que rien ne marche, et sont parfois(pas toujours) autorisés à demander des corrections de la spec, il y a plus ou moins d'aller-retours entre tous ces gens-là, et quand arrive la date de livraison, on ignore l'avis de l'homologateur pour qui rien n'est prêt et on livre quand même. Sauf si on a un risque comptable avéré(la comptabilité, c'est sacré). Une fois le projet en production, on vire tout le monde puisque c'est fini, puis ça plante de partout(comme l'homologateur l'avait dit, et comme les programmeurs le savaient mais n'ont pas eu le temps de corriger), et on recrute en catastrophe d'autres prestataires pour ramasser les morceaux. Prestataires qui ne connaissent pas le sujet, évidemment, sinon c'est pas drôle. Pendant ce temps là, fort du succès total du projet, le directeur qui a mené tout cela de loin part ailleurs avec une belle augmentation de salaire.

Je caricature, évidemment. Il peut aussi arriver qu'on ne dépasse jamais le stade ou les programmeurs essayent vainement de faire quelque chose, et les homologateurs préparent des cahiers de test pendant des années, sans jamais avoir sous la main de quoi les appliquer(j'ai eu la chance de sortir assez vite. Le pauvre malheureux qui m'a remplacé a refusé de parler à son point de fin d'année. Je ne crois pas que j'aurais été aussi poli).

Bon, il y a aussi des cas plus normaux ou on a laissé aux programmeurs le temps de bosser, voire, miracle, aux testeurs le temps de tester. Là, ça se passe quand même mieux. Ca a du m'arriver à peu près deux fois, et bizarrement, dans les deux cas, la charge de maintenance derrière était dérisoire, comparée aux somme pharaoniques investies pour faire tourner les applis démoulées trop chaud. Mais comme ce n'est pas le même budget, le décideur ignore délibérément cette variable, et se fait mousser sur le fait que lui est capable de faire un projet pour pas cher.

Conclusion : je suis assez cynique, mais la vraie vie dans le vrai monde du travail, c'est brutal. Le testeur arrive en fin de cycle, parfois pour valider de l'excellent boulot, souvent pour trouver une daube infâme, et n'a pas toujours, loin s'en faut, les moyens de redresser la barre. Ca ne le rend pas inutile, sans lui, tout est encore bien pire(vécu), mais c'est parfois décourageant. C'est toujours mon boulot(à ceci près que je fais plus de scripts automatiques de tests que de test manuel, de nos jours), donc ça n'est pas si catastrophique que ça non plus. Mais il ne faut pas se bercer d'illusions non plus. Le premier contact est très différent des attentes. Et c'est aussi ça qui est rigolo - il faut s'adapter, faire de notre mieux avec les moyens que l'on a, et faire la différence quand même.