Skip to main content

Test du caractère « lovable »

Définition des tests du caractère « lovable »

La stratégie de test Pega Express est conçue et exécutée durant la phase Build. Les tests sont importants, car ils permettent de confirmer que la solution Pega Platform est non seulement fonctionnelle mais aussi appréciée par le client, « lovable ». 

Pour ce faire, la stratégie de test a recours aux méthodes suivantes :

  • Shifting left – Commencez à effectuer des tests le plus tôt possible au cours du cycle de vie du projet et faites de ces tests un composant essentiel de chaque sprint.
  • Tests utilisateurs – Impliquez les utilisateurs métier plus tôt dans le projet et recueillez leur feedback, ainsi que celui de testeurs professionnels. Notez que nous ne parlons pas ici de recette utilisateur (UAT, User Acceptance Testing).
  • Planification – Créez un plan de test pour vous assurer que l’application répond aux attentes métier, pas seulement à des critères fonctionnels.
  • Cohérence – Convenez d’une Definition of Done (DoD).
  • Outils – Utilisez des outils de validation intégrés, comme l’Application Quality Dashboard ou Pega Predictive Diagnostic Cloud.
  • Automatisation – Construisez une suite de tests automatisés avec Pega Platform ou des outils tiers.
Note: La réalisation de tests est essentielle pour la réussite du projet ; elle permet de s’assurer que la solution Pega est à la fois lovable et de qualité. Contrairement aux projets informatiques traditionnels qui n’effectuent des tests qu’en fin de projet, la stratégie Pega Express consiste à tester les activités durant la phase Préparation (ou Découverte) et à continuer pendant toute la durée du projet.

Visionnez la courte vidéo pour en savoir un peu plus sur les tests avec Pega Express.

Shifting left

Shifting left signifie que vous démarrez les activités de test plus tôt au cours du cycle de vie du projet. DevOps fait appel à cette méthode aux fins du développement logiciel pour aider les équipes à mettre l’accent sur la qualité, sur la prévention des problèmes plutôt que leur détection, et à démarrer les tests en phase précoce. Il planifie et valide la qualité de votre application dès le premier jour.

Comme l’illustre l’image suivante, la méthodologie Pega Express prévoit diverses activités de test et de validation en amont du projet. Cette méthode consistant à tester tôt, souvent et de façon continue est centrale à Pega Express. Elle est rendue possible par un processus officiel et un ensemble d’outils intégrés visant à promouvoir des contrôles de la qualité dans chaque sprint et tout du long du cycle de vie complet du projet.

Shift Left

Shifting left est simple avec Pega Express ; il suffit de procéder comme suit (remarque : cette approche doit permettre de mieux identifier les problèmes lors des tests de sprint pour réduire leur fréquence à mesure que la phase de tests de version approche) :

 

Objet des tests

Type de test

Bonne pratique Shift Left

Tests de sprint

Tests unitaires

  • Utilisation de Pega Diagnostic Cloud pour résoudre les problèmes
  • Utilisation des seuils (guardrails)
  • Test d'utilisabilité lean sur les prototypes XD durant la phase Préparation
  • Les outils de Pega permettent de s’assurer que vous vous concentrez uniquement sur le MLP
  • Focus uniquement sur ce qui a changé
  • Adhésion obligatoire à la Definition of Done
  • Automatisation des tests avec Pega Unit

Tests sprint

Tests scrum

  • Réalisation de tests le plus tôt possible sur des interfaces réelles pour éviter les problèmes
  • Implication des parties prenantes métier pour assurer la validation précoce
  • Automatisation avec Pega API et Pega Scenario

Tests fonctionnels

De bout en bout

  • Déploiement avec DevOps et utilisation des tests de non-régression automatisés
  • Plan de test Pega Express pour stimuler les efforts et cibler

Tests fonctionnels

Recette utilisateur (UAT)

  • Déploiement avec DevOps et utilisation de smoke tests automatisés

Tests de version

Performance et sécurité

  • Utilisation de Deployment Manager

Plus les anomalies sont détectées tôt, plus il est facile et moins il est onéreux d’y remédier. Le moins cher est de corriger un problème en phase Découverte ou Préparation. Le plus onéreux est de corriger une anomalie à la phase d’assurance-qualité post-build ou lors des tests d’acceptation, comme c’était autrefois le cas dans les projets en cascade. C’est pourquoi Pega Express recommande de valider et tester la solution le plus tôt possible.

Activités de test à la phase Préparation

Votre stratégie de test commence à prendre forme durant la phase Préparation. Avant qu’une seule ligne de code ne soit écrite, les business architects et les testeurs valident les résultats métier, la portée et la conception avec le client. Tandis que les business architects créent les user stories, les testeurs confirment que chaque user story est claire, concise, exploitable et contient des critères d’acceptation.

Toutes les user stories doivent comporter des critères d’acceptation.

Les critères d’acceptation complètent la description d’une user story. Ils précisent les conditions qui doivent être respectées pour que la story soit terminée. Les critères d’acceptation enrichissent la story, la rendent testable et permettent qu’elle soit validée, démontrée ou lancée auprès des utilisateurs et autres parties prenantes.

Des critères d’acceptation bien conçus doivent présenter les caractéristiques suivantes :

  • Testables, avec des résultats attendus clairement définis
  • Clairs et concis, sans ambiguïté
