Tests & recette - Les fondamentaux

Digital performance.
LES FONDAMENTAUX
VERS UNE CONVERGENCE DES APPROCHES
TESTS & RECETTE
V1.0 2 OCTOBRE 2015 Ch. Dessus

NOUS RESPIRONS, PARLONS & VIVONS L’INNOVATION 24/7
LIKEZ & SUIVEZ-NOUS !
CONTACT
Christine Dessus
chdessus@sqli.com
+33 6 79 87 79 30
SQLI Entreprise Agence de Lyon
1 place Verrazzano
69009 Lyon
Tel : +33 4 72 40 53 53
V1.0 2 octobre 2015
chdessus@sqli.com© SQLI Enterprise – SQLI GROUP | 2015 2

NOUS RESPIRONS, PARLONS & VIVONS L’INNOVATION 24/7
CONTACT
SQLI Enterprise France
268 Avenue du Président Wilson
93210 Saint-Denis La Plaine
Tel : +33 1 55 93 26 26
SQLI Enterprise Suisse
Chemin de la Rueyre 116 - 1020 Renens, VD
Tel : +41 (0)21 637 72 30
SQLI Enterprise Belgium
Kortrijksesteenweg 90 - 9830 Sint-Martens-Latem
Tel : +32 (0)9 329 83 80
V1.0 2 octobre 2015

+La recette vise à
Contrôler le niveau de qualité des produits conçus et implémentés au
regard de l’utilité et de la garantie
Contrôler le respect des spécifications fonctionnelles et techniques
Contrôler le respect du cahier des charges initial
Contrôler l’atteinte des objectifs initiaux du projet
PRINCIPES
V1.0 2 octobre 2015
MOEetMOA
MOA
Commanditaire
Sponsor
La MOA est l’intermédiaire traducteur du commanditaire au service de la MOE.
Elle parle les 2 langues et est donc un acteur essentiel à la recette.

+ La recette est un projet dans le projet
+ La recette doit être planifiée :
› Charges estimées : combien de temps nécessaire (élaboration des documents, passation, rapports, etc.)
› Campagnes de tests planifiées : les tests doivent être prévus dans le planning du projet, comme des phases à part entière.
+ La recette est industrialisée
› La recette doit reposer sur des process clairement établis et documentés, et permettre de produire des résultats : rapports de
test, création d'entrées dans un outil de ticketing, suivi des cas de tests déroulés, organisation des campagnes de test etc…
+ L’efficacité de la recette doit être évaluée
› A la fin de chaque campagne de test
› Au regard de la satisfaction du client/utilisateur, du quota de bugs décelés.
PRINCIPES
V1.0 2 octobre 2015

+ Entre ne pas faire de tests et tout tester, il y a un compromis à trouver.
+ Tester coûte : même si l’on ne teste pas tout, il faut accepter l’effort de test !
+ Certains tests sont plus prioritaires que d’autres :
Ils ont une valeur métier plus importante
La complexité de mise œuvre ou l’éventualité d’impacts avec d’autres composants du système impose des tests techniques
approfondis
+ Le choix des tests et leur organisation dépend du projet, de la situation.
SOYONS PRAGMATIQUES
V1.0 2 octobre 2015

+ Une SSII s’engage sur un taux de défaut client pour la réalisation d’un logiciel
Taux de défaut client = Nb de défauts détectés par le client après livraison / Nb de jours d’activité vendus
(hors pilotage)
+ Engagement pris
Taux de défaut = 0,2
Anomalies bloquantes ou majeures : 2% des anomalies constatées par le client
+ Ces taux de défaut jugés corrects en informatique ne sauraient être tolérés dans
l’industrie.
+ Se convaincre par l’absurde de la non-fiabilité du SI !
POURQUOI TESTER ?
V1.0 2 octobre 2015

+ Exemple d’un aéroport de taille « moyenne »:
environ 25 000 passagers/jour
environ 410 mouvements/jour
Remplissage moyen d’un avion : 60 passagers
+ Indicateurs mesurés
Défaut :
› Incidents avion : décollage, atterrissage, déplacement, du simple accrochage sans
gravité au crash majeur d’un avion
› Impacts passagers : simple blessure sans gravité au décès
POURQUOI TESTER ?
V1.0 2 octobre 2015

+ Taux de défaut inacceptable !!! Un aéroport a un taux de défaut proche de 0% par journée
d’exploitation, en 365/24/7.
POURQUOI TESTER ?
V1.0 2 octobre 2015
Taux de défaut Base de calcul 0,1 0,2 0,3
Impact passagers
Par jour, en 24/7
25000
passagers/jour
2500 personnes / jour 5000 personnes / jour 7500 personnes /
jour
Impact passagers
Taux incident bloquant : 2% >> décès
Par jour, en 24/7
25000
passagers/jour
50 décès / jour 100 décès / jour 150 décès / jour
Incidents avion
Par jour, en 24/7
410
mouvements/jour
41 incidents / jour 82 incidents / jour 123 incidents / jour
Accidents avion
Par jour, en 24/7
Taux incident bloquant : 2% >> crash
410
mouvements/jour
4 crash
majeurs/semaine
>> 300 par an.
8 crash majeurs
/semaine
>> 600 par an
12 crash majeurs /
semaine
>> 900 par an

