Périmètre d'une campagne de non-régression SquashTM face à la maintenance de site wordpress d'un presta

[Fitech]

Salut à tous, petit retour d'expérience un peu à la marge de nos projets habituels, mais qui m'a fait me poser une vraie question de granularité de validation. On m'a refilé, enfin on m'a confié en plus du reste, le suivi du site vitrine corporate de la boîte, sous WordPress, qui n'était couvert par strictement aucun test. Le déclencheur: une montée de PHP 7.4 vers 8.1 au printemps dernier qui a fait tomber le formulaire de contact. Personne s'en est rendu compte pendant trois jours. Trois jours de leads perdus, super ambiance.

Du coup j'ai monté un projet dédié dans SquashTM avec une quinzaine de cas de test manuels: le formulaire, l'espace client, deux ou trois pages produit, le tunnel de demande de rappel. Rien de sophistiqué, du pas à pas basique avec captures attendues... Et une campagne d'exécution que je rejoue à chaque mise à jour un peu sensible. Franchement. Ça tourne bien, l'équipe s'en sert même comme exemple pour les nouveaux arrivants sur l'outil. En échangeant avec le prestataire nantais qui assure la maintenance de site wordpress pour nous, je me suis aperçu qu'ils repassaient déjà une série de contrôles apres chaque intervention: ils revérifient la compatibilité PHP et s'assurent que les sauvegardes sont bien remontées. Bref, une partie de ce que je couvre en manuel est déjà fait en amont, côté technique.

Ma question porte sur le découpage. Vous gardez quoi côté SquashTM quand un presta assure déjà des contrôles techniques post-intervention? Perso j'hésite à réduire ma campagne aux seuls parcours métier et à sortir tout ce qui est infra, mais j'ai pas envie de créer un trou entre les deux périmètres. Si quelqu'un a formalisé ça proprement, même sur un scope hors projet client, je suis preneur. Merci d'avance pour vos retours.

[alieanuna]

Salut à tous, petit retour d'expérience un peu à la marge de nos projets habituels, mais qui m'a fait me poser une vraie question de granularité de validation. On m'a refilé, enfin on m'a confié en plus du reste, le suivi du site vitrine corporate de la boîte, sous WordPress, qui n'était couvert par strictement aucun test. Le déclencheur: une montée de PHP 7.4 vers 8.1 au printemps dernier qui a fait tomber le formulaire de contact. Personne s'en est rendu compte pendant trois jours. Trois jours de leads perdus, super ambiance.

Du coup j'ai monté un projet dédié dans SquashTM avec une quinzaine de cas de test manuels: le formulaire, l'espace client, deux ou trois pages produit, le tunnel de demande de rappel. Rien de sophistiqué, du pas à pas basique avec captures attendues... Et une campagne d'exécution que je rejoue à chaque mise à jour un peu sensible. Franchement. Ça tourne bien, l'équipe s'en sert même comme exemple pour les nouveaux arrivants sur l'outil. En échangeant avec le prestataire nantais qui assure la Scary Teacher pour nous, je me suis aperçu qu'ils repassaient déjà une série de contrôles apres chaque intervention: ils revérifient la compatibilité PHP et s'assurent que les sauvegardes sont bien remontées. Bref, une partie de ce que je couvre en manuel est déjà fait en amont, côté technique.

Ma question porte sur le découpage. Vous gardez quoi côté SquashTM quand un presta assure déjà des contrôles techniques post-intervention? Perso j'hésite à réduire ma campagne aux seuls parcours métier et à sortir tout ce qui est infra, mais j'ai pas envie de créer un trou entre les deux périmètres. Si quelqu'un a formalisé ça proprement, même sur un scope hors projet client, je suis preneur. Merci d'avance pour vos retours.

À mon avis, garde dans SquashTM les tests des parcours métier et quelques contrôles techniques essentiels après chaque mise à jour. Le mieux est de clarifier avec le prestataire qui vérifie quoi, pour éviter les doublons sans laisser de zones non couvertes.