Discussion :

[Aelitia]

Bonjour à tous,

J'ai un master en contrôle qualité alimentaire (2013).

Je souhaite de me reconvertir dans les métiers de la qualification logicielle. Ces métiers paraissent très intéressant : vérifier et assurer la qualification d'une application ou d’un logiciel avant sa mise en production. C'est ce que je fait en biologie : analyser et vérifier la qualité des aliments.

Je voulais savoir comment se déroule une journée type d'une consultant testeur ? Que fait t-il de 9-17h en gros lorsqu'il travail sur un logiciel (ou plusieurs?) ?
Qu'es ce que j'aurai à faire en tant que "testeur" si je me reconverti ? Seulement tester une application ?

Si un testeur passe par là ou quelqu'un qui connaît bien le métier, merci par avance pour vos réponses.

[el_slapper]

Bonjour.

En fait, comme beaucoup de métier, ça dépend des boites. Ce que j'ai fait dans cette grande banque Française qui sponsorise le Rugby :
_analyse des spécifications
_mise en place des scénarios de test
_déroulement des scénarios à chaque nouvelle version
_création d'un outil VBA/excel pour faciliter l'exécution des tests et pour analyser en masse les données
_analyse des résultats, remontée d'anomalies
_choix d'uns stratégie de tests de non-régression

Ce que je fais maintenant dans un éditeur logiciel qui installe de dossier patient informatisé dans de grands hôpitaux publics(moins facile à trouver que le premier, il y a plusieurs suspects. Indice pour les enquêteurs : nous avons notre propre SGBD)
_gestion des environnements de test; clonage des machines, paramétrages, gestion des données, et suivi de la disponibilité
_test manuels ad hoc, en fonction de la demande
_le gros morceau : codage de test automatiques de non-régression. Qui valident que chaque nouvelle version n'est pas complètement badibulguée avant de la déployer chez nos hôpitaux clients.
_assistance aux installations chez le client(ça n'a rien à voir avec le reste, mais c'est rigolo de passer 13 heures par jour à écouter se plaindre le personnel médical, et lui expliquer que non, prendre son stylo et barrer le dossier papier, en informatisé, ça ne marche plus, et le voir pleurer auprès de sa hiérarchie pour revenir au papier).

Le cas bancaire est quand même, et de loin, le plus probable.

[Aelitia]

Merci pour votre réponse, elle m'aide énormément.

Le cas bancaire paraît aussi plus intéressant ; c'est plus proche de ce que j'ai vu sur la qualité logicielle.
Chez l'éditeur de logiciel, le travail du consultant paraît plus complexe et cela nécessite un très bon relationnel avec le client.

J'ai aussi vu que la plupart des consultants travaillent dans des ESN (ssii) : chez leurs clients.
Les clients peuvent être les banques et les éditeurs de logiciels ? C'est bien ça ?

Votre travail vous plaît ? Es t-il compliqué en lui même?

[el_slapper]

(.../...)Le cas bancaire paraît aussi plus intéressant ; c'est plus proche de ce que j'ai vu sur la qualité logicielle.
Chez l'éditeur de logiciel, le travail du consultant paraît plus complexe et cela nécessite un très bon relationnel avec le client.

ça, ça dépend de la boite. Une majorité sortira rarement ses ingénieurs qualité, mais nôtre branche française est petite, donc je suis amené à dépasser mes fonctions officielles. En bancaire, évidemment, vu la taille des boites, les fonctions sont beaucoup plus restreintes.

J'ai aussi vu que la plupart des consultants travaillent dans des ESN (ssii) : chez leurs clients.
Les clients peuvent être les banques et les éditeurs de logiciels ? C'est bien ça ?

il y en a bien d'autres, que je n'ai pas fréquenté. En particulier l'aérospatial, qui a des normes, euh, très strictes, en comparaison. La qualité, chez eux, ça va jusqu'à renifler et valider chaque ligne de code. Mais je n'en sais pas plus.