VALEUR D’UN SERVICE, SYSTÈME (ITIL V3)
VALEUR
V1.0 2 octobre 2015
Garantie
Capacité
Disponibilité
Fiabilité
Maintenabilité
Continuité
Sécurité
« Fit for use »
Utilité
Contraintes
supprimées
Nouvelles
Fonctionnalités
Performance
« Fit for purpose »
Responsabilité de l’équipe projet
MOE & MOA
Responsabilité de l’intégrateur, sur la
base du DAT et procédure d’installation
fournis par l’équipe projet

+ Vérification
Contrôler que le produit fini correspond aux spécifications et aux
exigences
Spécifications, exigences = intentions
+ Validation
Contrôler que le produit fini correspond aux attentes du donneur d’ordre :
sponsor, métier, clients
On va s’appuyer sur le cahier des charges, l’expression de besoin initiale,
le dossier de cadrage du projet.
VÉRIFICATION & VALIDATION
V1.0 2 octobre 2015
Maîtrise
d’œuvre
Maîtrised’Ouvrage
Commanditaire
Sponsor
Maîtrise
d’ouvrage

+ Une expérience d’exécution ou d’usage destinée à trouver des défauts de fonctionnement
Ecart  constat
Diagnostic  quel est le problème ? Où est la cause du problème ?
Est-ce conforme aux intentions ?
+ Un test doit mettre en lumière des écarts, et tout particulièrement des défauts. On recherche un
résultat négatif.
Un test qui ne ramène pas d’anomalies ne sert à rien.
Attention : trop de défauts indiquent une mauvaise qualité de réalisation et doivent conduire au
rejet du produit.
TEST
V1.0 2 octobre 2015

Plusieurs types d’écart
Alerte  événement, information, changement d’état. Exemple : fin d’une
sauvegarde, résultat d’un flux. Une alerte peut se transformer en défaut (échec),
problème (alerte récurrente) ou évolution (amélioration du fonctionnement).
Défaut  écart jugé négatif. Constaté en production : Incident. Constaté en
recette : Anomalie.
Problème  cause inconnue d’un défaut. Lorsque la cause du problème est
connue, le problème devient une évolution.
Erreur connue  un problème non résolu mais avec une solution de
contournement.
Evolution  changement souhaité du fonctionnement nominal, tel que conçu,
spécifié et réalisé.
Non-conformité  écart par rapport aux attendus d’une norme ou d’une
règle.
ECART
V1.0 2 octobre 2015
Ecart
Alerte
Défaut
Problème
Evolution
Non
conformité
Erreur
connue
Un écart est une différence par rapport au fonctionnement nominal du système tel que conçu,
spécifié et réalisé.

+ Evénement, changement d’état.
+ Détectée souvent à l’issue d’un processus ou d’une activité
Positif : c’est une information
Négatif : c’est un souvent un défaut à corriger.
On s’attachera à analyser la récurrence des alertes « négatives »
+ Exemples d’alerte :
Succès ou échec sur la réalisation d’un flux
+ Les alertes sont suivies de façon récurrente en mode pérenne
ALERTE
V1.0 2 octobre 2015

+ Ecart involontaire par rapport au
fonctionnement attendu
+ Plusieurs terminologies
Non-conformité  audit, revue réglementaire ou
vérification de la conformité à une norme
Incident  défaut constaté en mode pérenne
(production)
Anomalie  défaut constaté en cours de construction,
avant le déploiement et l’usage en mode pérenne
DÉFAUT
V1.0 2 octobre 2015
+ Des degrés de gravité
Bloquant : le processus ne s’exécute pas. Il n’y a pas de
solution de contournement.
Majeur : le processus ne s’exécute pas. Il y a une solution
de contournement
Mineur : le processus s’exécute mais on constate des
erreurs non critiques. Il est moins performant.
+ Cela va sans dire … mais…
Un défaut n’est pas une évolution.
Evolution = écart par rapport aux spécifications.
Attention une évolution peut cacher un défaut de
spécification… qui doit être tracé comme tel.

+ Ecart volontaire par rapport au fonctionnement attendu
+ Changement du mode de fonctionnement nominal du système
Non demandé au cahier des charges, Non spécifié, Non réalisé
+ La valeur de chaque évolution est évaluée au regard des attentes du projet :
Objectifs
Garantie
Utilité
+ Les évolutions sont tracées dans le référentiel des exigences
EVOLUTION
V1.0 2 octobre 2015

