Publicité
Publicité

Contenu connexe

Publicité

Méthodologie de tests et qualité

  1. MÉTHODES DE TESTS ET DE QUALITÉ Diane Sevin Rennes | 19.01.2022
  2. 2 SOMMAIRE En théorie : les bonnes pratiques tests et qualité Utilisation de l’agilité : un ensemble d’outils de productivité Cadre des tests et de la qualité : le besoin, la MOA, la MOE En pratique Agilité et qualité : un équilibre à trouver Qualité en pratique : la spécification par les tests Points d’attentions : limites, améliorations, difficultés, formalisation Conclusion : un exemple de bonnes pratiques
  3. 1 EN THÉORIE : LES BONNES PRATIQUES TESTS ET QUALITÉ • Utilisation de l’agilité • Cadre des tests et de la qualité
  4. UTILISATION DE L’AGILITÉ : UN ENSEMBLE D’OUTILS DE PRODUCTIVITÉ SCRUM Méthode agile la plus utilisée Définir des besoins simples orientés par l’utilisateur : les « User Stories » Le client est le principal pilote Principal avantage sa rapidité à avoir une première itération Le sprint au centre de la méthode Trois piliers fondamentaux : Transparence Inspection Adaptation Cadence temporelle des livraisons 4
  5. UTILISATION DE L’AGILITÉ : UN ENSEMBLE D’OUTILS DE PRODUCTIVITÉ KANBAN Méthode qui s’inspire de l’approche Lean S’adapter en permanence au client (« flux tirés » plutôt que « flux poussés ») Amélioration continue Visualisation des flux avec un tableau Priorisation des tâches Complémentaire à SCRUM Cadence fonctionnelle des livraisons 5
  6. UTILISATION DE L’AGILITÉ : UN ENSEMBLE D’OUTILS DE PRODUCTIVITÉ Azure DevOps De nombreux outils sur une même plateforme Différents types d’éléments utilisés lors d’un Sprint : Epic  famille de Features Feature  fonctionnalité, une famille d’US User Story  cas d’utilisation Task  tâche de développement Bug  anomalie de fonctionnement (technique/fonctionnelle) Permet d’utiliser complémentairement SCRUM et KANBAN 6
  7. CADRE DES TESTS ET DE LA QUALITÉ : LE BESOIN, LA MOA, LA MOE La MOA - La maîtrise d'ouvrage Entité organisatrice d'un projet Conduire la réalisation Pilotage Côté Client La MOE – La maîtrise d’oeuvre Entité de suivi du projet Assurer la bonne réalisation Concevoir et coordonner Côté Développement 7
  8. CADRE DES TESTS ET DE LA QUALITÉ : LE BESOIN, LA MOA, LA MOE La définition/expression du besoin Recueil des besoins autour d’un périmètre métier donné Le client exprime ses besoins métier, l’équipe de réalisation produit les solutions qui permettent d’y répondre La MOA doit exprimer clairement ses besoins de manière à ce qu’ils soient compris par la MOE Cette expression de besoin doit être faite par itérations en faisant intervenir la MOA et la MOE Une fois l’expression de besoin validée, la MOE considère l’implémentation de la solution en découpant les besoins sous la forme d’US C’est la MOA qui valide les besoins 8
  9. CADRE DES TESTS ET DE LA QUALITÉ : LE BESOIN, LA MOA, LA MOE Ce qui est important en plus du besoin, de la MOA et la MOE : La communication La clarté La transparence La gestion du temps 9
  10. 2 EN PRATIQUE • Agilité et qualité • Qualité en pratique • Cas concret • Points d’attentions
  11. AGILITÉ ET QUALITÉ : UN ÉQUILIBRE À TROUVER Le client souhaite livrer à intervalle régulier Le client souhaite de la qualité sur une fonctionnalité complète De nombreuses modifications de besoin au cours du sprint (très couteux) L’équipe de tests : difficulté à qualifier des fonctionnalités incomplètes Nombre de jours de tests insuffisants De nombreux outils restent très pratiques pour l’organisation US tâche cahier de tests Une validation du besoin importante Un dialogue à mettre en place La solution attendue Gain de performance Traçabilité … 11
  12. QUALITÉ EN PRATIQUE : LA SPÉCIFICATION PAR LES TESTS Les étapes clés de la spécification par les tests : Le recueil du besoin La modélisation du besoin dans un diagramme d’activités La formalisation du besoin sous forme d’US La déclinaison de chaque scénario dans un Test Case La constitution d’un Test Plan comprenant tous les Test Cases 12
  13. QUALITÉ EN PRATIQUE : LA SPÉCIFICATION PAR LES TESTS Diagramme d’activité La modélisation doit dégager : Les actions (expression du besoin) Les acteurs Les données/objets manipulés Leur type Leurs valeurs particulières (changement d’état) Le déclenchement des actions Les états des données/objets Les transitions d’un état à l’autre On doit pouvoir identifier les différents scénarios pour le Test Plan 13
  14. QUALITÉ EN PRATIQUE : LA SPÉCIFICATION PAR LES TESTS Point positifs : Gain de temps en rédigeant les spécification et les tests sur un seul support La collecte/validation du besoin modélisée par des diagrammes d’activités Un lien fort entre les activités du diagramme et les tâches assignés aux développeurs Un cahier de tests complets couvrant les scénarios identifiables dans les diagrammes 14
  15. QUALITÉ EN PRATIQUE : LA SPÉCIFICATION PAR LES TESTS EN QUALIFICATION PRODUCTION PREPROD. SUPERVISION MEP UAT ENVIRONNEMENT DEVELOPPEMENT VALIDATION CLIENT MER MEPP SPECIFICATIONS PRIORISATION, CADRAGE ET PLANNING REALISATION LIVRAISON - Définition du contenu d’une version - Définition des scénarios - Réalisation d’un diagramme (d’activité) - Chiffrage - Mise en place du RIDA 1 15 TESTS INTERNES 1 : Validation par le Client du périmètre MER : Mise En Recette MEPP : Mise En PréProduction MEP : Mise En Production
  16. QUALITÉ EN PRATIQUE : LA SPÉCIFICATION PAR LES TESTS 16 - Réalisation des US à partir du périmètre défini - Mise en place d’un Test Plan à partir du périmètre défini - Relecture des US par le chef de projet Client EN QUALIFICATION PRODUCTION PREPROD. SUPERVISION MEP UAT ENVIRONNEMENT DEVELOPPEMENT VALIDATION CLIENT MER MEPP SPECIFICATIONS PRIORISATION, CADRAGE ET PLANNING REALISATION LIVRAISON 1 TESTS INTERNES 2 - Définition du contenu d’une version - Définition des scénarios - Réalisation d’un diagramme (d’activité) - Chiffrage - Mise en place du RIDA 1 : Validation par le Client du périmètre 2 : Validation par le Client des US et des tests MER : Mise En Recette MEPP : Mise En PréProduction MEP : Mise En Production
  17. QUALITÉ EN PRATIQUE : LA SPÉCIFICATION PAR LES TESTS 17 EN QUALIFICATION PRODUCTION PREPROD. SUPERVISION MEP UAT ENVIRONNEMENT DEVELOPPEMENT VALIDATION CLIENT MER MEPP SPECIFICATIONS PRIORISATION, CADRAGE ET PLANNING REALISATION LIVRAISON 1 TESTS INTERNES 2 - Développement des US - Tests internes en utilisant les Test Cases - Réalisation de tests croisés - Durée dépendant de la complexité du périmètre 3 - Réalisation des US à partir du périmètre défini - Mise en place d’un Test Plan à partir du périmètre défini - Relecture des US par le chef de projet Client - Définition du contenu d’une version - Définition des scénarios - Réalisation d’un diagramme (d’activité) - Chiffrage - Mise en place du RIDA 1 : Validation par le Client du périmètre 2 : Validation par le Client des US et des tests 3 : Validation par le Client du développement du périmètre MER : Mise En Recette MEPP : Mise En PréProduction MEP : Mise En Production
  18. QUALITÉ EN PRATIQUE : LA SPÉCIFICATION PAR LES TESTS 18 EN QUALIFICATION PRODUCTION PREPROD. SUPERVISION MEP UAT ENVIRONNEMENT DEVELOPPEMENT VALIDATION CLIENT MER MEPP SPECIFICATIONS PRIORISATION, CADRAGE ET PLANNING REALISATION LIVRAISON 1 TESTS INTERNES 2 - Développement des US - Tests internes en utilisant les Test Cases - Réalisation de tests croisés - Durée dépendant de la complexité du périmètre 3 - Validation de la livraison par rapport à la définition du périmètre réalisé au début du lot - Réalisation des US à partir du périmètre défini - Mise en place d’un Test Plan à partir du périmètre défini - Relecture des US par le chef de projet Client - Définition du contenu d’une version - Définition des scénarios - Réalisation d’un diagramme (d’activité) - Chiffrage - Mise en place du RIDA 1 : Validation par le Client du périmètre 2 : Validation par le Client des US et des tests 3 : Validation par le Client du développement du périmètre MER : Mise En Recette MEPP : Mise En PréProduction MEP : Mise En Production
  19. QUALITÉ EN PRATIQUE : LA SPÉCIFICATION PAR LES TESTS 19 1 : Validation par le Client du périmètre 2 : Validation par le Client des US et des tests 3 : Validation par le Client du développement du périmètre MER : Mise En Recette MEPP : Mise En PréProduction MEP : Mise En Production EN QUALIFICATION PRODUCTION PREPROD. SUPERVISION MEP UAT ENVIRONNEMENT DEVELOPPEMENT VALIDATION CLIENT MER MEPP SPECIFICATIONS PRIORISATION, CADRAGE ET PLANNING REALISATION LIVRAISON 1 TESTS INTERNES 2 - Développement des US - Tests internes en utilisant les Test Cases - Réalisation de tests croisés - Durée dépendant de la complexité du périmètre 3 - Validation de la livraison par rapport à la définition du périmètre réalisé au début du lot - Réalisation des US à partir du périmètre défini - Mise en place d’un Test Plan à partir du périmètre défini - Relecture des US par le chef de projet Client - Définition du contenu d’une version - Définition des scénarios - Réalisation d’un diagramme (d’activité) - Chiffrage - Mise en place du RIDA Si remise en question de la validation, on reprend au début  impact sur les charges
  20. QUALITÉ EN PRATIQUE : LA SPÉCIFICATION PAR LES TESTS 20
  21. POINTS D’ATTENTIONS : LIMITES, AMÉLIORATIONS, DIFFICULTÉS, FORMALISATION La gestion du temps Les sujets techniques demandent un niveau de détail supplémentaire Les Diagrammes de séquences Une personne dédié pour la réalisation de la spécification : Les Diagrammes (activités – séquences) Le Test Plan avec les Tests Cases Exécution du test plan à répartir aux testeurs Attention à essayer de formaliser les tests d’installation, de rollback et d’exploitation Les tests cases doivent être bien compréhensible Méthode beaucoup moins agile à mettre en place en parallèle 21
  22. 3 CONCLUSION : UN EXEMPLE DE BONNES PRATIQUES • Un besoin • Une méthode • Un dialogue • Un compromis
  23. Rennes 35 Boulevard Solférino 35000 Rennes Paris 350 rue de Vaugirard 75015 Paris Nantes 9 rue Nina Simone 44000 Nantes + 33 2 30 96 21 60 www.spikeelabs.fr Diane Sevin Avez-vous des questions ?

