Version en ligne + QUIZ OFFERTE ! pendant 1 an Le test Le ...€¦ · d’une équipe pour...

45 €

isbn

: 978

-2-4

09-0

1943

-2 Le te

st e

n m

ode

Agi

le

Le test en mode Agile L’Agilité dans les projets se généralise et le testeur comprend vite qu’il faut penser le test différemment pour que les mises en production du pro-duit puissent se faire régulièrement à un rythme parfois soutenu. Dans ce livre, l’auteur donne au lecteur, au travers de nombreux exemples, anecdotes, réfé-rences bibliographiques et illustrations, les connaissances fondamentales pour appréhender l’état d’esprit du test agile et les pratiques du test qui en découlent.

Chaque chapitre, même le plus technique, intéressera autant le DSI dans son virage vers l’Agilité, que le testeur qui ressent le besoin de s’adapter à ce nouveau mode de développement ou encore les développeurs ou autres membres d’une équipe Agile qui doivent s’adapter pour fournir un logiciel de qualité.

Après quelques rappels sur l’agilité et sur les principes et techniques du test, un chapitre est entièrement consacré à l’état d’esprit du test agile. Puis, au fil des pages, l’auteur met l’accent sur l’importance de la connaissance du métier et de la connaissance technique pour réaliser des tests en mode agile. Le lecteur est également amené à étudier la problématique de ce qui est produit par les tests (anomalies et rapports des sessions de test) ainsi que la notion de tests non fonctionnels.

Pour finir, comme il est souvent nécessaire d’adapter l’organisation complète d’une équipe pour faciliter le test agile, un chapitre montre quels sont les facteurs qui permettent une amélioration plus profonde du test au travers de l’organisation autour du projet.

Christophe MOUSTIER débute son voyage dans le monde du développement logiciel dans les années 1980 et transforme ensuite sa passion en une profession, d’abord comme développeur certifié Java puis comme chef de projet. Il commence à travailler avec les méthodes agiles dans une startup dès 2001 avec l’Extreme Pro-gramming et, depuis 2006, il s’intéresse plus particulièrement à la problématique du test. Aujourd’hui expert dans le do-maine du test logiciel, il intervient dans de nombreuses entreprises pour les aider à changer leur vision du test et du rôle de chacun dans cette activité du développe-ment logiciel.

Pour plus d’informations :

Le test en mode Agile Christophe MOUSTIER

+ QUIZ

Version en ligne

OFFERTE !pendant 1 an

1Table des matières

Avant-propos1. Une transformation digitale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2. Pourquoi ce livre ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3. À qui est destiné ce livre ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1 Cas n°1 - C’était mieux avant ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Cas n°2 - Comment puis-je améliorer mon agilité dans mes tests ? . . 153.3 Cas n°3 - Mon équipe veut passer au DevOps,

quels sont mes besoins de tests ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4 Cas n°4 - Je suis dans une équipe agile en « Fast IT »

et tout le monde code et teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4. Comment lire ce livre ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5. Qui suis-je ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Chapitre 1Quelques rappels

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2. Les 4 valeurs de l’agile - Rappel du Manifeste Agile . . . . . . . . . . . . . . . . . . . 22

3. Les 7 principes du test - Rappel ISTQB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.1 Les tests montrent la présence de défauts. . . . . . . . . . . . . . . . . . . . . . . 233.2 Les tests exhaustifs sont impossibles . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Tester tôt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4 Regroupement des défauts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5 Paradoxe du pesticide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.6 Les tests dépendent du contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.7 Illusion de l’absence de défaut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4. Techniques de test de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.1 Partitionnement de classes d’équivalences et valeurs limites . . . . . . . 294.2 Heuristique CORRECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3 Table de décision. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3.1 Approche analytique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3.2 Heuristique - Test n-wise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4 Transitions d’états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

lcroise

Tampon

2 Le test en mode Agile

5. Le Cycle de vie logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.1 Projet à l’échelle d’une seule équipe SCRUM . . . . . . . . . . . . . . . . . . . . 39