+ Cause inconnue d’une alerte ou d’un défaut (ITIL)
+ La résolution d’un problème peut être longue.
+ On s’attache aussi à trouver une solution de contournement
PROBLÈME
V1.0 2 octobre 2015
Problème
Erreur
connue
Evolution
Défaut
Alerte
Amélioration

+ C’est un problème dont on connait la solution de contournement
La solution définitive n’est pas encore connue
La solution définitive est connue mais pas implémentée : planifiée mais non réalisée, refusée par la
gouvernance du système : trop chère, trop impactante sur les autres composants du système
+ Les erreurs connues sont généralement intégrées au manuel d’exploitation.
+ La liste des erreurs connues peut être constituée dès les phases de conception et
implémentation.
ERREUR CONNUE
V1.0 2 octobre 2015

+ Stratégie & plan de tests servent à délimiter le périmètre des recettes à mener lors d’un
changement majeur du système
+ La stratégie de tests :
Expression du besoin de tests
Définir l’objectif des tests en fonction des enjeux du projet
+ Le plan de tests :
Spécifications du besoin de tests
Définir les typologies de tests en lien avec chaque phase du projet
Organiser les campagnes de tests, les planifier
Rédiger les cas et scénarios de tests
+ Sur un projet < 100j/h, Stratégie et Plan de tests sont regroupés sur un seul document.
+ Attention au piège : certains très petits projets techniques (<10-20 jours) demandent un effort
de test conséquent du fait des effets de bord potentiels sur d’autres environnements.
STRATÉGIE & PLAN DE TESTS
V1.0 2 octobre 2015

Qualité de
l’information
DES TESTS POUR RÉPONDRE À QUELLE QUESTION ?
V1.0 2 octobre 2015
Montée en charge, Vulnérabilité
Débit, Rapidité, Temps de réponse
Volumes, Exploitabilité, Installation, Intégration
Chargement de données
Pertinence d’une recherche
Cohérence, contrôle règles
de gestion
Technique
Fonctionnel
Limite
Exploratoire
Que de passe t-il si …
Performance
Analyse du comportement
de l’utilisateur
Je n’arrive pas à…
Est-ce que je peux ….
Standard Mesurer la
résistance
aux pannes
Vérifier le
comportemen
t nominal
Vérifier
l’usage
(utilité)
Vérifier les
composants
internes (garantie)

TYPOLOGIES DE TESTS
V1.0 2 octobre 2015
Type Définition Fonctionnel/Technique
Standard/Limite
Revue
documentaire
La revue documentaire permet d’éliminer les défauts (incohérences,
imprécisions, erreurs…) et contribue à fiabiliser le produit final.
Dans l’industrie, la revue documentaire a aussi pour objectif de contrôler la
sureté :
- absence d’impact du produit SI final sur les process industriel
- sécurité des biens et personnes
- criticité des données (perte ou diffusion).
Technique
Fonctionnel
Standard
Limite
Revue de code
Revue de
paramétrage
Relecture du code de l'application ou de son paramétrage en cas
d’intégration d’un outil
Pour la revue de code, il existe des outils automatiques qui inspectent le
code par rapport à des normes prédéfinies.
Technique
Limite
Revues de livrables

TYPOLOGIES DE TESTS
V1.0 2 octobre 2015
Standard/Limite
Tests de mise au
point
Le développeur (intégrateur) contrôle ses réalisations au regard des
spécifications à développer
Fonctionnel
Technique
Standard
Tests unitaires Chaque sous ensemble de l'application est testé de manière séparée.
Ces tests permettent de s'assurer que chaque élément fonctionne
correctement de manière indépendante.
Fonctionnel
Standard et Limite
Tests
d’intégration
S'assurer que les sous ensembles de l'application "communiquent" bien
entre eux et respectent les spécifications d'interface qui ont été définies
dans le projet
 2 à 2 puis 3 à 3 puis n à n
Technique
Standard et Limite
Tests en cours de réalisation

TYPOLOGIES DE TESTS
V1.0 2 octobre 2015
Standard/Limite
Tests de
performance
Un test de performance est un terme générique qui désigne un test dont l'objectif
est de déterminer la performance d'un système informatique (endurance,
robustesse, capacité à monter en charge, temps de réponse…) selon les besoins
du client décrit dans le plan de cadrage du projet, GARANTIE.
Technique
Limite
Tests de
charge
Ce sont des tests de performance pour s'assurer que l'application va être capable
de tenir la charge qu'on lui impose conformément à la Qualité de Service exigée
par le Client
Technique
Limite
Test de
vulnérabilité
Contrôler la sécurité informatique : de l’intrusion à la recherche de failles, virus…
etc… Norme : ISO/IEC 27001
Technique
Limite
Test de
robustesse
(Stress)
Définir des hypothèses et pousser le système aux limites : mots de passe, nb
utilisateurs simultanés…
Technique
Limite
Fin de réalisation ou après un changement majeur

