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.
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 |
|
Tests sprint |
Tests scrum |
|
Tests fonctionnels |
De bout en bout |
|
Tests fonctionnels |
Recette utilisateur (UAT) |
|
Tests de version |
Performance et sécurité |
|
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 :
- Créez un tableau à six colonnes afin de pouvoir identifier facilement et tester pleinement l’ensemble de vos microjourneys.
- Dans la première colonne, indiquez vos microjourneys, par exemple « Obtenir un prêt immobilier ».
- Dans la colonne suivante, précisez les sous-dossiers, les composants de base de Pega, de chacun de ces microjourneys.
- 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.
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.
Want to help us improve this content?