En éditeur de logiciel, on est souvent interne(mais pas toujours. C'est mon cas, mais quand j'étais en SSII, j'ai aussi bossé pour ce profil de boites. Le niveau moyen est supérieur, je trouve, mais avec parfois des surprises)

Votre travail vous plaît ? Es t-il compliqué en lui même?

C'est bien payé, et ça n'est pas un hasard. ceux qui y collent des développeurs ratés y laissent pas mal de plumes. Moi j'aime bien, mais ce n'est pas pour tout le monde. 60% de ceux qui ont essayé n'ont pas aimé(stat purement personelle, et donc limitée).

[Aelitia]

Il me paraît toujours fort intéressant ce métier.

Merci pour toutes vos réponses et vos précisions.

[el_slapper]

Quand même un avertissement : il y a sur le marché du travail à peu près un homologateur pour 7 développeurs - mais c'est aussi le ratio des offres d'emploi. Il y a des places, mais pas pour tout le monde, et surtout, même si on est bon, on a moins le choix que les développeurs.

Mais pour quelqu'un qui aime le contrôle qualité, normalement, ça devrait le faire.

[Aelitia]

Merci de cette mise en garde.
Franchement, je n'aime pas du tout le métier de développeur, pour moi c'est un vrai casse tête. Une fois, j'ai fait du 'python' pour de la bio-informatique (c'est un programme informatique). Je n'ai vraiment pas apprécié. Je comprenais tout juste.

Il n'y a pas énormément d'offre d'emploi, mais j'en ai vu pas mal (comparé à ma biologie, plus précisément je faisait de du contrôle qualité en microbiologie, c'est énorme). Mais c'est vrai que les offres pour les développeurs sont plus qu'abondantes.

Oui le contrôle qualité c'est mon domaine. Bien sûr, je vais poursuivre mes recherches. On ne se reconvertit pas à la légère. Je passerais surement par une formation et/ou un stage d'observation d'un testeur.

[garn]

Bonjour à tous,

J'ai un master en contrôle qualité alimentaire (2013).

Je souhaite de me reconvertir dans les métiers de la qualification logicielle. Ces métiers paraissent très intéressant : vérifier et assurer la qualification d'une application ou d’un logiciel avant sa mise en production. C'est ce que je fait en biologie : analyser et vérifier la qualité des aliments.

Je voulais savoir comment se déroule une journée type d'une consultant testeur ? Que fait t-il de 9-17h en gros lorsqu'il travail sur un logiciel (ou plusieurs?) ?
Qu'es ce que j'aurai à faire en tant que "testeur" si je me reconverti ? Seulement tester une application ?

Si un testeur passe par là ou quelqu'un qui connaît bien le métier, merci par avance pour vos réponses.

Bonjour,

C'est ma formation de base, je peux donc te renseigner je pense, meme si depuis j'ai évolué vers de l'assistance à maitrise d'ouvrage de manière plus générale

Pour ma part j'ai eu l'occasion de me lancer via une formation financée par l'ANPE (à l'époque ca s'appelait comme ca :p)
En partenariat avec une SSII spécialisée en test, qui offrait un CDI certain à la fin de la formation, en échange de deux mois de "stage" sous payé par rapport à un emploi CDI. Bref, chacun s'y retrouvait financièrement ou en formation, et c'était via FITEC, un organisme sérieux (en ile de france, http://www.fitec.fr/ )

Quoiqu'il en soit : le test est une logique propre, avec ses avantages et ses inconvénients comme tout métier

Avantages : Pour tester il faut savoir ce qu'on doit tester. on développe une connaissance des outils / logiciels qu'on doit tester qui est parfois supérieure à celle qu'on les gens qui l'ont conçus...C'est pourquoi il n'est pas rare que les testeurs et les gens qui écrivent les spécifications à l'origine d'un programme soient une seule et même personne

Inconvénient : Il est très courant de devoir opérer des tâches répétitives

Avantage ou inconvénient selon la personne : le test est un des métiers les plus carrés, rigoureux, organisé et logique qui soient. Ca se rapproche par certains aspects d'une logique juridique : on développe un arbre, sans rater aucun aspect, comme une table des matières : Grand 1, Petit 1, petit a - Grand 1, petit 1, petit b - Grand 1, petit 2, petit a... etc etc

Avantage : il n'y a pas besoin de connaissance informatique, au moins au début. Ensuite on développe quelques connaissances de base, comme du SQL, pour comprendre et appliquer ce qu'on test, en fonction du logiciel (par exemple tester un programme qui s'appuie sur une base de données, le SQL est obligatoire). Inconvénient de ce fait : les informaticiens purs ont souvent du mal avec le test, malgré leur capacités à bien mieux comprendre les aspects techniques

Avantage ou inconvénient : il faut avoir une certaine imagination et surtout savoir se projeter, essayer de penser à ce que doit être un logiciel avant qu'il ne soit réalisé et qu'on l'ait en main. Et ca, souvent uniquement avec l'appui de la description fonctionnelle (ou technique) à partir de laquelle les développeurs travaillent.


La journée d'un testeur ressemble à celle d'un développeur quelque part, sauf qu'on test au lieu de développer
En simplifiant, il y a trois grandes phase dans la recette

1) La préparation
prise de connaissance des spécifications du logiciel, et préparation de ce qu'on appelle un cahier de recette. C'est à dire mettre sur papier (enfin, sur Excel en fait) ce qu'on veut tester, selon quelle logique, avec quelles données, pourquoi, comment... Il faut qu'au moment du test on n'ait plus aucune question à se poser et que tout soit prévu

2) l'exécution
Lorsque le logiciel est livré, on ouvre son cahier de recette et on suit pas à pas ce qu'on a normalement bien décrit. Et on regarde les différences entre ce qui est livré réellement (le logiciel) et ce qu'on avait anticipé à partir de la spécification

3) la saisie des anomalies
Une anomalie n'est pas forcément un bug. C'est juste une différence entre une (bonne) spécification et la réalité. Si le document te dis que le logiciel doit être rouge, et qu'il est fait en orange, c'est une anomalie, pas un choix artistique : On ne juge pas, on suit un manuel.

4) la répétition des étapes 2 et 3. Quand il y a des bugs, ils son corrigés, ils sont relivrés, on retest, toujours la même chose, toujours comme on a prévu, et on vérifie si non seulement l'anomalie est corrigée mais qu'elle n'a pas déclenché un autre problème. Le test c'est quelque chose d'exhaustif (dans l'idéal, toujours, je ne parle pas des contraintes de planning à respecter...)

5) quand tout est fini, le testeur signe un PV de recette : il appose sa signature pour indiquer que selon lui, il n'y a plus d'anomalies (ou s'il en reste, il les signale sur le dit PV). C'est un des seuls métiers ou il y a quelque part une vrai responsabilité et une signature en bas d'un document mettant en jeu sa qualité de travail.

Personnellement, j'adore. Mais je connais beaucoup de monde qui ne supportent pas !

Il y aurait énormément d'autres choses à dire mais je pense que déja, il faut te poser la question de savoir si tu as les qualités de rigueur et la patience nécessaires. Ca n'est pas un travail gratifiant : on ne crée rien, on ne fait que vérifier. Et comme on mets le doigts sur toutes les mauvaises chose qu'un développeur peut avoir fait, sans pouvoir a coté le féliciter des bonnes, on est mal recu. Il y a un coté humain à gérer, au final c'est le développeur qui livre un logiciel de qualité (ou non), et qui facilite notre travail.

[el_slapper]

(.../...)

Inconvénient : Il est très courant de devoir opérer des tâches répétitives

Avantage ou inconvénient selon la personne : le test est un des métiers les plus carrés, rigoureux, organisé et logique qui soient. Ca se rapproche par certains aspects d'une logique juridique : on développe un arbre, sans rater aucun aspect, comme une table des matières : Grand 1, Petit 1, petit a - Grand 1, petit 1, petit b - Grand 1, petit 2, petit a... etc etc

Avantage : il n'y a pas besoin de connaissance informatique, au moins au début. Ensuite on développe quelques connaissances de base, comme du SQL, pour comprendre et appliquer ce qu'on test, en fonction du logiciel (par exemple tester un programme qui s'appuie sur une base de données, le SQL est obligatoire). Inconvénient de ce fait : les informaticiens purs ont souvent du mal avec le test, malgré leur capacités à bien mieux comprendre les aspects techniques

Avantage ou inconvénient : il faut avoir une certaine imagination et surtout savoir se projeter, essayer de penser à ce que doit être un logiciel avant qu'il ne soit réalisé et qu'on l'ait en main. Et ca, souvent uniquement avec l'appui de la description fonctionnelle (ou technique) à partir de laquelle les développeurs travaillent.
(.../...)

Merci pour ce très bon résumé. Je dirais que le test partage avec le développement le fait d'exiger une très grande rigueur ET une très grande créativité. Souffler le chaud et le froid, quoi. Sans doute pas dans les mêmes proportions, avec moins d'exigence technique, et plus d'exigence fonctionnelle. Le froid de la rigueur pour n'oublier aucun cas, le chaud de l'exploration quand on trouve un truc bizarre et qu'on commence à creuser, et qu'il faut penser à tout avec l'esprit critique.

Quand aux tâches répétitives, moi j'adore : c'est l'occasion de les automatiser(mais Aelitia n'aimant pas la programmation, ça sera sans doute moins vrai dans son cas)

[Aelitia]

Merci pour votre réponse et vos précisions.

Faire des tâches répétitives ne me dérange pas plus que ça (dans l’analyse des aliments, je faisais aussi la même chose quasi tout les jours). La journée d’un testeur est plutôt sympa quand même.
Les tâches sont aussi répétitives dans les SSII-ESN ? Il me semblait qu’il y avait plusieurs missions plus ou moins longues, chez différents clients (banque, assurance,….) ?
Je suis plutôt patiente et sérieuse même si j‘ai quand même des limites.

Ce qui me dérange le plus, c’est de ne pas arriver à me projeter en voyant ce que serait le logiciel dans le futur ; et de ne pas voir les anomalies du logiciel. Mais bon, j’espère que ça s’apprend et qu’à longue on y arrive.
Le testeur travaille en équipe ? ou il fait toutes ses trois grandes phases seul ?


Si ce n'est pas indiscret, pourquoi es-tu passé à l'assistance à maîtrise d'ouvrage ? Quelle était ton domaine de formation avant ta formation testeur? la formation à fitec était-elle compliquée ?

[el_slapper]

(.../...)
Faire des tâches répétitives ne me dérange pas plus que ça (dans l’analyse des aliments, je faisais aussi la même chose quasi tout les jours). La journée d’un testeur est plutôt sympa quand même.
Les tâches sont aussi répétitives dans les SSII-ESN ? Il me semblait qu’il y avait plusieurs missions plus ou moins longues, chez différents clients (banque, assurance,….) ?
Je suis plutôt patiente et sérieuse même si j‘ai quand même des limites.

Je ne parlait pas de la répétitivité des missions. Ça, c'est purement de la chance. Non, parfois, certaines tâches reviennent souvent(remettre la base dans son état initial, faire un test, remettre à nouveau la base dans son état initial, etc...), et les automatiser est un plaisir.

Ce qui me dérange le plus, c’est de ne pas arriver à me projeter en voyant ce que serait le logiciel dans le futur ; et de ne pas voir les anomalies du logiciel. Mais bon, j’espère que ça s’apprend et qu’à longue on y arrive.
Le testeur travaille en équipe ? ou il fait toutes ses trois grandes phases seul ?

ça dépend. J'ai bossé en équipes de 10, j'ai bossé tout seul. De toutes façons, le job du testeur n'est pas d'imaginer la prochaine version. Il est de tester, de trouver les anomalies, et de faire des propositions à partir de la version qu'on a sous la main. La vision à long terme, c'est pour la MOA. ou les développeurs.

Si ce n'est pas indiscret, pourquoi es-tu passé à l'assistance à maîtrise d'ouvrage ? Quelle était ton domaine de formation avant ta formation testeur? la formation à fitec était-elle compliquée ?

Ou-là, j'espère que tu aimes les histoires alambiquées...

A la base, je suis ingénieur plasturgiste. La plasturgie étant en crise quand je sors du service militaire, je me retrouve en SSII comme des milliers d'autres, formé en 5 semaines au COBOL... et ma boite m'envoie homologuer dans une grande banque Française(qui me forme à ce métier en interne), avant de faire pas mal de missions en développement. Quelques années plus tard, je me retrouve par hasard à revenir sur le lieu de mes débuts, et cette fois-si, je fais une longue mission en homologation pour échapper à un projet voué à l'échec(6 ans de retard, 60 personnes, l'horreur). Et donc, j'ai depuis la double casquette homologateur développeur. Pendant quelques années, j'alterne les deux. Finalement, j'ai une occasion d'entrer chez un éditeur de logiciel pour faire du test automatique, et voilà, sorti des SSII au moment ou mon âge commençai à y être à un obstacle.

