Première Approche Et Cadre Réglementaire

Première approche
et cadre
réglementaire
Bertrand Cornanguer V1
OBJECTIFS
 Comprendre ce qu'est un projet de développement informatique

 Identifier les enjeux économiques et techniques
 Comprendre le tryptique Qualité / Coût / Délai
 Comprendre l'intérêt de l'amélioration continue
 Comprendre comment les tests et la gestion des exigences participent
à la qualité du produit
 Faire la différence entre le besoin et la solution
 Appréhender les différents types et niveaux de tests
 Connaître les bonnes pratiques de tests
 Identifier les étapes fondamentales du processus de test
 Connaître les standards dans les SI, la sécurité des systèmes critiques
 Identifier les principales familles d'outils de tests
 Connaître les contraintes liées au RGPD, et notamment la notion
de "Privacy by Design".
Bertrand Cornanguer Reproduction et distribution interdite

www.info@springit.fr
Introduction
 Objectif de la formation
 Avez-vous des attentes particulières sur cette formation ?
Sommaire
 Qu'est-ce qu'un projet  Processus fondamental de test
informatique ?  Niveaux de test
 Enjeux économiques  Formaliser les tests
 Origine et coût des défaillances  Cas de test
 CNIL, RGPD, W3C  Suites de test
 Comprendre le besoin  Comprendre les objectifs de test

 Faire exprimer le besoin et le  Tester, c’est informer
formaliser
 Outils
 Les standards liés aux tests  Gestion des tests
et à la sécurité
 Automatisation
 Avionique et sécurité
des systèmes critiques  Exploitation informatique
 AMDEC, DO178, ISO 26262  Amélioration continue

 ISO 29119, 2500n  La rétrospective
 Qu'est-ce que le test ?  PDCA / DMAIC / PAQ / TMMi / C

MMi
 Assurance et contrôle qualité
 Prévenir les défauts

Tour de table
Présentation des participants

 Vous  Moi
– Email info@Springit.fr
– WEB www.springit.fr
– Tel (+33) 06 21 40 27 13
•Votre ancienneté dans le monde informatique

•Votre rôle et vos expériences
•Vos activités actuelles
•Les formations déjà suivies
Introduction - Organisation
 Heure de début
 9h00
 Heure de fin Contraintes particulières ?
Enfants, ...
 17h00
 Pauses
Règles de bonne conduite
 11h et 15h30
Pas de téléphone
 Repas
 12h30 (12h45-13h45)
Pour la certification une pièce
d’identité est nécessaire

1
Qu’est ce qu’un projet informatique
Qu’est ce qu’un projet ?
 AFNOR X50-105:
« Un projet se définit comme une démarche spécifique qui permet de structurer
méthodiquement une réalité à venir.
Un projet implique un objectif et des actions à entreprendre avec des ressources
données »
ISO X50-106 :« Démarche scientifique qui permet

 Trouver un équilibre entre : de structurer méthodiquement et progressivement
une réalité à venir », »un projet est défini et mis en
 Qualité du projet œuvre pour élaborer une réponse aux besoins
d’un utilisateur ou d’une clientèle, et il implique un
 Coût objectif et des actions à entreprendre avec des
ressources données »
 Délais
AFNOR X50-115:
« un ensemble d’activités coordonnées et
maîtrisées comportant des dates de début et de
Qualité fin, entrepris dans le but d’atteindre un objectif
conforme à des exigences spécifiques »
Définir le QQOQCCP !
Qui Quoi Ou Quand Comment Combien Pourquoi
A un objectif, a un début, une fin, est temporaire,
se prépare, se fait par étapes
Coût Délai Vous entendrez souvent parler du tryptique
Qualité Coûts Délais
Trouver un équilibre entre :
Qualité du projet
Coût
Délais

Qu’est ce qu’un projet ?
 Un projet est différent des opérations/activités des services habituels

 Innover plutôt que maintenir (réduire la dette technique)
 Créer de la valeur, augmenter la productivité

• Ex: Automatiser des tâches
• Donne une nouvelle dynamique, mobiliser, fédérer des équipes
• Réponse politique de l’entreprise face à un problème
• Réponse à une obligation réglementaire
• Réponse à un besoin
 Un projet est différent des opérations/activités des services habituels

• Innover plutôt que maintenir (réduire la dette technique)
Quelques termes
 Maitre d’ouvrage:
• Le client qui aura besoin de l’objet du projet mais qui ne veux/peux pas le
faire lui-même
 Maitre d’œuvre:
• Réalise le projet, chef d’orchestre de ce projet, il doit tout mettre en œuvre
pour finaliser le projet, même si cela lui parait impossible
 Planning/Plan projet
• Plan d’organisation d’un projet
 Guide du chef de projet / Kit de gestion de projet
• Outils mis à disposition par les services outils/Méthodes pour gérer les projets
• Modèles de documents
• Outils de planification
• Indicateurs de reporting à utiliser
• Manuels de formation
10

Quelques termes
Le client
 Manager un projet c’est gérer un projet sur toute sa durée dans le but de satisfaire un
client
 La satisfaction du client est l’enjeu réel d’un projet: respect de la qualité, du délai et
du coût.
 Un client non satisfait est un client qui ne paye pas (ou qui met une mauvaise note…)
 Ses attentes envers le chef de projet sont que celui si:
• comprenne réellement son besoin,
• Le chef de projet doit identifie les conditions de satisfaction du client
• tienne ces engagements,
• lui propose un produit directement utilisable.
 Le client ne doit pas être impliqué dans le projet mais on doit lui rendre des comptes
régulièrement. Il attend le résultat!!!
 Il doit y avoir un réel dialogue entre le client et le chef de projet.
11
L’équipe projet
Client
Chef de projet
Acteur 1 Acteur 2 Acteur 3 Acteur 4
? ? ? ?
 Un travail en équipe ne veut pas dire travail commun sur toutes les taches.
 Chaque personne travaille individuellement sur une tache (5 personnes sur un
projet = 5 taches en parallèles…)
 Les phases de travail commun sont très rares.
 Les acteurs du projet: ils travaillent sur toutes les taches du projet en respectant
l’organisation et les contraintes mises en place par le chef de projet.
 Comme c’est une démocratie et non une dictature, les acteurs participent aux
décisions avec le chef de projet
 Par exemple le chiffrage des tâches doit être fait idéalement par celui qui
les fera…
12

Les parties prenantes du projet
 Différents Métiers du test

 Testeur
 Analyste de tests
 Analyste technique de tests
 Gestionnaire de tests
 Responsable Méthodes et processus
 Expert outil
Considérons
 Le Gestionnaire de test
 Le testeur (tous les rôles de testeur)
13
Les parties prenantes du projet
Le Gestionnaire de test, délégué du chef de projet
Organise, planifie, prépare le Plan de tests

•Approche de tests
•Niveaux de tests Planifie et contrôle
•Estime la charge
•Défini le Workflow des incidents
•Calendrier
Met en œuvre
•Environnements
Vérifie
•Gestion de configuration
•Revues du testware
•Accepte les livraisons
•Les écarts au plan
Mesure & Communique
•Métriques et avancement Informe
•Rapports de tests
14

Les grandes étapes d’un projet
Avant projet Projet
Marketing
Besoin
Faisabilité Planification Etudes et
Conception
Cadrage
Réalisation
Mise en œuvre du Plan Qualité - Revues Qualification
Mise en service
Clôture
Suivi du projet / Amélioration continue
Temps
Et en sous activités.
Ici le processus fondamental des tests.
La communication est primordiale.
Il faut éviter l’effet tunnel.
15
Le plan projet
 Rassemble toutes les informations concernant le projet

 Qui Quand Ou Quoi Comment Combien Pourquoi
A présenter et expliquer aux parties

prenantes pour éviter le classement
vertical…
Ce ne sont que des hypothèses…
Temps
Connaissance du projet
Pouvoir d’action
16

Organisation informatique
Ne pas être juge et partie

Les tests sont effectués par d'autres que les développeurs
 Cela prend la forme de
 TRAs, Centres de service, centre de compétences de tests
Test conçu par une autre organisation
Test conçu par une équipe indépendante de

l’organisation
Test conçu par un pair du développeur
Test conçu par le développeur
17
Les enjeux
 Risques croissants,
L’informatique n’est plus considérée

comme un simple support logistique
c’est un élément important de la stratégie de l’entreprise
 Concurrence, mondialisation → Réactivité & Agilité
 La nécessaire industrialisation des processus de production de

logiciels passe par une démarche d’amélioration continue
 Démarche dont finalité est la maîtrise du changement

pour satisfaire les objectifs Métier
18

Les enjeux
 Pour le processus de production de logiciels d’une organisation:

 Améliorer la performance
• Coûts, Qualité, Délais, Contenu

• Rendre prédictible la performance
• Capacité et stabilité du processus

• Délivrer la performance de façon continue et adaptée
• Maturité de l’organisation
 En cohérence avec les objectifs du business et de maîtrise du SI
• Gouvernance IT
19
Origine et coût des défauts
Nécessité de la qualité logicielle

Etude DoD américain
 Projets d’ingénierie Logicielle : retard, dépassement de budget,
non-qualité
30 à 35% des projets initiés ne voient jamais le jour

25% de ceux qui arrivent à terme ont du retard,
dépassent les budgets ou ne sont pas opérationnels
 Image désastreuse pour certains secteurs,

 Budgets Importants,
Le coût global des moyens informatiques

10 à 40% des coûts de fonctionnement de l’entreprise
20

Ce que demande Ce qui est décrit dans Ce que l’analyste a

l’utilisateur l’expression du besoin spécifié
Tout le monde connaît cette histoire …
Ce que le
programmeur a Après la mise au point Ce qu’il fallait
réalisé
21
56 %
Ce que demande Ce qui est décrit dans Ce que l’analyste a
l’utilisateur l’expression du besoin spécifié
27 % Tout le monde
connaît cette
histoire …
Mais pourquoi
est elle
toujours
d’actualité ?
17 % Ce que le
programmeur a Après la mise au point Ce qu’il fallait
réalisé
22

Origine et coût des défaillances
 Les Erreurs surviennent de
 Pression du temps
 Défaillance humaine
 Inexpérience, compétences insuffisantes
 Mauvaise communication
 Complexité, nouveauté technique
 Non compréhension des systèmes en interface en grand nombre
Défaillance <> Défaut
23
Origine et coût des défaillances
 Dette technique (maintenance à réaliser)

 Andy Kyte gartner VP 500Milliards de dollar =>1 trillion en 2015
 Bill Curtis CAST: Etude sur 288 applications de 75 sociétés de domaines
différents
 108Millions de lignes de code => 2,82$ /ligne de coût de
maintenance
 Capers Jones
 Revues de spec: Permet de détecter 65% des anomalies de spec
 Revue de code: Permet de détecter 60% des anomalies de code
 85% des anomalies seraient détectées par les revues
 0,75 anomalie/point de fonction seraient livrées au client
24

Coût de défaillances
 Les systèmes logiciels deviennent une part intégrante de notre

existence, des applications commerciales (p.ex. bancaires) aux
produits de grande consommation (p.ex. automobiles)
 La plupart d'entre nous ont eu l'expérience d'un logiciel qui n'a pas
fonctionné comme attendu
 Des logiciels ne fonctionnant pas correctement entrainent

des pertes financières,
de temps ou de réputation,
peuvent causer des blessures ou la mort
 Les risques existent aussi bien dans l'informatique embarquée que

dans les logiciels de gestion
25
 Dommages à l'environnement
 Rejet d'eaux non traitées du fait de données de capteurs
erronées
 Mauvais réglage d'un moteur entrainant un surcroit de
pollution
 Dommages à la société
 Arrêt des traitements boursiers
 Pertes de résultats de votes
 Débit anormal sur une compte bancaire lors d'un traitement
mensuel
 Ariane V qui explose en vol malgré la redondance ' des
calculateurs (qui avaient le même hardware et software)
26

 Dommages à des personnes

 Accident de voiture ABS défectueux