5.1.1 Scrum en quelques lignes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.1.2 Sprint Refinement Meeting (grooming). . . . . . . . . . . . . . . . . . . 425.1.3 Sprint planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.1.4 Daily Scrum Meeting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.1.5 Sprint Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.1.6 Rétrospective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.1.7 Réflexions sur les rétrospectives . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2 Projet à l’échelle de plusieurs équipes . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2.1 Cas de frameworks agiles existants . . . . . . . . . . . . . . . . . . . . . . 665.2.2 Point de vue du modèle SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.2.3 Point de vue du modèle Spotify . . . . . . . . . . . . . . . . . . . . . . . . . 725.2.4 Point de vue Less . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 765.2.5 Point de vue DAD - « Disciplined Agile Delivery ». . . . . . . . . . . 795.2.6 Point de vue Scrum@Scale - S@S. . . . . . . . . . . . . . . . . . . . . . . . 82

5.3 Approche Composant vs Fonctionnalité. . . . . . . . . . . . . . . . . . . . . . . . 84

Chapitre 2L’état d’esprit

1. Introduction - Exemple de l’industrie du textile . . . . . . . . . . . . . . . . . . . . . . 911.1 Contrôle des ballots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931.2 Contrôle pendant le tissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 931.3 Amélioration du procédé de tissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 941.4 Le test agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

2. État d’esprit Lean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952.1 Le Lean, les origines de l’agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952.2 Quelques pratiques Lean utiles au test . . . . . . . . . . . . . . . . . . . . . . . . . 96

2.2.1 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972.2.2 Juste à Temps - « Just in time » . . . . . . . . . . . . . . . . . . . . . . . . . . 972.2.3 5S. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 982.2.4 Intégrer la qualité dès la conception . . . . . . . . . . . . . . . . . . . . . . 992.2.5 Le First Pass Yield : faire bon du 1er coup ! . . . . . . . . . . . . . . . 1002.2.6 Analyse de cause racine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002.2.7 Petits stocks, régularité des flux . . . . . . . . . . . . . . . . . . . . . . . . 109


2.3 Manifeste du test agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1092.3.1 Tester pendant le sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102.3.2 Prévenir les bugs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1112.3.3 Comprendre ce que l’on doit tester . . . . . . . . . . . . . . . . . . . . . 1132.3.4 Concevoir un meilleur système . . . . . . . . . . . . . . . . . . . . . . . . 1142.3.5 L’équipe est responsable de la qualité du produit . . . . . . . . . . 114

Chapitre 3Versant métier

1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

