J'ai remarqué que les SSII proposaient pas mal d'emploi dans le domaine des tests et de la qualification logicielle (appelé aussi Tierce Recette Applicative).
 
D'après ce que j'ai compris, le but de cette activité est d'assuré que le logicielle crée correspond aux attentes du client (pas de bug, bonne performances etc ...). Les outils utilisés sont principalement TestDirector et LoadRunner.
 
Quelqu'un pourrait il dire si cette activité est intéressante, si il faut beaucoup coder dans ce domaine et dans quel langage (il faut coder les scénarii je suppose). Enfin quels sont les perspectives d'évolution professionnelles dans ce domaine.
 
merci

Sans m'avancer (je suis tech pas ingé):
Rédaction du cahier de recette (à partir de la spéc du besoin logiciel) et passage de celle-ci (devant le client).
Zero programmation.
 
Pour ce qui est de TestDirector et LoadRunner, je suis aussi preneur d'infos  

 
 
 
Salut
 
je vais faire assez court. Je ne connaissais pas le domaine du test quand j'étais jeune diplômé. Maintenant que j'en ai fait, je te le dis tout de suite... fais ça juste quelques mois pour vérifier mes dires. C'est vraiment sans avenir professionnel ce domaine, tu passes ton temps à cliquer, à vérifier si une application tourne bien. Tester un logiciel n'a rien de bien passionnant sauf si tu as créé toi-même le programme. Tu ne peux pas envisager de progression de carrière : quand tu es étiquetté testeur, tu le resteras... sur un CV, avoir un profil Testeur, c'est être condamné à y rester enfermé... garde en tête qu'il est nécessaire d'avoir occupé un poste de testeur juste quelques mois (moi, j'en ai fait 1 mois + qqes semaines en interne dans la SSII). Essaie plutôt de faire de la programmation ou mieux commencer à faire de la gestion de projet en tant qu'asistant au client. Je ne connais pas ton profil donc c'est impossible de bien te guider...
 
Moi je suis ingénieur de formation avec 2 ans d'XP.

Et quand on fait tout; analyse/dev/tests/déploiement/(formation et assistance) ça vaut le coût de préciser test?

 
 
là oui, il faut le mettre, ça montre que tu connais ce que c'est. Mais avoir une expérience PURE 100% TEST/RECETTE, c'st fait mal...

Je pensais même pas que ça existait une XP 100% test. Par ailleurs les seuls offres de ce type que j'ai vu était adressées à des techniciens!
 
Pour revenir sur les outils TestDirector et LoadRunner qq à des infos?

Tu veux savoir quoi sur ces outils ?

 
Google est ton ami.
 
Le premier est une bête application de base de données, style Requirements Traceability Management, ou test units management.  Le deuxième simule la charge sur le système.

Il y a des ingénieurs commerciaux/ssii qui ne sont capables de proposer comme activités que ça. De toute façon, faire ça ou seulement développer, c'est presque pareil, à cette différence que souvent, avec un bac+2, on peut faire aisément des tests, du moins pour des appli simples, de gestion par exemple, pour de l'UMTS, c'est totalement différent. Cela étant, les tests sont souvent liés à l'intégration, et on peut des fois, rares mais ça arrive, passer de l'intégration aux spécifications, le top du top, à condition d'avoir un "bon" niveau. Malheureusement, les 3/4 du temps, on fait des tests et on en reste là.

Je croyais que les tests d'intégration étaient liés à la conception préliminaire et la recette aux spécifications? Enfin c'est ce j'ai appris en formation et c'est ce qu'on pratique au taf...

oui c' tout a fait ça sinon pour les tests:
clif.forge.objectweb.org/load_tools_overview.pdf
 