Tip: Une bonne pratique Pega Express consiste à créer trois à cinq critères d’acceptation pour les stories détaillées.

Création et respect d’une Definition of Done

En plus de créer des critères d’acceptation individuels pour chaque user story, l’équipe Scrum crée une Definition of Done (DoD) officielle, qui identifie des critères d’acceptation cohérents requis dans toutes les user stories. Une DoD permet de s’assurer de la qualité du travail. Elle recense ce qui doit être fait pour que le travail de développement de la user story soit considéré comme terminé.

La Definition of Done (DoD) permet de s’assurer que chaque membre de l’équipe sait exactement ce qui est attendu de chaque composant livré par l’équipe. La DoD est un gage de transparence. Elle permet de s’assurer que la qualité répond aux attentes produit et aux besoins de l’entreprise.

La DoD comprend généralement les éléments suivants :

  • Une fonctionnalité qui est développée, fait l’objet de tests unitaires et répond aux critères d’acceptation.
  • Des scripts de tests unitaires créés dans l’application PegaUnit et disponibles à des fins de tests de régression ultérieurs
  • Un élément est prêt à être soumis aux tests d’acceptation
  • N’importe quel code qui est examiné
  • Un élément pouvant être livré
  • Pas de hausse de la dette technique

Vous pouvez télécharger un modèle Definition of Done sur la page Ressources Pega Express Delivery.

Microjourneys et résultats métier

Une question revient toujours : comment organiser les tests pour qu’ils soient efficaces et nous permettent de nous assurer que nous répondons aux attentes métier du client et leur proposons aussi un produit qu’il appréciera ?

Pega a mis au point un plan de test simple qui permet d’atteindre ces objectifs tout en suivant une approche centrée sur le Microjourney™. Ce plan permet à la fois de s’assurer que la couverture des tests est complète et de générer des rapports d’état des tests en termes de résultats métier plutôt que d’éléments fonctionnels disparates et de statistiques de couverture génériques.

Le plan de test assure au client que ses microjourneys fonctionnent comme prévu et que le produit final est lovable et répond à ses attentes métier.

Création du plan de test

La création d’un plan de test Pega Express est très simple. Pour commencer :

  1. Créez un tableau à six colonnes afin de pouvoir identifier facilement et tester pleinement l’ensemble de vos microjourneys.
  2. Dans la première colonne, indiquez vos microjourneys, par exemple « Obtenir un prêt immobilier ».
  3. Dans la colonne suivante, précisez les sous-dossiers, les composants de base de Pega, de chacun de ces microjourneys.
  4. Dans les colonnes suivantes, allez plus loin dans le détail en inscrivant les phases, personas, canaux et interfaces de chaque microjourney.

Une fois que vous aurez terminé, vous disposerez d’un tableau pour chaque microjourney, comme l’illustre l’exemple suivant. Chaque ligne du tableau représente un chemin à tester dans le microjourney, ce qui garantit que tous ses résultats sont testés.

Pega Express Test Plan
Note: L’un des avantages de cette approche est qu’elle illustre la santé de l’application dans des termes que les parties prenantes métier comprennent. Plutôt que de rendre compte des fonctionnalités, le plan rend compte de microjourneys client spécifiques et des résultats métier. Il montre quelles portions du parcours ont subi des tests, lesquelles ont réussi et lesquelles ont échoué. Les parties prenantes métier voient ce qui fonctionne et ce qui ne fonctionne pas, car la formulation et le format de ces rapports leur parleront.

Outils de validation et tests automatisés

L’automatisation a pour objectif de favoriser la qualité et la reproductibilité. Le System Architect n’a pas terminé son travail tant qu’il n’en a pas testé chaque unité et créé un script de test PegaUnit.

Outils de validation intégrés

Pega Platform comprend plusieurs outils de validation intégrés et tableaux de bord qui fournissent une vue globale de la santé de l’application, comme l’Application Quality Dashboard, qui concerne la santé de l’application, et Pega Predictive Diagnostic Cloud (PDC), qui présente un aperçu de la santé du service cloud.

Tip: N’oubliez pas de consulter l’Application Quality Dashboard et le PDC au minimum une fois par sprint.

Créez votre pyramide de test automatisée à l’aide des outils intégrés de Pega ou d’outils tiers.

La plateforme Pega dispose d’outils natifs qui prennent en charge les composants de la pyramide de tests. Vous pouvez également utiliser des outils standard du secteur. Toutefois, dans le cadre du test d’une application Pega, les outils Pega constituent généralement la meilleure option.

Dans l’image suivante, cliquez sur les icônes + pour en savoir plus sur la pyramide de test.

Checklist pour réussir

  • Démarrer les activités de test et inclure les ressources de test dès le début du projet
  • S’assurer que toutes les user stories comportent des critères d’acceptation
  • Créer et respecter une DoD
  • Créer un plan de test pour se concentrer sur les microjourneys et les résultats métier
  • Utiliser des outils de validation intégrés
  • Automatiser les tests

Pour en savoir plus sur les tests unitaires et comment utiliser PegaUnit, reportez-vous au module Règles de test unitaire de Pega Academy.

Vérifiez vos connaissances avec l’interaction suivante.


This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice