Oracle Fusion : faire de la non-régression une capacité durable.
Les mises à jour récurrentes demandent une organisation de test réutilisable, centrée sur les parcours métier et leurs points de rupture.
Publié le · À propos des dates
Mis à jour le
Le point de vue Spark
Une campagne de non-régression utile permet de savoir quels usages restent opérationnels après un changement. Son patrimoine de scénarios doit être entretenu entre les campagnes : données, accès, résultats attendus et responsables font partie du test.
- Partir des parcours métier et des changements applicables.
- Vérifier les prérequis avant de mobiliser les testeurs.
- Automatiser les contrôles stables et conserver une analyse des échecs.
1. Partir du calendrier réel et du périmètre de changement
Oracle documente les mises à jour trimestrielles obligatoires de Fusion Applications et les cadences de maintenance des environnements. La préparation doit partir du calendrier applicable à votre environnement et à vos services, plutôt que d’une hypothèse générique de délai. Consulter les principes de maintenance Oracle.
Le portail Oracle Cloud Applications Readiness permet de consulter les informations de préparation aux évolutions par produit. Nous recommandons d’en faire une entrée de l’analyse d’impact, à rapprocher de vos fonctionnalités utilisées, paramétrages, extensions et interfaces.
La liste des nouveautés ne suffit pas à décrire votre campagne. Certains parcours critiques doivent être contrôlés même s’ils ne sont pas identifiés comme une nouveauté. À l’inverse, une évolution sans rapport avec votre périmètre n’a pas nécessairement la même priorité.
2. Décrire un parcours avec son résultat attendu
« Ouvrir l’écran » ou « créer une transaction » peut être une étape du test, mais ne décrit pas toujours le résultat métier. Un parcours peut inclure une approbation, une comptabilisation, un échange et un contrôle dans le système destinataire.
| Élément | Question à documenter |
|---|---|
| Usage et priorité | Quelle opération protège-t-on et quel serait l’impact d’un échec ? |
| Données et accès | Quels objets, rôles et états initiaux sont nécessaires ? |
| Étapes | Qui exécute quoi, dans quel ordre ? |
| Résultat | Que doit-on constater pour conclure ? |
| Preuve et reprise | Que conserve-t-on et comment rejouer le test ? |
Une attente précise évite deux écueils : déclarer un test réussi parce qu’aucune erreur n’apparaît, ou déclarer un défaut parce que le testeur ne connaît pas la règle applicable. Le responsable fonctionnel doit pouvoir confirmer l’attendu.
3. Exemple : la transaction passe, mais le parcours reste incomplet
Le scénario illustre une question de couverture, pas une défaillance particulière d’Oracle. Les mêmes précautions s’appliquent aux droits, aux interfaces et aux contrôles construits autour du système.
4. Automatiser sans déplacer l’incertitude
Nous recommandons de sélectionner les scénarios à automatiser selon leur répétitivité, leur stabilité, leur criticité et le coût de leur entretien. Le nombre de scripts est un indicateur d’activité ; il ne suffit pas à mesurer la couverture des usages.
Avant d’automatiser, il faut pouvoir décrire l’attendu et préparer les données. Un script qui reproduit une procédure ambiguë rend l’ambiguïté plus rapide à exécuter. Une automatisation utile doit aussi permettre de distinguer un problème applicatif d’un défaut d’accès, de données ou d’environnement.
- Prévoir la préparation et la remise en état des données de test.
- Conserver une preuve lisible du résultat et de l’étape en échec.
- Attribuer la maintenance du scénario lorsque le processus évolue.
- Compléter les contrôles automatisés par l’examen des changements pertinents.
Le résultat global doit séparer les tests réussis, échoués, bloqués et non exécutés. Regrouper les deux dernières catégories avec les réussites donnerait une image trompeuse du travail réellement effectué.
5. Clore la campagne avec une décision exploitable
- Couverture : quels parcours ont réellement été exécutés ?
- Écarts : quels résultats diffèrent de l’attendu confirmé ?
- Impact : quels utilisateurs et opérations sont concernés ?
- Traitement : qui analyse, corrige ou escalade chaque anomalie ?
- Réserves : quelles limites restent ouvertes et qui en prend connaissance ?
- Capitalisation : quels scénarios, données et prérequis faut-il mettre à jour ?
Cette conclusion sert à organiser les actions restantes et à informer les responsables concernés. Elle ne constitue pas une garantie d’absence de régression et ne signifie pas que le client peut librement reporter une maintenance Oracle.
Entre deux campagnes, un parcours ajouté ou modifié doit rejoindre le patrimoine de tests avec son responsable. C’est cet entretien qui rend la non-régression réutilisable, au-delà de la mobilisation ponctuelle des testeurs.
Sources et périmètre
Les références Oracle étayent le fonctionnement de la maintenance et l’accès aux informations produit. La fiche de test, les critères d’automatisation et le scénario sont des propositions éditoriales Spark, sans résultat client revendiqué.