2. Définition du Prêt (DoR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

3. Clarté d’une US . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

4. Test des US . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304.1 Ingénierie des critères d’acceptation des US . . . . . . . . . . . . . . . . . . . . 130

4.1.1 Définition du Terminé (DoD) . . . . . . . . . . . . . . . . . . . . . . . . . 1314.1.2 BDD, Gherkin et ATDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

4.2 Préparation de la revue d’US ou d’Epic . . . . . . . . . . . . . . . . . . . . . . . . 1414.3 Revue de définition des US . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

4.3.1 Affinement des US . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1424.3.2 Approche « Los Très Amigos ». . . . . . . . . . . . . . . . . . . . . . . . . . 1434.3.3 Visite guidée. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

4.4 Revue de réalisation de l'US . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

5. Le Produit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

6. La valeur métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496.1 Modèle MoSCoW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496.2 Diagramme de Kano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1496.3 Priorisations complexes (Weighted Shortest Job First - WSJF) . . . . . 152

7. Production des spécifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1537.1 Cas des exigences et spécifications . . . . . . . . . . . . . . . . . . . . . . . . . . . 1537.2 Cas des US. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

7.2.1 Le rôle de chacun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1547.2.2 Le récit utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155


7.3 Cas des Epics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1577.3.1 Les Features - les Fonctionnalités . . . . . . . . . . . . . . . . . . . . . . . 1587.3.2 Les Capabilities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1607.3.3 Les Epics du Portfolio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Chapitre 4Versant industriel du test

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

2. Stratégie de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1632.1 Vision académique de la stratégie de test . . . . . . . . . . . . . . . . . . . . . . 1632.2 Catégories d’approches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1662.3 Tester tôt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1692.4 Approche par le risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

2.4.1 Caractérisation du niveau de risque . . . . . . . . . . . . . . . . . . . . . 1712.4.2 Principe du Risk-Based Testing - RBT . . . . . . . . . . . . . . . . . . . 1742.4.3 Granularité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762.4.4 Niveau « données de tests » . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762.4.5 Niveau « scénarios de tests » . . . . . . . . . . . . . . . . . . . . . . . . . . . 1762.4.6 Niveau « exigence de tests ». . . . . . . . . . . . . . . . . . . . . . . . . . . . 1772.4.7 Niveau « campagnes de tests ». . . . . . . . . . . . . . . . . . . . . . . . . . 1772.4.8 Exemple de gestion des campagnes de tests de régression . . . 1792.4.9 Périmètre vs Qualité et objectifs de test . . . . . . . . . . . . . . . . . . 180

2.5 Heuristique pour une stratégie de test . . . . . . . . . . . . . . . . . . . . . . . . 1822.6 Context-Driven Testing (CDT) - Test Piloté par le Contexte. . . . . . 186

2.6.1 Valeur d’une pratique dépendante du contexte. . . . . . . . . . . . 1872.6.2 Les Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1882.6.3 Les gens qui travaillent ensemble . . . . . . . . . . . . . . . . . . . . . . . 1882.6.4 Prédictibilité des projets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1892.6.5 Résolution du problème. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1892.6.6 Le challenge intellectuel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1892.6.7 Esprit critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

3. Tests systèmes et bout-en-bout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1893.1 Organisation des tests scénarisés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1903.2 Ingénierie des Tests systèmes/bout-en-bout. . . . . . . . . . . . . . . . . . . . 191


3.3 Campagne de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1923.3.1 Planification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1933.3.2 Monitoring et Contrôle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1943.3.3 Clôture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

3.4 Tests de régression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1953.4.1 Smoke tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1953.4.2 Campagnes prédéfinies par le risque . . . . . . . . . . . . . . . . . . . . 1963.4.3 Campagnes prédéfinies par thème . . . . . . . . . . . . . . . . . . . . . . 1983.4.4 Check-list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

4. Tests exploratoires. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2004.1 Préparation des tests exploratoires . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

4.1.1 La charte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2024.1.2 La zone de recherche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2024.1.3 L’état d’esprit - Technique de la Persona . . . . . . . . . . . . . . . . . 2034.1.4 Les moyens d’une session de TE . . . . . . . . . . . . . . . . . . . . . . . . 2064.1.5 Session de TE avec Intervenants Externes . . . . . . . . . . . . . . . . 206

4.2 Session de Test exploratoire. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2084.3 Fin de Session de Test exploratoire . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

5. Ingénierie des Tests de recette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2105.1 Préparation de la recette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2105.2 Cas des certifications et des tests réglementaires . . . . . . . . . . . . . . . . 211

6. Stratégies de gestion des anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2146.1 Loi de Pareto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2146.2 Taxonomie des erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

6.2.1 Quelques chiffres de l’industrie . . . . . . . . . . . . . . . . . . . . . . . . 2156.2.2 Bugs ou parasites ?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2166.2.3 Quels types de bugs ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

6.3 La dette technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2196.3.1 Mesurer la dette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2206.3.2 Attitudes face à la dette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

7. Rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

8. Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2318.1 Généralités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2318.2 Contenu d’un rapport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231


9. Stratégies Données et Environnements de tests . . . . . . . . . . . . . . . . . . . . . 2329.1 Clonage des données de production. . . . . . . . . . . . . . . . . . . . . . . . . . . 2339.2 Gestion des données de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

9.2.1 Génération des données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2339.2.2 Optimisation des tests par les valeurs . . . . . . . . . . . . . . . . . . . 2349.2.3 Génération aléatoire des valeurs nominales . . . . . . . . . . . . . . . 2359.2.4 Approche combinatoire aléatoire . . . . . . . . . . . . . . . . . . . . . . . 2369.2.5 Generative Adversarial Network - GAN. . . . . . . . . . . . . . . . . . 2369.2.6 Minimisation des données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2379.2.7 Anonymisation des données . . . . . . . . . . . . . . . . . . . . . . . . . . . 2389.2.8 Cas des données sujettes à la péremption . . . . . . . . . . . . . . . . 2399.2.9 Dictionnaire de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2399.2.10 Isolation des données. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2409.2.11 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

9.3 Reprise de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

Chapitre 5Tests non fonctionnels

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

2. Tests de sécurité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2482.1 Généralités sur les tests de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . 2492.2 Orientations en termes de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . 2512.3 Principes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

2.3.1 Séparation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2532.3.2 Contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2542.3.3 Étapes pour définir un test de sécurité . . . . . . . . . . . . . . . . . . . 2542.3.4 Technique de tests pour les OpSec . . . . . . . . . . . . . . . . . . . . . . 2572.3.5 Types d’anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2622.3.6 Activités à contrôler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

2.4 Organisation des tests de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2682.4.1 Modèle par jalons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2692.4.2 Correspondance entre sécurité et activités compatibles agile . 2692.4.3 Vision SEAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2702.4.4 Approche par le risque . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2702.4.5 Modèle Microsoft SDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272


2.4.6 Modèle PASTA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2732.4.7 Vision Coveros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2742.4.8 Security Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

2.5 Quelques techniques de tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2772.5.1 Analyse de sécurité pour les exigences . . . . . . . . . . . . . . . . . . . 2772.5.2 Analyse de failles de sécurité sur le design et le code . . . . . . . 2842.5.3 Tests de pénétration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2982.5.4 Détection d’intrusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3052.5.5 Intégration de la sécurité dans une approche DevOps . . . . . . 3092.5.6 Analyse de patch & applications sur la production. . . . . . . . . 310

3. Tests d’utilisabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3113.1 Le test du Magicien d’Oz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3123.2 L’Experience Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3123.3 Retours des utilisateurs en production . . . . . . . . . . . . . . . . . . . . . . . . 3153.4 Accessibilité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

3.4.1 Intérêt de l’accessibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3163.4.2 Comprendre les recommandations. . . . . . . . . . . . . . . . . . . . . . 3203.4.3 Certification et pénalités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321

4. Tests de charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322

5. Tests de migration ou reprise de données . . . . . . . . . . . . . . . . . . . . . . . . . . 3265.1 Généralités sur les Migrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3265.2 Migrations impliquant la reprise des données . . . . . . . . . . . . . . . . . . 329

5.2.1 Classification des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3315.2.2 Migration de type Big Bang . . . . . . . . . . . . . . . . . . . . . . . . . . . 3315.2.3 Migration au fil de l’eau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3325.2.4 Outillage de la migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334

5.3 Phase finale de la migration - le décommissionnement . . . . . . . . . . . 335

6. Tests de tolérance aux pannes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3366.1 Facteurs de défaillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336

6.1.1 L’Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3376.1.2 La disponibilité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3406.1.3 La compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3436.1.4 La stabilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

6.2 Conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3446.2.1 N+1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3446.2.2 Fail fast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344


6.2.3 Paxos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3446.2.4 Raft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346

6.3 Reprise de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3476.3.1 Définition des tests de reprise de fonctionnement . . . . . . . . . 3486.3.2 Préparation des tests de reprise de fonctionnement . . . . . . . . 3486.3.3 Exécution des tests de reprise de fonctionnement. . . . . . . . . . 349

7. Tests d’exploitabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

8. Tests de traçabilité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3518.1 Périmètre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3518.2 La vérification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

9. Tests de sûreté de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354

Chapitre 6Versant technique du test

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

2. Test de conception et de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3592.1 Préparation des tests pour la conception et le code . . . . . . . . . . . . . . 359

2.1.1 Responsabilité collective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3602.1.2 Préparation de la revue de conception et de code . . . . . . . . . . 3612.1.3 Tests Unitaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3772.1.4 Pair programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404

2.2 Revue de conception et de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4062.2.1 Inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4062.2.2 Méthode B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408

2.3 Software Craftsmanship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410

3. Ingénierie des tests d’intégration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4143.1 Approche Big Bang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4163.2 Approche Top-down. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4173.3 Approche Bottom-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4193.4 Approche Sandwich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4213.5 Autres approches. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422

3.5.1 Intégration par Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . 4223.5.2 Intégration au Backbone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4223.5.3 Intégration à fréquence élevée. . . . . . . . . . . . . . . . . . . . . . . . . . 422


3.5.4 Intégration de Services Distribués . . . . . . . . . . . . . . . . . . . . . . 4223.5.5 Intégration Continue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424

4. Stratégies d’automatisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4254.1 Difficultés d’automatisation des tests. . . . . . . . . . . . . . . . . . . . . . . . . 4264.2 Plateformes techniques de test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426

4.2.1 Application web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4274.2.2 Automatisation des tests pour applications web . . . . . . . . . . 4284.2.3 Automatisation des tests pour navigateurs

graphiques pour ordinateur personnel . . . . . . . . . . . . . . . . . . . 4294.2.4 Automatisation des tests pour navigateurs textuels . . . . . . . . 4304.2.5 Application mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4314.2.6 Des plateformes au secours du problème de portabilité . . . . . 4364.2.7 Application native pour ordinateur personnel. . . . . . . . . . . . . 439

4.3 Le cornet de glace des tests automatisés . . . . . . . . . . . . . . . . . . . . . . . 4404.4 Élaboration des scripts de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441

4.4.1 Automatisation des tests de composants. . . . . . . . . . . . . . . . . 4424.4.2 Automatisation des tests d’intégration . . . . . . . . . . . . . . . . . . 4434.4.3 Automatisation des tests fonctionnels. . . . . . . . . . . . . . . . . . . 4434.4.4 Compétences de programmation . . . . . . . . . . . . . . . . . . . . . . . 4444.4.5 Approche par mots-clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4464.4.6 Model-Based Testing - MBT . . . . . . . . . . . . . . . . . . . . . . . . . . . 4484.4.7 Priorisation pour l’automatisation . . . . . . . . . . . . . . . . . . . . . . 4524.4.8 Qui automatise ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454

4.5 Répétabilité des scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4564.6 Robustesse des scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

4.6.1 Concept de Jidoka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4574.6.2 Insensibilité aux bruits - Objectif du script . . . . . . . . . . . . . . . 4584.6.3 Les Faux-Positifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458

4.7 Maintenabilité des scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4594.7.1 Design pattern Page Object . . . . . . . . . . . . . . . . . . . . . . . . . . . 4614.7.2 Objets métier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4624.7.3 Design pattern ScreenPlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4634.7.4 Framework des tests automatiques . . . . . . . . . . . . . . . . . . . . . 464

4.8 Exécution des scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4654.8.1 Exécution en aveugle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4664.8.2 Reporting d’exécution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466


5. Environnement technique du test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4675.1 Alpha Testing et Beta Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4675.2 Projet DevOps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469

5.2.1 Culture et généralités. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4695.2.2 Processus d’Intégration Continue (PIC) . . . . . . . . . . . . . . . . . . 4745.2.3 Observabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4905.2.4 Patterns & antipatterns organisationnels . . . . . . . . . . . . . . . . 4905.2.5 Feature Flipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4955.2.6 Notion de Conteneur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4975.2.7 Stratégie Shift Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5065.2.8 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511

Chapitre 7Facteurs de succès

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513

2. Le Contexte organisationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5132.1 Le Management 3.0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5152.2 Holacratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5182.3 Et quoi d’autre ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518

3. Vue globalo-locale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5213.1 Point de vue de la régression. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5213.2 Lien entre les anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5223.3 Point de vue de l’humeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5223.4 En résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523

4. Culture générale. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5244.1 Gestion de la connaissance comme enjeux du test . . . . . . . . . . . . . . . 5244.2 Vouloir apprendre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5264.3 Repérage de la connaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5284.4 Actualisation de la connaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5294.5 Préservation de la connaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 529

4.5.1 La Solution Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5304.5.2 La CMDB d’ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5314.5.3 Généralités sur les outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532


4.6 Valorisation de la connaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5364.6.1 Mise en avant d’un document . . . . . . . . . . . . . . . . . . . . . . . . . 5364.6.2 Mesure de la compétence acquise. . . . . . . . . . . . . . . . . . . . . . . 536

4.7 Partage de la connaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5394.7.1 Généralités sur la documentation. . . . . . . . . . . . . . . . . . . . . . . 5404.7.2 Modélisation Agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5424.7.3 État d’esprit du modélisateur Agile . . . . . . . . . . . . . . . . . . . . . 5514.7.4 La notion de « Ba - » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 551

5. Ce qui fait l’âme du Testeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5545.1 Ceux qui testent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554

5.1.1 Le Pragmatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5565.1.2 Le Joueur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5565.1.3 Le Méthodique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5575.1.4 L’Empirique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5575.1.5 Le relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5575.1.6 Changement des mentalités . . . . . . . . . . . . . . . . . . . . . . . . . . . 561

5.2 Passion et motivation intrinsèque . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5665.3 La confiance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 567

5.3.1 La confiance en une version . . . . . . . . . . . . . . . . . . . . . . . . . . . 5675.3.2 La confiance comme attribut du Leadership . . . . . . . . . . . . . . 568

5.4 Biais cognitifs et test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5695.4.1 L’intuition du Testeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5715.4.2 Biais de confirmation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5725.4.3 Dissonance cognitive chez le Testeur. . . . . . . . . . . . . . . . . . . . 5735.4.4 Effet de cadrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5745.4.5 Corrélation illusoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5755.4.6 Raisonnement fallacieux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5755.4.7 Illusions cognitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5775.4.8 Identification de motifs à partir du vide . . . . . . . . . . . . . . . . . 579

5.5 Pensée critique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5855.6 Créativité. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5895.7 Le Leadership. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5925.8 Les valeurs du Testeur Agile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594


AnnexesBibliographie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629

247

Chapitre 5

Tests non fonctionnels

Tests non fonctionnels1. Introduction

Sur une grosse majorité des projets rencontrés, il s’avère que les tests non fonctionnelssont éludés. À l’évocation de cette catégorie de test, un soupir sonore « Aaaaah » unpeu gêné est en général l’unique Exigence Non Fonctionnelle (ENF ou NFR enanglais - Non Functional Requirements) connue de tous. Dans certains cas, on aura destentatives telles qu’un essai de l’application sur X navigateurs différents ou uneéquipe spécialisée qui fait des tests de charge ou de sécurité.Les anomalies ne proviennent des fonctionnalités qu’à hauteur de 16 % [Beizer 1994],mais si certaines contraintes rencontrées en exploitation ne sont pas respec-tées, le produit ne sera qu’un prototype ou une expérience de laboratoire.C’est pourquoi une stratégie de test ne doit pas faire l’économie de tests non fonction-nels avec une prise en compte dès la conception.

Exigences non fonctionnelles dans la mobilité

Dans le domaine de la mobilité, il existe une ENF connue de tous : l’énorme choixde combinaisons OS/Version/Matériel et si l’utilisation du produit sur différentesplateformes mobiles n’est pas prise en compte dès le début, on risque de dévelop-

per pour iOS et de devoir reprendre tous les développements pour Android ouWinPhone !

lcroise

Tampon

© E

dit

ions

EN

I -

All r

ights

rese

rved


Remarque

On pourrait multiplier dans ce livre les informations sur l'importance des ENF, mais ce nesera que par le vécu et un partage au sein de l'équipe que la maturité émergera pourimpliquer réellement ces contraintes. La culture est un facteur majeur dans la prise encompte des ENF. Lorsqu’une ENF est bien ancrée dans celle-ci, les solutions techniqueset les moyens de tests sont impliqués et budgétés sans avoir ni à réfléchir, ni àconvaincre :

- une technologie multi-plateforme est impliquée : Ionic (https://fr.wikipedia.org/wiki/Ionic_(framework)), Cordova (https://fr.wikipedia.org/wiki/Apache_Cordova), Xama-rin (https://fr.wikipedia.org/wiki/Xamarin), NativeScript (https://en.wikipedia.org/wiki/NativeScript), ReactNative (http://www.reactnative.com/), Titanium (https://fr.wikipe-dia.org/wiki/Appcelerator_Titanium) ou Flutter (https://flutter.dev/) ;

- une ferme de serveur est montée avec OpenStf (https://openstf.io/) ou louée à unprestataire dans le Cloud comme BrowserStack (https://www.browserstack.com/) ouSauceLab (https://saucelabs.com/) pour avoir autant de combinaisons que son mar-ché le nécessite.

On l’aura compris, cette culture provient de contraintes opérationnelles (voirchapitre Versant technique du test) qui imposent une vision proche du terrain.

2. Tests de sécurité

Depuis le 26 mai 2018, l’Europe a promulgué une loi (RGPD - voir plus bas dans cechapitre) pour lutter contre le faible niveau de sécurité lié au traitement et à laprotection des données personnelles. Cela a fait beaucoup de bruit au vu des sanctionsannoncées (https://fr.wikipedia.org/wiki/R%C3%A8glement_g%C3%A9n%C3%A9ral_sur_la_protection_des_donn%C3%A9es) et n’est qu’un prétexte de plus pourmettre au centre des préoccupations les tests de sécurité déjà abordés par l’industriedes cartes bancaires [PCI-DSS], l’Agence Nationale de la Sécurité des Systèmesd’Information (ANSSI) qui a produit le « Référentiel général de sécurité » [RGS] desstandards internationaux de sécurité [ISO27002] ou encore ceux liés aux sociétéscotées en bourse [SAS70].Cette section se penche avec ambition sur un domaine souvent obscur.

249Tests non fonctionnelsChapitre 5

2.1 Généralités sur les tests de sécurité

La sécurité est un domaine des plus vastes, car il touche toutes les parties duproduit et les personnes qui interagissent avec. Cette configuration fait du testde sécurité :– une activité pluridisciplinaire avec des Experts qui comprennent les règles, les

lois, l’organisation sous-jacente, les opérations, les processus et les technologiesutilisées ;

– une exploration des dangers dans l’obscurité avec pour seul éclairage l’expertiseafin de trouver les failles avant qu’elles ne soient exploitées ;

– une activité de contrôle perpétuel des failles connues pour éviter qu’ellesn’impactent (à nouveau) le système ;

– une tâche qui ne saurait être simple…

Astuce

Le MVP pour les tests de sécurité

Ce sujet est très difficile à aborder, car techniquement complexe, culturellement am-

bitieux et politiquement délicat. Aussi, comme à chaque fois avec l'agilité, on tenterad’identifier le MVP de la sécurité ; ce MVP peut être complètement empirique (on faitavec les moyens et la connaissance du bord), sous-traité à un tiers compétent dans ledomaine, ou pris en main dès qu’on a un peu de temps devant soi, par exemple enlisant ce chapitre pour, au moins, aborder le « SHU » de la sécurité.

Les problèmes de sécurité ne sont pas seulement réservés au domaine de l’infrastruc-ture. La communauté « Common Weakness Enumeration » (énumération des failles ré-currentes) recense une liste de failles directement liées au développement avec près de700 vulnérabilités identifiées (voir https://cwe.mitre.org/). Selon Jeffery Payne, lesfailles liées au code représentent 50 % des menaces [Payne 2016].

Astuce

Challenge « 30 jours sur les tests de sécurité »

Pour commencer l’acculturation d’une équipe aux tests de sécurité, Melissa Eadenpropose un challenge de 30 jours sur ce thème avec un défi par jour pour avancer surdifférents axes [Eaden 2016] :

1. Lire un blog sur la sécurité.

2. Sélectionner et lire un livre sur le test de sécurité.

3. Utiliser un outil de test de sécurité tel que ZAP (https://www.zaptest.com/) ouBurpSuite (https://fr.wikipedia.org/wiki/Burp_suite).

4. Apprendre quoique ce soit sur le scan de vulnérabilité.

5. Connaître le modèle de menace (voir par exemple le modèle « STRIDE »).

© E

dit

ions

EN

I -

All r

ights

rese

rved


6. Explorer ces sites : Google gruyere; HackYourself First; Ticket Magpie; The BodgeItstore.

7. Apprendre une chose ou plus sur les tests de pénétration.

8. Utiliser un outil de type proxy pour observer le trafic d’une application web ou mobile.

9. Découvrir le processus et les procédures liées à l’audit de sécurité.

10. Apprendre ce qu’est le Hacking Ethique (White Hat).

11. Tenter de se représenter une posture de cybersécurité pour une application.

12. Se documenter sur le test de sécurité et établir une discussion sur le meilleur endroitdu cycle de développement logiciel où on pourrait en introduire.

13. Réaliser une analyse de sécurité dans une US.

14. Faire l’ingénierie d’un plan de test incluant des tests de sécurité.

15. Écrire et partager des idées sur les tests de sécurité sur Twitter ou un blog.

16. Faire des recherches sur comment construire une « Tiger Box ».

17. Faire des recherches sur une faille de sécurité ou un hack récent.

18. Se documenter sur la sécurisation des Headers.

19. Se documenter sur les Script Kiddies et/ou les Packet monkeys.

20. Se documenter sur les attaques DoS/DDoS. Partager quelques exemples sur unréseau social.

21. Se documenter sur les vulnérabilités d’un réseau et les rechercher dans son organi-sation.

22. Se documenter sur la sécurité des systèmes et l’appliquer sur son organisation.

23. Répondre à la question : quel est le top 10 des menaces de sécurité cette année ?

24. Utiliser une suggestion de la check-list OWASP pour les applications web.

25. Identifier et utiliser un outil de test de sécurité pour mobile.

26. Faire un comparatif sur les réseaux sociaux des tests web et mobile.

27. Comment le BYOA (Bring Your Own Application - Amenez votre propre application)peut jouer un rôle dans la sécurité ?

28. Partager des idées de tests de sécurité pour un domaine particulier.

29. Faire des recherches sur les contraintes réglementaires de sécurité pour un domaineparticulier.

30. Décrouvrir la différence entre le Hacking White Hat, Grey Hat et Black Hat.

31. BONUS : participer à un Bug Bounty.

251Tests non fonctionnelsChapitre 5

2.2 Orientations en termes de sécurité

Pour tenter de lutter contre la menace liée aux problèmes de sécurité, plusieurs stan-dards existent et Aleatha Shanley propose une comparaison de différents modèles[Shanley 2015] :– BSIMM - Building Security in Maturity Model : propose différentes pratiques liées à

la sécurité (dont les tests de pénétration), mais aucun outil ;– ISSAF - Information Systems Security Assessment Framework : un framework de test de

pénétration avec des processus et des outils ;– MSF - Metasploit Framework : palette d’outils de tests de pénétration et de détection

d’intrusion ;– OSSTMM - Open Source Security Testing Methodology Manual : méthode d’audit de

sécurité ;– OWASP - Open Web Application Security Project : outils, guides et méthodes de

travail pour les applications web qui couvrent tout le cycle de développement ;– PTES - Penetration Testing Execution Standard : standard de tests de sécurité qui re-

groupe différentes sources dont le OWASP [Hayes 2012].Aleatha Shanley utilise d’autres critères de comparaison :– l’ISO25010 comme base de son benchmark ;– la longévité, le nombre de révisions et la date de dernière mise à jour ;– le facteur de lisibilité tel que le Gunning Fog Index - GFI (voir chapitre Facteurs de

succès) pour guider le choix d'orientation pour une organisation.

Figure 1 : Positionnement de l'OSSTMM par rapport aux pratiques usuelles de tests de sécurité [Leita 2011]

© E

dit

ions

EN

I -

All r

ights

rese

rved


Le positionnement de l’OSSTMM semble être le meilleur, étant donné la représenta-tion choisie ; en revanche, sur la perspective de la mise en pratique, ce standard sesitue loin derrière des approches basées sur les scans de vulnérabilité comme l'OWASPou MSF qui fournissent des outils.

Définir sa stratégie de test de sécurité

Même si Aleatha Shanley ne va pas jusqu’au bout de la démarche en montrantl’étude comparative des six standards, cela peut donner des pistes pour vousaider à choisir le vôtre ; c’est ce que fait Corrado Leita en comparant à sa façonles frameworks OSSTMM, ISSAF et NIST.

La norme ISO 27001 (voir https://fr.wikipedia.org/wiki/ISO/CEI_27001) aborde lacomplexité de la sécurité suivant l’approche du progrès continu, le PDCA - Prévoir/Donner corps/Contrôler/Améliorer (en anglais : « Plan/Do/Check/Act » - voir https://fr.wikipedia.org/wiki/Roue_de_Deming) avec les activités suivantes :

– Prévoir :

– on délimite le périmètre du Système de Management de la Sécurité de l’Infor-mation (SMSI) ;

– on s’engage sur une politique de SMSI en fonction des enjeux métier ;

– on s’engage sur une approche du risque ;

– on réalise une analyse de risques ;

– Donner corps :

– sensibilisation et communication ;

– gestion de l’exploitation du SMSI ;

– gestion des ressources du SMSI ;

– définition des procédures de détection des incidents de sécurité ;

– définition de procédures de gestion de la documentation ;

– Contrôler :

– mesure de l’efficacité du SMSI ;

– révision de l’analyse des risques ;

– conduite d’audits internes ;

– archivage des incidents ;

– collecte et analyse des enregistrements ;

– Améliorer :

– mise en place des améliorations identifiées ;

– communication des améliorations ;

– vérification de l’efficacité des améliorations.

Version en ligne + QUIZ OFFERTE ! pendant 1 an Le test Le ...€¦ · d’une équipe pour...

Documents

Transcript of Version en ligne + QUIZ OFFERTE ! pendant 1 an Le test Le ...€¦ · d’une équipe pour...