[garn]

Merci pour votre réponse et vos précisions.

Faire des tâches répétitives ne me dérange pas plus que ça (dans l’analyse des aliments, je faisais aussi la même chose quasi tout les jours). La journée d’un testeur est plutôt sympa quand même.
Les tâches sont aussi répétitives dans les SSII-ESN ? Il me semblait qu’il y avait plusieurs missions plus ou moins longues, chez différents clients (banque, assurance,….) ?
Je suis plutôt patiente et sérieuse même si j‘ai quand même des limites.

Ce qui me dérange le plus, c’est de ne pas arriver à me projeter en voyant ce que serait le logiciel dans le futur ; et de ne pas voir les anomalies du logiciel. Mais bon, j’espère que ça s’apprend et qu’à longue on y arrive.
Le testeur travaille en équipe ? ou il fait toutes ses trois grandes phases seul ?


Si ce n'est pas indiscret, pourquoi es-tu passé à l'assistance à maîtrise d'ouvrage ? Quelle était ton domaine de formation avant ta formation testeur? la formation à fitec était-elle compliquée ?

je n'ai pas vraiment eu le choix de passer en AMOA de manière générale. Le travail en SSII fera que ton entreprise te proposera des missions même si ce n'est pas ton idéal / ta spécialité :
le but d'une SSII (enfin ca s'appelle une ESN maintenant) est de pouvoir te placer contre rémuération du client. Mettons qu'un client veuille une personne sachant faire du test a 60% et des spécifications a 40%. Tu n'as fait que tu test jusqu'a présent: heh bien si le client l'accepte (tu n'as souvent pas ton mot à dire) il te prendras, et tu apprendras à faire des spécifications, de gré ou de force...
Après ca n'est pas tout noir : se diversifier dans ses compétences est un plus indéniable sur le marché du travail en général (à condition de pas trop se diversifier quand meme il faut que ca soit cohérent)

pour ma formation j'ai commencé en tant que testeur juste après mes études. mais plusieurs de mes collegues sur cette formation étaient plus agés et avaient des formations préliminaires, dont quelqu'un qui s'occupait de valider les installations de chaufferies / plomberies ! (et il était bon en test informatique en plus, très rigoureux)

Oui le testeur travaille souvent en équipe du fait que le test est une procédure longue et demandée souvent sur un planning assez court. C'est la base de la gestion de charge : il faut 4 personnes pour réaliser en un jour ce qui prendrait 4 jours à une personne (de manière théorique)
Tu as aussi différents types de test :

- les tests métiers, c'est à dire les plus proche de l'utilisateur final : on se met à la place de quelqu'un qui n'est pas informaticien et a le logiciel en main, et on essaye de savoir si toutes ses manipulations, même les plus illogiques, ne provoquent pas d'erreur, si tout fonctionne selon ce qui est attendu. En ce moment je test une application mobile par exemple

- personnellement j'ai un CV un peu compliqué entre l'AMOA et la business intelligence / base de données. De fait, j'ai souvent manipulé des fichiers qui permettent de faire transiter des données, et donc fait des tests "technico fonctionnels", la 2eme sorte
C'est le test qui valide ce qui est développé mais en relation avec la MOE (les développeurs) plutot que la MOA (les métiers)

- les tests purement techniques : normalement on n'a pas a en faire a moins d'avoir des connaissances techniques sur le sujet, les développeurs font eux même (théoriquement) un certain nombre de tests avant de livrer un développement

Enfin, le sujet est vaste, j'ai un ami qui ne fait par exemple QUE des tests de charge, c'est pratiquement un travail de développeur : ca consiste a utiliser des logiciels ou des scripts pour envoyer une grand quantité de données, souvent pour tester la robustesse d'un systeme (nombre d'accès simultanés, par exemple le site de paris de la francaise de jeux doit pouvoir supporter X millions de requêtes un soir de finale de football)

