Discussion :

[mouss4rs]

Bonsoir,

J'aimerai savoir ce qu'il faut demandé sur un projet de test en mode AGILE déjà démarré dés le début (pour planifié ces futurs campagnes de test automatisés) ?

Mon souci, c'est de pouvoir planifié à l'avance mes sprints jusque Décembre 2018.

En tant que nouveau CP, je sêche là ...

[Luckyluke34]

Hello,

Alors déjà, ce n'est pas AGILE mais Agile

Que veux-tu dire par "un projet de tests" ? Je n'ai jamais entendu parler d'un projet agile où l'on ne ferait que des tests puisque le but est de livrer de la valeur métier fréquemment.

On peut réutiliser certains principes de l'agilité (livraisons fréquentes, collaboration quotidienne avec le business, amélioration continue...) quand on produit du test, mais si le projet principal ne suit pas ces principes, ça risque de ne pas coller.

Mon souci, c'est de pouvoir planifié à l'avance mes sprints jusque Décembre 2018.

Ca tombe bien, les sprints sont en général de durée égale, donc il suffit de choisir une durée et tu auras tes dates Pour le contenu c'est moins prévisible, on part en général avec un scope arbitraire et on planifie en N pour le sprint N+1. On peut faire des projections mais ce ne sont que des estimations.

[el_slapper]

Il y a test automatisés et tests automatisés. Les tests unitaires, de préférence automatisés, sont faits pare les développeurs en plus du livrable lui-même. La méthode,agile ou autre, importe peu. Les tests de recette, qui tapent généralement sur l'interface, eux, sont plus rigides, faits par une équipe à part(c'est mon job), et servent principalement à la non-régression. Mieux vaut les faire plus tard, sur des parties de l'application considérée comme stable, pour éviter que les couts de maintenance desdits tests n'explose.

[mouss4rs]

Hello,

Alors déjà, ce n'est pas AGILE mais Agile

Que veux-tu dire par "un projet de tests" ? Je n'ai jamais entendu parler d'un projet agile où l'on ne ferait que des tests puisque le but est de livrer de la valeur métier fréquemment.

On peut réutiliser certains principes de l'agilité (livraisons fréquentes, collaboration quotidienne avec le business, amélioration continue...) quand on produit du test, mais si le projet principal ne suit pas ces principes, ça risque de ne pas coller.


Ca tombe bien, les sprints sont en général de durée égale, donc il suffit de choisir une durée et tu auras tes dates Pour le contenu c'est moins prévisible, on part en général avec un scope arbitraire et on planifie en N pour le sprint N+1. On peut faire des projections mais ce ne sont que des estimations.

Merci pour ces précisions
Un projet de test indépendamment du développement applicatif.
Le test est une valeur ajouté sur le projet de développement applicatif.

J'y répond moi-même: je pense qu'il faut connaitre la capacité maximum qu'un automaticien peut développer au cours d'un sprint déjà.
Ca permet de faire l'estimation derrière.

Après, le reste je ne sais pas s'il y'a autre chose à demander...

Par expérience, quelqu'un sait-il ce qu'il faut demander au tout début d'un projet de test automatisé pour établir le planning ?
Des entrants qui m'aideront pour l'estimation?

[mouss4rs]

Il y a test automatisés et tests automatisés. Les tests unitaires, de préférence automatisés, sont faits pare les développeurs en plus du livrable lui-même. La méthode,agile ou autre, importe peu. Les tests de recette, qui tapent généralement sur l'interface, eux, sont plus rigides, faits par une équipe à part(c'est mon job), et servent principalement à la non-régression. Mieux vaut les faire plus tard, sur des parties de l'application considérée comme stable, pour éviter que les couts de maintenance desdits tests n'explose.

c'est pas vraiment ce que je demandait...

J'aimerai savoir ce qu'il faut demandé sur un projet de test en mode AGILE déjà démarré dés le début (pour planifié ces futurs campagnes de test automatisés) ?

Mon souci, c'est de pouvoir planifié à l'avance mes sprints jusque Décembre 2018.

[Luckyluke34]

J'y répond moi-même: je pense qu'il faut connaitre la capacité maximum qu'un automaticien peut développer au cours d'un sprint déjà.

Ca, on ne le sait pas au début à moins que la même équipe ait déjà travaillé sur un projet très similaire. Du coup on part sur une valeur arbitraire ou à très grosses louches et on ajuste au fil des sprints en constatant ce qui a réellement été développé.

Les méthodes agiles ne font pas d'estimation précise en avance de phase. Tout est dans l'affinage progressif. Attention à ne pas tomber dans le travers des méthodes traditionnelles qui consiste à planifier au millimètre près dès le début, tout baser là-dessus et se planter royalement en cours de route.

[Marco46]

J'aimerai savoir ce qu'il faut demandé sur un projet de test en mode AGILE déjà démarré dés le début (pour planifié ces futurs campagnes de test automatisés) ?

Dans un projet agile les tests font partie intégrante du sprint. Une fonctionnalité non-testée, et j'entends par là non couverte par du test automatisé doit être considérée comme non-livrée.

Pourquoi ?

Un des principes de base de l'agile c'est de pouvoir changer de priorité d'un sprint à l'autre pour satisfaire le besoin du métier. Ça veut dire changer l'ordre des priorités du backlog, mais aussi modifier un existant qui ne correspond pas au besoin après livraison.

Cela signifie donc refactoring.

Et qui dit refactoring, dit nécessité d'avoir des tests.

Tes développeurs ont besoin des tests non pas 3 mois après le développement de la feature, mais avant de commencer leur refactoring pour :
- modifier les tests de la feature à refacto pour adapter au nouveau besoin
- vérifier que les modifications sur une feature A n'entrainent pas de bugs ou de régressions sur le reste

Donc ce que tu demandes n'a pas de rapport avec l'agile.

Ce que tu demandes c'est : Quels sont les entrants dont une équipe de QA a besoin pour réaliser des tests sur un existant.

Dans les grandes lignes ils ont besoin :

- d'un environnement de test
- d'une visibilité sur les versions installées
- des bons de livraison (ou CHANGELOG) des différentes versions
- d'un accès à la base de données (via logiciel type Workbench / DBeaver)
- d'un accès aux users stories (les specs fonctionnelles quoi)
- d'un logiciel pour saisir les anomalies rencontrées et communiquer avec l'équipe de développement
- ...

[el_slapper]

(.../...)

J'avais mal lu. "pour planifier jusqu'en décembre 2018", par définition, ce n'est pas de l'agile. Donc il n'y a pas de réponse à sa question. C'est du waterfall par petits lots(improprement appelés sprints). Ce qui ne me choque pas, des lots de petite taille peuvent marcher aussi bien, dans nombre de contextes. C'est juste que "agile" est faux dans cette configuration, et pollue l'esprit.

Sinon, j'ai l'impression qu'il parle de tests automatiques de non-régression faits par la QA, en plus de ceux faits par les devs(si les devs n'en font pas au niveau unitaire, il est chocolat, de toutes façons, je suis d'accord avec toi). Mon métier, quoi. en plus de tout ce que tu cites(nécéssaire pour les tests manuels, mais insuffisant pour les tests automatiques), il faut :
_une manière rapide de sauvegarder la base de données à un statut initial, et un moyen tout aussi rapide d'y revenir.
_un outil d'automation de tests d'interface(99% des tests automatiques QA sont des tests d'interface)
_un outil de pilotage des-dits tests automatisés. Ce n'est pas toujours lié à l'outil précédent, ça dépend des solutions.
_des environnements dédiés aux tests automatiques - pour ne pas à chaque retour à la base de référence bousiller le boulot des testeurs manuels.

Tout ceci en plus des tests automatiques de développement. Nous, on ne cherche pas les mêmes choses que les développeurs. On a des situations réalistes, des scripts couvrant l'ensemble de l'appli, et permettant souvent de détecter des impensés à droite qui provoquent des régressions à gauche. Et on a déjà ramassé des anomalies qui auraient tué des bébés(indétectables en tests unitaires, et hors du périmètre du changement, donc que les testeurs manuels n'auraient jamais regardé).

Et, évidemment, tout ceci nécessite en général quelques semaines à être mis en place. Si il n'a rien et qu'il faut finir le projet en décembre 2018, le ROI sera misérable.

[mouss4rs]

J'avais mal lu. "pour planifier jusqu'en décembre 2018", par définition, ce n'est pas de l'agile. Donc il n'y a pas de réponse à sa question. C'est du waterfall par petits lots(improprement appelés sprints). Ce qui ne me choque pas, des lots de petite taille peuvent marcher aussi bien, dans nombre de contextes. C'est juste que "agile" est faux dans cette configuration, et pollue l'esprit.

Sinon, j'ai l'impression qu'il parle de tests automatiques de non-régression faits par la QA, en plus de ceux faits par les devs(si les devs n'en font pas au niveau unitaire, il est chocolat, de toutes façons, je suis d'accord avec toi). Mon métier, quoi. en plus de tout ce que tu cites(nécéssaire pour les tests manuels, mais insuffisant pour les tests automatiques), il faut :
_une manière rapide de sauvegarder la base de données à un statut initial, et un moyen tout aussi rapide d'y revenir.
_un outil d'automation de tests d'interface(99% des tests automatiques QA sont des tests d'interface)
_un outil de pilotage des-dits tests automatisés. Ce n'est pas toujours lié à l'outil précédent, ça dépend des solutions.
_des environnements dédiés aux tests automatiques - pour ne pas à chaque retour à la base de référence bousiller le boulot des testeurs manuels.

Tout ceci en plus des tests automatiques de développement. Nous, on ne cherche pas les mêmes choses que les développeurs. On a des situations réalistes, des scripts couvrant l'ensemble de l'appli, et permettant souvent de détecter des impensés à droite qui provoquent des régressions à gauche. Et on a déjà ramassé des anomalies qui auraient tué des bébés(indétectables en tests unitaires, et hors du périmètre du changement, donc que les testeurs manuels n'auraient jamais regardé).

Et, évidemment, tout ceci nécessite en général quelques semaines à être mis en place. Si il n'a rien et qu'il faut finir le projet en décembre 2018, le ROI sera misérable.

merci je kiffe le chocolat :-)

Oui, test automatisé je suis sur de l'UFT.
C'est le client qui stress.
Il croit qu'en revenant de vacances, les choses vont s'améliorer toute seule.

Moi je part sur une vitesse de croisière d'ici 4-5mois car avec toutes les problématiques, on est loin du compte...
Surtout que j'ai pris beaucoup de retard à cause de plein de choses qui ne sont pas de mon ressort...bref...j'ai plus envie de me casser de cette mission lool.
mais bon on va patienter et si y'en a un qui bronche, gare à lui.
Je suis prêt à me casser car la politique de l'autruche y'en a marre.

[mouss4rs]

Ca, on ne le sait pas au début à moins que la même équipe ait déjà travaillé sur un projet très similaire. Du coup on part sur une valeur arbitraire ou à très grosses louches et on ajuste au fil des sprints en constatant ce qui a réellement été développé.

Les méthodes agiles ne font pas d'estimation précise en avance de phase. Tout est dans l'affinage progressif. Attention à ne pas tomber dans le travers des méthodes traditionnelles qui consiste à planifier au millimètre près dès le début, tout baser là-dessus et se planter royalement en cours de route.

merci beaucoup c'est un très bon rappel

[el_slapper]

merci je kiffe le chocolat :-)

Oui, test automatisé je suis sur de l'UFT.

On essaye de s'en débarrasser pour des trucs plus modernes, mais tant qu'on a une partie client lourd, UFT nous colle à la patte comme le sparadrap du capitaine Haddock. Sur certaines pages web compliquées, on a trop d'event listener, et ça aveugle les capacité de reconnaissance de UFT.

En tous cas, c'est bien du test automatique d'interface, avec ce genre d'outils. Donc oui, il faut monter en gamme doucement. J'irais même plus loin : ce n'est pas grave si ce n'est pas fini à la fin du projet. L'intérêt, c'est principalement en maintenance, donc bien plus tard. Là ou les tests niveau dev dont parle Mat sont nécessaires dès le développement(comme il l'explique si bien). Ca peut prendre du retard, mais ça doit se faire à terme. Je viens de finir un test sur une fonctionnalité de 2014, tiens. Et ça a ramené une grosse régression sur la version 2018.

C'est le client qui stress.
Il croit qu'en revenant de vacances, les choses vont s'améliorer toute seule.
(.../...)

Tiens, j'en ai connu d'autres du même acabit. Ma seule et unique expérience en suivi de projet : le chef est en congés, et comme tous les gens qui connaissent le projet sont en congés aussi, on ramasse un type de l'équipe d'a coté - moi - sans aucune expérience dans ce genre de boulot, sans aucune connaissance de ce projet, et on l'envoie en réunion avec la CdP coté métier. Qui demande ou en est le suivi d'anomalies. Je réponds que je n'en sais rien - ben oui, j'ai découvert son projet le matin même. Elle entre dans une rage folle, et le lendemain, le N+3 me passe un savon et me rétrograde à la place que j'avais deux jours avant, et que je n'avais jamais demandé à quitter. La semaine suivante, le CdP rentre de vacances, se fait plomber, et convoque mon commercial pour me passer un savon officiel. La seule faute que j'ai accepté de reconnaitre lors de ce pénible entretien : avoir accepté de donner un coup de main sans savoir.



En fait, ils voulaient que je joue des claquettes et que j'invente des réponses plausibles. Sans rien connaitre de ce projet. Je ne sais pas faire. C'est à ce moment que j'ai compris que la politique c'est important, et que je n'ai pas de talent là-dedans. Depuis, je fais plus gaffe, mais je reste mauvais dans l'exercice.

[mouss4rs]

C'est un mal pour un bien el_slapper , tu aurais perdu du temps malheureusement avec des gens qui ne te kiffe pas dés le départ.
et la confiance sur un projet, c'est important !


Dernier news concernant ce beau projet mais à la sauce IBM (certaines femmes me font vomir!) :

Il souhaite me donner congés dans les 2 semaines qui suit alors que mon préavis est de 1 mois (à la suite d'une mauvaise entente avec celle qui voulait que je travaille à chaque fois côté à cote et qui m'épuisait chaque jours, et qui n'était pas ma N+1 mais juste une soit-disante chef de projet pour mieux apprendre sur la partie TEST et me dire dire bye bye... insupportable !

Au final, elle a réussi à me faire sortir du projet la catin !

Dommage très beau projet, mais je le savais, rares sont les femmes qui sont directes et je ne l'a sentais vraiment mais vraiment pas du tout celle-là... mais bon j'avais ESPOIR...

Pour ma part, j'ai été directe, j'ai vider mon sac sur les 4 mois de cauchemar que je vis avec elle et au final elle sort le dictaphone lool franchement, c'est pitoyable !
Quand c'est elle qui m'invite au REU, je rigole quand elle rigole.
Quand c'est moi qui l'invite a une REU cliente et qu'on se met à rigoler, elle trouve un pretexte pour nous refroidir à chaque fois et ca devient PENIBLE !!

Surtout que la goutte d'eau qui a fait débordé le vase, c'est le fait de me dire de travailler au 6ème étage sinon tu retourne chez IBM en fin de journée alors que je lui répétais sans cesse que le 6ème étage côté fenetre sans clim (JE NE SUPPORTE PAS LA CHALEUR lool).
Elle a réussi la catin, elle a reussi !

Quelle hypocrisie, j'ai bien envie de lui faire un coup quelle sans souviendra, quelqu'un a-t-il une très belle idée ?

Sinon, je reste calme et poli comme dab et je sort de la mission comme un pro.

C'est le côté politique que je n'ai pas, mais je ne voudrais en aucun cas jouer l'hypocrite, je suis quelqu'un de directe mais pas brute et je suis quelqu'un de sympa à vivre et gentil mais faut pas pousser non plus.

la suite au prochain épisode llool!

[mouss4rs]

Dernièrement ma société qui m'a vendu me fait du forcing pour signer un contrat que j'ai déjà signer mais avec des modifications de période d'essai.

malheureusement, je n'ai pas garder le document electronique que j'ai signé, la mouizz

Que faire quelqu'un connait-il un bon avocat au cas ou ?