Discussion :

[Paradisma]

Bonjour,

j voualis des informations sur le poste "ingénieur Test et recettes".
à quoi consiste ce poste !? quelles sont les missions qu'ils sont afféctés !?
que dois je connaître et maitriser pour passer un entretien correctement pour ce poste !?
et quel salaire dois je demander, à savoir que je suis débutante sans expérience, avec un Bac + 5 (fraichement diplômée) !?

merci d'avance

[Glutinus]

La recette est une étape de validation de développement. Tu vas donc préparer et/ou disposer d'un cahier de recette qui recense une batterie de tests qui permettra de valider ou non si le composant développé fait bien ce qui a été demandé. Après cela dépend du domaine, je prendrai celui de la banque-assurances parce que je la connais bien : est-ce qu'on prend bien en compte tous les contrats ? Est-ce que les contrats de type "A" ont bien été filtrés ? Le montant total a-t-il bien été calculé ? Au niveau de la charte graphique les couleurs sont bonnes ? le bouton radio fonctionne-t-il bien ? etc.

Tu disposeras aussi de nombreux outils, comme test director, qui te permettra d'ouvrir des fiches et tenir au courant de l'évolution d'une anomalie auprès des développeurs. Pour moi un bon recetteur doit avoir un bon aspect technique pour bien communiquer avec l'équipe technique ; il doit aussi clairement énoncer l'anomalie et non un simple "ça marche pas" (ce qui arrive plus souvent qu'on ne l'imagine).

[Paradisma]

Merci Glutinus, d'ailleur c'est pour un projet bancaire.

si j'ai bien compris, j'aurais pas à developper !?
test director me permettera juste de faire l suivie des anomalies trouvés et les communiquer au developpeur !?
vous créer des tests automatiques !?

[HerQuLe]

Il doit aussi avoir le profil de celui qui aime "chercher la petite bête", pour ne pas laisser passer le moindre bug et aider à la production d'un logiciel de qualité.


Ce métier, de mon point de vue, a l'air relativement chiant.
Mais a mon avis, ça dépend des endroits:
- Si tu te contente de dérouler un cahier de recette que d'autres ont réalisé: c'est pas très glamour.
- Si c'est toi qui réalise le cahier de recette avec une équipe de fonctionnels, c'est deja un peu plus intéressant (mais sans plus)


Ce qui peut être intéressant, c'est d'utiliser des outils de tests automatisés (qui permettent d'éviter toute la partie routine du déroulage du cahier de recette).


Par exemple, avec un outil comme Sélénium, tu peux faire naviguer un robot sur un site web pour vérifier différentes choses, le faire cliquer sur des boutons, naviguer dans les menus, envoyer des formulaires...

Généralement, juste au dessus de l'API Selenium, on développe une abstraction, un framework qui englobe toute la complexité du site que tu veux tester.
Ce qui te permet d'écrire des tests en langage "humain".

Prenons un site connu, comme Voyages SNCF par exemple. Une fois le framework réalisé, tu peux écrire un test de cette manière:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
rechercherVoyage("Paris","Lyon", "24/10/2011" , Passager.ADULT );
verifierNombreDeTrainsAffichés( 6 );
verifierTarifsDisponibles( Tarif.LOISIR, Tarif.PREMS, Tarif.FIRST_CLASS );
choisirTrain( 1 );
choisirTarif( Tarif.LOISIR );
verifierPrix ( 107 );
verifierPropositionsDispos( Partenaires.AVIS , Partenaires.Assurance );
validerSelection();
verifierModesDeRetraitDispos( MDR.E_BILLET, MDR.BILLET_NORMAL );
validerModeDeRetrait( MDR.BILLET_NORMAL );
veriifierMoyensDePaiement( Carte.VISA, Carte.MASTERCARD );
payer( Carte.VISA , "12345678912345" , "123" );
verifierPrixDebite( 107 );
verifierModeDeRetrait( MDR.BILLET_NORMAL );
verifierReceptionMailRecapitulatif();

Moi perso je trouve ça plus rigolo, mais c'est le point de vue d'un développeur.


Tu as des outils aussi qui permettent d'écrire des tableaux de tests sur un Wiki, et qui executent un test pour chacune des lignes du tableau (Ex: FitNesse)

[Robin56]

Moi perso je trouve ça plus rigolo, mais c'est le point de vue d'un développeur.

Même avis d'un autre développeur.

[troll:on]Sinon c'est bien connu que les développeurs détestent les créateurs d'anos et que les testeurs détestent les créateurs de bugs. [/troll]

[garn]

bah la recette c'est l'anti développement
c'est de la MOA, contrairement au dev qui est de la MOE

ca varie fortement suivant ce qui est demandé, le résumé de Glutinus est bon, on peut meme faire de la recette sur du BI (validation et test des univers BO...)

Pour les profils, il faut voir que c'est un secteur qui émerge de facon relativement récente (j'ai commencé en 2007 avec une formation spécifique perso), parcequ'on s'est rendu compte que c'était bien de développer dans les délais mais qu'il fallait ensuite que ca fonctionne

Un peu comme la Bi qui prend de plus en plus d'ampleur.

Le pendant de ceci est qu'il y a eu une grosse demande il y a quelques années, et qu'il fallait trouver les gens pour : beaucoup de formation ou entreprise ont alors pris ce qui leur tombait sous la main (ingénieur en chimie par ex) pour leur apprendre les processus. Un peu comme apprendre du C a un ingénieur qui n'a jamais touché.

Généralement les tests sont plutot "manuels", l'outil est un assistant, et tu n'auras souvent qu'un outil pour loger les anomalies, pas pour t'aider sur ta recette. Voire aucun outil du tout parfois. Bon, sur un secteur bancaire j'ai tendence a dire que ca sera bien suivi par un outil. Mais il n'y a que rarement des tests "automatiques", generalement c'est un processus a acquérir, la base est un peu de penser a tousles cas de figure possibles qui puissent se produire, par simplement les cas "normaux" (ex : ca fait quoi si je mets une lettre dans un numerique? on sait que ca va planter bien sur, mais jusqu'a quoi, et quelles conséquences...)

Les salaires sont assez bas au début, il faudra bien faire valoir ton diplome.
En région parisienne, ca peut être vers les 27k pour un non ingé, je pense qu'un ingé peut demande un minimum de 30 / 32 sur paris : il ne faut pas dénigrer ce job sous pretexte que "nimporte qui" peut le faire, c'est parfois pointu et porte de lourdes responsabilités, car parfois les développeurs ont tendence a se dire "boah, je verifie pas, de toute facon y a la recette qui passe derriere"... Et tu as souvent un PV de recette a signer pour t'engager a ce que tu ai tout vérifié.

Également, j'ai tendance a dire qu'une fois engagé dans cette voie, comme beaucoup, on y reste souvent. La "simple" recette est parfois très ingrate, parceque c'est pas forcément folichon de vérifier de l'ortographe dans un processus automatique d'envoi de lettre, par exemple, mais ca peut monter assez vite, vers de l'AMOA ou un poste de chef de projet, voire une spécificité technique sur un outil qui est très recherchée (je pense notamment au test de charge, particulier mais qui paye assez bien car relativement rare).

[troll:on]Sinon c'est bien connu que les développeurs détestent les créateurs d'anos et que les testeurs détestent les créateurs de bugs. [/troll]

Le pire c'est que c'est vrai. Pour avoir fait les deux, développeur et recette, c'est assez drole de voir ca

[Paradisma]

C interessant, merci beaucoup.
Si non, on parle souvnt de plan de test, de cas de test, de cahier de recette !!!
quelqu'un peut m'éclaircir !?
aussi, quels sont ls differents livrables possible !? j'ai lu fiche de rechett, fiche d'anomalie !!! vous pouvez m'aider à comprendr leurs significations t la difference entre chacun !?
Merci d'avance.

[el_slapper]

C interessant, merci beaucoup.
Si non, on parle souvnt de plan de test, de cas de test, de cahier de recette !!!
quelqu'un peut m'éclaircir !?
aussi, quels sont ls differents livrables possible !? j'ai lu fiche de rechett, fiche d'anomalie !!! vous pouvez m'aider à comprendr leurs significations t la difference entre chacun !?
Merci d'avance.

la difficulté, c'est que ça change de boite en boite. En gros(mais c'est pas toujours vrai, hélas) :

stratégie : une vue "macro" de la manière dont on va valider l'application
Plan : vision détaillée de la stratégie.
Scenario : un ensemble de cas qui permet de tester une configuration dans son ensemble(ce que signifie configuration varie fortement)
Cas : un morceau unitaire de test.

exemple, pour une appli de gestion de salon de coiffure :
Stratégie : on va tester la solidité de l'appli, puis la bonne prise en compte de chaque service.
Plan : contient un scénario de solidité cases, un scénario de solidité charge, un scénario de coupe homme, un scénario de coupe femme.....
Scenario de solidité cases : liste de cas de solidité de chaque case
Cas de solidité case "montant" : renvoyer une erreur propre si plus de 2 chiffres derrière la virgule ou si caractère non numérique, rajouter automatiquement des zéros après la virgule si il n'y a pas 2 chiffres, etc.....

Ca, c'est pour ce qu'on va faire.

Pour ce qu'on va trouver, par anomalie, on créée une fiche d'anomalie(ou on lève l'anomalie). Bloquante(test impossible à continuer), grave(impensable de livrer en l'état), génante(à corriger quand ça sera possible), de routine(à corriger si on a le temps).

Fiche recette, ça peut être un scenario, un plan, comme un compte-rendu ou un PV de recette, c'est très vague, à se faire préciser.

[phili_b]

Voilà 2 articles trouvés sur internet sur http://phortail.org/webntic/ :

Webntic : Gestion de Projet > Tests et recettes > Organiser une recette fonctionnelle

Webntic : Gestion de Projet > Tests et recettes > Gestion des anomalies

edit:

Il faut rajouter un truc qui ne doit jamais être fait en théorie mais qui est souvent pratiqué: la pré-recette.

Dans certains cas faute de disponibilité ou de motivation, les utilisateurs rechignent à faire la recette, par conséquent l'équipe technique ou au moins la maitrise d’œuvre est contrainte d'élaguer en amont les soucis avenirs et vérifier les principaux cas de tests et les montrer aux utilisateurs.

Ceci en leur expliquant qu'on ne peut être juge et partie et qu'il faudrait mieux que les utilisateurs métiers fassent la recette. Mais dans les toutes petites structure c'est très difficile qu'ils trouvent du temps pour ça, d'autant qu'ils disent que ce n'est pas leur travail, alors que qui mieux que les utilisateurs métiers peuvent juger de la conformité fonctionnelle avec l'application livrée.

Les réunions de démarrage de projet et de conduite du changement sont donc indispensable pour que la recette, comme l'application, soient bien acceptés.