Lors d'un essai Volvo, un journaliste a eu un accident car selon un certain angle de
braquage des roues, l'ABS ne s'est pas déclenché
Il y a plus d’informatique dans la Volvo S80 que dans le chasseur F15 » déclarait en
janvier 2000 Denis Griot, responsable de l’électronique automobile chez
Motorola.
 Calibrage du scanner défectueux

Des personnes ont été irradiées du fait d'une incompatibilité entre le driver et
l'appareil de radiographie
 Arrêt de la climatisation, d'un ascenseur
27
Coût des défaillances
• Coûts internes des défaillances

➢ fonction des anomalies identifiées suite aux revues et tests
« Élément du coût d'obtention de la qualité constitué de l'ensemble

des coûts résultant des défauts constatés dans les produits, les
matières et le matériel avant même que les produits soient livrés au
client, notamment les coûts des rejets, des mises au rebut, des
retouches, des remises en fabrication et des arrêts-machines »
 Coût des revues d’anomalies

 Coût de la correction des anomalies en test
 Correction des spécifications
 Correction du code
 Coût de composants acquis non utilisables

 Environnements en panne
28

 Coûts externes des défaillances
La « non qualité » a des impacts sur l’image, sur la pérennisation des clients ainsi que
sur la rentabilité des affaires conclues avec ces derniers.
Les différents coûts de la « non qualité » se traduisent pour la DSI, par des coûts de
support interne et de maintenance corrective accrus, et pour les utilisateurs par des
baisses de performance ou des impossibilités de travailler correctement, pouvant
aller indirectement jusqu’à des erreurs dans les productions.
29
Lorsqu’une « non-conformité » est détectée en production, l’utilisateur peut

rencontrer une indisponibilité du service attendu qui perdure tant que ce dernier
n’est pas redevenu pleinement opérationnel l
30

L’utilisateur signale alors l’anomalie pour une prise en charge par le support
technique (coût de détection), qui va réparer le système si besoin ou mettre en
place une procédure temporaire de contournement (maintenance palliative).
31

L’anomalie lorsqu’elle est corrigée

(Maintenance corrective) fait
l’objet d’un redéploiement associé
à une communication auprès des
utilisateurs.
Le coût de la « non qualité » est l’ensemble des coûts liés

à ces différentes activités. A ces coûts, se rajoute celui
des anomalies cachées qui peuvent entrainer
indirectement des non-conformités dans la conception
des navires, sous-marins et autres productions du Groupe
32

 Le test nécessaire et suffisant est rentable

 Il est nécessaire de calculer les différents coûts
Coûts
Coûts internes externes des
« La qualité coûte cher, mais il existe défaillances
quelque chose de plus coûteux que la
qualité : son absence »
P. Jocou (les enjeux économiques de la qualité)
33
RGPD Règlement Général sur la Protection des Données
 RGPD s’inscrit dans la continuité de la Loi française Informatique et

Libertés de 1978 établissant des règles sur la collecte et l’utilisation des
données sur le territoire français. Il a été conçu autour de 3 objectifs :
 renforcer les droits des personnes
 responsabiliser les acteurs traitant des données
 crédibiliser la régulation grâce à une coopération renforcée entre les
autorités de protection des données.
25 mai 2018
 La CNIL doit  Les organismes

prouver la non- doivent prouver
conformité des leur conformité à
organismes la CNIL
34

Qu’est-ce qui relève des données personnelles ?

 « toute information se rapportant à une personne physique identifiée
ou identifiable ».
 identification directe (nom, prénom etc.)
 identification indirecte (identifiant, numéro etc.).
Identité
Données sensibles
Données judiciaires
Protection des données personnelles Localisation
Informations économiques
Vie professionnelle
Vie personnelle
35
 Mise en œuvre pour les entreprises
https://www.cnil.fr/fr/cartographier-vos-traitements-de-donnees-personnelles
36

 Mise en œuvre pour les entreprises
37
 LE PRIVACY BY DESIGN
 Le PbD s’articule autour de 7 principes fondamentaux:
 Des mesures proactives et préventives
 Cases à cocher sur la protection déjà cochées
 Une protection implicite et automatique

 Ne collecter que ce qui est nécessaire
 Les boutons de partage de facebook devraient être inactifs par défaut
 Une intégration de la vie privée dans la conception des systèmes et au

cœur des pratiques
 Une protection intégrale
 Une sécurité de bout en bout, durant toute la durée de la conservation des
données
 Assurer la visibilité et la transparence
 Respecter la vie privée des utilisateurs (en privilégiant les intérêts des
particuliers)
38

 Sécuriser les données

 Accès limité aux administrateurs
 Limiter le profilage avec l’inscription possible à une liste rouger
 Mesures de protection physique (Contrôle d’accès aux installations

 Gérer les données rapidement à la demande
 Permettre l’accès pour modifier et supprimer (Droit à l’oubli)
 Méthode pour supprimer l’ensemble des données d’un utilisateur
 API pour supprimer certaines données, ihm pour utilisateur
 Durées de conservation en lien avec leur finalité

 Modifier les développements
 Cookies,
 Mentions d’information,
 Recueil du consentement,
 Sécurité et confidentialité des données
 Droit d’accès aux traitements des données
39
2
Comprendre le besoin
40

Besoin versus solution
 Besoin: Le besoin est un état de tension ou de désir
 Besoin implicite: Besoin ressenti mais non exprimé car non identifié ou
sensé être compris par le fournisseur
 Besoins explicite: Besoin exprimé
 Besoin Suscité: Besoins non inhérents au client mais qui lui sont suscités
par son entourage, un vendeur… En tant qu’industriel, les leviers
d’actions sur ces besoins sont principalement la communication
(permettant d’influencer son entourage) et la formation des vendeurs.
 Besoin imposé: Dictés par des normes, réglementations, règles tacites.
Par exemple, avoir la norme NF pour vendre un casque de moto est
un atout clair
 Attente: Description par le client de l’élément ou de la prestation
pouvant répondre au besoin (Primaires, secondaires, tertiaires)
 Condition de satisfaction/de frustration: Définir qui va satisfaire ou pas
le client
 Solution: Elément ou prestation devant répondre aux attentes.
 Exigence: Ce qui est requis…
41
Besoin
Caractériser le besoin :
 Débuter par percevoir le besoin et vérifier sa validité.
 Quelle est l’utilité du produit ? A quoi, à qui sert-il ?
 Quelle est son action ? Sur quoi, sur qui agit-il ?
 Qu’est qui est important ?
 Que se passe t’il si le besoin n’est pas satisfait ?
Valider le besoin dans le temps
 Qu’est-ce qui peut faire évoluer le besoin ?
 Est-ce peu probable ?
 Est-ce probable, ou très probable ?
 A quelle échéance : court, moyen ou long terme ?
Exprimer le besoin
 Le Cahier des Charges Fonctionnel
On verra la
solution après…
42

Besoin versus solution
Besoin Solution
• Se reposer Voyage en bord de mer

• Se divertir
• Se changer les idées, se dépayser
• Budget 100€
• Avoir des contacts toute la journée Ouvrir un magasin

• Être autonome
• En vivre
• Concevoir une habitation pour 4 personnes, Maison de 100m² orientée sud en

• lumineuse parpaings
• Coût inférieur à 200K€
• Se déplacer 4x4
• Confort
• Dans les champs et en ville
43
Pyramide de Maslow – Classification des besoins
Ecore moins de personnes

Réalisation • S’épanouir
satisfont les besoins de ce
de soi • Méditer
niveau
• Développement personnel
• Développer son autonomie

Une partie seulement • Etre reconnu, apprécié
d’êtres humains satisfont Reconnaissance
• Parler
ces besoins • Sortir du lot
• Sentir une dépendance

Beaucoup d’êtres Appartenance • S’intégrer dans un groupe
humains • Avoir un statut social
obtiennent dans la • S’exprimer
vie une relative
satisfaction des 3 • Accumuler
Sécurité • Privilégier la stabilité
premiers niveaux
de besoin • Construire une maison
• Manger
Survie • Boire
• Respirer
44

Modèle de Kano 1/3 Niveau de satisfaction du client
Très satisfait
 Kano propose de déterminer

la catégorie d’une Plus on en a mieux
fonctionnalité en posant c’est!
Excitant
deux questions sous deux Séduction,
Besoins explicites
formes : enthousiasme
Surprises agréables
 une forme fonctionnelle :
Degré de réalisation Complètement
comment l’utilisateur se de la fonction réalisé
sentirait si la fonctionnalité
était présente dans le
Obligatoires
produit
Devrait être, basique
On en veut
On s’y attend
 une forme dysfonctionnelle : davantage…
Besoins implicites
comment l’utilisateur se
Indifférents
sentirait si la fonctionnalité Pas d’influence sur le
n’était pas présente dans le niveau de satisfaction
Fonctions inutiles
produit. Non satisfait
Le client est satisfait s’il a des

fonctions excitantes en plus de
ses besoins.
Il est insatisfait s’il n’a pas les

fonctions qu’il souhaite, même si
il a des excitants.
45
Modèle de Kano 2/3

 Pour chaque fonctionnalité le client répond avec cette échelle de
valeurs
Puis on croise les deux réponses :
Question
dysfonctionnelle
Fait avec
Souhaite
N'aime
Neutre
Aime
pas
Aime Q E E E L O Obligatoire
Souhaite C I I I O L Linéaire
Question
Neutre C I I I O E Excitant
Fonctionnelle
Fait avec C I I I O C Contradictoire
N'aime pas C C C C Q Q Questionnable
I Indifférent
 Pour prioriser le développement des fonctions du produit, les fonctions

« Obligatoires » devront être développées pour la première version du
produit.
 Puis on ajoute les fonctions « Linéaires », puis les fonctions « Excitantes ».
 Les réponses «Contradictoire » ou « Questionnable » doivent être
élicitées.
46

Modèle de Kano 3/3
Pour chaque fonctionnalité le client répond avec cette échelle de
valeurs J’aimerais ça.
Que pensez vous si vous Je m’attends à ce qu’il en soit ainsi.

Forme
avez des câpres sur votre Je suis neutre.
fonctionnelle pizza,?
Je peux vivre avec ça.
Je n’aime pas ça.
J’aimerais ça.
Que pensez vous si vous Je m’attends à ce qu’il en soit ainsi.

Forme
dysfonctionnelle n’avez pas de câpres sur Je suis neutre.
votre pizza,? Je peux vivre avec ça.
Je n’aime pas ça.
Question
dysfonction-
nelle
N'aime pas
Fait avec
Souhaite
Neutre
Aime
Aime Q E E E L O Obligatoire
Souhaite C I I I O L Linéaire
Question E Excitant
Neutre C I I I O
Fonctionnelle C Contradictoire
Fait avec C I I I O
Q Questionnable
N'aime pas C C C C Q I Indifférent
47
Trier les attentes du client
 Les « Critical To Quality » (Cruciaux pour la qualité)
Besoin crucial Crucial pour Crucial pour

Exemple de pour la qualité 1 la qualité 2
le client (La fonction) (Le moyen)
diagramme CTQ pour
Temps de
un service de livraison pétrissage
à domicile Goût
Fraicheur des
ingrédients
Température Assurer la
Qualité de la pizza
température
Variétés Boite
Vitesse de
Livraison Véhicule
livraison
Coût de
Prix habituels
fabrication
Prix
Promotions Marges
48

Exprimer le besoin
1. Définir le système étudié
2. Définir les situations de vie
K Importance
3. Définir le besoin 1 Souhaitable
4. Valider le besoin 2 Nécessaire
3 Importante
5. Le hiérarchiser 4 Très importante
5 Vitale
Fonction de transfert/contrainte Critère d’appréciation Niveaux Flexibilités K

FC1: Le client doit rester propre Aspect visuel propre 0 4
FC2: La pizza doit rester chaude Température 40° +/- 5 4
FP1: contenir la pizza de la pizzeria Pizza intègre Plate et ronde 0 5

jusqu’au domicile
Cahier des charges
49
Plan du CdCF
1. Une présentation générale
2. L’énoncé fonctionnel des besoins
3. Un appel éventuel à des variantes

4. Un cadre de réponse
5. Les annexes
50

3 Les standards liés aux tests et à la sécurité
51
Test Basé sur les Risques
 Risque Qualité, produit ou Qualité produit

 L’effet initial d’un problème potentiel porte sur la qualité du produit
Prenons un crayon comme produit par exemple
 Les tests visent à limiter ce risque

 un risque fonctionnel lié à la précision
 un risque non-fonctionnel lié à l’efficacité et au temps de réponse
 Risque Projet ou risque de planning

 l’effet initial d’un problème potentiel impacte le succès du projet
52

 Test et risques - Risques produit
Criticité des exigences Métier

L'analyse des risques liés au produit permet d'identifier les risques liés aux
processus Métier, applications, fonctionnalités, chaines.
Ces risques sont liés

Aux utilisateurs finaux
Que se passe-t-il si l'utilisateur ne peut pas utiliser le logiciel, car il est trop
lent, parce qu'il est figé, parce qu'il n'est pas facile d'utilisation ?
Que se passe-t-il si les calculs ne sont pas exacts ?
A l'exploitation (Opérationnels)
Que se passe-t-il si des fichiers vides sont générés ?
Que se passe-t-il en cas de crash du système et que le séquenceur
relance les batchs ?
53
 Test et risques - Risques produit
Les dommages ou des besoins non couverts sont provoqués par un

manque de qualité
• Une facture erronée va

– Générer une mauvaise marge brute Capacité
– Engendrer des coûts de correction Fonctionnelle
– Chasser les clients
• Des performances lentes vont

Performance
décourager les acheteurs par téléphone
• Des interfaces web non correctement définies

rendent l’achat en ligne presque impossible Capacité
d’utilisation
54

 Risques et Tests
 Le niveau de risque est défini à partir de la probabilité d'occurrence et
de l'impact
Criticité = Occurrence X Impact

Ce tableau donne le niveau de criticité en fonction de l'occurrence :
Critique : Criticité = 1
Forte : Criticité = 2 Importance/Impact de l'élément
Moyenne : Criticité = 3
Fort Moyen Modéré
Très
fréquente Critique Critique Forte
Occurrence
Fréquente Critique Forte Moyenne
Risque
du risque
Forte Moyenne Moyenne
Rare
Dommage
x Fréquence
d’utilisation
Chance
d’échec
x
Chance
de défaut
55
 Analyser le risque prend en compte également les criticités et les

complexités.
Importance technique de
Importance du processus Métier l’application/flux
Fort Moyen Pondéré Fort Moyen Pondéré
Fort Critique Critique Forte Fort Critique Critique Forte
Occurrence Occurrence
Moyen Critique Forte Moyenne Moyen Critique Forte Moyenne
du risque du risque
Modéré Forte Moyenne Moyenne Modéré Forte Moyenne Moyenne
Complexité technique de la Complexité fonctionnelles de la

fonctionnalité fonctionnalité
Fort Moyen Pondéré Fort Moyen Pondéré
Fort Critique Critique Forte Fort Critique Critique Forte
Occurrence Occurrence
Moyen Critique Forte Moyenne Moyen Critique Forte Moyenne
du risque du risque
Modéré Forte Moyenne Moyenne Modéré Forte Moyenne Moyenne
Il est nécessaire de mettre en balance la valeur ajoutée de la fonction

avec sa complexité de réalisation
56

Test Basé sur les Risques DO178
 Normes avioniques, automobile, trains…

 ED-12B et DO-178B avionique
 26262: Automobile
 Précisent
 Conditions de sécurité applicables aux logiciels critiques
 Contraintes de développement liées à l'obtention de la certification d'un
logiciel d'avionique.
 5 niveaux de criticité (de A à E) appelés DAL de
 A critique = > contraintes de développement fortes
 …..
 E sans effet sur la sécurité du vol = > pas de contrainte
57
ISO 29119
 Uniformiser des standard existant

 Parfois conflictuels
 Eclaircir ce que sont les bonnes pratiques de test
58

ISO25010
Caractéristiques Qualité ISO25010:20111
Fonctionnel Performances Compatibilité Utilisabilité Fiabilité Sécurité Maintenabilité Portabilité
Temps de Coexistenc Confidentia Adaptabilit

Exacte Intelligibilité Maturité Modularité
réponse e llité é
Utilisation
Interopérab Apprentissa Réutilisabilit
Complète des Disponibilité Intégrité Instalabilité
ilité ge é
ressources
Remplaçab
Appropriée Capacité Opérabilité Robustesse Rejet Analysibilité
ilité
Protection
Responsabil
contre les Restaurable Modifiable
ité
erreurs
Authenticit
Ergonomie Testabilité
é
Accessibilit
é
Comment la fonction rend le service
59
Test Basé sur les Risques DO178
Plus le niveau de criticité est proche du niveau A, plus le nombre

d'objectifs à tenir est élevé.
Classer les contraintes ci-dessous dans l’ordre d’importance
Revues
Couverture des instructions (code)
Couverture des décisions (if du code)
Couverture des conditions (&, or du
code)
Couverture fonctionnelle
Traçabilité
Inspection du respect de la norme
Indépendance des tests
60

• Niveau E :
• Le développement logiciel n'est soumis à aucune contrainte particulière.
• Niveau D :
• Le logiciel doit être documenté la liste de documents à fournir est fixée par la norme (voir plus bas).
• Préalablement au développement, des plans doivent être établis pour fixer les méthodes de
développement, de vérification, de gestion de configuration, d'assurance qualité.
• Il faut assurer et vérifier la traçabilité entre les spécifications du système, les spécifications de haut
niveau du logiciel, et les vérifications.
• Tout ce qui est spécifié doit être formellement vérifié : la couverture fonctionnelle doit être assurée.
Les documents doivent aussi être formellement vérifiés.
• Le logiciel doit être géré en configuration, par exemple toutes les évolutions du code source doivent
être justifiées
• Un service Qualité indépendant doit assurer le respect de la norme en inspectant les sorties du cycle
de vie du logiciel.
• Niveau C : en plus des contraintes du niveau D :
• Des règles de développement doivent être fixées au préalable (sur les phases de spécification,
conception et codage)
• Les contraintes de traçabilité et de vérification s'appliquent également aux phases de conception et
de codage du logiciel.
• Les exigences de bas niveau (ou exigences de conception) doivent être formellement vérifiées.
• La couverture structurelle, ou couverture de code, doit être vérifiée et analysée : toutes les instructions
du code doivent avoir été exécutées et testées, tous les écarts doivent être justifiés. Ces contraintes
amènent souvent à devoir passer des tests unitaires.
• Niveau B : en plus des contraintes du niveau C :
• La couverture de code au niveau "décision" est requise.
• Les activités de développement et de vérification doivent être confiées à des équipes
indépendantes.
• Niveau A : en plus des contraintes du niveau B :
• La couverture de code au niveau "condition"/"décision" est requise.
61

Exemple d’étude d’un problème
arrivé en production
 Graphe de cause à effet, d’Ishikawa
Un fichier PDF Pas d’exigences Main

(Pas de fichiers
spécifique à généré
types)
d’œuvre
une erreur
Méthode
Pas de pilote
Un type de
fonctionnel
Matériel spécifique sur W7
Incident en contrat n’est pas
correctement
Matière Milieu production imprimé
Driver universel Go donné suite à
livré par Lexmark document Office •Main d’œuvre
passé OK Compétences Métier, habitude de travail
L’Imprimante a 10
•Matériel
ans d’existence. Communication entre
5000 exemplaires Environnement de test, outils utilisés
Lexmark et DET ? •Méthode
Normes mises en œuvre, processus de
tests
•Matière
Package, solution logicielle
•Milieu
Processus de fabrication DET,
Communication
62

Test Basé sur les Risques - AMDEC
Fréquence
Modes de Moyens de d’occurrenc Détection Actions de
Causes Effets Sévérité IPR
défaillance détection e prévention
0
0
0
0
0
0
0
AMDEC (FMEA)
Analyse des modes de défaillance de leurs effets et de leur criticité
Indice de Priorité d’un Risque = Sévérité * probabilité d’occurrence *

Probabilité d’occurrence de détection
63
AMDEC
SEVERITY EVALUATION CRITERIA
Effect Criteria: Severity of Effect Ranking
Hazardous- Very high severity ranking when a potential failure 10
mode effects safe system operation
Without and/or involves noncompliance with a government
warning regulation without warning
Hazardous- Very high severity ranking when a potential failure 9
mode effects safe system operation
With and/or involves noncompliance with a government
warning regulation with warning
Very High System / item inoperable, with loss of primary function 8
High System / item operable, but at a reduced level of 7
performance. Customer dissatisfied.
Moderate System / item operable, but comfort / convenience 6
item(s) inoperable. Customer experiences discomfort.
Low System / item operable, but comfort / convenience 5
item(s) operable at a reduced level of performance.
Customer experiences some dissatisfaction.
Very Low Fit & Finish / Squeak & Rattle item does not conform. 4
Defect noticed by most customers.
Minor Fit & Finish / Squeak & Rattle item does not conform. 3
Defect noticed by average customers
Very Minor Fit & Finish / Squeak & Rattle item does not conform. 2
Defect noticed by discriminating customers
None No effect 1
64

OCCURANCE EVALUATION CRITERIA
Likelihood Failure Mode Will Occur
Probability of failure Possible failure Rates Ranking
Very High: Failure is almost inevitable > or = 1 in 2 10
High: Repeated Failures 1 in 8 8

1 in 20 7
Moderate: Occasional Failures 1 in 80 6
1 in 400 5
1 in 2,000 4
Low: Relatively few failures 1 in 15,000 3
1 in 150,000 2
Remote: Failure is highly unlikely < or = 1 in 1,5000,000 1
65
AMEC
DETECTION EVALUATION CRITERIA
Likelihood the cause will be detected using the process controls

Detection Criteria: Likelihood of Detection by Process Control Ranking
Absolute Process Control will not and/or cannot detect a potential 10
Uncertainty cause / mechanism and subsequent failure mode; or
there is no Process Control
Very remote Very remote chance Process Control will detect a 9
potential cause / mechanism and subsequent failure
mode
Remote Remote chance Process Control will detect a potential 8
cause / mechanism and subsequent failure mode
Very Low Very low chance Process Control will detect a potential 7
Low Low chance Process Control will detect a potential 6
Moderate Moderate chance Process Control will detect a potential 5
Moderately Moderately high chance Process Control will detect a 4
High potential cause / mechanism and subsequent failure
mode
High High chance Process Control will detect a potential 3
Very High Very high chance Process Control will detect a potential 2
Almost Process Control will almost certainly detect a potential 1
Certain cause / mechanism and subsequent failure mode
66

4 Qu’est ce que le test
67
Fondamentaux des tests
 Que sont les tests ?

 « Que choisir » présente une comparaison de pulls
 Pourquoi les ont-ils testés ?
 Quand vous achetez un pull dans un magasin, vous attendez vous à

trouver des défauts ?
 Pourquoi le testez vous ?
 Et le magasin l’a-t-il vérifié ? Comment ?
 Et le fabriquant ? Comment ?
 Et le vendeur de laine ?
68

 Assurance qualité
 Assurance Qualité: CMMI, Livrer des produit ' de qualité '
 REQM, VER, VAL
 Tests de réception de livrable, tests des livrables, tests d'intégration dans le

SI ou les systèmes, tests d'acceptation des utilisateurs
Mettre en œuvre des actions qui vont garantir que le produit sera de qualité
Formation
Analyse des Causes Racines

Assurance
Qualité
Contrôle qualité
Amélioration continue
69
 Contrôle qualité
 Vérifier le produit après fabrication
Des tests rigoureux des systèmes et de la documentation peuvent

aider à réduire les risques d'occurrence de problèmes dans
l'environnement opérationnel et contribuent à la qualité des
systèmes logiciels, si les défauts découverts sont corrigés avant la
livraison du système pour un usage opérationnel
70

Prévenir les défauts
« Contrairement au test dynamique, qui exige l'exécution du logiciel, les

techniques de tests statiques reposent sur l'examen manuel (revues)
ou l'analyse(analyse statique) du code ou de la documentation du
projet sans exécution du code. »
 Qu’est ce qui peut être passé en revue ?
 Toutes les bases de tests
 Le code
 Tout le testware
 Les manuels
 ....
 Bénéfice ?
 Identifier les défauts avant qu’ils ne soient codés
 Des défauts difficiles à trouver dynamiquement
 Améliorer la productivité
 Réduire les couts et le temps
 Améliorer la communication
71
 Revue des exigences: Permet de s'assurer que les exigences sont

complètes, précises, compréhensibles, uniques.
➢ Permet de détecter au plus tôt des défauts qui pourraient être causés par
la méprise du développeur
➢ User stories, EPIC
➢ Architecture
➢ Code
➢ Guides utilisateur
➢ Contrats, plans, budgets
➢ Modèles formels comme UML, BPMN
 Revue des spécifications de tests: Permet de vérifier la couverture des
tests
 Revue du testware: Permet de vérifier que tous les tests prévus ont été
réalisés
72

 Types de défauts trouvés
 Défauts d'exigence (p. ex. incohérences, ambiguïtés, contradictions,

omissions, imprécisions et redondances
 Défauts de conception (p. ex., algorithmes ou structures de bases de
données inefficaces , couplage élevé, faible cohésion)
 Défauts de codage (par exemple, les variables avec des valeurs non
définies, les variables qui sont déclarées mais jamais utilisées, code
inaccessible, code dupliqué
 Ecarts par rapport aux normes (p. ex., manque de respect des normes de
codage)
 Spécifications d'interface incorrectes (par exemple, différentes unités de
mesure utilisées par le système appelant et le système appelé)
 Vulnérabilités de sécurité (p. ex., possibilités de débordements de buffers
 Manques ou inexactitudes dans la traçabilité ou la couverture avec les
bases de tests (p. ex., tests manquants comme critères d’acceptation
73
 3.1 Techniques statiques et processus de test (K2)

Statique Dynamique
Objectifs Identifier des défauts avant Identifier les défaut

le développement savant de passer à
l'étape suivante
Types de défaut Défauts, Omission, Défaillances
redondance, non précision
EDB Tests
d'acceptation
Conception
générale Tests
Systèmes
DCG, SFG
Tests
Architecture
d'intégration
de composants
Tests
Codage de composants
74

Prévenir les défauts - Processus de revue
 ISO20246 précise les rôles, process, type de revues

 Revue formelle: revue par les pairs, inspection
 Rôles: Management, Modérateur/Facilitateur, Leader de revue,
Réviseur, Scribe, Auteur
 Phases:
 1. Planification
 2. Lancement/Introduction/Initialisation
 3. Revue/Préparation individuelle
 4. Analyse et communication des problèmes rencontrés (dont réunion)
 5. Corrections et rapport
75
 Revue informelle: Un type de revue qui n’est pas basée sur une
procédure formelle (documentée) Ref: ISO 20246
 Relecture technique: Type de revue dans laquelle un auteur conduit la
revue en parcourant avec les participants un produit d’activités. Les
Formalisation
participants posent des questions et font des commentaires sur des

problèmes possibles (D’après ISO 20246)
 Revue technique: Idéalement dirigée par un modérateur formé (pas
l'auteur) , réunion de préparation des réviseurs, discuter, décider
 Inspection: Formelles avec règles et check lists, trouver des défauts
76

Techniques statiques – Synthèse des types de revues
Type de revue Formalisation

Informelle, par les Non formelle Agile
collègues, binôme,
pair
Relecture De non formel Organisée par l’auteur
technique à formel Scribe
Scénarios, simulations
Revue technique Formelle Pairs de l’auteur
Préparation individuelle
Réunion optionnelle
Scribe
Documentation générée
Inspection Très Formelle Règles et checklistes
Préparation individuelle
Rôles à respecter, scribe, facilitateur
Lecteur dédié
Critères d’entrée/sortie, métriques
Peuvent être des revues par les pairs
77
Techniques statiques
 Scénarios et dry runs (Tests à blanc)

 Lignes directrices structurées sur la façon de lire les documents, comment
détecter les défauts
 Dry runs si le format le permet (use case)
 Les revues ne doivent pas être limitées aux documents
 Basés sur les rôles/Persona/Profils Utilisateur
 Evaluation du point de vue des rôles utilisateur
 Utilisateurs finaux
 expérimentés, inexpérimentés, senior, enfants, etc.
 Rôles spécifiques
 Administrateurs, administrateur système, testeur de performance etc.
 Basé sur les points de vue
 (Similaire à basé sur les rôles, Marketing, Concepteur, Testeur, Utilisateur
final)
 Utilisateurs révisent en fonction des risques Produit de leur point de vue
78

Techniques de test
Voir IEEE 29119
Tests Checklist
Statiques exploratoires
Dynamiques
Basées sur
Revue Analyse
l’expérience
informelle statique
Relecture Estimation
technique d’erreur
Revue Boites noires

technique
Fonctionnelles et non
Inspection Partitions
Structurelles d’équivalence
Boites blanches
Valeurs limites
Instructions
Décisions Tables de
décision
Conditions
Tous les Transitions Cas

chemins d’états d’utilisation
79
Le processus de tests
Clôture
 Facteurs influençant le processus Exécution

 Cycle de vie
 Agile ? Implémentation
 Cascade, V ?
Pilotage Conception
 Niveau de test et
Contrôle
 Risques projet et produit
Analyse
 Domaine métier
 Avionique, mixeur moulinex
 Politiques/Pratiques Planification
 Standards
 Contraintes (temps, budget)
Les activités du processus de tests ne sont pas forcément

séquentielles mais parallèle, intégrées, itératives
80

 Activité de Planification (QQOQCCP)

Clôture
• Définir les objectifs de tests
• Spécifier les activités Exécution
• Identifier les rôles et responsabilités des

parties prenantes Implémentation
• Développer la stratégie de test Pilotage

Conception
(approche) et
Contrôle
• Estimer l'effort de test Analyse
• Déterminer le calendrier
• Définir les techniques de test
• Définir les produits de test Planification
• Définir l'organisation
• Définir l'infrastructure de test
• Organiser le management
• Déterminer les risques du projet de test, les mesures et les
indicateurs
• Commenter et consolider le plan de test
81
 Activité de Pilotage & de Contrôle

(Aidé par l’évaluation des critères de sortie, DoD)
• Contrôle : Actions pour atteindre les objectifs du plan

• Ex: Recruter un testeur
Clôture
• Suivi :
• Comparaison de Exécution
l’avancement / plan
• Utilisation des métriques Implémentation
• Evaluer les critères de sortie Pilotage

Conception
et
Contrôle
• Vérifier les résultats des tests/couverture
Analyse
• Déterminer les tests complémentaires
Planification
Voir 5.3
82

 Analyse des tests - « ce qu’il faut »tester »
Clôture
•Identifier et prioriser les conditions de test

Exécution
•Réservation billet
(Conditions
•Réservation borne de tests)
•Réservation guichet •Plan de Implémentation
•A/R Paris Roissy (Cas de tests)
test Pilotage
et Conception
Contrôle
Analyse
•Stratégie
retenue
Vous n’avez jamais
vu le logiciel Planification
développé •Critères de succès

Vous découvrez les du projet
Spécifications…
•Base de test
Analyse •Objectifs de test Conditions
•Risques produit de tests
83
 Analyse des tests (Quoi tester)
 Réviser les bases du test (Exigences, analyse de risque, Spécifier

l'architecture, la conception et les interfaces)
• Evaluer la testabilité des exigences et du système
• Mettre en œuvre le BDD, ATDD
• Identifier les défauts :
• Ambiguïtés
• Omissions
• Inconsistances
• Inexactitudes
• Contradictions
• Eléments superflus
• Identifier les fonctions/ensembles de fonctions à tester

• Identifier et prioriser les conditions de test sur la base de l'analyse des
articles de test, la spécification, le comportement et la structure du
logiciel
• Utilisation des techniques de test

• Peut conduire à des chartes de test
84

 Conception des tests (Comment tester ?)
• Transformer les conditions de test en cas de tests et suitesClôture

de test
• Concevoir et prioriser les tests de haut niveau
• Identifier les données de test nécessaires pour les conditions de test et
Exécution
les cas de test

Implémentation
• Concevoir l'environnement de test et identifier les infrastructures et
outils requis Contrôle Conception
• Créer une traçabilité bidirectionnelle entre lesetbases
suivi de test et les cas
de test Analyse
• Permet d’identifier des défauts

Planification
•Réservation guichet (Conditions de tests)

•A/R Paris Roissy (Cas de tests de haut niveau)
85
 Implémentation (on est livré, est ce qu’on a tout ce qu’il faut ?)

• Finaliser, développer et prioriser les cas de test, les procédures de tests
• Créer des suites de tests
• Construire/Vérifier les environnements (simulateurs, données)
• Accepter la livraison
• Automatiser les tests
 Exécution
• Exécuter les tests
• Consigner les résultats et les comparer aux
attendus
• Analyser les anomalies
• Signaler les défauts sur la base des défaillances observées
• Enregistrer les résultats des tests
• Répéter les tests
• Vérifier et mettre à jour la traçabilité bidirectionnelle
86

 Activité d’achèvement des tests
1. Vérifier quels livrables prévus ont été livrés Clôture
2. Clôturer les rapports d'incidents

3. Créer des demandes d'évolution Exécution
4. Documenter l'acceptation du système Implémentation

• Évaluer la qualité de l’objet testé
• Evaluer le processus de tests Contrôle Conception
et suivi
• Sauvegarder le testware
5. Fournir les testware à la maintenance Analyse
6. Capitaliser le testware pour réutilisation

Planification
87
Gestion des tests
 Organisation des tests

Organisation des • Contribuer à la stratégie de tests et à sa rédaction et aux évolutions du plan de tests
tests
Conception des • Analyser les documents entrants de spécification, en extraire les exigences et en
tests dériver les tests (Bases de tests)
• Spécifier les cas de tests en conformité avec le plan de tests maitre associé
o Tests fonctionnels, d’ergonomie, de performance...
o En fonction de l’approche de tests précisée dans le plan de tests
o En fonction de la couverture demandée et de la criticité du produit.
• Identifier la couverture des environnements de tests nécessaires
Implémentation • Demander le déploiement des environnements de tests spécifiés
• Valoriser les cas de tests
• Vérifier la documentation remise avec les objets en tests
• Vérifier les livraisons
Exécution des • Exécuter les tests
tests • Rapporter factuellement les anomalies
• Vérifier les corrections , effectuer les re-tests
• Clore les fiches d’anomalies
Clôture • Participer aux réunions de retours d’expérience ou rétroactives
• Archiver le testware et le rendre disponible dans l’organisation
Processus • Informer de la prise en charge des commandes, de leur avancement et clôture.
88

Produits d’activité du Processus de Tests
Activité Livrable
Planification des tests 1 ou plusieurs Plans de tests (5.2)
Suivi et contrôle Rapports de test réguliers, Rapports
de synthèse des tests (à des jalons)
Analyse des tests Conditions de tests priorisées,
chartes de test
Conception des tests Cas de tests abstraits, identification
des données, outils, infras,
procédures de test
Implémentation des tests Planning, suites de procédures de
test, suites de test
Virtualisation, scripts automatisés
Données concrètes (cas de test
concrets)
Exécution des tests Fiches d’anomalies, Etats
Clôture des tests Bilan projet
89
2
LES DIFFÉRENTS TYPES ET NIVEAUX DE TESTS
Appréhender les différents types et niveaux
de tests
Connaître les bonnes pratiques de tests
90

Cycle de vie
 De nombreux tests sont réalisés dans un cycle de développement

Objectif ? Objectif ? Objectifs ? Tests
d’acceptation
Tests de Tests Tests
composants d’intégration systèmes
• Les objectifs de ces tests sont différents

• Le développement d’un logiciel suit un Objectifs ?
cycle similaire
91
Cycle de vie
 Les modèles de développement logiciel
Conception Niveaux de
tests
Exigences de haut niveau Tests Validation que le produit

d'acceptation
Expression de besoins
correspond au besoin
Conception
générale Tests
Systèmes
DCG, SFG
Activités de
conception
Vérification que ce qui est
Tests
Architecture
d'intégration développé corrrespond aux
de composants spécifications
Activités de Tests
développement Codage de composants
Conception des
tests au plus tôt
92

Cycle de vie
 Adaptation des modèles de développement
scrum
sprint
Scrum
Scrum
daily
24 hrs
•Sélection/chiffrag sprint
e des Stories/Tests
du Sprint 2-4 semaines
• Raffinement des •Choix des types
Epics et UC en de tests à réaliser
•Tests manuels
Stories
•Automatisation
Planification du Revue
Planification du Planning de sprint Atelier de Grooming Rétrospective
produit Planning de sprint de Sprint
Revue
produit Rétrospective
burndown
Afficher charts Démonstration
l’avancement Analyse de code
…
94
Cycle de vie
 Le cycle en V
Exigences
légales
Tests Tests Tests Tests

Exigences Exigences d'acceptation d'acceptation d'acceptation d'acceptation
Métier opérationnelles Utilisateur opérationnelle contractuelle réglementaire
Conception Tests
générale Systèmes
A chaque étape de conception

Architecture
Tests correspond une étape de tests
d'intégration
de composants
Tests
95

Cycle de vie – Niveaux de test
Niveaux de
Conception tests Tests de composants
Composant : un élément logiciel minimal qui

EDB Tests
d'acceptation peut être testé isolément.
Conception
générale Tests
Systèmes Objets habituels de test:
DCG, SFG
•Composant
Architecture
Tests •Conversions de données / utilitaires ou
d'intégration
de composants Programmes de migration, ou en C
Tests
•Modules de bases de données ou java
•Un programme (en C)
Ou tests
unitaires Bases de tests:
•Exigences des composants
•Conception détaillée
•Code
Peuvent inclure des tests de fonctionnalités et des tests de caractéristiques non-

fonctionnelles, telles que le comportement des ressources (p.ex. fuites mémoire) ou des
tests de robustesse, ainsi que des tests structurels (p.ex. couverture des branches).
96
Le Développement piloté par les tests

• Le développeur conçoit le test automatisé avant le
développement.
• Les tests documentent le code et facilitent la phase
de maintenance
• Les tests automatisés sont rejoués en non régression
en intégration continue
1 Ajouter un
test
2 Exécuter le
test 5 Refactoriser
le code
3 Ecrire le code 4 Exécuter tous

jusqu'au succès les tests avec
du test succès
97

Intégration de composants
Bases de Tests:
•Conception du logiciel et du système
•Architecture
•Workflows
•Cas d'utilisation
Objets habituels de test:

•Sous-systèmes
•Implémentation de bases de données
•Infrastructure
•Interfaces
•Configuration système et données de configuration
Stratégies d'intégration systématique
•Basées sur l'architecture des systèmes (telles que top-down ou bottom-up),
•les tâches fonctionnelles, (en gardant l’objectif de tester les interfaces…)
•les séquences d'exécution de transactions,
•ou d'autres aspects du système ou du composant
98
Dans la réalité,
plusieurs niveaux
d'intégration
peuvent être
nécessaires
Tests
d'intégration
système
« Une intégration système à

grande échelle peut arriver
après les tests d'acceptation
du système »
Intégration : le processus de combiner des composants ou

systèmes en assemblages plus grands.
99

De haut vers le bas - Tests top-down :
une approche incrémentale des tests
d'intégration où les composants en haut de la
hiérarchie sont testés d'abord, avec les
composants de niveau inférieur simulés par des
bouchons. (harnais de tests)
Les composants testés sont ensuite utilisés pour
tester des composants de niveaux inférieurs. Le
processus est répété jusqu'à ce que les
composants de plus bas niveau ont été testés.
Test d'intégration : test effectué pour découvrir des défauts dans les interfaces et les
interactions entre des composants intégrés.
Test d'interface : un type de test d'intégration qui porte sur le test des interfaces entre
les composants ou systèmes.
Interopérabilité : a mesure selon laquelle deux ou plusieurs composants ou systèmes
peuvent échanger de l'information et utiliser l'information qui a été échangée. D’après
ISO 25010
100
Test de bas en haut – Bottom up :
Une approche incrémentale des tests
d'intégration ou le niveau le plus bas des
composants sont testés d'abord, et ensuite
utilisés pour faciliter les tests des composants de
plus haut niveau. Ce processus est répété
jusqu'au test du composant le plus haut de la
hiérarchie
Test Big-Bang : un type de tests d'intégration dans lequel les éléments logiciels,
matériel ou les deux sont combinés en une fois en un composant ou un système
complet, plutôt qu'effectué par étape
Afin d'isoler facilement les fautes, et détecter les défauts au plus tôt,
l'intégration devrait normalement être incrémentale plutôt qu'être
effectuée en une fois (“big bang”).
101

Tests système: le processus de test d'un système

intégré pour vérifier qu'il réponde à des
exigences spécifiques.
Bases de Test:
•Spécifications d'exigences Système et logiciel
•Cas d'utilisation
•Spécifications fonctionnelles
•Rapports d'analyse des risques
Objets de tests habituels:
Manuels système, utilisateur et opérationnels
Configuration système et données de
configuration
•Les tests systèmes traitent le comportement d'un système/produit complet

•L'environnement de test devrait correspondre à la cible finale ou à un environnement
de production
•Les tests système peuvent inclure des tests basés sur les risques et/ou sur les
spécifications et les exigences, les processus commerciaux, les cas d'utilisation, ou autres
descriptions de haut niveau du comportement du système, les modèles de
comportement, les interactions avec le système d'exploitation et les ressources système
102
 Tests système: Sont toutes les

vérifications effectuées avant de livrer
le client
Concernent
•Les exigences fonctionnelles
•Les exigences non fonctionnelles
•Performance, ergonomie,....
103

 Tests d'acceptation
• Bases de test
• Exigences utilisateur
• Exigences du système
• Cas d'utilisation
• Processus métier
• Rapports d'analyse des risques
• Objets habituels de test
•Processus métier sur l'intégralité du système
•Processus opérationnels de maintenance
•Procédures utilisateur
•Formulaires
•Rapports
•Données de configuration
•Les objectifs des tests d'acceptation sont de prendre confiance dans le système, dans
des parties du système ou dans des caractéristiques non-fonctionnelles du système.
•La recherche d'anomalies n'est pas l'objectif principal des tests d'acceptation.
•Les tests d'acceptation peuvent évaluer si le système est prêt à être déployé et utilisé
104
 Les tests d'acceptation peuvent se

faire à plusieurs niveaux de tests, par
exemple:
• Des tests d'acceptation peuvent
avoir lieu sur un composant sur
étagère quand il est installé ou
intégré.
• Les tests d'acceptation de la

capacité d'utilisation d'un
composant peuvent être effectués
pendant les tests unitaires.
• Les tests d'acceptation d'une

évolution fonctionnelle peuvent
être exécutés avant les tests
système.
105

Tests
d'acceptation
opérationnelle
 Tests d'acceptation utilisateur

Ces tests vérifient l'aptitude et la capacité
d'utilisation du système par des utilisateurs.
 Tests (d'acceptation) opérationnelle

L'acceptation du système par les
administrateurs système, dont:
•Tests des backups et restaurations;
•Reprise après sinistre;
•Gestion des utilisateurs;
•Tâches de maintenance;
•Chargements de données et tâches de
migration
•Vérification périodique des vulnérabilités de
sécurité.
106
Test Tests Tests Tests

Exigences Exigences d'acceptation d'acceptation d'acceptation d'acceptation
Métier opérationnelles utilisateur
opérationnelle contractuelle réglementaire
 Tests d'acceptation contractuelle et réglementaire

• Sont exécutés sur base des critères d'acceptation contractuels.
• Les critères d'acceptation devraient être définis lors de la rédaction du
contrat.
• Les tests d'acceptation réglementaires sont exécutés par rapport aux
règlements et législations qui doivent être respectés, telles que les
obligations légales, gouvernementales ou de sécurité.
 Tests alpha et beta (ou sur le terrain)
• Les Alpha tests sont exécutés sur le site de l'organisation effectuant le
développement mais pas par les équipes de développement.
• Les Béta tests ou tests sur le terrain sont exécutés par des personnes sur
leurs sites propres
 Tests sur site ou acceptation usine: Tests effectués sur le site du
développeur avant transfert du système sur le site client.
107

Formaliser les tests
 Condition de test : Un aspect des bases de test qui est pertinent pour
atteindre des objectifs de test spécifiques.
Synonymes : exigence de test, situation de test
 Cas de test :Un ensemble de conditions préalables, de données d'entrée,

d'actions (le cas échéant), de résultats attendus et de postconditions,
élaboré sur la base des conditions de test. Ref :
D’après ISO 29119
 Suite de tests : Ensemble de cas de test ou de procédures de test à

exécuter dans un cycle de test spécifique.
Synonymes : Suite de cas de test, Ensemble de tests
 Procédure de test : Une séquence de cas de test dans l'ordre d'exécution,

et toutes les actions associées qui peuvent être nécessaires pour mettre en
place les préconditions initiales et toutes les activités de bouclage après
l'exécution.
108
 Cas de test abstrait (de haut niveau)

Un cas de test sans valeurs concrètes pour les données d'entrée et les résultats
attendus. Voir aussi : Cas de test de bas niveau Synonymes : cas de test
abstrait, cas de test logique
 Cas de test concret: un cas de test avec des valeurs concrètes en

entrée et en sortie.
Voir aussi : Cas de test de haut niveau Synonymes : Cas de test
concret
 Cas de test bloqué : cas de test ne pouvant être exécuté parce que
les pré-conditions pour son exécution ne sont pas réalisées.
 Faux-positif : Voir faux-échec : Un résultat de test dans lequel un
défaut est rapporté alors qu’en réalité ce défaut n’existe pas dans
l’objet de test. Antivirus détecte un virus qui n’en est pas un
 Faux négatif: Un résultat de test qui n’a pas identifié la présence d’un
défaut qui est réellement présent dans l’objet de test
Antivirus ne détecte pas un virus
109

 Dites également « de comportement »
 Conditions de test, Cas de test et Données de test dérivés des exigences,
spécifications, cas d'utilisation et US
 les cas de test détectent les écarts entre les exigences et leur mise en
œuvre
 Couverture mesurée en fonction des éléments testés dans la base de test
et de la technique appliquée
Exemple
Un plan de tests décompose la réservation d’un billet
d’avion en 3 conditions de tests Conditions de
tests extraites des
SFG
•Réservation à la borne
Nouveau billet Nantes Paris, 1
•Réservation au guichet Cas de tests personne
•Réservation en agence cas de tests
Resultat attendu: Billet imprimé
Aller à l’aéroport
procédure de tests Aller à une borne libre
Si pas libre appeler hotesse
Comment vais je faire pour tester ? Exécuter cas de test A
110
 Le test de
validation de la
User Story est
prévu avant son
développement
(Critères
d’acceptation)
111

Objectifs de test
 Les objectifs de tests peuvent varier :

 Evaluer des produits du travail
 Exigences, US, Conception, code
 Vérifier l’atteinte des exigences

 Vérifier que l’objet en test est complet et fonctionne comme attendu
 Prendre confiance dans le niveau de qualité
 Prévenir les défauts
 Trouver des défaillances et des défauts
 Fournir de l’information aux parties prenantes
 Réduire le risque d’avoir une faible qualité
 Respecter des exigences légales, des standards
112
Objectifs de test
 Que sont les tests ?

 Les objectifs de tests peuvent varier :
Objectif de tests Phase de tests

Trouver des défauts Tests systèmes, de composants,
d'intégration
Acquérir de la confiance sur le Acceptation utilisateurs,
niveau de qualité opérationnelle
Fournir de l'information utile aux Tests d'acceptabilité, acceptation

prises de décision
Prévenir des défauts Revues d'exigences, de

spécifications
113

La communication
 La réussite d'un projet repose en grande partie sur des facteurs humains.
• La diversité des profils avec des objectifs propres, composant les parties
prenantes, nécessite de bâtir et de mettre en œuvre un plan de
communication projet, bien construit.
• Cette tâche passe par l'analyse des cibles, le choix des moyens de
communication, le budget associé et la planification des actions de com
(réunions, comptes-rendus...).
 Préparation du plan de conduite du changement

• Associée avec le plan de communication, la problématique du
changement doit être pensée assez tôt de manière à anticiper les
résistances et budgéter les actions nécessaires.
• Par exemple, des formations à dispenser.
114
La communication
Entre le chef de Entre les différents acteurs

projet et le client du projet
Le chef de projet
Réunion de travail hebdomadaire
• Est à l’initiative des communications Coup de téléphone hebdomadaire,,,
Mails
• Doit éviter l’effet tunnel
Pour informer
• Informe régulièrement le client Pour suivre l’avancement
• Participe aux réunions, instances
 Gérer un projet, c’est communiquer
115

 Communication du chef de projet
 C’est le chef de projet qui est à l’initiative des communications et non l’inverse.
 Il doit éviter l’effet tunnel
 A vous d’élaborer et d’informer le client de vos moyens de communications.
Par exemple:
• Une réunion hebdomadaire
• Un mail récapitulatif tous les 15 jours…
• Un coup de téléphone hebdomadaire
• Par Facebook, Tweeter.,,,.
 Vous devez gérer aussi l’échange de données informatiques
 Communication entre les différents acteurs du projet

Le chef de projet doit être en permanence informé du travail réalisé par les acteurs
du projet.
 Mise en place des moyen de communication entre les acteurs. Par exemple:
• Une réunion de travail hebdomadaire
• Un mail récapitulatif après chaque séance de travail…
• Un coup de téléphone hebdomadaire,,,
• Par Facebook, Tweeter.,,,.
116
Plan de communication
 Objectifs (exemples)  Quelles informations doit-il contenir ?
 Aider à des prises de  Que veulent connaitre les destinataires ?

décisions  Définir
 Alerter sur des difficultés  Le type d'information,
 Informer de l'avancée  Pour quelles phases du projet
d'un projet
 Obtenir un support Exemples:
 Obtenir des ressources  le tableau de bord de pilotage du projet
complémentaires
 le suivi budgétaire
 S'assurer que rien n'est
oublié  le suivi du planning
 Préparer le terrain pour  le suivi des livrables

conduire un  les retards et autres difficultés rencontrées
changement…
 les risques mis à jour
 les décisions prises
 Qui sont les destinataires ?
(exemples)
 l'équipe projet
 le sponsor du projet
117

Communication du chef de projet
– Différentes instances de pilotage
– Comité stratégique
– Comité des changements
– Comité de pilotage
– Comité de chantier
– Objectifs
– Anime et coordonne la réalisation des travaux
– Suit de manière détaillée l’avancement du/des projets
– Examine les points critiques
– Arbitre et organise les priorités à donner
– Suit les risques liés au projet
– Membres
– Managers, personnes impliquées
– Fréquence
 A définir
 Livrables
 Suivi de projet (Risques, Avancement, Qualité)
118
Analyser et documenter les résultats de test
119

Analyser et documenter les résultats de test
120
Exemple de Tableau de bord de suivi de projet

Réalisations, acquis et faits marquants Prochaines étapes
◼ ◼ Mettre en conformité le projet avec chiffrage
Recrutement de l’équipe ◼
Rédaction du Plan Projet Jours total budgetés (hors Gest.proj) 164

Avt de la TRA (hors WebServices) 70%
Chiffrage de la conception Total consommé en jours 132
% de jours consommés/budgétés 80%
Nbre total de jours de préparation 85

Avancement de la préparation des tests 89%
Jours de préparation consommés 77
% de jours prepa conso/total budgété 91%
Nbre total de jours d'exécution 79

Avancement de l'exécution des tests 48%
Jours d'exécution consommés 55
% de jours exé conso/total budgété 42%
Produit / Date de fin Date de fin Motif / validation

Modification de planning Sous-Produit initiale reportée
Décisions attendues
Problématique Décision attendue Responsable Échéance
Recrutement en attente RH donne son accord RD 31 octobre
121

5 Outils
122
Outils de support aux tests
 Outil de test
• Un produit logiciel qui supporte une ou plusieurs activités de tests,
tel la
• planification et le contrôle,
• la spécification,
• la conception des fichiers et données initiaux,
• l'exécution des tests et
• l'analyse des tests
123

Exemples d'outils
Autres
Editeurs
Test Modeling
Gestion des exigences Requisite Pro Quality Center TFS2010

/ Doors TestManager
Gestion du
Quality Manager Quality Center TFS2010 Silk
référentiel de tests TestManager Test Manager
Gestion données de test Optim Informatica
Automatisation Functional Tester QuickTest Pro TFS2010 Silk Test Selenium

VisualStudio
Test Lab
Gestion des Manager Surgient TFS2010
environnements Build Forge LabManagement
TFS2010 Silk Performer
Tests de performances Performance Tester Performance Center
VisualStudio
Tests de sécurité Appscan Security Center
Business
Tests en production ITCam for RTT Availability System center
Center Scom
Gestion des anomalies

Quality Manager TFS2010
Clear Quest Quality Center
(VisualStudio)
Solutions verticales Siebel SAP / TAO
Gestion de projet Test Lab Manager Project Portfolio Project Serveur

Management
Collaboratif Jazz ALM 11 TFS2010
124
 Outils d'aide à la gestion du test et des tests
– Outils de gestion des exigences : un outil qui supporte la

consignation des exigences, des attributs des exigences (p.ex. priorité,
connaissance responsable) et des annotations, et facilite la traçabilité au
travers des couches d'exigences et de la gestion des modifications des
exigences. Quelques outils de gestion des exigences fournissent aussi
des facilités pour l'analyse statique, tel que la vérification de cohérence
et la violation de règles pré-définies de spécification des exigences
Polarion ALM
JIRA Agile
Exemples
125

– Outils de gestion des tests : Outil d’assistance à la gestion des tests et

de contrôle partiel du processus de test. Il offre souvent de nombreuses
fonctionnalités telles que la gestion du testware, la planification des tests, la
traçabilité des résultats, le suivi d’avancement, la gestion des incidents et le
Reporting.
Polarion ALM
Microsoft TFS Quality Center

JIRA Agile
Exemples Avec Plugins de test
126
 Outils de gestion d'incidents (outils de suivi de défauts) : Un

outil qui facilite l'enregistrement et le suivi de l'état des défauts.
– Outils de gestion de configuration : un outil qui permet d’aider à

identifier et contrôler la configuration des composants, leur état en regard
des changements et versions, ainsi que la production de baselines
constituées d’éléments de configuration.
127

 Outils d’aide à l'exécution et à l’enregistrement des tests
 Outils d’exécution des tests : Un outil de test qui exécute des tests
par rapport à un élément de test donné et évalue les résultats par
rapport aux résultats attendus et aux postconditions.
128
Bénéfices de l’automatisation
 Le simple achat, ou la location d'un outil ne garantit par le succès.

Chaque type d'outil nécessite des efforts supplémentaires pour
atteindre des bénéfices réels et durables. S'il existe des
opportunités potentielles de bénéfices à utiliser des outils dans le
test, il existe aussi des risques.
 Bénéfices potentiels à l'utilisation d'outils :

 Réduction du travail répétitif
 Répétabilité et cohérence accrues
 Évaluation objective
 Facilité d'accès aux informations concernant les tests ou leur exécution
129

Bénéfices et risques de l'automatisation des tests

 Risques liés à l'utilisation d'outils
• Attentes irréalistes placées dans l'outil

• Sous-estimation du temps, du coût et de l'effort pour l'introduction
initiale d’un outil
• Sous-estimation du temps et de l'effort nécessaires pour obtenir de
l'outil des bénéfices significatifs et continus de l'outil
• Sous-estimation de l'effort requis pour maintenir les acquis générés par
l'outil.
• Confiance excessive dans l’outil
• Négligence du contrôle de version des éléments de test dans l'outil
130
 Bénéfices et risques de l'automatisation des tests

 Risques liés à l'utilisation d'outils
• Négligence des problèmes de relation et interopérabilité entre les outils

critiques
• Risque de faillite de l'éditeur d'outil, de retirer l'outil, ou de vendre l'outil
à un autre éditeur
• Faible réactivité du vendeur pour le support, les mises à jour, et
corrections des défauts
• Risque de suspension d'un logiciel ou projet open-source ou libre
• Imprévu, comme l'incapacité de support d'une nouvelle plate-forme
131


 Gain en temps (délai et charge)
• Réduction de la charge liée à l’exécution des campagnes de non-

régression
• La charge gagnée par la diminution de l’effort de test pourrait être
réinvestie pour une extension de la couverture de test et ainsi garantir
une meilleure qualité de l'applicatif
• Réduction des délais de recette (lancement des tests sans surveillance
sous réserve de la disponibilité des environnements de recette)
132

 Gain en traçabilité
• Suivi et stockage des jeux de données dans le référentiel de tests

• Remontée des résultats de l’exécution dans le référentiel de tests
133


 Critères d'automatisation des tests
• Fréquence des mises à jour (Pourquoi ?)
• Criticité des fonctions
• Stabilité des fonctions, des IHMs (Pourquoi ?)
Avoir une stratégie
• L'objectif du test automatisé d’automatisation
– (VNR Métier, Flux, Fonctions de code) (Pourquoi ?)
• Avoir des ressources
– Avoir des procédures/cas de tests manuels bien définis
– Ëtre capable de reproduire les conditions initiales de tests (données, état du
système)
– Connaitre la technologie de script
– Maintenir les scripts
– Analyser les résultats
• Avoir un outil compatible avec la solution développée
134
Méthodologie Avantages Inconvénients
Capture/replay Rapide Scripts sensible aux

changements d’IHM
Tests pilotés par les Traite des volumes Investissement dans

données de données la création du moteur
Tests pilotés par Maintenance rapide Investissement dans

mots clés et globale la création du moteur
135

Principes de base pour la sélection des outils
 Evaluation de la maturité de l'organisation, de ses forces et de ses

faiblesses et identification des possibilités d'amélioration du
processus de test par le support d'outils.
 Evaluation au regard d'exigences claires et de critères objectifs.
 Une preuve de concept, à l'aide d'un outil de test pendant la phase

d'évaluation pour vérifier qu'il fonctionne efficacement avec le
logiciel en cours de test et dans l'infrastructure courante ou pour
identifier des modifications requises de cette infrastructure pour
utiliser l'outil efficacement
136
Principes de base pour la sélection des outils

 Evaluation du vendeur (aspects de formation, de support et de
commerce y compris) ou des fournisseurs de service de support en
cas d'outils non commerciaux
 Identification des exigences internes pour le soutien et la tutelle

dans l'utilisation de l'outil
 Evaluation de besoin de formation par rapport aux compétences en

automatisation de tests de l'équipe de test courante
 Evaluation du rapport coût/bénéfice basé sur un cas métier concret
137

 Projets pilotes pour l'introduction d'un outil dans une organisation
 Introduire l'outil choisi dans une organisation commence par un

projet pilote, qui a les objectifs suivants :
• Apprendre l'outil plus en profondeur.
• Voir comment l'outil s'adapte à des processus et pratiques existants, et
comment ces derniers devraient évoluer.
• Décider d'une manière standard d'utiliser, de gérer, de stocker et de
maintenir l'outil et le testware (p.ex. décider d'une convention de
nommage pour les fichiers et les tests, créer des bibliothèques et
définir la modularité des suites de tests).
• Evaluer si les bénéfices escomptés seront atteints pour un coût
raisonnable.
138
Facteurs de succès pour les outils

 Les facteurs de succès du déploiement d'un outil dans une
organisation incluent
• Etendre l'outil au reste de l'organisation de façon incrémentale.
• Adapter et améliorer les processus de façon à les adapter à l'utilisation
de l'outil.
• Fournir de la formation et une assistance aux nouveaux utilisateurs.
• Établir des guides d'utilisation.
• Implémenter une manière de tirer des enseignements de l'utilisation de
l'outil.
• Surveiller l'utilisation de l'outil et les bénéfices recueillis
• Fournir le support pour l'équipe de test pour un outil donné
• Recueillir l'expérience acquise de toutes les équipes
139

6 Amélioration continue
140
Rétrospectives
Eléments couverts par une rétrospective
Sujet Exemple
Processus • Changer l’heure de début du daily stand-up meeting de 9:00 à
9:30 pour que tous les membres soient présent.
• Décider de discuter des obstacles dans la journée pas plus tard.
• Faire plus de raffinement d’exigences pour éviter les surprises
• Mieux définir les taches à réaliser en sprint Sprint Planning pour ne
pas perdre de temps.
• Ajouter l’effort de test du testeur à l’estimation de la taille de la US.
• Analyser la cause racine des défauts et définir les meilleurs types
de test pour adresser ces risques
Equipe • Affecter les tests fonctionnels à un membre de l’équipe

• Inviter un testeur de performances dans l’équipe pour définir des
cas de test spécifiques
Organisation • Faire automatiser les tests dans un centre de test
• Faire du Scrum de Scrum et dispatcher le backlog Produit sur
plusieurs équipes
Relations • Organiser plus d’échanges avec les représentants des utilisateurs
pour mieux comprendre leurs besoins
Outils • Utiliser un outil pour créer les données de test
141

Rétrospectives
Exemple de processus d’une rétrospective 1/2
Après chaque itération de 3 semaines, une rétrospective est organisée par le Scrum
Master
1. Commencer la réunion et préparer les outils et le matériel

• Faire un tour de table et demander à chacun d’évaluer leur expérience de l’itération
• Chaque personne est encouragé à parler librement
• Comparer la liste d’actions avec ce qui a été fait
2. Collecter les données

• La liste des obstacles collectés pendant l’itération est le point d’entrée.
• Demander à chaque participant ce qui a bien fonctionné et ce qui a été problématique
• Encourage les personnes à parler et à participer à la rétrospective
• Utiliser des “innovation games” connue “Turn the table”, “Jeopardy”, or “Speed Boat”.
• Les participants peuvent s’exprimer anonymement en utilisant les postits
142
Rétrospectives
Exemple de processus d’une rétrospective 2/2
3. Discuter des axes d’amélioration

• Le modérateur de la rétrospective, par exemple, les Scrum Master dans Scrum, doit
penser en coach. Il aide les participants à imaginer différentes solutions, mais ne
devrait pas décider comment résoudre les problèmes.
4. Décider des actions pour mettre en œuvre les améliorations

• A partir des solutions potentielles d’une problématique, l’équipe doit en sélectionner
une avec un responsable.
• Ne pas identifier trop d’améliorations
• Aller progressivement, rétrospective après rétrospective est la meilleure façon
d’accompagner le changement
5. Sauver les résultats de la rétrospective dans une liste d’action et terminer la réunion
143

Rétrospectives
 Rétrospective d’itération
 2 heures
 Discuter de ce qui s’est passé
 Identifier des axes d’amélioration
 Finir par un ROTI (Return On Time Invested
➢ L’objectif est de remettre en question le fonctionnement et de
devenir plus efficace.
➢ Innovation games: SpeedBoat Meeting (Turn the table, On refait le
match…)
144
Rétrospectives
Speed boat meeting
 1- Poser le cadre
 Chaque personne dispose de 5 minutes pour préparer individuellement ses
post-its pour les différents éléments du dessin.
 2- Rassembler les informations
 Chacun des membres de l’équipe vient coller ses post-its sur le dessin en
expliquant rapidement chaque point.
 3- Générer de la réflexion
 L’équipe vote pour le ou les sujets qui lui semble(nt) les plus prioritaires à
traiter.
 4- Identifier les actions à mener
 Prioriser. L’amélioration continue doit s’effectuer par petits pas mesurables.
 5- Clore la rétrospective
 Sur chacun des sujets l’équipe élabore un plan d’action qui seront mises en
place dès le sprint suivant.
145

Rétrospectives
 http://www.qualitystreet.fr/2017/02/19/retrospective-agile-mes-
exercices-favoris/
 Et vous, comment vous-sentez-vous aujourd’hui ?
146
Assurance Qualité Logiciel
Démarche Qualité
Objectif
 Mise en place d’une politique de gestion de la qualité appropriée aux
besoins d’une l’entreprise.
Principe
 Description des moyens à mettre en œuvre et les étapes pour la mise
en place d’un système qualité ou pour l’amélioration d’un système
existant.
147

Démarche Qualité : Roue de Deming
Planifier : Établir les objectifs et les

processus nécessaires pour fournir des • Développer : Mettre en œuvre les processus
résultats correspondant aux exigences des
clients et aux politiques de l’organisme.
• Controler : Surveiller et mesurer les

Ajuster : Entreprendre les actions processus et le produit par rapport aux
pour améliorer en permanence les politiques, objectifs et exigences du
performances des processus. produit et rendre compte des résultats.
148
Assurance Qualité Logiciel PDCA
 Plan Do Check Act (Roue de Deming)

 Préparer Dérouler Comprendre Agir
 Méthode
 Plan :
 Comprendre le ou les problèmes
 Définir les causes à traiter
 Do
 Choisir une solution de traitement
 Agir
 Check
 Vérifier le traitement (Pareto)
 Act
 Généraliser (modification de
processus)
149

Assurance Qualité Logiciel - Démarche Six Sigma
 Définir : définir le projet, le processus à améliorer, identifier les gains opérationnels et financiers ,
comprendre les attentes des clients (voix du client) et les CTQ appelés aussi Yi , cartographier
le processus ( SIPOC) (Supplier Input Process Output Customer),identifier les facteurs influents
du processus ( appelés Xi)
 Mesurer : mettre sous monitoring le processus pour mesurer simultanément les Yi et XI
, diagrammes d'Ishikawa…après s'être assuré de la capabilité des processus de mesure (R&R ,
kappa)
 Analyser : réaliser une analyse de données pour identifier les facteurs Xi les plus influents sur les
Yi (réponses) cartographie détaillée des processus (par exemple, analyse de la
valeur ajoutée), tests d'hypothèses (ANOVA, χ², tests de variances, …), plans d'expérience…
 Améliorer : trouver des actions d'améliorations relativement aux Xi les plus influentes en utilisant
des outils tels que plans d'expérience, AMDEC, poka yoke…
 Maîtriser : Mettre en place des outils de pilotage du processus. Les objectifs pour l'entreprise
sont de se doter d'actions mesurables et efficaces, de satisfaire ses clients, d'impliquer les
équipes et bien souvent d'améliorer son image.
150
Assurance Qualité Logiciel - Modèle IDEAL (SEI)
Apprendre
Proposer
les actions Analyser et
futures valider
Mettre en
place la
solution
Raffiner la
solution Mettre en
Besoin de Comprendr Construire œuvre La
Définir les
changemen e le le
moyens
transformatio
t contexte sponsorship
Faire un
n
pilote
Initialise
Définir les
r la états actuel
démarch et cible
e
Créer la
Développer les solution
recommandations
Diagnostique
r Planifier les
Définir les actions
priorités Développer
l’approche
Etablir la carte de
transformation
151

Assurance Qualité Logiciel - Modèle IDEAL (SEI)Modèle
IDEAL (SEI)
 Initiating: Initier le processus d’amélioration
 Avant le début des activités d’amélioration de processus, les

objectifs, les buts, le périmètre et la couverture des améliorations
de processus doivent être convenus par les parties prenantes.
 Le choix du modèle d’amélioration de processus est aussi fait à ce
moment. Le modèle peut soit être choisi parmi ceux du domaine
public (tels que CTP, STEP, TMMi, et TPI Next) soit développé en
interne. De plus, les critères de succès devraient être définis et la
méthode à utiliser pour les mesurer tout au long de l’activité
d’amélioration devrait être déterminée
152
Assurance Qualité Logiciel - Modèle IDEAL (SEI)
Initiating
Experts techniques
Tests unitaires
Analyse statique
Performances(loadrunner) Démonstrations
Sécurité
Automatisation (QC, QTP)
Experts processus
(ISTQB Niveau avancé)
Personnes Auditées
Assesseur
Experts
sur et hors site client
+ Evaluation spécifique
Livrables
Scoring des thématiques exprimées
+ (Qualité perçue du processus, axes
d’amélioration proposés)
Services transverses Testing
Utilisateurs Métier Assurance
153

Modèle IDEAL (SEI)
 Diagnosing : diagnostiquer la situation actuelle
 L’approche d’évaluation convenue est mise en œuvre et un

rapport d’évaluation est créé lequel contient une estimation des
pratiques de test actuelles et une liste d’améliorations possibles
des processus.
 Establishing: établir un plan d’amélioration de processus
 Une liste d’améliorations possible des processus est priorisée. La

priorisation pourrait être basée sur le retour sur investissement, les
risques, le respect d’une stratégie de l’organisation, et/ou des
bénéfices qualitatifs ou quantitatifs mesurables.
 Une fois établi l’ordre de priorité, un plan de mise en œuvre des
améliorations est développé.
154
Modèle IDEAL (SEI)
 Acting : agir pour mettre en œuvre l’amélioration

 Le plan d’amélioration des processus de test est implémenté. Cela
pourrait inclure
 toutes les formations ou coaching nécessaires,
 le pilotage des processus
 et leur déploiement complet.
 Learning: apprendre du programme d’amélioration

 Une fois les améliorations de processus entièrement déployées, il
est essentiel de vérifier quels bénéfices ont été atteints (en
considérant les bénéfices escomptés initialement mais aussi les
éventuels bénéfices non-prévus).
 Il est aussi important de regarder quels critères de succès ont été
atteints en termes d’activités d’amélioration de processus.
155

MANUEL QUALITE
 Décrit les procédures définies par une entreprise ou une organisation,

pour atteindre ses objectifs de qualité.
 Répertorie les méthodes et procédures à utiliser pour:
 Gestion de projets
 Réalisation, Vérification, Validation,
 Evaluation de la Qualité (Mesures).
 en s'appuyant sur:
 Rédaction de standards, normes (ISO, DOD..) , conventions,
guides,
 Expérience acquise des projets, pour améliorer le processus.
156
MANUEL QUALITE
 Précise
 L’Activité principale à la base d’une démarche qualité
 Les critères d’évaluation rapide du niveau de l’entreprise
 Le rôle interne pour les employés
 Le rôle externe pour les auditeurs, stagiaires, etc. …
 A l’entreprise les critères d’établissement d’une alliance Outils – Méthodes –

Assurance Qualité.
 Doit
 Etre bien maintenu
 Servir à toute l’entreprise
157

MANUEL QUALITE
 Organisé en 6 parties :
 Organisation de l’entreprise
 Activité de production et de contrôle technique
 Activité de gestion
 Activité de contrôle de la Qualité
 Plan type du Plan Qualité
 Lignes directives pour le Plan d’Assurance Qualité
158
PLAN QUALITE
Définit, pour un projet donné, en accord avec le manuel qualité de

l'entreprise, les
 méthodes techniques
 outils
permettant d'atteindre les objectifs de qualité pour
un coût donné.
Le plan qualité fait partie des éléments contractuels liant un client et

son fournisseur de logiciels.
Il est établi lors de la phase de planification.
159

CMMi - Dans la jungle des normes
Produits du Processus de Outils de

Logiciel livré développementconstitution
Qualité externe Qualité interne développement
de l'offre
• Iso 12119 Progiciel • ISO 9126 SQ • Z 67-142 PCTE
• Z 67-133-1 IHM • Z67-130 PQL • ISO 14102 AGL
• ISO 9241 TTY • IEEE 829 DC • IEEE 1209 CASE
Activités du Processus de Système Qualité

développement développement
• ISO 9001
• IEEE 1012 V&V • ISO 12207
• ISO 9000-3
• Z 67-101 Projet • CMMI, ... • TickIT
• IEEE 830 Spec. • MIL-Std 498
160
CMMi : Identification
 Un modèle pour l’évaluation et l’évolution

 de la maturité d’une organisation (échelle de 1 à 5)
 de la capacité des processus d’une organisation
en matière de développement et maintenance de logiciels
• Le travail de l’organisation est vu comme un processus

• L’évolution de ce processus est systématiquement géré
• Ensemble structuré de bonnes pratiques issues du terrain
• Les pratiques sont groupées en domaines de processus
161

Les domaines de processus CMMI
 Deux modèles
Modèle continu Modèle étagé

Flexibilité du choix d’amélioration Chemin prédéfini et prouvé pour
des processus améliorer le ROI
Grande visibilité d’amélioration pour Focalisation sur le modèle
chaque domaine de processus organisationnel de l’entreprise
Mise à jour aisée EIA 731 Mise à jour aisée depuis SW-CMM
Comparable à ISO 15504
Différents niveaux suivant les Résultats globaux résumés par un
domaines de processus niveau
Vient de l’électronique Vient du développement

logiciel
162
Les domaines de processus CMMI
Dans la représentation étagée chaque

domaine de processus contient :
Niveau de
• des objectifs spécifiques à satisfaire par:
maturité
• des pratiques spécifiques
Domaine Domaine Domaine • pour l’implémentation des

de de de
processus processus processus pratiques qui permettent de
1 2 n
remplir les exigences du
Objectifs Objectifs domaine de processus
spécifique générique Caractéristiques
s s communes
Pratiques Pratiques • des objectifs génériques à satisfaire par:

spécifique générique
s s
• des pratiques génériques
• pour l’ institutionnalisation
(engagement à réaliser,
capacité de réaliser, gestion
et vérification de
Modèle de composants l’implémentation)
CMMI V1.2
163

Les domaines de processus CMMI Etagé
• L’évolution du processus vers une amélioration continue est géré

par Niveau de Maturité Organisationnelle (1 à 5)
• Chaque niveau se
focalise sur un ensemble
imposé de domaines de
processus
• Pour un niveau ciblé, une organisation doit démontrer par une

évaluation qu’elle couvre les pratiques de ce palier et de tous les
paliers inférieurs
164
Les domaines de processus CMMI-DEV - Etagé
 Les niveaux CMMI Etagé
Optimisation 2 PA
5
Maîtrisé 2 PA PA (Process Areas) du
4 niveau 2
Personnalisé 11 PA
3 Gestion des exigences
Discipliné 7 PA
2 Planification du projet
Initial
1 Gestion et suivi de projet
Gestion des fournisseurs
Mesure et analyse
Assurance de la qualité du
produit et des processus
Gestion de configuration
165

Les domaines de processus
CMMi : Niveau CMMI – niveau 2
2 de maturité
 Mise en œuvre effective de

pratiques de base au niveau
des projets mais sans
harmonisation au niveau de
l’organisation.
 Le niveau 2 se focalise
essentiellement sur des
problématiques de gestion
de Projet.
166
CMMi : Niveau 2 de maturité

Les domaines de processus CMMI – niveau 2
MANAGEMENT PP PMC SAM

DE Planification Contrôle Gestion
PROJET de & Suivi Contrats
Projet de Projet Fournisseurs
REQM
INGENIERIE Gestion
des
Exigences
CM MA PPQA
SUPPORT Gestion Mesure AQ
de & Process
Configuration Analyse & Produits
• Les plans sont développés conformément aux directives

• Les activités sont réalisées conformément aux plans
• Les produits sont livrés et fonctionnent Objectif
Activités
• Le processus est défini au niveau de chaque projet Mesures
Livrable
167

Les domaines de processus CMMI – REQM
Exemple
 7 Pratiques spécifiques 1 objectif
 Gestion des exigences REQM
 Specific Goal 1 Gérer les exigences
 SP1.1 Obtenir une compréhension des exigences

5  SP1.2 Obtenir l’engagement sur les exigences
Pratiques  SP1.3 Gérer les changements aux exigences
Spécifiques
pour réaliser  SP1.4 Maintenir la traçabilité biunivoque des
exigences
l’objectif
 SP1.5 Identifier les incohérences entre les produits
du projet et les exigences
168

CMMi : Niveau CMMI – Niveau 3
3 de maturité
 Déploiement harmonisé de
pratiques définies au niveau
organisation
 Le niveau 3 s’adresse à toute la

population et met l’accent sur
l’ingénierie produit et
l’organisation centrale.
 Focalisation sur la capitalisation
169

3 de maturité
CATEGORIES DOMAINES DE PROCESSUS
MANAGEMENT OPF OPD OT

DE Focalisation Définition Formation
PROCESS sur Process du Process Organisation.
Organisation. Organisation.
MANAGEMENT RSKM IPM IT ISM

DE Gestion Gestion Équipe Gestion
PROJET du risque de Projet Intégrée fournisseur
Intégrée intégrée
RD TS PI VER VAL
INGENIERIE Dév.
Solution Intégration Vérification Validation
des
Technique Produit
Exigences
DAR OEI
SUPPORT Analyse Env..Orga.
& Prise pour
de décision l’intégration
Domaines de processus Ciblés par le niveau 3
170

4 de maturité
 Gestion quantitative des processus,

basée sur des analyses statistiques.
 Les performances de l’organisation

sont prévisibles.
 Le niveau 4 se focalise sur

l’élimination des causes spéciales de
variations des performances et la
stabilisation des processus
171

5 de maturité
 Maturité de l’organisation où veille

technologique et amélioration
continue concourent à
l’excellence du processus de
production
 Le niveau 5 se focalise sur les

causes naturelles de variation de la
performances
 La finalité est la maîtrise du

changement pour satisfaire les
objectifs business
172

5 de maturité
CATEGORIES DOMAINES DE PROCESSUS
MANAGEMENT OPF OPD OT OPP OID

DE Focalisation Définition Formation PerformanceInnovation
PROCESS sur Process du Process Organisation. du Process déploiement
Organisation. Organisation. Organisation. Organisation.
MANAGEMENT PP PMC SAM RSKM IPM IT ISM QPM

DE Planification Contrôle Gestion Gestion Gestion Équipe Gestion Gestion
PROJET de Projet et Suivi Contrats du risque de Projet Intégrée fournisseur de projet
de Projet Fournisseurs Intégrée intégrée quantitative
REQM RD TS PI VER VAL

INGENIERIE Gestion Dév Solution Intégration
Vérification Validation
Des des Technique Produit
Exigences Exigences
CM MA PPQA DAR CAR OEI

SUPPORT Gestion Mesure AQ Analyse Analyse Envt .Orga.
de & Analyse Process & Prise causale pour
Configuration & Produits de décision & résolution l’intégration
Passage du Niveau 4 au Niveau 5 : de 18 à 24 Mois

4: Géré
1: Initial 2: Géré 3: Défini 5: En Optimisation
Processus non défini Processus organisé Processus Standardisé Quantitativement Amélioration Continue
Processus Prévisible
Structuration Standardisation Mesure & Prévision Maîtrise du Changement
173

Améliorer le Processus de Test avec TMMi
 Modèle étagé, 5 niveaux
 Basé sur ISTQB CMM,

CMMI, TPI, IEEE829 5- Optimisé
•Prévention des défauts
•Optimisation des processus de test
•Contrôle qualité
 www.tmmi.org 4- Mesuré quantativement

•Métriques de tests
•Evaluation de la qualité
•Revues par les pairs avancées
3- Défini, Institutionnalisé
•Organisation de test
•Programmes de formation aux tests
•Cycle de vie des tests et de l’intégration
•Tests non fonctionnels
•Revues par les pairs
2- Géré
•Politique et stratégie de test
•Planification des tests
•Pilotage et contrôle des tests
•Conception et exécution des tests
•Environnements de test
1- Initial
174
Objectifs:
 Evaluer la maturité des processus de test pour l’ensemble du cycle de vie de

développement logiciel
 Identifier et partager les forces et meilleures pratiques en test pour améliorer

l’efficacité et la rentabilité du test
 Identifier les risques et problèmes relatifs aux projets et aux processus de test
 Définir un plan d’amélioration des processus de test réaliste et mesurable
175

 Structure de TMMI
176
 Exemple de rapport TMMI
177


Première Approche Et Cadre Réglementaire

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Première Approche Et Cadre Réglementaire

Transféré par

Droits d'auteur :

Formats disponibles

Première approche

 Comprendre ce qu'est un projet de développement informatique

Bertrand Cornanguer Reproduction et distribution interdite

 Comprendre le besoin  Comprendre les objectifs de test

 AMDEC, DO178, ISO 26262  Amélioration continue

 Qu'est-ce que le test ?  PDCA / DMAIC / PAQ / TMMi / C

Bertrand Cornanguer Reproduction et distribution interdite

Présentation des participants

•Votre ancienneté dans le monde informatique

Bertrand Cornanguer Reproduction et distribution interdite

Qu’est ce qu’un projet ?

ISO X50-106 :« Démarche scientifique qui permet

Bertrand Cornanguer Reproduction et distribution interdite

 Un projet est différent des opérations/activités des services habituels

 Créer de la valeur, augmenter la productivité

 Un projet est différent des opérations/activités des services habituels

Bertrand Cornanguer Reproduction et distribution interdite

Acteur 1 Acteur 2 Acteur 3 Acteur 4

Bertrand Cornanguer Reproduction et distribution interdite

 Différents Métiers du test

Les parties prenantes du projet

Le Gestionnaire de test, délégué du chef de projet

Organise, planifie, prépare le Plan de tests

Bertrand Cornanguer Reproduction et distribution interdite

Mise en œuvre du Plan Qualité - Revues Qualification

Suivi du projet / Amélioration continue

 Rassemble toutes les informations concernant le projet

A présenter et expliquer aux parties

Bertrand Cornanguer Reproduction et distribution interdite

Ne pas être juge et partie

Test conçu par une autre organisation

Test conçu par une équipe indépendante de

Test conçu par un pair du développeur

Test conçu par le développeur

L’informatique n’est plus considérée

 Concurrence, mondialisation → Réactivité & Agilité

 La nécessaire industrialisation des processus de production de

 Démarche dont finalité est la maîtrise du changement

Bertrand Cornanguer Reproduction et distribution interdite

 Pour le processus de production de logiciels d’une organisation:

• Coûts, Qualité, Délais, Contenu

• Capacité et stabilité du processus

Origine et coût des défauts

Nécessité de la qualité logicielle

30 à 35% des projets initiés ne voient jamais le jour

 Image désastreuse pour certains secteurs,

Le coût global des moyens informatiques

Bertrand Cornanguer Reproduction et distribution interdite

Ce que demande Ce qui est décrit dans Ce que l’analyste a

Tout le monde connaît cette histoire …

Origine et coût des défauts

Bertrand Cornanguer Reproduction et distribution interdite

 Les Erreurs surviennent de

Défaillance <> Défaut

Origine et coût des défaillances

 Dette technique (maintenance à réaliser)

Bertrand Cornanguer Reproduction et distribution interdite

 Les systèmes logiciels deviennent une part intégrante de notre

 Des logiciels ne fonctionnant pas correctement entrainent

 Les risques existent aussi bien dans l'informatique embarquée que

Bertrand Cornanguer Reproduction et distribution interdite

 Dommages à des personnes

 Calibrage du scanner défectueux