Que fais t-on qd on "réalise des tests" ?

**hélios44** · 19/01/2007, 14h40

Bonjour,

Voila je suis developpeur debutant et je suis tombé sur cette annonce :
"VOUS REALISEZ LES TESTS
DE LOGICIELS DE GESTION ET DE L EX- PLOITATION INFORMATIQUE. VOUS CON-
NAISSEZ LINUX ET SQL. "

Je me demandais ce quon attendait CONCRETEMENT d'un tel poste ?
Quelle est la journée type? j'imagine qu'il n'ya pas de developpement ?

Merci d'avance

**CoZo** · 19/01/2007, 15h07

Bonjour helios , realiser des tests , (ce que je fait en ce moment) , en fait ca depend des tests.Si c'est de la recette , tu dois ecrire des scénarii qui permettent de tester toutes les fonctionnalités de l'application dans tout les cas , donc ca demande une bonne lecture et comprhension des spécs. Le sql , je pense qu'ils le demande car pour realiser ces scénarii , il faut des jeux de données donc te peler les bases de données pour trouver par exemple des factures emise tel jours avec un client de tel type pour tester l'edition d'un duplicata ou autre.
Donc pour résumer les test c'est 'un peu' interessant car au niveau fonctionnel , tu as une vue d'ensemle et tu vois
comment est conçu l'appli.Apres c'est pas tres technique et c'est plutot barbant (certain trouve ca meme degradant).
Perso je finis ma mission ce soir et j en suis tres content (de finir).
Vala

**GLDavid** · 19/01/2007, 15h09

Peut-on inclure aussi le développement d'unit tests ?
Car je fais ça, et c'est "passionnant" (mode ironique).

@++

**cladsam** · 19/01/2007, 15h22

Hum en fait ca dépend,
il y a plusieurs types de tests :
- unitaires, c'est ma fonction marche je la nouri avec tels paramètres elle rend tels résultats , c'est ennuyeux au possible et fait par le développeur dans la plupart des cas
- test d'intégration : est-ce que les composants testés unitairement fonctionnent bien entre eux.
- test de non régression ; j'ai un système qui marche, je veux passer un package ( dont un ensemble de fonction testée d'abord uniatirement puis en intégration) , est- ce que ce package ne va pas cassé un truc qui fonctionnait avant dans le système?
- test de performance : mon package répond il au performance demandée lors de l'expression des besoins ?
- test de validation ( acceptance ) : est ce que la package répond au besoin fonctionnel bref fait-il tout ce qui est demandé et que ce qui est demandé, comme c'est demandé ?

Quand on prend quelqu'un pour des tests et uniquement pour ca il fera surtout la partie rédaction /execution des test de perf / validation voir non regression.
ET après l'execution des tests, il faut assurer la relation des avec l'équipe de développement c'est a dire partager les bugs , receptionner les retour, retester ...

**hélios44** · 19/01/2007, 15h29

Merci pour vos reponses.
Pour avoir une bonne vue d'ensemble, il faut qd meme avoir un minimum d'expé non? Parce que la, c'est "debutant accepté" (Service public > ds un Ministère :p ....a la baule!!)

**la drogue c'est mal** · 19/01/2007, 16h52

minimum d'expérience pour cliquer sur des boutons et faire des fiches de bugs ? non pas besoins

**cladsam** · 19/01/2007, 17h01

Envoyé par la drogue c'est mal

minimum d'expérience pour cliquer sur des boutons et faire des fiches de bugs ? non pas besoins

Euh la fau relativiser, un vrai plan de test avec des vrais outils de tests c'est tout sauf juste cliquer sur des boutons ...

**GLDavid** · 19/01/2007, 17h06

Envoyé par cladsam

Euh la fau relativiser, un vrai plan de test avec des vrais outils de tests c'est tout sauf juste cliquer sur des boutons ...

+1
Et si tu t'occupes de développer les tests unitaires, la connaissance du langage ainsi que des APIs d'unt tests seront exigés (JUnit pour Java ou cppUnit pour C/C++).

@++

