Diane, ingénieure chez SpikeeLabs, a eu l’occasion de travailler sur l’amélioration des process d’un projet important en termes d’équipes engagées.
En se basant sur ce projet, Diane nous propose ici un retour d’expérience focalisé sur la méthodologie de tests et de la qualité plus globalement.
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
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 ?
Editor's Notes
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.
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
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
Ligne de vie du projet : Recueil du besoin et modélisation
Ligne de vie du projet : Formalisation du besoin et Test Plan
Ligne de vie du projet : Développements et tests internes
Ligne de vie du projet : Validation client après livraison
Ligne de vie du projet : Process de modification du périmètre
Ç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