Bref, sans vouloir casser; Les tests c' souvent ce que l'on propose à ceux qui veulent faire du "fonctionnel" parce qu'il ignore la technique et le metier. ça leur donne l'impression de faire de la maitrise d'ouvrage... Et tout le monde est content. Bon apres ya des specialiste du test qui concoivent des cycles de developpement et des outils de tests (des qualiticiens tres techniques qui accompagnent et maitrise la recette).  

Finalement je suis content du boulot que je fais (plutôt varié ) et technique/fonctionnel en même temps. Seul bémol la paye ABSOLUMENT dérisoire même pour un technicien.
 
Pour l'anecdote j'ai travaillé avec un consultant (enfin c pas le mot qui convient mais c pas grave) dès mon embauche et tenez vous bien en moins d'un mois il me sort: "vu comment t'es payé tu demandes (et tu obtiens) une augmentation rapidement ou sinon tu vas voir ailleurs"   .
En bref c'est lui qui est parti (la boîte a rompu son contrat) et moi qui suit resté    (mais pas augmenté    )

rien pigé a ton histoire mais bon pas grave...
si je comprends bien:
"tu es resté avec un mauvais salaire et le consultant est parti en mission mieux payé loin des test..."

C'est pas vraiment ça:
1. c pas un consultant en fait c'est un ébenniste (ingénieur conseil - wharf c'te blague) qui s'est reconverti dans le dev d'application et a créer un produit logiciel (en Windev of course). La boîte s'était associée et assurait la maintenance évolutive et corrective en partenariat avec lui (un sacré bordel).
La boîte a rompu les ponts pour rentabilité commerciale.
2. je ne fais pas que du test. Je suis dév dans une PME donc je fais de tout analyse/conception/dev/tests/assistance sur des petits projets (j'suis tout seul).
3. Oui je suis toujours payé une misère.
Voilà les choses sont remises à plat maintenant

Donc si je comprend bien, ce métier est plutôt destiné à des techniciens et pas à des ingénieurs ....
 
Pourtant, on trouve pas mal d'offres dans ce domaine pour des bac +5.  En cherchant sur le net j'ai plus ou moins lu que la Tierce Recette Applicative se développe beaucoup en ce moment car la plupart des logiciels développés ne fonctionnent pas correctement et ne correspondent pas à ce qu'avait demandé initialement le client. Il semblerait que maintenant on ne parle même plus de qualification pour cette activité. La qualification consistait à tester le logiciel une fois ce dernier développé et avant sa mise en production.
 
Maintenant, en théorie, l'équipe de Tierce Recette Applicative entre en jeu pendant la rédaction des spécifications. Pendant que les dévéloppeurs rédigent leur spécification, les "testeurs" rédigent les plans de tests décrivant les tests à réalisé et la stratégie de tests. Les personnes travaillant dans ce domaine participe également à la mise en place de méthode pour améliorer les processus de développement.
 
J'ai l'impression que dans ce domaine il faut faire attention à ne pas se retrouver qu'avec les tests à réaliser mais bien sur une mission en entier, avec la mise en place des procédures dans le projet, la stratégie de test, la création des scénarios etc ....
 
Qu'en est il exactement ?

En théorie cela devrait toujours se passer comme ça. En pratique s'est déja moins sûr.

Y'a tests d'intégration et tests d'intégration. Chez les équipementiers de téléphonie mobile par exemple, en intégration, tu vérifies les corrections des bugs des développeurs, avec assistance aux développeurs, sur plateforme. Donc, ce n'est pas la conception préliminaire telle que l'on puisse imaginer. Et pour les progiciels, ce doit être pareil. Au niveau technicité, ce sont les testeurs d'intégration qui sont les plus balèzes, et il faut avoir de l'expérience pour en faire, alors qu'on peut prendre des débutants pour faire de la recette (pas pour écrire les tests tout de même).
 

 
je confirme, c'est archi casse-couille. je viens de quitter une SSII pour faire ça "en direct". ma période d'essai vient de finir, et je me demande si je ne vais pas me barrer si j'ai pas moyen d'intégrer un autre équipe de la société
 
pour résumer, il y a bcp d'annonce parce que peu de gens est prêt à faire ça
 
si tu peux, oriente-toi vers l'intégration. c'est bcp plus interessant car "tu mets les mains dans le camboui !"

 
L'homologation et les recettes, c'est un des seuls domaines dans la MOE où tu peux espérer apprendre un peu de fonctionnel. En testant les applis, si t'es pas noeud, tu peux comprendre les problématiques d'un métier (marketing, achats, etc...) appliquées à ton secteur (Banque, Industrie). Quand t'as assez de compétences, tu peux passer MOA plus facilement.

Parce qu'en analyse tu n'apprends pas le fonctionnel peut être?

Ca suppose qu'il y'ait une "réelle" phase d'analyse  

LoadRunner permet aussi, dans une certaine mesure, de réaliser (automatiser ?) des tests de non régressions ... Enfin pour les SSII qui se prennent ces tests dans la figure, j'appellerai ça des tests d'"agression"  

Pour les tests de non régression ne faut-il pas plutôt préférer les frameworks de tests unitaires type JUnit, CppUnit, etc (chercher la déclinaison pour votre langage).

Pas forcément

 
Pour les tests unitaires (et de non régression), oui.
 
Mais si tu veux vérifier la non régression en terme de performances on trouve difficilement mieux qu'un stress test et du code bien instrumenté.

Qu'entends tu par là?

 
avec tout plein de logs activables lors de l'execution

Ha d'accord, classique quoi.

dans la theorie le classique

Salut,
 
Je ne suis pas du tout d'accord ..  
 
Le métier du test est bien plus passionnant que ça, je le sais j'y suis dedans, et en plus les possibilités d'évolution existent réellement ... de tester, à consultant test ou bien encore test manager tous les profils sont présents!
 
Le test s'est industrialisé via de nouveaux outils : QTP,LoadRunner, TestDirector.
Il n'a plus rien à voir avec le test unitaire réalisé par les developpeurs. Ilest en plein essor, d'ailleurs dans les appels d'offre il ne fait plus partie d'un lot de developpement mais necessite un lot indépendant. Le test donne lieu à des certifications et des formations, preuve que n'importe qui n'est pas testeur. De plus l'approche du testeur est primordial pour l'aboutissement d'un projet info car il en est le garant de la qualité...
 
Aujourd'hui les personnes du Test sont très convoitées, à cause de cette mauvaise image du test, qui je le répète, est fausse...  
 
 
 
 

 
Bonjour,
Je suis également de cet avis. Je suis actuellement en mission pour l'intégration et la qualification d'un produit logiciel en cours de développement chez un gros acteurs de telecom. Il est clair que le métier n'est pas juste du clic, mais beaucoup plus varié. Les tests doivent être rédigés en parallèle aux phases de développement pour être passé le plus vite possible dès que le dev finit une partie. La plupart du temps, il y a tellement de problème que c'est bien souvent les intégrateurs qui remontent les problèmes non détectés pendant la spécification. De plus il est nécessaire d'avoir à la fois une bonne connaissance du cahier des charges mais aussi de la prod. (vision et suivi des services parfois) Sans compter tout ce qui est respect des normes (RFC, etsi ...) Pour moi, le boulot que je fais, je le vois plus en temps que liaison entre le dev et la prod.
Bref, faire que du tests, oui c'est lassant, par contre avoir une vrai activité d'intégration et de recherche des problèmes, ça c'est nettement plus intéressant.
Pour finir, je rejoindrai informatikevou sur le fait que les certifications logicielles sont en train d'apparaître sur le marché français (istqb par exemple) pour justement avoir un process de validation cohérent (stratégie de tests, gestions des exigences, tests composants, tests d'intégration, tests système, métrologie, tests en charges, tests de performances, robustesse, suivi des bugs, tests de non reg et j'en oublie surement ...)
 
++