Bonjour à tous   ,
 
Je voulais connaître l'utilité de faire des tests dans une carrière d'ingénieur informaticien. En clair, je suis JD et en 4 mois chez un client, j'ai fait 3 mois de test et 1 mois l'étude d'une techno (JSF). Je suis plutôt mécontent de cette mission car je n'ai rien appris et je ne pratique quasi pas ! Mettre sur un CV "3 mois de test d'un logiciel" est-il perçu comme "chômeur/incompétent" ? Je ne veux pas faire une carrière de testeur moi, il n'y a aucun avenir là dedans et je perds toutes mes connaissances.
Bref, vous en pensez-quoi du métier de testeur ?
 
N.B. : et 3 mois ça commence a faire sur mon C.V. (je n'ai qu'un stage de 6 mois de compétence)

 
C'est nawak ce que tu dis les phase de recette des projets informatique sont en plein boom. Apres si t'aime pas ca c'est ton choix  

au contraire, tester et valider, c'est de manière formelle / informelle être le garant du bon fonctionnement du logiciel .... dans le style responsabilité, c'est quand meme pas mal .....
Puis faudrait aussi enlever les oeilleres, l'informatique, ca se limite pas à une vie derrière un IDE ou un shell ......
après si toi tu aimes ca, alors il faut voir à changer de mission .... si possible ....

Peut être je n'aime pas ça, mais alors dîtes moi ce que vous apprenez à faire des cliques sur des icônes en longueur de journée pour voir si vous ne trouvez pas un bug. C'est se comporter comme un utilisateur ça, pas un créateur ! D'ailleurs les meilleurs testeurs sont les clients qui utilisent les logiciels .

Tester c'est très vague et ca regroupe énormément d'activités.  
 
Déjà, il faut identifier sur quelle phase de test tu interviens:  
1. Mise en place de la stratégie de test (quels tests il va falloir réaliser, à quel moment du projet, les environnements à mettre en place, les équipes, ...)
2. Mise en place des approches de test (ce que tu vas effectivement faire dans cette phase de test: les livrables, pré requis, post requis, ...)
3. Identifier ce qu'il faut tester (si si c'est un travail à part entière)
4. Formaliser ce que tu vas tester
5. Valider ce que tu as formalisé (répétition des scripts ok ? identification du JDD? ...)
6. Executer ce que tu as formalisé
7. Automatiser les tests de non régression
...
Et durant toutes ces phases, la gestion projet de la phase de test
 
Ensuite sur quel domaine de test vas tu travaillé? Tests fonctionnels? Tests techniques? Tests architecture? Tests performance? ...
 
Si tu te limites à l'étape bête et méchante "6. Executer ce que tu as formalisé", ce n'est pas très valorisant. Mais si tu as l'occasion de naviguer sur ces différentes phases, alors ca peut commencer à être intéressant. Après tout dépend de ce que tu recherches.
 
Qu'on aime ou pas, les tests risquent de prendre une part de plus en plus importante dans nos contrées: tout se qui est architecture / fonctionnel / qualité restant en France, toutes les tâches liées au développement pur et dur s'expatriant vers des territoires plus "hospitaliers". Et comme il faut bien manger ...
 
Pour finir, un petit lien sur un article lié à cette activité: http://www.01net.com/editorial/338 [...] alorisant/

 
dans l'informatique en france, on ne crée pas grand chose. La plus part du temps, on ne fait qu'appliquer/recopier les choses qui ont été créées par d'autre, voir pire, on réinvente la roue en pensant qu'on en est l'inventeur...

 
Pendant 3 mois je n'ai fait que l'étape 6 !   Très pénible à terme !  
 
Pourtant je trouve que les phases de dév. sont largement plus complexe que des phases de test. Et les phases de dév sont les briques de l'application ! Les phases de test ne sont que la sécurité...et puis pas besoin d'être ingé pour faire des tests si ce n'est que pour faire des tests (et pas de dev lié au métier où les tests permettent d'apprendre le domaine.)
La procédure que tu cites, très formelle pour les tests, c'est à l'école qu'on t'apprends ça. Dans la réalité c'est moins strict.