Quand au sujet des SSII / ESN... c'est partout pareil, que ce soit en test ou en développement. Malheureusement, ce sera aussi incontournable, sauf gros coup de chance a trouver une place directement dans une entreprise

[Aelitia]

Je ne parlait pas de la répétitivité des missions. Ça, c'est purement de la chance. Non, parfois, certaines tâches reviennent souvent(remettre la base dans son état initial, faire un test, remettre à nouveau la base dans son état initial, etc...), et les automatiser est un plaisir.



ça dépend. J'ai bossé en équipes de 10, j'ai bossé tout seul. De toutes façons, le job du testeur n'est pas d'imaginer la prochaine version. Il est de tester, de trouver les anomalies, et de faire des propositions à partir de la version qu'on a sous la main. La vision à long terme, c'est pour la MOA. ou les développeurs.

D'accord, c'est plus clair.

Ou-là, j'espère que tu aimes les histoires alambiquées...

A la base, je suis ingénieur plasturgiste. La plasturgie étant en crise quand je sors du service militaire, je me retrouve en SSII comme des milliers d'autres, formé en 5 semaines au COBOL... et ma boite m'envoie homologuer dans une grande banque Française(qui me forme à ce métier en interne), avant de faire pas mal de missions en développement. Quelques années plus tard, je me retrouve par hasard à revenir sur le lieu de mes débuts, et cette fois-si, je fais une longue mission en homologation pour échapper à un projet voué à l'échec(6 ans de retard, 60 personnes, l'horreur). Et donc, j'ai depuis la double casquette homologateur développeur. Pendant quelques années, j'alterne les deux. Finalement, j'ai une occasion d'entrer chez un éditeur de logiciel pour faire du test automatique, et voilà, sorti des SSII au moment ou mon âge commençai à y être à un obstacle.