TYPOLOGIES DE TESTS
V1.0 2 octobre 2015
Standard/Limite
Tests
d’exploitabilité
S'assurer que l'application sera exploitable par la Production informatique
conformément aux Normes de Production. Le client de cette phase de test est
la Production Informatique
L’équipe projet doit s’assurer de l’innocuité des outillages d’exploitation sur le
fonctionnement de l’application
Technique
Standard
Tests
d’installation
Tester les procédures d’installation
Vérifier la documentation
Technique
Standard
Tests de Flux Vérifier les flux, interfaces, transferts, synchronisation de données entre
plusieurs systèmes
Fonctionnel
Technique
Standard
Limites
Intégration dans le SI (information) et le SI (informatique)

TYPOLOGIES DE TESTS
V1.0 2 octobre 2015
Standard/Limite
Test de non
régression
Vérifier que les modifications apportées n'ont pas perturbé le
fonctionnement du composant modifié, des autres composants ou
leur intégration.
Fonctionnel
Standard
Test d’acceptation Dérouler les processus métier de bout en bout avec une vision
utilisateur et s'assurer qu'ils sont conformes aux attentes du
client.
Se concentrer sur le QUOI
Fonctionnel
Standard
Tests fonctionnels de
bout en bout
Dérouler les processus métier de bout en bout avec une vision
utilisateur et s'assurer qu'ils sont conformes aux spécifications.
Fonctionnel
Standard
Test système Tester l’ensemble du système d’un point de vue métier :
- Toutes les solutions intégrées
Fonctionnel ou Technique
Standard
Vérification & Validation fonctionnelle

TYPOLOGIES DE TESTS
V1.0 2 octobre 2015
Standard/Limite
Test de reprise après
catastrophe
Vérifier la capacité du système à reprendre après un accident
majeur.
Le plan de reprise / continuité doit être vérifié.
Fonctionnel
Technique
Limite
Test de restauration
de données
Vérifier la capacité de restauration des données
Définir auparavant les types de sauvegarde, le délais de rétention
des sauvegardes et le délais entre 2 sauvegardes.
Technique
Standard ou Limite
Test de vulnérabilité Contrôler la sécurité informatique : de l’intrusion à la recherche de
failles, virus… etc… Norme : ISO/IEC 27001
Technique
Limite
Autres ? Tout type de test technique : charge, stress… Technique
Limite
Se préparer aux crises pour y faire face
Tests périodiques à réaliser en mode pérenne

MAÎTRISE D’OEUVRE
+ Recette fonctionnelle et technique par la maîtrise d’œuvre
+ Vérification du respect des engagements et spécifications
+ (hors traitement des écarts)
RESPONSABILITÉS
V1.0 2 octobre 2015

MAÎTRISE D’OUVRAGE
RESPONSABILITÉS
V1.0 2 octobre 2015
+ Recette d’acceptation par la maîtrise d’ouvrage
+ Vérification & validation de l’utilité et garantie
+ (hors traitement des écarts)

+ Chef de projet recette
› a la responsabilité du succès de la phase de recette
› évalue la charge de recette et estime le volume d’anomalies à détecter
› définit avec le chef de projet la stratégie de tests et initialise le plan de tests
› valide par échantillonnage la préparation et l’exécution des cas de tests
› vérifie la traçabilité et la bonne qualification des écarts
› valide les conditions de sortie des différentes campagnes de tests
› rédige le bilan des tests après chaque campagne
› décide de l’arrêt de la campagne de recette
+ Une bonne pratique est de garantir l’indépendance de la recette en nommant un « Chef de projet
Recette » qui ne soit pas le « Chef de projet » du projet
RÔLES ET RESPONSABILITÉS
V1.0 2 octobre 2015

+ Concepteur des tests
Complète le plan de tests en appliquant la
stratégie : choisit les types de test à réaliser,
définit le mode de tests automatisés ou non.
Justifie la non réalisation de certains tests.
Constitue les scenarii de tests
Selon son profil, rédige les cas de tests
fonctionnels ou techniques
 Une pratique courante : Le concepteur
des tests est généralement celui qui spécifie
le système.
RÔLES ET RESPONSABILITÉS
V1.0 2 octobre 2015
+ Testeurs
Exécute les campagnes de tests
Trace les écarts constatés
 Une bonne pratique si les développeurs
sont impliqués dans la recette : réaliser des
tests croisés. Les développements /
paramétrages d’un développeur sont vérifiés
par un autre développeur.