GLDavid, unit testeur et debugger d'un projet

**cladsam** · 19/01/2007, 17h12

Oui et sur des gros trucs comme SAP il y a aussi de soutils d'automatisatin des tests fonctionnels qui sont a mi-chemin entre le ttest et la prog et qui permette par exemple de créer un test, loger les erreurs et le rejouer soit sur le même serveur soit sur un autre ( pratique quand tu passes par des serveurs intermédiaires entre le développement et la production)

**tipiak** · 19/01/2007, 17h12

Bonjour,
Effectivement l'annonce est très évasive

"réaliser des tests" déja cela dépend de ce que l'on appel réaliser
mener de bout en bout un projet de recette d'acceptance (implique de la connaissance fonctionnelle, de la gestion de projet, voir de la gestion d'équipe et des interaction avec la maitrise d'ouvrage et la maitrise d'oeuvre, gérer les datas de tests, gérer les environments de tests etc etc) cela peut être super enrichissant.

mais "réaliser des tests" cela peut être aussi du "click bouton": dans le cas où ton job se limite à l'execution des tests (je ne parle meme pas "d'ecrire" ou de designer les tests...) c'est tout de suite moins drole.
(d'ailleurs au court de mes expériences testing, une bonne partie de cette "réalisation de tests" se faisait off-shore...)

selon moi des critères qui peuvent aider à voir l'interet d'une mission de testing:

- quelle est la phase de test impliquée: Unit test, intégration, User acceptance....

- quel type de tests: régression, performance, fonctionnel, sécurité (par exemple de la régression manuelle c'est tout de suite moins instructif que des tests de sécurité ou de performance puisque tu fais tjr la même chose, alors que de la perf tu vas jouer avec des environments similaires à la production, jouer avec du monitoring, des outils de tests, et intéragir avec pas mal d'experts technique DBA/app serveur/network..., sans oublier experts métiers et les architectes ...)

- maturité des process de testing: (aspect assurance qualité et industrialisation des process de tests peut être sympa) ie: faire de l'outillage et designer des process sympatiques pour augmenter la valeur ajouté et le rendement d'un projet qualification (cela peut être sympatique) (cette partie ressemble plus à celle d'un ingénieur process et qualité qu'à celle de testeur pure et dur...)

- les méta-activité autour du projet de qualification: Gestion des environments de test, gestion des données de tests, gestion du projet de test/d'une équipe de tests. (ie. le job de test manager s'apparente plus à un job de chef de projet qu'à celui de testeur off-shore qui click sur des boutons..)

en gros pour conclure les tests c'est une activité qui semble s'élargir (du moins on y accorde de plus en plus d'importance), ce qui a pour conséquence que le terme de "Testeur" devient de plus en plus "vague"

**hegros** · 21/01/2007, 00h48

Envoyé par cladsam

Euh la fau relativiser, un vrai plan de test avec des vrais outils de tests c'est tout sauf juste cliquer sur des boutons ...

Il se peut aussi que les plans de tests soient déja rédigés et que les outils soient déja sélectionnés ce qui fait que tu peux te retrouver exactement à faire ce que la drogue c'est mal à écrit.

**la drogue c'est mal** · 21/01/2007, 12h48

bah dans ma boite, le plan de test se fait AVANT la réalisation (en meme temps ou apres les specs). Cela permet de mettre en avant des incohérence ou contradiction des specs et des cas d'utilisation( use case ). De plus, cela permet au developpeur de faire leur test unitaire plus simplement. Donc pour moi, faire ses plans de test quand tout est fini est une mauvaise démarche, on ne se demande pas comment l'ensemble doit réagir quand il est deja fini (enfin, c'est un autre débat)

Et si tu t'occupes de développer les tests unitaires, la connaissance du langage ainsi que des APIs d'unt tests seront exigés (JUnit pour Java ou cppUnit pour C/C++).

les tests unitaires releve du developpeur (nomal qu'on test ce qu'on developpe). Dans ce cas, on recherche un developpeur et non une personne pour réaliser des tests

**Go_Ahead** · 25/01/2007, 09h06

bah dans ma boite, le plan de test se fait AVANT la réalisation (en meme temps ou apres les specs). Cela permet de mettre en avant des incohérence ou contradiction des specs et des cas d'utilisation( use case ). De plus, cela permet au developpeur de faire leur test unitaire plus simplement. Donc pour moi, faire ses plans de test quand tout est fini est une mauvaise démarche, on ne se demande pas comment l'ensemble doit réagir quand il est deja fini (enfin, c'est un autre débat)

les tests unitaires releve du developpeur (nomal qu'on test ce qu'on developpe). Dans ce cas, on recherche un developpeur et non une personne pour réaliser des tests

Je suis entierement d'accord avec ces propos.
Un développeur lorsqu'il developpe, doit assurer que tout doit etre en ordre et ainsi livrer un pdt fini.
Sinon c'est que le developpeur est un peu fénéant, a moins qu'il a trop de boulot....

**cladsam** · 25/01/2007, 09h20

Envoyé par Go_Ahead

Je suis entierement d'accord avec ces propos.
Un développeur lorsqu'il developpe, doit assurer que tout doit etre en ordre et ainsi livrer un pdt fini.
Sinon c'est que le developpeur est un peu fénéant, a moins qu'il a trop de boulot....

Pour information sur un gros système le plan de test ne se limite heureusement pas au tests qu'effectuent les développeurs, donc je ne vois pas trop bien en quoi le fait que les développeurs fassent leurs tests avant le développement imlique que tous les test se doivent d'être réalisés en amont.

Par exemple je suis en train de préparer un plan de test pour après la livraison faites par les développeurs qui font parties d'une société dont nous sommes clients.

On a spécifié notre besoin, il préparent leur produit et le livrent, ensuite on repasse des tests dessus pour savoir si l'on accepte ou pas, les développeurs savent ce qu'ils ont a respecter, ils n'ont pa sla vue sur les moyens qu'on met en place pour tester qu'ils le repsecte bien et ils ne sont pas dispensés de faire leurs tests avant de nous livrer ...

**hegros** · 25/01/2007, 12h29

Envoyé par cladsam

Pour information sur un gros système le plan de test ne se limite heureusement pas au tests qu'effectuent les développeurs, donc je ne vois pas trop bien en quoi le fait que les développeurs fassent leurs tests avant le développement imlique que tous les test se doivent d'être réalisés en amont.

Peut être qu'il y a confusion mais il me semble que se sont bien les plans de tests qui sont rédigés en amont.La réalisation des tests peut venir bien plus tard.

Envoyé par cladsam

On a spécifié notre besoin, il préparent leur produit et le livrent, ensuite on repasse des tests dessus pour savoir si l'on accepte ou pas, les développeurs savent ce qu'ils ont a respecter, ils n'ont pa sla vue sur les moyens qu'on met en place pour tester qu'ils le repsecte bien et ils ne sont pas dispensés de faire leurs tests avant de nous livrer ...

Les derniers tests que tu effectues serait la recette de ton programme.J'ose espérer quand même qu'avant de faire les tests généraux les développeurs ont quand même réalisé des tests unitaires (fonction,module,sous-système,interaction sous-système,....)

**cladsam** · 25/01/2007, 14h19

Envoyé par hegros

Peut être qu'il y a confusion mais il me semble que se sont bien les plans de tests qui sont rédigés en amont.La réalisation des tests peut venir bien plus tard.

Tu as très bien compris je pense que je me suis trompé et qu eje voulais écrire "implique que tous les test soient rédigés en amont"

Envoyé par hegros

Les derniers tests que tu effectues serait la recette de ton programme.J'ose espérer quand même qu'avant de faire les tests généraux les développeurs ont quand même réalisé des tests unitaires (fonction,module,sous-système,interaction sous-système,....)

Oui mais la je vois pas en quoi tu dis le contraire de ce que je dis puisque je dis que le fait que les developpeur fassent des test avant de livrer ( ce qui veut bien dire qu'ils en font) ne t'oblige pas a rédiger les test que tu feras toi a reception avant meme qu'ils commencent les dév.

Bref les units tests peuvent et idéalement doivent etre rédigés avant le début des dév. Il doivent être éxecutés avant la livraison
Les tests d'accepetance sont rédigés avant la livraison et exécutés juste après.
Moralité , si tu interviens sur la partie test d'acceptance, tu peux etre amené a rédiger ces test pendant les dev , voila ce que j'ai dit en version un eu plus française

**t_om84** · 26/01/2007, 10h33

Bonjour,

Je viens réintégrer mon ancienne entreprise qui fait du développement de logiciels dans l'éditique et mon poste sera de mettre en place des batteries de tests grâce à QuickTest Pro de Mercury.

Je viens de lire le post, et certains d'entre vous parle d'un métier assez ennuyeux voir "très passionnant" d'un ton ironique!

Or, je ne vois pas pourquoi, dans un société de dév, la fait de mettre en place des tests automatiques ou manuel est devenu important. J'aimerais comprendre pourquoi certains n'aiment pas ça!

Suite à la formation que j'ai eu, je trouve que je vais quand même avoir pas mal de code à taper, et beaucoup de cheveux à m'arracher. Mais bon après ça,je pense que ça dépend de la taille de l'entreprise et de son logiciel.

Bref, j'espere que ça va me plaire!

**tipiak** · 26/01/2007, 11h34

Envoyé par t_om84

Bonjour,

Je viens réintégrer mon ancienne entreprise qui fait du développement de logiciels dans l'éditique et mon poste sera de mettre en place des batteries de tests grâce à QuickTest Pro de Mercury.

Je viens de lire le post, et certains d'entre vous parle d'un métier assez ennuyeux voir "très passionnant" d'un ton ironique!

Or, je ne vois pas pourquoi, dans un société de dév, la fait de mettre en place des tests automatiques ou manuel est devenu important. J'aimerais comprendre pourquoi certains n'aiment pas ça!

Suite à la formation que j'ai eu, je trouve que je vais quand même avoir pas mal de code à taper, et beaucoup de cheveux à m'arracher. Mais bon après ça,je pense que ça dépend de la taille de l'entreprise et de son logiciel.

Bref, j'espere que ça va me plaire!

mes posts étaient loin d'être ironiques (je ne vais quand meme pas couper l'herbe sous mes pieds...).

les métiers du tests sont même très prisés dans certaines boites.
(je n'inclus pas les Unit tests comme déja mentionné c'est le job des developpeurs) il n'y a pas que du unit test et l'acteptance. pour chaque phase de spec ou de conception on peut y retrouver son équivalent testing (User acceptance, System tests, integration ...)
sans oublier les tests non fonctionnels (performance, sécurité ...)

et les aspects tooling process et méthodes qui se raprochent plus de l'assurance qualité (avec des fondements techniques pour implementer et garantir les process)

Toutes les organisations n'ont pas forcement les moyens et le besoin de mettre en place toutes ces facettes du metier de testing.
(mais cela reste tout de meme un domaine ne plein essor)

**t_om84** · 26/01/2007, 12h19

Envoyé par tipiak

(mais cela reste tout de meme un domaine ne plein essor)

C'est ça qui est intéréssant actuellement, il faut savoir se possitionner et lorsque l'on m'a proposer de revenir dans la société pour faire cette mission, j'ai accepté de suite car c'est en plein essor
mais bon après dans ce post on dit par exemple :

Envoyé par CoZo

Apres c'est pas tres technique et c'est plutot barbant (certain trouve ca meme degradant)

pas très technique, acteullement sur QTP, il y a quand meme des scripts à rélaiser, certes en VBScript mais bon, si tu ne te sers pas des outils graphiques, là ça deveint devient techniques

Envoyé par cladsam

Quand on prend quelqu'un pour des tests et uniquement pour ca il fera surtout la partie rédaction /execution des test de perf / validation voir non regression.
ET après l'execution des tests, il faut assurer la relation des avec l'équipe de développement c'est a dire partager les bugs , receptionner les retour, retester ...

C'est tout de même intéréssant ça!