Je connais le Cobol, j'ai été contacté par plusieurs ssii pour des formations + CDI mais après renseignement le Cobol ne m’intéressait pas du tout.
Ton parcours n'est pas si compliqué que ça. Il y a bien pire, et tu n'es pas resté inactif.
Il ne prenne que les jeunes en ssii?

[Aelitia]

je n'ai pas vraiment eu le choix de passer en AMOA de manière générale. Le travail en SSII fera que ton entreprise te proposera des missions même si ce n'est pas ton idéal / ta spécialité :
le but d'une SSII (enfin ca s'appelle une ESN maintenant) est de pouvoir te placer contre rémuération du client. Mettons qu'un client veuille une personne sachant faire du test a 60% et des spécifications a 40%. Tu n'as fait que tu test jusqu'a présent: heh bien si le client l'accepte (tu n'as souvent pas ton mot à dire) il te prendras, et tu apprendras à faire des spécifications, de gré ou de force...
Après ca n'est pas tout noir : se diversifier dans ses compétences est un plus indéniable sur le marché du travail en général (à condition de pas trop se diversifier quand meme il faut que ca soit cohérent)

pour ma formation j'ai commencé en tant que testeur juste après mes études. mais plusieurs de mes collegues sur cette formation étaient plus agés et avaient des formations préliminaires, dont quelqu'un qui s'occupait de valider les installations de chaufferies / plomberies ! (et il était bon en test informatique en plus, très rigoureux)

Oui le testeur travaille souvent en équipe du fait que le test est une procédure longue et demandée souvent sur un planning assez court. C'est la base de la gestion de charge : il faut 4 personnes pour réaliser en un jour ce qui prendrait 4 jours à une personne (de manière théorique)
Tu as aussi différents types de test :

- les tests métiers, c'est à dire les plus proche de l'utilisateur final : on se met à la place de quelqu'un qui n'est pas informaticien et a le logiciel en main, et on essaye de savoir si toutes ses manipulations, même les plus illogiques, ne provoquent pas d'erreur, si tout fonctionne selon ce qui est attendu. En ce moment je test une application mobile par exemple

- personnellement j'ai un CV un peu compliqué entre l'AMOA et la business intelligence / base de données. De fait, j'ai souvent manipulé des fichiers qui permettent de faire transiter des données, et donc fait des tests "technico fonctionnels", la 2eme sorte
C'est le test qui valide ce qui est développé mais en relation avec la MOE (les développeurs) plutot que la MOA (les métiers)

- les tests purement techniques : normalement on n'a pas a en faire a moins d'avoir des connaissances techniques sur le sujet, les développeurs font eux même (théoriquement) un certain nombre de tests avant de livrer un développement

Enfin, le sujet est vaste, j'ai un ami qui ne fait par exemple QUE des tests de charge, c'est pratiquement un travail de développeur : ca consiste a utiliser des logiciels ou des scripts pour envoyer une grand quantité de données, souvent pour tester la robustesse d'un systeme (nombre d'accès simultanés, par exemple le site de paris de la francaise de jeux doit pouvoir supporter X millions de requêtes un soir de finale de football)