+ Stratégie & plan de tests sont initialisés en phase de conception
+ Tous les types de tests ne sont pas forcément mis en œuvre. Leur mise en œuvre dépend
des contraintes, besoins et contenu du projet.
+ Il est aussi normal qu’en début de conception, la totalité des types de tests ne soit pas
complètement figée (plan de test).
STRATÉGIE & PLAN DE TESTS
V1.0 2 octobre 2015

+ Le contenu du document :
 Enjeux métier, rappel de la garantie, utilité et objectifs à atteindre
 Rôles et responsabilités dans la realisation des tests
 Plan de formation des testeurs et utilisateurs impliqués
 Standards et normes à suivre (exemple : attentes de la norme ISO 27001)
 Types de test à réaliser + objectifs par type
 Automatisation des tests
 Indicateurs à suivre
 Risques et actions de mitigation
 Traçabilité des écarts : principes et outils
 Engagement de prise en compte et resolution des incidents. Engagement de de prise en compte des
évolutions (SLA)
 Mode de gestion des changements et mise en oeuvre de la gestion de configuration (logiciel et
système)
+ Document réalisé en impliquant fortement la maîtrise d’ouvrage du projet
STRATÉGIE DE TEST
V1.0 2 octobre 2015

+ Le contenu du document :
Environnement technique de tests
Typologies et techniques de tests
› Fonctionnalités à tester
› Fonctionnalités qui ne seront pas testées
› Tests techniques à réaliser
› Tests techniques qui ne seront pas réalisés
› Critères de suspension des tests  critères d’arrêt de la recette
› Critères d’acceptation d’un test
Responsabilités (si non décrites dans la stratégie de tests)
Cas de tests
Constitution des scénarii de tests
Planification des campagnes de tests et organisation
+ Document réalisé par le responsable des tests et validé par la maîtrise d’ouvrage du projet
PLAN DE TEST
V1.0 2 octobre 2015

07PRÉPARER & RÉALISER LES TESTS

+ Formaliser les cas de tests et critères d’acceptation
+ Constituer les scénarii de test
+ Organiser les campagnes de tests
+ Initialiser les outils et environnements de tests
+ Identifier et générer les données de test
Iso production ?
Anonymisation des données ?
Volume ?
PRÉPARER LES TESTS
V1.0 2 octobre 2015

+ Rédiger la stratégie et le plan de tests
+ Rédiger les cas de tests
On rédige généralement plus de cas de test que réellement exécutés
+ Constituer les scénarii de tests
Regroupement de cas de tests
+ Organiser les campagnes de tests
Regroupement de scenarii
Attribuer les responsabilités et planifier
+ Réaliser
+ Collecter les retours de tests et traiter les écarts
+ Faire le bilan, piloter l’ensemble
RÉALISER LES TESTS
V1.0 2 octobre 2015

+ Critères d’arrêt de la recette
› Trop d’anomalies : la qualité du produit est mauvaise
› Pas assez d’anomalies : les cas de tests ne sont pas
pertinents
› Le nombre d’anomalies à détecter et corriger est atteint
› La qualité du produit est satisfaisante (avis humain)
+ Refaire systématiquement une passe de contrôle
› S’assurer de la prise en compte des anomalies et de leur
correction
› Rédiger le bilan des recettes
› Faire valider la fin de la recette et le passage de jalon/phase
+ Ne pas sous-estimer le temps nécessaire pour effectuer un bilan
de recette indispensable pour maintenir une certification ISO
RÉALISER LES TESTS
V1.0 2 octobre 2015
Métrique : 2 erreurs commises
chaque jour
Au travail comme ailleurs
Hypothèses :
• 10 jours de charge opérationnelle
= 20 anomalies documentaires ou
logicielles produites
• La recette doit détecter 75-80%
des anomalies produites : 15
anomalies

+ Campagne : planification des tests. Une
campagne est composé de un ou plusieurs
scenarios
+ Scenario : ensemble de tests à réaliser. Un
scénario est composé de un ou plusieurs cas de
tests
+ Cas de tests : c’est le test à réaliser. Une petite
histoire à raconter et vérifier. Un cas de tests
ressemble beaucoup à une user-story : contexte,
déclencheur, action, résultat attendu  « given-
when-then »
+ L’exécution des cas de tests permet de détecter
des écarts par rapport aux spécifications
(vérification), objectif initial (validation).
RÉALISER LES TESTS
V1.0 2 octobre 2015
CAMPAGNE DE TEST
ID
Date de réalisation
SCENARIO DE TEST
ID
Description
CAS DE TEST
ID
Description
ECART
ID
Description
Type (Evol ou Défaut)
Une campagne de test planifie
la réalisation de un à plusieurs
scenarii de tests
Un scenario de tests rassemble
plusieurs cas de tests.
Le scénario indique la séquence dans
laquelle les cas de tests sont exécutés.
Un écart est une non-conformité
relevée lors de la réalisation d’un cas de
tests pendant une campagne de tests

