robot en gros plan ayant le visage du logo robot framework, utilisé dans l'automatisation de tests

Le framework de la dernière chance | Episode 1 : automatisation des tests en 360h chrono

Une équipe projet voit son destin vaciller lorsqu’elle apprend que son client, vendeur en ligne de masques de catch mexicains, ne peut maintenir son projet du fait de contraintes budgétaires.

L’équipe se lance alors dans une aventure périlleuse et mouvementée pour proposer une solution satisfaisante dans un délai très serré. Parviendra-t-elle à sauver son projet ?

Organigramme de l’équipe qui travail sur l’automatisation des tests avec Robot Framework

 

La tension est palpable, alors que Kelly se tient devant son équipe pour lui annoncer une nouvelle qui va faire vaciller leur destin. Mobilisée sur l’évolution et la maintenance d’un site web de vente en ligne, dont elle pilote le développement, l'équipe travaille sans relâche pour assurer la réussite du projet. Les mains moites et la voix tremblante, Kelly s’apprête à révéler le drame qui va tout bouleverser.

« Bon les chums, on est mal ! Notre client vient de m’annoncer qu’on va devoir multiplier par deux la fréquence des mises en prod’ pour des contraintes budgétaires, sinon le projet nous sera retiré. Il nous accorde 15 jours pour trouver une solution. Autant dire qu’il ne va pas falloir niaiser ! »

Brenda, testeuse manuelle dans l’équipe, hyperventile.

Les développeurs, Brad, Courtney et Harper geignent : « C’est quoi encore ce troll ? »

« On ne va pas se laisser démonter ! s’exclame Kelly. À vos méninges ! »

Après quelques instants de silence pesant et plusieurs respirations ventrales réalisées par Brenda, les suggestions fusent, dans une ambiance électrique.

Le défi est de taille : doubler la fréquence de mise en production implique une accélération du rythme de travail déjà très intense pour l’équipe, qui n'est ni dimensionnée ni équipée pour y faire face. De plus, une telle accélération risque d'augmenter les erreurs de développement en rendant impossible l'exécution manuelle de tous les tests dans les délais, avec pour conséquence une augmentation du nombre de bugs en production.

Alors que les neurones s’embrasent et que les propositions veines se succèdent, Kelly suggère : « Je pense peut-être une niaiserie, mais nous pourrions tenter l’automatisation des tests après développement, plutôt que de les réaliser manuellement ? Ce serait un gain de temps colossal ! »

Brenda se fige : « L’automatisation des tests ? Mais alors, je fais comment mes tests ? »

Les développeurs s’animent :

« Nous pourrions démultiplier la fréquence et la quantité des tests joués, tout en sécurisant le développement et en diminuant les erreurs humaines (no offense Brenda) » s’enthousiasme Harper.

« Nous pourrions aussi sécuriser au plus tôt nos déploiements avec des campagnes de non-régression qui seraient lancées systématiquement après chaque intégration ! » ajoute Brad.

« L'automatisation des tests nous permettra aussi de capitaliser sur nos précédents tests grâce au versioning ! » complète Harper.

Seule Brenda panique face à tant d’enthousiasme : « Mais alors, je fais comment mes tests ? »

« Il faut tout de même demander l’avis de notre Expert Technique, recommande Harper, car cette solution ne peut pas s’appliquer à tous les projets. »

Courtney s’exécute : « Scott est AFK sur Teams, mais je le MAJ dès que possible sur le projet. »

« C’est bon, je le spam déjà » avertit Brad.

Le suspense est à son comble. Leur projet client est-il compatible avec une automatisation des tests ? L’équipe doit-elle envisager une nouvelle solution ? L’espoir de conserver ce projet repose à présent entre les mains expertes de Scott…

À suivre dans l'épisode 2.

Lire l'épisode suivant

Karine Dejean, Concepteur développeur
Florent Veslin, Buiness Analyst et Proxi Product Owner
Alexandra Canu, Responsable Communication France

Vous souhaitez échanger avec un expert ?

Contactez-nous