Quand au sujet des SSII / ESN... c'est partout pareil, que ce soit en test ou en développement. Malheureusement, ce sera aussi incontournable, sauf gros coup de chance a trouver une place directement dans une entreprise

J'avais entendu parler des inter-contrats, quand tu n'as pas de missions pendant longtemps, tu prends la première proposition. Je ne pensais pas que c'était au point de changer de métier. Mais c'est vrai que c'est intéressant pour avoir plus de compétence dans son domaine.

Peut on se spécialiser dans les tests métiers par exemple ? ou on ne sait vraiment pas sur quoi on va tomber ?

[el_slapper]

Je connais le Cobol, j'ai été contacté par plusieurs ssii pour des formations + CDI mais après renseignement le Cobol ne m’intéressait pas du tout.
Ton parcours n'est pas si compliqué que ça. Il y a bien pire, et tu n'es pas resté inactif.
Il ne prenne que les jeunes en ssii?

Ils prennent des jeunes, ou alors des profils vraiment spécialisés. J'étais un peu trop dispersé. Ça a bien plus à cet éditeur de logiciels américain, mais en tant que prestataire, je devenais de plus en plus dur à caser.

Le COBOL, j'aime bien, mais c'est vrai que ça n'est pas très vendable en société. J'ai lu en 85(j'avais 9 ans) dans un 01 informatique de mon père que c'était un langage mort. Il m'a quand même nourri à 60/70% de 2001 et 2013... Et on continue à former des gens. Mais il ne faut pas avoir peur des écrans noirs avec des caractères verts.

Et sinon, oui, en intercontrat, tu prends la première mission ou tu est accepté. Il m'est arrivé de passer deux entretiens en parallèle, mais je n'ai jamais eu deux réponses positives - donc jamais eu le choix. Le seul cas ou je ne suis pas aller alors que j'aurais du, c'était pour un job à Lille(j'étais basé à Paris), ou j'ai dit "d'accord, mais vous me payez l’hôtel le lundi soir, le jeudi soir, 2 AR en TGV, et je suis en télétravail le mercredi". Bizarrement, ils n'ont pas insisté...

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.

[garn]

J'avais entendu parler des inter-contrats, quand tu n'as pas de missions pendant longtemps, tu prends la première proposition. Je ne pensais pas que c'était au point de changer de métier. Mais c'est vrai que c'est intéressant pour avoir plus de compétence dans son domaine.

Peut on se spécialiser dans les tests métiers par exemple ? ou on ne sait vraiment pas sur quoi on va tomber ?

bien sur on peut, et on devrait
mais il y a deux sortes de choses qui rentrent en conflit, totalement indépendantes du métier

1) l'intéret de la SSII c'est le commercial, juste le commercial. Faire de l'argent. je ne caricature pas, c'est leur métier : faut bien rentrer des sous pour payer les employés
D'une manière générale aucune entreprise, et certainement pas dans la prestation de service, ne privilégiera le bien être du consultant (demander à travailler sur un type de mission en particulier) au fait de pouvoir faire de l'argent - et surtout ne pas en perdre. Si tu es en intercontrat, ta SSII continue a te payer mais tu ne rapportes rien. Forcément ca veut dire que l'entreprise essaiera de te placer le plus vite possible, peu importe ou

il y a des exceptions a toutes choses, des boites honnetes, mais il faut être conscient de la réalité générale du monde du travail en prestation de service informatique


2) le consultant lui, voulant se spécialiser, doit pouvoir se construire l'expérience correspondante. En dehors du fait de couter de l'argent a ta boite, si tu es en intercontrat, ca n'est pas de l'expérience, ca ne rapporte rien sur ton CV en valeur ajoutée. Donc il faut bien a un moment se dire, SSII comme consultant, qu'il est temps de réagir