+ Le suivi des écarts est effectué
En cours de projet, lors des campagnes de tests de vérification et validation
Tout au long de la vie du système, en lien avec les équipes support
+ Un écart est un défaut ou une évolution
Défaut  processus de résolution
Evolution  processus d’évaluation et validation avant sa prise en compte
+ Un écart suppose une base de référence
Référentiel des exigences, spécification  vérification
Objectifs initiaux, cahier des charges  validation
La base de référence doit être indiquée dans la stratégie de tests.
+ Tous les écarts sont traités au travers du processus de changement et de
déploiement des versions (ITIL).
ECART
V1.0 2 octobre 2015

+ En cas de défaut, la priorité de résolution est définie au regard de :
La criticité du défaut et des risques/impacts occasionnés
L’urgence de résolution
+ Priorité = URGENCE x CRITICITE
Le métier/utilisateur/client donne la criticité et l’urgence qui sont ensuite revues par la MOE.
+ Toujours prévoir des mécanismes d’escalade et gestion de crise
+ Se définir une matrice de priorité :
Mesurer la criticité, matrice à adapter selon les besoins du projet ou règles d’entreprise
Indiquer l’urgence et en déduire la priorité de prise en compte.
DÉFAUT |PRIORITÉ DE RÉSOLUTION
V1.0 2 octobre 2015

PRIORITÉ = CRITICITÉ & URGENCE
DÉFAUT |CRITICITÉ & URGENCE
V1.0 2 octobre 2015
Criticité  analyse d’impacts et risques Urgence de résolution  ressenti humain
• Respect d’une norme ou réglementation….
• Données critiques de l’entreprise, impact sur la
sécurité (biens, personnes, cyber-attaque…)
• Processus métier, fonctions critiques ou vitales de
l’entreprise,
• Données (perte ou altération) avec une notion de
volume
• Nombre d’utilisateurs impactés
• Urgent, Normale, Faible
• L’urgence est donnée par la MOA
• L’urgence est revue par la MOE qui effectue le
diagnostic du défaut :
• Y a-t-il une solution de contournement ? Est-ce une erreur
connue ?
• Quelle est la cause du problème ? Est ce que le problème
peut se reproduire ?
• Y a-t-il un moyen de corriger le problème ? Sous quel délais ?
Priorité de résolution  Mettre en correspondance la criticité et l’urgence.
La priorité de résolution est définie grâce à une « matrice de priorité »

Faible Moyen Avéré
Non respect d’une norme ou réglementation….
Normal Forte Forte
Incident ayant dépassé le délais de diagnostic et rétablissement
du service
Faible Normal Forte
Pertes ou altération de données de l’entreprise
Aucune donnée critique n'est affectée OU
Des moyens de restauration peuvent être activés
Faible Normal Normal
Pertes ou altération de données critiques de l’entreprise
Perte = la confidentialité, l'intégrité ou l'accès aux données n'est
plus assurée
Forte Forte
Pertes ou altération de données critiques des clients SaaS
Perte = la confidentialité, l'intégrité ou l'accès aux données n'est
plus assurée
Forte Forte
Impact potentiel sur la sécurité : biens, personnes, cyber-
attaque…
Forte Forte
Impact sur les processus métier
Aucune fonction vitale n'est affectée
Au moins une fonction vitale est affectée
Forte Forte
Aucune fonction vitale n'est affectée
NB d’utilisateurs impactés Faible Selon évaluation Selon évaluation
Sévérité des impacts du défaut
EXEMPLE DE MATRICE D’ÉVALUATION DE LA CRITICITÉ  À ADAPTER À LA SITUATION
DÉFAUT |EVALUER LA CRITICITÉ
V1.0 2 octobre 2015
Criticité

EXEMPLE DE MATRICE D’ÉVALUATION DE LA PRIORITÉ  À ADAPTER À LA SITUATION
+ Exemple de matrice de priorité de la correction d’un défaut
+ Construire des SLA :
Délais prise en compte des anomalie, pose d’un diagnostic, résolution sur la base de chaque niveau de priorité
Nb d’anomalies ou incidents par niveau d’urgence, criticité, priorité, types d’anomalies ou incidents.
+ Etablir un processus d’escalade et gestion de crise pour la criticité FORTE.
DÉFAUT |PRIORITÉ DE RÉSOLUTION
V1.0 2 octobre 2015
FORTE NORMAL FAIBLE
FORTE FORTE FORTE NORMAL
NORMAL FORTE NORMAL FAIBLE
FAIBLE NORMAL NORMAL FAIBLE
CRITICITE
URGENCE
Priorité