la, si tu penses ca, c'est que t'a loupé qqchose ..... en tout cas pour ce que j'en vois .....
après, pour ce qui est du dev, que c'est bien plus interessant valorisant toussa .....  trés discutable aussi ..... un de plus pour qui informatique = pisser du code.
 
tu dis qu'il n'est pas nécessaire d'etre ingé pour faire des tests, tu n'as pas non plus besoin d'etre ingé pour etre dev.
 
enfin, remarque personnelle, pas mal de personnes te disent qu'un poste de testeur peut etre interessant, mais tu persistes dans l'autre sens. Je me demandes si tu ne t'ai pas auto-persuadé avant meme de créer ce topic .... alors pourquoi le créer ?
 
après si tu veux pas écouter les avis d'autres personnes, après tout c'est ton problème .....
 

Généralement, quand tu passe 1h à écrire un bout de code, tu passes 10h à le tester dans tous les sens....
Pour un ingé, faire des tests en cliquant partout est peu valorisant
Ce qui est plus interressant, c'est d'automatiser ces tests
Voir de mettre en place les outils pour passer des tests automatiques !

 
C'est ce que j'ai fais pendant 3 mois   ... et après ils m'ont viré ! J'ai rien appris dans cette mission. Je passe la moitié de mon temps à faaire du net ou à lire 01 informatique . C'est trop la punition un boulot comme ça  

Ce que tu n'as pas compris c est que beaucoup de ssii s'en foutent de ce que tu as envie de faire:ce qui les intéresse, c'est que tu rapportes.On te dit rarement quelles sont les missions disponibles, on te met sur les missions qui rapportent.Et si tu passes plusieurs entretetiens, c'est le commercial qui choisit en dernier, très souvent, quelle mission tu vas faire, indépendamment de tes désirs.Les tests, c'est une activité comme une autre, mais il faut aimer.Ce n'est pas créatif, pas valorisant.Mais il y a des sociétés (clients) où après des activités de recette, tu fais des spécifications, le fin du fin.Mais les places sont très chères et il y a peu d'élus.

 
c'est surtout que tu ne sais pas le valoriser. J'ai fait une mission de recette pour un editeur et c'est cette mission qui me permet de mettre en avant des qualités moins naturellement reconnues pour un developpeur

 
le test c'est comme le dev: travailler en mode Quick and Dirty (c'est à dire tester au petit bonheur la chance) marchera très bien sur un petit projet non critique avec peu de complexité. Mais tu es quasiment sûr d'aller dans le mur sur un projet de plus grande envergure.
Et c svt sur la partie test d'un projet que l'on va pouvoir juger de la rigueur/qualité du projet (pas uniquement sur le nombre de bugs ou sur les différents indicateurs mis en place, mais surtout sur la façon dont cette partie est appréhendée par l'équipe qui s'en occupe).
 

 
et c là que tester prend tout son sens
 
Tester pour exécuter des scripts n'est pas très valorisant mais peut te permettre d'appréhender le SI sous un angle différent. A partir de là: soit il y a des possibilités réelles d'évolution sur le projet ou dans l'entreprise, soit il n'y a aucune possibilité d'évolution.
Dans le 2eme cas, à toi de faire les démarches auprès de tes managers/commerciaux/RH (la terminologie diffère selon les SSII/entreprises mais ca revient toujours au même) pour évoluer vers un poste correspondant plus à tes attentes, tout en restant motivé (au moins sur la forme, sur le fond à toi de voir ...) sur la tâche qui t'a été assigné (qui aura envie de donner un poste intéressant à une personne affichant clairement sa démotivation, voire faisant obstacle à l'avancement du projet lui même?).