le plus simple et ce que je conseille toujours aux jeunes : changez de boite quand vous sentez que la votre ne trouve pas de mission à votre gout. Il y a des milliers de SSII sur le marché en ile de france. Si tu es en intercontrat, ta société sera très content de se débarasser de toi, et tu sera content de bosser ailleurs (gain salarial, et avec de la chance une bonne expérience à la clé)

C'est aussi pour cela que je conseille a un débutant des embauches "sur mission", c'est à dire que tu n'es embauché dans la SSII que si un client veut te prendre en prestation. Ca équivaut à ne chercher de la main d'oeuvre qu'en fonction du marché du travail et des offres commerciales, ce qui assure un minimum de confiance financières (et évite les intercontrats d'entrée de jeu)

L'inverse est l'embauche "sur profil" : tu es embauché dans la société, qui ne sais pas encore ou / chez qui elle va te placer, mais elle pense que ton CV est suffisamment intéressant pour que ca puisse se faire rapidement. Ca équivaut à avoir de la main d'oeuvre sous la main pour répondre le plus vite possible aux offres commerciales

[Aelitia]

Merci à vous pour toutes vos précisions/réponses.
Je connais mieux les ssii et le métier du test.
Je pense faire un stage d'observation et une formation fitec de qualification logicielle.

[geraltdvt]

Bonjour,

Je profite de cette discussion pour demander s'il y a des bassins d'emploi en test logiciel en France. Hors région parisienne. Est ce que Lyon propose des opportunités en test logiciel ? Quel salaire pour une personne ayant de 1 à 3 ans d'expérience sur Lyon ?

Merci

[Invité]

Bonjour à tous,

J'ai un master en contrôle qualité alimentaire (2013).

Je souhaite de me reconvertir dans les métiers de la qualification logicielle. Ces métiers paraissent très intéressant : vérifier et assurer la qualification d'une application ou d’un logiciel avant sa mise en production. C'est ce que je fait en biologie : analyser et vérifier la qualité des aliments.

Je voulais savoir comment se déroule une journée type d'une consultant testeur ? Que fait t-il de 9-17h en gros lorsqu'il travail sur un logiciel (ou plusieurs?) ?
Qu'es ce que j'aurai à faire en tant que "testeur" si je me reconverti ? Seulement tester une application ?

Si un testeur passe par là ou quelqu'un qui connaît bien le métier, merci par avance pour vos réponses.

Bonjour !
Ce metier est un sujet que je connais bien. Dans mes deux precedentes boites j'ai croise pas mal de SDET/QA.
Si tu te demandes ce qu'est un SDET tu peux lire mon article ici: http://julien.dollon.net/post/Ce2809...r-ou-SDET.aspx
Le probleme c'est que les entreprises de la cote ouest americaine (petites et grandes) ont commence il y a un an a faire la guerre aux SDET et commencer a les virer.
Ils ont de bonnes raisons, entre autre le fait que cela donne plus d'ownership a un ingenieur. Mais je veux pas rentrer dans le debat (si ca t'interesse: http://blog.dollon.net/ne-devenez-pa...tez-ingenieur/)
Bref, pas de pb pour toi de devenir QA/SDET, mais si tu le deviens sachez que tres souvent les tendances de la cote ouest arrive en france apres 5 a 10 ans, et d'ici la ce job n'existera peut etre plus.

Bon en meme temps dans 15 ans on sera tous au chomage d'apres la singularity is near

[laetitiacruchinho]

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.