+Une évolution est associée à un processus de validation et
gouvernance :
› Mesurer les impacts sur les composants, systèmes, interfaces
› Evaluer le changement à réaliser : analyse coût/bénéfice
› Décider de sa réalisation ou abandonner
› En cas de prise en charge, planifier sa réalisation.
EVOLUTION
V1.0 2 octobre 2015
Toujours tracer les
changements dans le
référentiel des exigences

+Toutes les modifications d’un système (défaut ou évolution) sont
filtrées et validées au travers des processus de :
Gestion des changements
Déploiement des versions
+Toutes les modifications sont tracées en gestion de configuration.
Evaluation des impacts d’un changement
Gestion de configuration = CMDB (ITIL)
DÉCIDER LA MISE EN ŒUVRE DES CHANGEMENTS
V1.0 2 octobre 2015

+ La recette doit être pilotée et suivie. Des KPI permettent de suivre la qualité, efficacité des
tests réalisés.
+ Exemple
KPI
V1.0 2 octobre 2015
KPI Type Objectif ?
Nb d’écarts détectées par niveau de criticité,
urgence, type
Volume <0,1 anomalie par journée opérationnelle
(conception, construction)
Nb d’écarts détectées par journée de test et
typologie des écarts
Efficacité des tests <10 anomalies par journée de test
>3 anomalies par journée de test
% de cas de tests exécutés
% des exigences vérifiées, validées
Taux de couverture des tests 90% des cas de test choisis réalisés
80% des exigences vérifiées et validées
Qualité des corrections Nb d’écarts réouverts après clôture 0 écart réouvert après correction
Vitesse de résolution Durée de vie moyenne des écarts par
niveau de criticité, urgence, type
N/A

Digital performance.
V1.0 2 OCTOBRE 2015 CHDESSUS@SQLI.COM

GROUPE EUROPÉEN DE CONSEIL EN MARKETING & TECHNOLOGIES
SQLI, LEADER DIGITAL PERFORMANCE
+ SQLI accompagne 30 entreprises du CAC 40:
+ Côté NYSE Euronext Paris (SQI)
162M€ EN 2014
80%DE NOS CLIENTS
RECOMMANDENT
SQLI
2000PASSIONNÉS
Suisse
Belgique
Luxembourg
Pays-Bas
Maroc
18AGENCES
7
A L’INTERNATIONAL
11
EN FRANCE

CRÉATEUR DE
PERFORMANCE DIGITALE
V1.0 2 octobre 2015

MARKETING & TECHNOLOGIE, LA
RENCONTRE
+ Conseil Business & IT
+ Innovation technologique
+ Solutions collaboratives
+ Solutions E-commerce CRM BI
+ Mobilité et objets connectés
+ Externalisation
+ Stratégie digitale
+ Marketing relationnel (data, CRM)
+ UX & design
+ Achat Media
+ Search & analytics
+ Social media
+ Programmes de fidélisation
DIGITAL THAT WORKS!
DIGITAL THAT SELLS.
AND BEYOND.

NOUS INDUSTRIALISONS LE
DIGITAL
DANS NOS CENTRES DE SERVICES
59
RTE
CENTRE DE SERVICES AGILE
QUALITÉ – AGILITÉ - INNOVATION
+ Approche sur mesure de l’acquisition
+ Reprise initiale de 60 applications
+ CMMI – Centre de Bordeaux
+ Java – Microsoft - Mobilité
+ Haute flexibilité de 10 000 à 30 000
jours-homme par an - 5 ans
V1.0 2 octobre 2015
chdessus@sqli.com© SQLI Enterprise – SQLI GROUP | 2015

NOUS AGILISONS
LES ORGANISATIONS
60
BNPP WEALTH MANAGEMENT
COACHING AGILE
+ SCRUM, XP, Innovation Game, définition des processus
+ CMMI
+ Collaboration offshore France / Singapour
+ Formation et coaching depuis 4 ans
V1.0 2 octobre 2015

RÉVÉLATEURS DE NOUVEAUX
USAGES
NOTRE ADN
61
Augmented banking
La banque au cœur de la vie digitale,
Une expérience personnalisée inédite
AirBnB
Hausse des réservations : + 32 % par
l’optimisation des investissements marketing
PASSIONNÉS D’
INNOVATION
CRÉATEURS DE
PERFORMANCE
Le Lab
Design de service & innovation technologique
pour la création de nouveaux services &
produits
V1.0 2 octobre 2015

NOTRE CULTURE DU
PARTAGE
62
TENDANCES
POINTS DE
VUEINNOVATION
V1.0 2 octobre 2015

POURQUOI NOUS
63
NOUS AVONS
1ère agence intégrée
UX & marketing
>100 consultants métier & IT
Un lab innovation
2 % de notre chiffre d’affaires
sont réinvestis en R&D chaque année
1er intégrateur Hybris en EMEA
L’unique partenaire certifié dans ces
3 environnements : Hybris, SAP et Open Text
MICROSOFT
1er partenaire digital - des solutions marketing
aux applications métier dans le cloud
> 300 formations techniques
Nous sommes des spécialistes de
l’outsourcing (20 % de notre CA)
Une méthodologie unique
CMMI & AGILE
Qualité ISO 9001:2008 (Toulouse,
Rabat)
NOUS MAÎTRISONS NOUS MAÎTRISONS
LES
TECHNOLOGIE
S
LES PROJETSLES IDÉES
V1.0 2 octobre 2015

CE QUE NOUS PROPOSONS
BOOSTER
VOTRE MARQUE ET VOS
VENTES
COMMERCE CONNECTÉ
+ Marketing personnalisé
+ Plateformes e-commerce
+ Connected showroom
+ Délégation e-commerce
MARKETING, CRM & DATA
+ Marketing & UX
+ Acquisition, programmes fidélisation
+ Branding & social marketing
+ CRM et marketing automation
+ Data intelligence
DÉVELOPPER
L’AGILITÉ DE VOTRE
ENTREPRISE
INDUSTRIALISATION
+ Stratégie d’externalisation
+ Digital factories & centres de services
+ Management applicatif
MANAGEMENT TRANSFORMATION
+ Gouvernance Digital Runner
+ Lab Innovation
+ Conseil metier & IT
+ Agilité & lean management
+ Formation
DIGITALISER
VOS PROCESSUS ET
SYSTÈMES
BUSINESS SOLUTIONS
+ Solutions collaboratives
+ Digitalisation des services
+ Solutions achats & finance
+ Enterprise Assets Management
+ BI & analytics
MOBILITÉ & OBJETS CONNECTÉS
+ Stratégie cross-canal
+ Usages mobiles & technologies
+ Innovation IoT
+ Mobile factory
64
V1.0 2 octobre 2015

A propos de SQLI Enterprise : L’ESN du groupe SQLI est le partenaire de
référence de la transformation digitale des entreprises : coopération
métiers/IT, architectures du futur, expertises de pointe sur les technologies
innovantes sont mises au service des usages collaboratifs et de la
digitalisation des processus et services. SQLI Enterprise œuvre pour la
création d’une véritable force de frappe digitale : mise en place d’usines
d’industrialisation digitale de taille significative alliant qualité, innovation et
flexibilité, conception de socles cross-canal évolutifs, conseil et solutions sur
le big data, les technologies mobiles et les objets connectés.
Notre cabinet de conseil Alcyonix vous aide a résoudre une équation
complexe : manager et optimiser la digitalisation ! Ses activités s’articulent
autour du management de l’organisation (Amélioration de processus,
gouvernance, méthodes Lean et Agile, innovation, conduite et changement et
formations) et du système d’information (Alignement SI et métiers, assurance
qualité, gouvernance et budgets IT, portfolio management et conseil IT). Ses
1200 passionnés sont répartis en France (Paris, Lyon, Toulouse, Bordeaux,
Rouen, Nantes, Lille), en Suisse (Lausanne et Genève), en Belgique
(Bruxelles), au Luxembourg, aux Pays-Bas et au Maroc (Rabat et Oujda).
GROUPE SQLI
+ Immeuble le Pressensé
268 Avenue du Président Wilson
93210 La Plaine Saint-Denis
Tél: 01 55 93 26 00 / Fax: 01 55 93 26 01
+ www.sqli.com
+ Propriété intellectuelle
Le présent document, propriété exclusive de SQLI, est
protégé par les lois françaises et internationales de la
propriété intellectuelle.
Toute reproduction ou représentation intégrale ou partielle
de ce document par quelque procédé et sur quelque
support que ce soit est strictement interdite, sauf
autorisation préalable, expresse et écrite de SQLI.
A défaut d'autorisation, toute utilisation est constitutive du
délit de contrefaçon. Tout contrevenant s'expose ainsi à
des poursuites judiciaires civiles et/ou pénales.
Seules sont tolérées, sans autorisation préalable, d'une
part, les reproductions strictement réservées à l'usage
privé du copiste et non destinées à une utilisation
collective, et d'autre part, les courtes citations justifiées
par le caractère scientifique ou d'information de l’œuvre
dans laquelle elles sont incorporées (articles L.122-4,
L.122-5 et L.335-2 du Code de la propriété intellectuelle).
V1.0 2 octobre 2015

Digital that works.
WWW.SQLI-ENTERPRISE.COM

Tests & recette - Les fondamentaux

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Tests & recette - Les fondamentaux

Similaire à Tests & recette - Les fondamentaux (20)

Plus de COMPETENSIS

Plus de COMPETENSIS (20)

Dernier

Dernier (20)

Tests & recette - Les fondamentaux