Notes de l'éditeur

  1. La transparence. Elle vise à faire en sorte que les parties prenantes (équipe projets, management et utilisateurs) partagent un langage commun et bénéficient de toutes les informations nécessaires à la compréhension du projet. L'inspection. Elle a pour but de vérifier, via des évaluations régulières, que le développement est toujours en phase avec les demandes du client et qu'il ne dévie pas par rapport à ces dernières. L'adaptation. Un concept qui porte bien son nom. Son objectif ? Corriger la trajectoire du projet si des écarts avec les résultats à atteindre sont détectés lors de la phase d'inspection.
  2. Sprint/Scrum : cadence temporelle des livraisons), une US peut être présente plusieurs versions Kanban : cadence fonctionnelle des livraisons), une Feature et donc une US, est rattachée à une seule version -> scrum pour le système de sprint -> kanban pour les task qui ont des états
  3. Les actions issues de l’expression de besoin Les acteurs intervenants sur l’application (exemple : OI, OC, système, …) Les données ou les objets manipulés dans l’application Leur type (fichier, JSON par API, données en sessions, …) Leurs valeurs particulières pour passer d’un état à l’autre Le déclenchement des actions (tâches planifiées, interventions humaines) Les états des données ou des objets suite à une action Les transitions d’un état d’une donnée ou d’un objet à l’autre
  4. Ligne de vie du projet : Recueil du besoin et modélisation
  5. Ligne de vie du projet : Formalisation du besoin et Test Plan
  6. Ligne de vie du projet : Développements et tests internes
  7. Ligne de vie du projet : Validation client après livraison
  8. Ligne de vie du projet : Process de modification du périmètre
  9. Ça prend du temps mais du temps qui n’ets pas forcément perdu aussi il faut qu’il soit optimisé Les sujets techniques demandent un niveau de détail supplémentaire Utilisation des diagrammes de séquences ? Il faut avoir quelqu’un de dédié pour la réalisation du diagramme et des tests case mais l’exécution du test plan va aux testeurs et peut être réparti -> pas de répartition possible trop pour la phase modélisation Les tests cases doivent être bien compréhensible Attention à essayer de formaliser les tests d’installation, de rollback et d’exploitation Méthode beaucoup moins agile à mettre en place en parallèle
Publicité