![Citation](https://forum.developpez.be/images/misc/quote_icon.png)
Envoyé par
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.
Partager