Une publication dIBM comportant la recherche de Gartner

Juin 2010

Introduction . . . . . . . . . . . . 2

Do vient la ncessit de
tester ? . . . . . . . . . . . . . . . 2
Les produits logiciels sont-ils
tests systmatiquement,
doit-on les tester systma-
tiquement ? . . . . . . . . . . . 2
Le rle de testeur est-il un
mtier part entire ? . . . 3
Terminologie . . . . . . . . . . . 4

Le testing sur le cycle de

dveloppement de logiciel
en deux exemples . . . . . . . 6

Testing bas sur les cas

dutilisation . . . . . . . . . . . . 6
LAssurance Qualit avec
DFSS . . . . . . . . . . . . . . . 12
Conclusion . . . . . . . . . . . . 15

Normaliser les dfinitions

et les attentes des activits
de test . . . . . . . . . . . . . . . 16

Test ou Assurance Qualit : pile ou face ?

Un guide pratique lintgration de la qualit de
logiciel dans le cycle de vie de dveloppement
Introduction

Il existe un sujet sur lequel tous les professionnels A ce jour, lindustrie du dveloppement de logiciel
de dveloppement de logiciel saccordent : il faut na pas encore trouv la recette dun processus
tester les produits bass sur le logiciel applications, de dveloppement parfait qui rendra le test logiciel
produits logiciels, logiciel embarqu et autres. obsolte. Les tudes menes par Standish Group2
montrent que 44% des projets dans le monde
Do vient la ncessit de tester ? ont t challengs soit par le budget, soit par des
Le dveloppement de logiciel est un processus de
retards, ou bien par le fait quils ont dlivr moins
rsolution dun problme rencontr par des individus
de fonctionnalits dans le primtre prvu. Le travail
ou des entreprises pour lesquels la solution la plus
supplmentaire (rework) li la correction des
durable et conomique est un logiciel. Ce processus
exigences, de la conception et de limplmentation,
est gouvern par des exigences qui ne sont que
est responsable de 40 50% du cot total du
la transcription des besoins de ces individus ou de
projet de dveloppement3. On peut se demander si
ces entreprises dans un produit final dans lequel
lintgration de la gestion de la qualit sur lensemble
les parties prenantes collaborent pour satisfaire ces
du processus de dveloppement au sens large
besoins. Le manque de communication lors de cette
est la recette magique qui a permis aux 32% de
collaboration peut produire des exigences ambiges,
projets lancs en 2009 datteindre le succs (source
incompltes ou bien incomprhensibles voire parfois
Standish Group).
incorrectes. Les exigences sont la cause principale
dapparition de dfauts dans le logiciel1. A cela Les produits logiciels sont-ils tests
sajoute des oublis ou des problmes de conception systmatiquement, doit-on les tester
et des dfauts lis limplmentation du logiciel.
systmatiquement ?
Chaque logiciel peut tre considr comme un Bien entendu, la rponse que nous souhaiterions
ensemble de risques ports aux entreprises, aux entendre est : oui. Mais dans la pratique, il y a des
utilisateurs et lenvironnement dans lequel il carts importants en fonction des quipes de livraison
sexcute. Le testing est une mthode qui permet de de logiciels. Les recherches rcentes menes par un
rduire ce risque stratgique port par le logiciel. cabinet dtudes4 ont rvles que plus de 40% des
applications sont livres avec 1 10 dfauts critiques.
Le test de logiciel, sil est mis en place correctement,
Dans certains projets, surtout dans les projets Agiles,
permet de satisfaire les intrts des diffrentes parties
on considre souvent que les tests unitaires sont
prenantes (utilisateurs, entreprises et autres). Par
suffisants pour garantir le niveau de qualit requis. Or
consquent, le but du test de logiciel ne se rsume
statistiquement, il est prouv que pour 1000 lignes de
pas au simple processus de recherche de bogues
code5, il faut sattendre avoir 6,5 9 dfauts lors du
mais consiste aussi assurer que la problmatique
test systme. De mme, 7% des dfauts corrigs vont
pose par les parties prenantes est bien rsolue par
engendrer un nouveau dfaut6. Les tests unitaires
le logiciel. Ceci constitue un changement majeur
sont absolument ncessaires au mme titre que la
dattitude dans le monde de dveloppement o
revue statique et automatique du code ainsi que le
le testeur est reconnu comme tant LE premier
profiling dynamique du code.
utilisateur du systme et, en tant que tel, son retour
sur lutilisation du logiciel devient primordial pour
lensemble de lquipe.

1Software Testing, R .Patton, p.17, Sams, 2005

2http://www1.standishgroup.com/newsroom/chaos_2009.php

3Steve McConnell, Software Quality at Top Speed, http://www.stevemcconnell.com/articles/art04.htm

4http://blog.testlabs.com/2009/04/software-testing-and-quality-assurance.html

5http://blog.testlabs.com/2009/04/software-testing-and-quality-assurance.html

6Software Cost Estimating Methods for Large Projects, Capers Jones, 2005, http://www.stsc.hill.af.mil/crosstalk/2005/04/0504Jones.html

2
Le testing par les testeurs permet de raliser un
changement de perspective et des mthodes de test
qui, au final, contribueront un logiciel de meilleure
qualit. Selon Grady7, les testeurs trouveront un
dfaut toutes les quatre heures en moyenne lors de
tests bote noire.
Le rle de testeur est-il un mtier part
entire ?
Avec le temps, les logiciels et les tests associs
deviennent de plus en plus complexes. Ceci a pour
consquence une plus grande professionnalisation
des tests.
En effet, pour concevoir et produire les tests qui
valideront un logiciel de manire efficace et efficiente,
le testeur doit :
- connatre les mthodes statistiques,
- avoir une bonne connaissance des mthodes
de dveloppement et de la problmatique mtier
adresse par le logiciel en dveloppement pour
anticiper lapparition des dfauts,
- bien connatre et appliquer la multitude de
techniques utilises pour tester le logiciel (test
de fonctionnalit, de performance, de fiabilit, de
scurit, de non rgression, ),
- dfinir les bonnes stratgies de test selon les
objectifs de lquipe projet,
Le large ventail de comptences demandes aux
testeurs prouve que le testing est un mtier part
entire. Pour devenir un vrai professionnel du testing,
il faut une formation adapte, une exprience et une
attitude spcifique qui permettront de challenger le
logiciel.
En rsum, voici les trois observations importantes
pour le reste de cet article :
1. Le processus de test est un processus majeur
au sein des quipes de dveloppement. Ce
processus est fortement li, dpendant
et connect aux autres activits telles que
la dfinition et la gestion des exigences, la
conception, la gestion des changements et
des configurations et autres disciplines. Cest
cet ensemble qui, mis en place correctement,
permettra damliorer la qualit, de rduire les
dlais et les cots des projets.
2. Une seule technique de test nest pas suffisante
pour assurer la qualit dun logiciel. Au-del de
lapplication des techniques diffrentes de test,
cest lensemble de la chane de production du
logiciel qui est responsable de la qualit de ces
logiciels.
3. Les professionnels du test doivent possder
de nombreuses comptences pour raliser des
tests efficaces et efficients de logiciels.

- programmer pour accrotre lefficacit de Le but de cet article est de montrer, du point de vue du
lautomatisation de test, testeur, le lien entre lassurance qualit et lensemble
du cycle de vie applicatif sur deux exemples.
- avoir dautres comptences et qualits
importantes.
Source: IBM

7Practical Software Metrics for Project Management and Process Improvement, Robert B. Grady, Prentice Hall, 1992

3
Terminologie
Avant de passer la suite, prcisons quelques
dfinitions importantes de vocabulaire.
Testing
Le processus dutilisation dun systme ou dune
composante sous des conditions bien dfinies qui,
au travers de lobservation et de lenregistrement des
rsultats, permet de faire une valuation de certains
aspects de ce systme ou de ces composantes.
Le Testing valide la qualit dun systme ou dune
composante.
Objectif du testing
La dfinition de lobjectif de testing (ou mission de
test) influencera profondment la manire dont le
logiciel sera test. Lobjectif de testing fera partie
des exigences de testing. Voici quelques exemples
dobjectifs de test :
Trouver des scnarii dutilisation sre du produit
(malgr les dfauts, trouver des scnarii o le
logiciel fonctionne)
Maximiser le nombre de dfauts trouvs
Aider la prise de dcision : livrer ou non le
produit logiciel
Evaluer la qualit
En fonction des objectifs, les testeurs seront amens
choisir des approches de test diffrentes.
Stratgie de test
La stratgie de test (ou lapproche de test) spcifiera
comment atteindre lobjectif de manire efficace et
la plus conomique possible. La stratgie de test
dfinira les techniques de test qui seront employes
par les testeurs ainsi que la faon dont elles seront
employes. Nanmoins, la meilleure stratgie de test
rpondra aux cinq critres suivants :
Diversifie
Axe sur les risques
Spcifique au produit
Pratique
Dfendable
8http://wilma.vub.ac.be/~se1_0607/svn/bin/cgi/viewvc.cgi/documents/standards/IEEE/IEEE-STD-829-1998.pdf?revision=45
4
Il existe plus de 200 techniques de test documentes
: test bote blanche, test fonctionnel, test de non
rgression, test exploratoire, test ax sur les risques,
test de performance, test bas sur les cas dutilisation,
test bas sur la table de dcision
Motivateur de test
La stratgie de test est guide par les motivateurs de
test. Un motivateur de test est une information ou une
combinaison dinformations qui motivent une action
de test. Par exemple un motivateur de test peut tre
une exigence couvrir un risque de mise en vidence
dun dysfonctionnement sur une fonctionnalit, la
prise en compte dune demande dvolution, la
vrification de correction dune anomalie,... Les
motivateurs de test sont analyss lors de la dfinition
de la stratgie de test. Ils aident dfinir les priorits
de test et aligner lquipe de test sur ces priorits.
Test
Le test est une activit dans laquelle un systme
ou un composant est excut dans des conditions
spcifies, les rsultats sont observs ou enregistrs,
et lvaluation dun certain aspect du systme ou du
composant est ralise.
Le standard IEEE 829 dfinit le test comme :
- (A) un ensemble dun ou plusieurs cas de test,
- (B) un ensemble dune ou plusieurs procdures
de test,
- (C) un ensemble dun ou plusieurs cas de test /
des procdures de test8.
Cas de test
Afin de pouvoir mettre en uvre un test, il est ncessaire
de connatre toutes les conditions dans lesquelles
lexcution aura lieu, la spcification de lensemble des
entres et des rsultats attendus. Cest cela que nous
appelons un cas de test (Figure 1). Le cas de test sera
la plus petite entit qui est toujours excute comme
une unit, du dbut la fin.
La notion dun cas de test reste centrale dans le
testing. Le cas de test est une fondation pour la
conception et limplmentation de procdures de test.
Il identifie et communique clairement les conditions
 Source: IBM

Figure 1 Relation entre un test et des cas de test

Source: IBM

Figure 2 Relation entre un test, un cas de test et

une procdure de test

mises en uvre par le test. Il a pour objectif de Leffort de test dun systme logiciel ne doit pas tre
vrifier limplmentation russie et/ou acceptable considr par les quipes projet comme une activit
des exigences vers le produit logiciel. Le cas de test part. En effet, le testing sappuiera fortement sur les
permet aussi de dimensionner leffort de test, de le exigences envers le logiciel. La qualit des exigences
mesurer et den faire le reporting. Il permet aussi de va non seulement dfinir le processus de test, mais
grer les changements. aussi impacter significativement la conception et
limplmentation. Elle aura une influence majeure sur
Procdure de test les dlais de livraison du logiciel. Ainsi, la maturit
Il existe de multiples faons de raliser un test. dquipe en termes de gestion des changements
Toute la ralisation, appele procdure de test, dterminera le degr de facilit avec lequel lquipe
doit fournir des instructions dtailles pour la sera capable de mener lanalyse dimpact lie un
mise en place, lexcution et lvaluation des changement sur la conception, limplmentation et
rsultats pour un cas de test. La procdure de les artefacts de test. Autrement dit : Garbage in =
test peut tre ralise par un script de test garbage out .
excuter manuellement ou peut tre automatise
par exemple avec IBM Rational Functional Tester.
La Figure 2 montre la relation entre un test, un cas Source: IBM
de test et une procdure de test.

5
Le testing sur le cycle de dveloppement
de logiciel en deux exemples
La porte et linterdpendance des artefacts issus
de disciplines diffrentes sur le cycle de vie de
dveloppement de logiciel soulignent limportance
croissante de la collaboration dans lquipe et, au-del,
dans le contexte de projet ainsi que le partage efficace
des informations entre les membres de lquipe et les
parties prenantes. Ces challenges sont adresss par la
plateforme collaborative de nouvelle gnration Jazz,
dIBM Rational. Grce lautomatisation des tches, aux
rapports automatiques et aux mcanismes dintgration
du cycle de vie de dveloppement, les outils bass sur
IBM Jazz accdent facilement aux informations gres
par lun et par lautre. Lensemble des artefacts test tels
que les exigences de test, le test plan, le cas de test et
autres, sont grs par IBM Rational Quality Manager.
Mais pour raliser une collaboration efficace, Rational
Quality Manager est capable de lier les cas de test
aux exigences captures par Rational Requirements
Composer et gres dans Rational DOORS ou dans
Requisite Pro. De la mme manire, Rational Quality
Manager propose des capacits basiques de gestion et
de suivi des anomalies. Il peut rattacher les anomalies
dtectes aux demandes de changement dans Rational
ClearQuest ou aux work items de Rational Team
Concert. De mme, Rational Quality Manager permet
une automatisation efficace des procdures de test avec
Rational Functional Tester et Rational Performance
Tester. Il permet aussi la reprise des automates de test
des diteurs tiers comme HP.
Les deux exemples qui suivent montreront limportance
de lintgration des activits de test sur le cycle de
vie de dveloppement, sans pour autant traiter la
question de gestion de testing.
Testing bas sur les cas
dutilisation
Application
Lapplication que nous tudions est une application
web de vente des articles via Internet. Elle propose
une interface conviviale pour slectionner, choisir
et acheter les articles en ligne, en fonction de leur
disponibilit en stock. Le paiement se fait avec
une carte bancaire et est ralis en ligne par une
transaction scurise avec la banque. Une fois larticle
achet, un ordre est envoy au systme de traitement
des commandes et le stock darticles est mis jour en
fonction de la quantit achete. Lapplication propose
aussi une interface de gestion ainsi quun mcanisme
dauthentification de ces utilisateurs.
6
Lorganisation et lquipe projet
Au sein de la direction des tudes, une quipe est
dsigne pour raliser ce projet en collaboration
avec lorganisation fonctionnelle. Lquipe projet
compte galement un responsable de test, qui
joue aussi le rle de testeur, et un autre testeur.
Lquipe projet utilise IBM Rational Requirements
Composer pour dfinir et capturer des exigences en
collaboration troite avec des parties prenantes. Elle
utilise, galement, Rational RequisitePro pour grer
ces exigences et Rational Quality Manager avec
Rational Functional Tester pour grer et automatiser
la campagne de test.
Afin dobtenir la comprhension du systme et
de converger rapidement et efficacement sur son
primtre avec des parties prenantes, lquipe projet
a dcid de dfinir les exigences travers des cas
dutilisation (Figure 3). Ceci favorise une approche
collaborative la dfinition des exigences, permet
une meilleure comprhension des exigences et du
logiciel en dveloppement par toutes les parties.
Le choix de la dfinition des exigences par des cas
dutilisation permet lquipe de soccuper de tests
tt dans le cycle de dveloppement. Bien que le
processus de dfinition des exigences reste hors
du scope de cet article, notons nanmoins que la
manire dont les cas dutilisation sont crits affectera
leur testabilit.
En ce qui concerne les applications web, les
internautes attachent une grande importance la
scurit de leurs donnes quils changent avec
lapplication. De plus, les critres comme la ractivit,
la convivialit et la disponibilit de lapplication sont
dterminants pour gnrer davantage de trafic et
assurer le succs du site.
Pour garantir le succs de lapplication et raliser
les objectifs business, lquipe projet a dcid
dimpliquer les testeurs de manire formelle dans
la validation des exigences, et ce dans le but de
vrifier leur testabilit.
Mise en place de tests fonctionnels bass
sur les cas dutilisation
Bien que ce projet utilise plusieurs approches de
test, cet article ne prend en considration que la
ralisation de la technique de test fonctionnel bas
sur les cas dutilisation.
 Source: IBM

Figure 3 Dfinition des exigences avec les cas dutilisation et

IBM Rational Requirements Composer

Les tests bass sur les cas dutilisation ont pour avantage
de tester le systme dun bout lautre en fonction
de son utilisation. Notons galement les avantages
suivants : diffrer la dcision dautomatisation de tests
avec les choix technologiques pour lautomatisation
des tests.
Cette technique de test permet aux testeurs dentamer
la dmarche dassurance qualit partir des exigences
prsentes en format de cas dutilisation. En effet,
cette technique favorise le dveloppement et la
ralisation de campagnes de test par itrations o
les testeurs peuvent dfinir des cas de test mme
si lapplication nexiste pas encore dans le code
excutable. De manire conceptuelle, le schma
(Figure 4) montre lvolution des cas dutilisation et
des cas de test correspondants en fonction du cycle
de vie de dveloppement.
Etape 1 : Dfinition de lobjectif de test
Lquipe labore le plan de test au dmarrage du projet.
Lquipe se met daccord avec les parties prenantes Source: IBM
sur lobjectif global de test tests dacceptation
(Figure 5). Le caractre itratif de dveloppement Figure 4 Le rapport entre le cycle de vie cas
oblige les testeurs dfinir des objectifs spcifiques dutilisation et le cycle de vie de ces de test
de test pour chaque itration : par exemple, valider
que larchitecture de lapplication soit conforme aux
performances requises sur les itrations prcoces. Il
faut noter que le plan de test voluera avec chaque
itration, tout au long du cycle de vie du projet.

7
Le testing sur le cycle de dveloppement
de logiciel en deux exemples
Figure 5 Dfinition de lobjectif de testing
Les motivateurs de test sont, dans Rational Quality
Manager (Figure 6), associs aux exigences
fonctionnelles, aux exigences non fonctionnelles,
aux exigences de scurit et dautres types
dexigences gres dans le rfrentiel dexigences,
Rational RequisitePro. Cependant, dautres types
dinformations, telles que les anomalies, les requtes
damlioration et autres peuvent servir de motivateur
de test.
Lors de llaboration de la stratgie de test, le
responsable de test analyse le niveau de risque
attach lexigence, la priorit mtier de lexigence
et son impact sur larchitecture pour dfinir une
priorit de test en fonction de la criticit de lexigence.
Un motivateur de test avec une priorit de test leve
ncessitera une attention plus importante. Ensuite,
le responsable de test associe un niveau de risque
sur le motivateur du point de vue de lactivit de
test. Ce niveau de risque est dautant plus lev que
la priorit de test est importante et que la mise en
uvre du test sur cette fonctionnalit est difficile.
Etape 2 : Identification de cas de test
Ds que la description schmatique du cas dutilisation
(outline) est prte, il est possible de dfinir les
scnarii correspondants (Figure 7). Ces scnarii
vont permettre de crer une matrice initiale de cas
de test.
8
Source: IBM
Pour chaque scnario unique, lquipe de test cre
un cas de test ventuel (une ligne dans la matrice) et
identifie les conditions qui dclencheront lexcution
de ce cas de test. Chaque condition trouve dans le
cas dutilisation ajoutera une colonne dans la matrice
de cas de test. Pour chaque cas de test identifi,
lquipe de test dtermine si la condition sera remplie
(V[alide]) ou non (I[nvalide]) et le rsultat attendu de
lexcution du scnario (Figure 8).
A ce stade, lquipe de test ne fournit pas de valeurs
pour les conditions identifies. Ceci permet de voir
facilement les conditions testes et de dterminer si
la couverture par les cas de test est suffisante. Il est
galement possible de valider de manire visuelle si
la matrice contient toutes les conditions et tous les
cas de test ncessaires selon deux rgles :
Sil ny a pas de condition Invalide sur la ligne
dans la matrice, alors il manque (sauf pour le cas
nominal) une condition.
Sil ny pas de condition Invalide dans une
colonne de la matrice, alors il manque dun cas
de test.
La matrice initiale permet lquipe de test damorcer
la pompe en crant les premiers cas de test qui
seront lis aux exigences exprimes par des cas
dutilisation. Ces cas de test seront crs dans
 Source: IBM
Figure 6 Exigences projet accessibles dans Rational Quality Manager

Figure 7 Scnarii pour les cas dutilisation

Source: IBM

Figure 8 Matrice initiale des cas de test

Source: IBM

9
Le testing sur le cycle de dveloppement
de logiciel en deux exemples
Rational Quality Manager. La Figure 9 montre les cas
de test crs sous IBM Rational Quality Manager. Le
symbole dans la colonne Status de cette capture
dcran (Figure 9) signifie que le Quality Manager a
dtect une incohrence un lien suspect entre
le(s) test(s) motivateur(s) et un cas de test. Cette
incohrence est provoque par un changement soit
dans le(s) test(s) motivateur(s), soit dans le cas
de test. IBM Rational Quality Manager propose un
accs facile toutes les informations ncessaires
qui permettent au responsable de test de prendre
les dcisions ncessaires. La Figure 10 montre les
exigences qui sont associes un cas de test et qui
sont dtectes comme suspectes par IBM Rational
Quality Manager.
Etape 3 : Mise au point de cas de test
A ce stade, la matrice initiale des cas de test est
prte. Leffort principal se porte sur la rconciliation,
la revue des cas de test, lajout des cas de test
ncessaires o la suppression des cas de test
redondants.
Lquipe amliore la matrice initiale des cas de test
en assignant des valeurs relles aux conditions
(Figure 11).
En fonction des impratifs de chaque itration,
ceux du projet et selon lavancement de ce projet,
lquipe de test pourra prendre la meilleure dcision
Figure 9 Les cas de test grs par IBM Rational Quality Manager
10
: automatiser ou non les procdures de test, procder
lautomatisation, Ceci grce IBM Rational
Quality Manager.
Etape 4 : Ralisation et excution des procdures de test
Dans un premier temps, les procdures de test sont
ralises avec Rational Quality Manager travers
les scripts manuels. Ceci permet de spcifier les
procdures de test mme si lapplication nexiste pas
encore. Puis, avec limplmentation incrmentale de la
fonctionnalit dans lapplication, lquipe de test dcide
dimplmenter certaines procdures de test dans des
scripts automatiques raliss avec Rational Functional
Tester. Grce ces capacits de reconnaissance des
lments dinterface graphique dutilisateur avances,
Rational Functional Tester permet une automatisation
simple et pratique des tests fonctionnels. Il capture
les interactions faites avec linterface utilisateur et les
enregistre dans un script. Le testeur peut facilement
dfinir les points de vrification et variabiliser les
donnes en utilisant des data pools au cours du
processus denregistrement du script. Une fois que
les scripts sont enregistrs le testeur peut modifier,
supprimer ou ajouter les lments : donnes dans le
data pool, les data pools, les points de vrification.
Ensuite ces scripts de test seront utiliss lors de
lexcution des campagnes de test.
Source: IBM
Figure 10 Test motivateur dun cas de test Source: IBM

Source: IBM
Figure 11 Matrice complte de cas de test

11
Le testing sur le cycle de dveloppement
de logiciel en deux exemples
Cette automatisation de test permet lquipe de
construire une suite de tests de non-rgression
excute contre chaque nouvelle fabrication (build)
livre aux testeurs. Tout problme dtect lors du
test est rapport via des demandes de correction
soumises dans Rational Quality Manager et
accessibles dynamiquement au reste de lquipe de
dveloppement dans IBM Rational Team Concert.
Les rsultats de lexcution de plan de test sur une
des itrations sont prsents en Figure 12.
IBM Rational Quality Manager propose des rapports
visuels et synthtiques comme, par exemple, celui
prsent en Figure 13.
Rsultats
Lexcution des cas de test permet de trouver des
problmes et dvaluer la qualit globale du systme.
Etant donn que les exigences sont lies aux cas de
test, il est possible :
- de dterminer quelle est la couverture de ces
exigences par les tests,
- dapporter un jugement sur le fait que le logiciel
sous le test se stabilise par rapport aux problmes
rapports dans le temps,
- dvaluer sil faut changer les techniques de test
face une immunisation possible du systme par
rapport la dtection de nouveaux problmes, etc.
Figure 12 Rsultats dexcution dun plan de test
9De Feo, Joseph A.; Barnard, William (2005). JURAN Institutes Six Sigma Breakthrough and Beyond - Quality Performance Breakthrough Methods.
Tata McGraw-Hill Publishing Company Limited. ISBN 0-07-059881-9
10Pour plus dinformation sur Six Sigma et DFSS http://en.wikipedia.org/wiki/DFSS
12
Mais cette vision densemble nest possible que
grce lintgration de testing sur le cycle de vie de
dveloppement de lapplication.
LAssurance Qualit avec DFSS
Le systme
Aujourdhui, les quipements mdicaux qui permettent
le diagnostic des maladies sont des systmes o la
composante principale est le logiciel. Cest grce au logiciel
que les mdecins sont capables de faire un diagnostic
plus rapide et beaucoup plus prcis quauparavant.
Le logiciel que nous tudions reprsente une plateforme
pour des applications qui permettent de dpister des
maladies en se basant sur des rsultats dexamens
mdicaux. Ce logiciel est install sur une plateforme
Linux spcialement configure. Il propose diverses
fonctions comme la rcupration de donnes lies au
dossier patient, la rcupration des examens effectus
sur divers appareils, leur visualisation et leur traitement
dans le but deffectuer un diagnostic, un archivage, une
impression et dautres fonctions spcifiques.
La dmarche de dveloppement de logiciel est faite
dans un cadre normatif strict (rgulations FDA et autres)
et, pour minimiser les risques ports par le logiciel, ce
dveloppement se fait en utilisant lapproche DMADV9
(Define Measure Analyse Design Verify) aussi connu
sous le nom de DFSS10 (Design For Six Sigma).
Source: IBM

Figure 13 Tableau de bord
Lorganisation de lquipe
Lquipe projet est compose dune dizaine dingnieurs
de dveloppement logiciel, dun chef de projet/
architecte, dun responsable dinstallation de produit,
dun responsable de test, de deux testeurs et dun
responsable de configuration logicielle/fabrication. De
plus, chaque ingnieur de dveloppement passe une
demi-journe en tant que testeur afin de renforcer
lquipe de test et dacqurir une vision globale du
systme en utilisant la fonctionnalit du systme
dveloppe par dautres ingnieurs.
Mise en place de lapproche DMADV vis--
vis du test
Phase DMADV : Dfinir et Mesurer (Define & Mesure)
Afin dlaborer une architecture de logiciel robuste
qui rpondra aux exigences imposes sur le systme
et sur le processus de dveloppement, lquipe de
dveloppement a tudi lutilisation typique dun
mme type de systme par ces utilisateurs.
Lquipe a constat que les mdecins travaillent avec
6 types dexamens diffrents. Ces examens sont
gnrs par lquipement qui vient principalement de
quatre constructeurs majeurs (95% de cas tudis). De
plus, le systme doit se comporter de manire stable
lors de son utilisation permanente et ininterrompue
(sans redmarrage) pendant au moins 185 jours.
Source: IBM
Cest une mesure qui est essentielle et critique vis--
vis de la qualit, appel un CTQ (Critical To Quality)
dans la terminologie de Six Sigma.
Les exigences sont dfinies dans des documents
qui sont grs par IBM Rational Requisite Pro. Ceci
permet de raliser la traabilit entre les exigences
et les lments de la conception, grce lintgration
avec Rational Software Modeler. De plus, lintgration
entre RequisitePro, Rational ClearQuest et Rational
Quality Manager permet de maintenir les liens de
traabilit entre les exigences, les demandes de
changement et les tests sur lensemble du cycle
de vie de dveloppement. Cette traabilit est un
lment important pour le dveloppement car cest
une contrainte, un autre CTQ, impos par FDA sur
tous les appareils mdicaux vendus sur le territoire
amricain. Tous les artefacts, y compris les exigences
sur lesquelles la baseline a t tablie, font lobjet dune
gestion de configuration avec Rational ClearCase.
Pour garantir la qualit intrinsque du logiciel, les
testeurs sont appels valider les exigences afin
dassurer leur testabilit. De plus, la testabilit du
logiciel (autre CTQ) est lune des exigences vis--vis
du systme.
13
 Le testing sur le cycle de dveloppement
de logiciel en deux exemples

Phase DMADV : Analyser (Analyse) de lquipement diagnostic. Il a t constat quen

Pour satisfaire lexigence de testabilit, les ingnieurs moyenne les mdecins font entre 12 (examens
en charge de la conception du produit ont dcids sophistiqus) et 96 (urgences) examens en 24 heures
de sparer linterface utilisateur du reste du systme avec 4 10 impressions par examen.
en lencapsulant dans un module spar. Chaque Pour simuler le travail fait sur 185 jours de fonctionnement
manipulation avec linterface utilisateur se rsume par ininterrompu de logiciel, il faut excuter 4.262.400 (6
un appel vers le proxy dinterface utilisateur dans une types dexamens x 4 constructeurs x 96 examens x 10
partie interne du systme (Figure 14). impressions x 185 jours) combinaisons possibles. En
procdant lanalyse de classes dquivalence, lquipe
rduit environ 30.000 le nombre de combinaisons
excuter pour simuler limpression des examens sur une
priode de 185 jours. Ce nombre reste lev pour procder
aux tests manuels et par consquent lautomatisation de
ces tests avec Rational Functional Tester simposait. Sous
Linux, comme sous Windows, Rational Functional Tester
(RFT) propose des capacits de scripting avances avec
Source: IBM
Java. Grce la conception du systme qui permet la
Figure 14 Permettre la testabilit par design testabilit, il est possible dattaquer le systme directement
partir des scripts dvelopps dans RFT et dappeler la
fonctionnalit ncessaire comme si cela tait fait partir
Cette approche permet de tester toute les
de linterface utilisateur.
fonctionnalits proposes par le logiciel mme sans
interface utilisateur. Phase DMADV : Concevoir (Design)
Pour raliser le projet de dveloppement dans le Pour simuler le workflow rel du travail du mdecin et
temps imparti avec une qualit requise, il a t dcid couvrir le plus de cas possible, la randomisation des flux
dutiliser la politique de prvention proactive des dfauts dexcution et des donnes a t utilise (rendue possible
travers des tests unitaires, de lanalyse du code grce un des assistants de RFT). Cette randomisation
statique et dynamique automatise, laide des outils a t journalise afin de permettre aux ingnieurs de
comme Rational PurifyPlus. La mise en place dune dveloppement de reproduire les tapes joues par les
telle politique doit permettre de rduire le temps pass scripts. Puis, la suite de scripts a t excute sur le
par lquipe dans le debugging du code (une recherche systme. Au dbut des tests, le systme sarrtait sans
effectue par un cabinet dtudes constate que, dans les raison apparente aprs une centaine de cas jous par
grandes entreprises, 37% du temps dun dveloppeur est le script. Lutilisation de Rational PurifyPlus (Figure 15)
dpens sur les tches de dbogages). Pour renforcer lors de lexcution des tests a permis de diagnostiquer
cette politique, les ingnieurs de dveloppement logiciel la fuite de mmoire, jamais dtecte auparavant, qui
doivent tester leur travail avant de le soumettre (checkin) saccumulait avec le temps et qui a caus le crash du
sur leur branche de dveloppement dans le rfrentiel. systme. Ainsi quelques dfauts lis la manipulation
Quand lingnieur demande la fabrication, lanalyse errone de la mmoire ont t trouvs. Les problmes
automatique du code source se dclenche. Puis, rencontrs avec le systme ont t enregistrs dans
toutes les fabrications faites sur la branche dintgration ClearQuest et ils ont t corrigs par la suite.
dclenchent lexcution de la batterie des tests unitaires Phase DMADV : Vrifier (Verify)
et une analyse statique du code. Si cette analyse ou les
tests unitaires gnrent des erreurs, la fabrication est Les tests fonctionnels automatiques ont t inclus dans
voue lchec. la suite de test de non rgression, excute lors de
chaque fabrication sur la branche dintgration. Quand
Pour la suite de cet article, seule la fonctionnalit les scripts de test contenaient des choix alatoires, plus
dimpression des examens sera couverte. Mais la ils taient jous, plus des cas de test taient prsents au
mme approche est utilise pour le test de toute systme et plus le systme tait test rigoureusement ; il
autre fonctionnalit propose par le logiciel. en rsultait par consquent une meilleure qualit. Cette
Pour dterminer la meilleure conception de test, approche avait permis dassurer la qualit durable du
lquipe de test a d procder une analyse systme dans le temps.
supplmentaire des exigences et de lutilisation

14
Rsultats
Lquipe de test a t implique ds le dbut du cycle
de dveloppement. Ceci a permis :
1. une meilleure qualit des exigences car les
testeurs validaient la testabilit des exigences,
2. la prise en compte en amont dans la conception
des exigences de testabilit du logiciel,
3. une analyse approfondie des exigences et une
meilleure comprhension du systme par les
testeurs afin de modliser une utilisation raliste
du systme lors de tests,
4. dassurer la couverture complte des exigences
par le test et de rpondre aux exigences
rglementaires (FDA par exemple).
Source: IBM
De plus, le professionnalisme de lquipe, sa Figure 15 Exemples derreur transmis par IBM
connaissance des utilisateurs, sa matrise des Rational PurifyPlus
techniques de test ont permis dobtenir un systme
qui intgre la Qualit par le Design.

Conclusion
Aujourdhui, testeur est un mtier part entire dans o lenvironnement change rapidement, voil les vrais
le processus mtier de dveloppement de logiciel. atouts de la plateforme. Cela permet aux testeurs de
Dans cet article, nous avons vu que le testing ne peut rester efficaces et de se concentrer sur leur mtier.
plus rester dans un silo, spar du reste du cycle
Sommes-nous tous prts considrer le testing
de vie de dveloppement. Les outils dIBM Rational
autrement et ne serait-ce pas un nouveau dpart qui
aident enlever les barrires de communication
permettrait au final, daugmenter considrablement
entre toutes les parties prenantes impliques dans
la part de projets russis, rapporte dans les tudes
le dveloppement de logiciel. Grce sa plateforme
annuelles de Standish Group ?
Jazz, IBM Rational permet lautomatisation, le
reporting et la collaboration lintrieur dune quipe Michel Speranski
projet mais aussi au sein de lentreprise, dans Rational Market Manager
sa globalit et au-del. Plus de visibilit, plus de IBM France
matrise, plus de capacits ragir dans le contexte

Copyright IBM Corporation 2010

Tous droits rservs
Rational Team Concert, Rational Requirements Composer, IBM, le logo IBM et Rational sont des marques dposes dInternational Business Machines
Corporation aux Etats-Unis et/ou dans certains autres pays.

Rational Quality Manager, Rational Functional Tester, Rational Team Concert, Rational Requirements Composer, Rational ClearCase, Rational ClearQuest,
Rational PurifyPlus, Rational Software Modeler, IBM, le logo IBM et Rational sont des marques dposes dInternational Business Machines Corporation aux
Etats-Unis et/ou dans certains autres pays.

Les autres noms de socits, de produits ou de services peuvent appartenir des tiers. Les rfrences donnes dans cet article sont valides au moment de
lcriture de cet article. Les liens cits dans cet article ne sont valides quau moment de lcriture de cet article.

Les informations contenues dans la prsente documentation sont fournies des fins dinformation uniquement. Mme si tout a t mis en uvre pour vrifier
lintgrit et lexactitude des informations contenues dans la prsente documentation, ces dernires sont fournies en ltat, sans aucune garantie, explicite
ou implicite. De plus, ces informations sont bases sur les plans et la stratgie de produits actuels dIBM, lesquels sont sujets modification par IBM sans
pravis. IBM ne peut tre tenu pour responsable de tout dommage manant de lutilisation de, ou sinon associe la prsente documentation ou toute autre
documentation. Aucun lment prsent dans cette documentation na pour objet, ni naura pour effet, de crer une quelconque garantie ou reprsentation
de la part dIBM (ou de ses fournisseurs ou concdants de licence) ou de modifier les conditions du contrat de licence en vigueur rgissant lutilisation des
logiciels IBM.

15
Normaliser les dfinitions et les
attentes des activits de test
Cette tude a pour objet de dfinir diffrents
termes et approches en matire de qualit et de
ralisation de tests. Les responsables chargs
du dveloppement des applications peuvent
sappuyer sur cette tude pour tablir un socle de
comprhension commun afin qu tous les niveaux
de lentreprise les approches appropries soient
appliques pour des circonstances spcifiques.
Constat
Chaque entreprise utilise les mmes termes de
test sa manire, ce qui se traduit par une certaine
ambigut et un manque de clart concernant les
attentes.
Lvaluation de la qualit des logiciels ne se
rsume pas identifier les dfauts ; il sagit dun
processus prenant en compte diffrents facteurs
tels que la scurit, lergonomie et lefficacit de
dveloppement.
Une approche oriente sur lassurance qualit
ne doit pas se limiter aux activits de test, elle
doit se concentrer sur lamlioration continue
des processus, la gestion et la traabilit des
exigences, ainsi que la gestion des modifications.
Elle doit galement viser supprimer la source
des dfauts.
Les activits concernant lvaluation de la qualit
doivent stendre sur lensemble du cycle de vie
dun projet.
Recommandations
tablir des dfinitions standard pour les activits
de test et la description des dfauts.
Mettre en uvre diverses activits de test pour
garantir la qualit globale des logiciels.
Favoriser la prvention des dfauts grce
lassurance qualit plutt que deffectuer un
contrle de qualit pur.
ANALYSE
Dans le cadre de ses conversations avec les entreprises
informatiques, Gartner a pu constater un manque de
cohrence dans la terminologie utilise pour dcrire
le processus de qualit global des logiciels et les
attentes concernant les diffrents types dactivits de
test. Les entreprises doivent comprendre les diffrents
types de test disponibles et par consquent savoir
quels outils et quelles comptences employer pour
raliser des tests efficaces. En outre, il est crucial quun
vocabulaire prcis et des dfinitions standard soient
16
utiliss pour les communications et les mesures.
Bien que les termes dcrivant la plupart des types
de tests courants, tels que les tests de charge,
de stress et de rgression, soient compris par le
plus grand nombre, dautres termes tels que les
tests de recette utilisateur peuvent tre interprts
de diffrentes manires. Par consquent, il est
difficile dappliquer des mtriques cohrentes et de
rpondre avec la mme constance aux exigences
des utilisateurs. Cette tude dresse une brve liste
des diverses activits de test, en donne une courte
description et indique leur usage. Les entreprises
doivent complter cette liste par des informations
provenant dautres organismes de dfinition de
normes, notamment lISTQB (International Software
Testing Qualifications Board), lISO (International
Organization for Standardization), lIEEE (Institute
of Electrical and Electronics Engineers), ou de
leurs fournisseurs doutils agrs. Lobjectif tant
de disposer dattentes ralistes et de dfinitions
cohrentes.
Bien quil soit judicieux de raliser des tests le plus
tt possible dans le cycle de vie, il nest pas utile
de commencer certains tests avant que le code
ne soit prt. La planification des tests commence
lors de la conception des applications ou de leur
implmentation. Toutefois, les activits de test et
de vrification de la qualit ne se limitent pas au
test du code des applications ; la vrification de
la qualit doit commencer par la validation des
spcifications (par exemple, la compltude et la
testabilit). En outre, les activits de vrification
de la qualit ne dpendent pas uniquement de
lquipe charge de la ralisation des tests. Les
entreprises informatiques ont souvent des attentes
irralistes concernant les rsultats de certains tests
ou bien elles sous-estiment le travail requis pour
quils soient efficaces.
Les entreprises ont tendance employer des
mtriques bases sur le nombre de bogues
dtects ; ce nest pas lobjectif du test de logiciels.
Lobjectif est de vrifier que le systme ragit
conformment aux exigences et quil se comportera
de mme dans son environnement de production.
En sappuyant sur les meilleures pratiques en la
matire, cela permet didentifier la source du dfaut
et den supprimer la cause, plutt que de supprimer
plusieurs fois le mme dfaut. Cest le cur de
lassurance qualit.
Assurance qualit ou contrle
qualit ?
De nombreuses entreprises utilisent indiffremment
les termes assurance qualit et contrle qualit
. Lassurance qualit doit tre envisage comme
une approche proactive visant amliorer la qualit.
Il ne sagit pas de rechercher seulement les dfauts
mais den rechercher la source afin de les supprimer.
Le contrle qualit, quant lui, est un processus de
vrification ractif visant rechercher les dfauts. Il
consiste vrifier et examiner le travail ralis.
Dans son tude complte sur la vrification de la
qualit dans le domaine de la production, W. Edwards
Deming dclare : Linspection dans le but de
rechercher les mauvais lments et de les supprimer
est trop tardive, inefficace et coteuse. La qualit
provient non de linspection mais de lamlioration
du processus. Cela est avr pour les logiciels ; la
recherche constante de dfauts une fois que le code
est cr est un processus de contrle qui intervient
trop tard. Les entreprises ont besoin de lassurance
qualit et du contrle qualit mais lassurance qualit
est plus efficace (voir les exemples dactivits de
chaque processus dans le tableau 1) :
Tableau 1. Couverture de la mthode par phase
Assurance qualit Contrle qualit
Audit de qualit Procdure pas pas
Dfinition du processus Test
Slection des outils Inspections
Formation Vrification des points
de contrle
Source : Gartner (novembre 2008)
Il existe diffrentes manires dutiliser les inspections,
par exemple, dans une approche proactive, comme
indiqu dans la section Qualit du code plus bas.
Dans cette approche, des outils dvaluation ou des
logiciels sont utiliss avant la phase de fabrication
(build) de lapplication (et ventuellement au cours de
la phase de conception et de codage) pour amliorer
en amont la conception et viter que les mmes erreurs
se reproduisent. Une entreprise favorisant lassurance
qualit peut galement se rendre compte que la
qualit ne relve pas uniquement de la responsabilit
de lquipe charge des tests. Lassurance qualit
repose sur la contribution et la participation dautres
intervenants tels que lquipe charge de
linfrastructure et de lexploitation, lquipe de
dveloppement, les utilisateurs et les analystes
des processus mtiers.
Types de tests
Test des exigences
Compltude : toutes les exigences
fonctionnelles et non fonctionnelles (telles
que les performances, lenvironnement et
lintgration) sont-elles prises en compte ?
Points dvaluation : Ies modalits visant
vrifier que les exigences sont respectes
sont-elles claires ? Est-il possible de tester les
exigences ?
Alignement : le plan de test respecte-t-il
les exigences en matire de planification,
dobjectifs et de priorits ?
Les entreprises mettant en uvre les meilleures
pratiques impliquent lquipe charge de lassurance
qualit ds le dbut du projet. Une fois que les
exigences initiales sont runies pour chaque point
dlaboration, lquipe charge de lassurance
qualit doit disposer dun point de contrle (avant
les phases de conception et de mise en uvre)
pour vrifier quaucune exigence ne manque et que
toutes les exigences peuvent tre testes, ainsi que
pour planifier les test en laboratoire. Si lquipe de
test ne peut pas dterminer de quelle manire elle
vrifiera que le code fonctionne correctement, les
exigences ne peuvent pas tre testes et il est fort
probable que la personne charge de la ralisation
des tests ne pourra que supposer.
Tests de performance
Performance : ces tests permettent de savoir
o les goulots dtranglement se produisent,
ces tests sont raliss par des dveloppeurs,
souvent laide doutils dits outils de
profilage.
Charge : ces tests visent analyser les
performances dune application mesure que
la charge ou que le nombre dutilisateurs ou
de messages augmente.
Stress : en sappuyant sur les tests de
charge, les tests de stress analysent ce qui
se produit lorsque les ressources du systme
spuisent.
17
Normaliser les dfinitions et les
attentes des activits de test

Lobjectif des tests de performance est de rechercher Tests unitaires : ces tests se concentrent sur
les causes sous-jacentes des mauvaises performances des units, des modules ou des composants
dune application, ce qui implique un examen approfondi spcifiques et ils indiquent si des rgles peuvent
des performances de lapplication au niveau de lexcution en tre tirer.
du code. Ces tests ont galement pour objectif de vrifier
Automatisation : un logiciel est utilis pour
que les algorithmes utiliss et les implmentations dans
automatiser lexcution des tests, la consignation
le code sont adapts aux besoins de lapplication. Les
des rsultats et la gestion des scnarios de test.
tests de performance doivent intervenir tt dans le
cycle de vie de lapplication, lorsque les modifications Tests de rgression : ces tests rptitifs
structurelles apportes aux algorithmes auront le moins et automatiss permettent dviter que les
deffet sur les autres composants du code. modifications apportes au systme introduisent
des dfauts.
Les tests de charge et de stress fournissent une vue
de lapplication un plus haut niveau. Ils ont pour Tests dintgration : ces tests sont effectus
objet dexaminer le comportement de lapplication entre les diffrentes units pour vrifier que les
mesure que le nombre dutilisateurs et la complexit interactions fonctionnent correctement.
ou la composition de la charge utile augmentent. Les
Tests du systme : ces tests sont effectus
utilisateurs sont gnrs de faon artificielle laide
sur le systme entier dans une configuration de
dordinateurs de contrle de la charge. Lobjectif de ces
production.
tests est de garantir la stabilit de lapplication et de
vrifier que les performances du systme rpondent auxLes tests fonctionnels sont au cur de la plupart
attentes des utilisateurs mme sous charge applique. des activits de test. Ils peuvent tre effectus
manuellement ou automatiquement sur le code ou sur
Bien quil soit important de savoir que le systme peut
fonctionner correctement sous la charge prvue, il estlAPI (linterface de programmation dune application).
Ils permettent de savoir si le code rpond aux attentes
galement crucial que les quipes ralisant les tests de
et de garantir la stabilit long terme de lapplication.
charge et de stress fournissent lquipe dexploitation
La plupart des tests fonctionnels sont effectus
les informations qui lui permettront dassurer le contrle
et la maintenance du systme. Le fonctionnement de manuellement. Lutilisation des cadres de tests
lapplication dpend-il du processeur ou de la mmoireunitaires et dune approche davantage axe sur les
tests (dveloppement pilot par les tests) est devenue
? Quest ce qui indique que le systme est sur le point
de tomber en panne ? Ces informations seront utiles une pratique de plus en plus courante pour dtecter les
pour le support long terme du systme mesure que dfauts le plus tt possible. Lautomatisation russie de
de nouvelles applications sont disponibles en ligne outests bote noire continue davoir un impact sur les
attentes de retour sur investissement de nombreuses
que lactivit utilisateur augmente au-del des volumes
entreprises. Toutefois, avec lutilisation accrue de
initialement prvus. Enfin, il est important de connatre
la cause des pannes sous la charge, leur effet (par logiciels packags et de solutions hberges, pouvoir
exemple, la perte de donnes) et leur impact ventuel raliser des tests sans accder au code va devenir
sur dautres systmes dpendants. Cela savrera de une comptence fondamentale. Les tests fonctionnels
plus en plus important du fait que les entreprises doivent permettre de vrifier que le comportement
adoptent de plus en plus aujourdhui une architecture dune application est satisfaisant et que les principaux
oriente services et quelles partagent des chanes descnarios sexcutent correctement lors des tests
service, internes et externes, complexes. bote noire . Pour le groupe informatique les tests
de rgression sont critiques, car la crdibilit de
Tests fonctionnels lentreprise est en jeu. Quels que soient les avantages
Bote blanche : ces tests impliquent une que prsentent les nouvelles fonctionnalits, il nest pas
comprhension explicite de limplmentation ; acceptable de briser les fonctionnalits dj tablies
les tests unitaires en sont un bon exemple. ; lavantage principal des outils dautomatisation de
Bote noire : limplmentation sous-jacente tests est quils prservent lintgrit de ces fonctions.
nest pas requise pour ces tests. Ces tests se
concentrent sur linterface ou les spcifications
externes ; la majorit des outils de test
fonctionnent de cette manire.

18
tant donn que les outils sappuient de plus en plus
sur un modle plus centr sur les donnes et que le
dveloppement soriente vers un format plus adapt
aux architectures orientes services et lexploitation
des mtadonnes, les outils dautomatisation offriront
un retour sur investissement plus rapide. En outre,
ils conviennent mieux la cration de tests en amont
de limplmentation.
Tests de scurit
Modles de menace : ces modles fournissent
une dfinition des brches potentielles de
la scurit (concernant les points dentres,
les privilges daccs et la disponibilit des
ressources). Ils permettent en outre aux
entreprises de constituer une arborescence
rsistant aux attaques et de mettre en uvre des
mesures de contrle de la surface dexposition
de lapplication.
Analyse statique : il sagit dune analyse du
code source qui recherche dans la structure de
lapplication des erreurs courantes de codage
pouvant crer des points de vulnrabilit.
Analyse dynamique : cette analyse teste
lapplication et recherche des attaques tels
que linjection de code SQL. Les techniques
dynamiques impliques ont tendance sappuyer
sur des mthodologies de data fuzzing
(injection de donnes alatoires).
Les tests de scurit sont devenus un lment cl
du cycle de vie du dveloppement dune application.
Les premiers outils se concentraient sur les mthodes
danalyse statique, ce qui constituait dj un progrs,
mais ils se conformaient au concept obsolte selon
lequel il fallait tester la qualit directement dans
une application. Pour suivre lvolution du march,
les entreprises et les fournisseurs ont amlior les
pratiques utilises de faon adopter une approche
oriente sur la prvention des attaques.
Tests de qualit du code
Analyse statique : ces outils semblables
un compilateur, examinent le code, en tenant
compte de la complexit et du respect des
rgles de codage, et recherchent les utilisations
incorrectes des bibliothques standards et tout
autre problme li au code.
valuation par les pairs : ces outils fournissent
un second regard sur le code. Il sagit dune
mthode prouve permettant de dtecter et de
rduire les erreurs plus tt dans le cycle de vie
sans que cela donne lieu un processus formel.
Lvaluation de la qualit du logiciel en amont et
lidentification des erreurs, laide doutils et de
techniques appropries, afin dviter quelles aient
un impact sur la fabrication, sont effectues lors de
lanalyse statique et de lvaluation du code par des
pairs. Appliques sous forme de paire, ces techniques
vrifient le logiciel sur la base des meilleures pratiques
en la matire et constituent le meilleur moyen de
supprimer les dfauts difficiles trouver. Ces dfauts
napparaissent pas dans la fonctionnalit gnrale
de lapplication mais ils impliquent des problmes
pouvant entraner une perte de stabilit ou nuire
la rutilisation de lapplication et ainsi augmenter les
cots de maintenance.
Autres lments
Tests de recette utilisateur : ces tests doivent
tre concentrs sur la validation du systme livr
par lutilisateur (logiciel, supports de formations
et documents connexes). Lobjectif de ces tests
nest pas de rechercher des bogues mais de
fournir une validation finale du systme livre ;
effectue par un tiers, cette phase de tests est
appele validation et vrification indpendante.
Fuzzing : ces tests sont utiliss pour plusieurs
objectifs mais ils sont surtout concentrs sur la
recherche des vulnrabilits de scurit. Cette
technique repose sur linjection alatoire de
donnes dans lapplication au cours des tests
fonctionnels.
Facilit dutilisation : ces tests se concentrent
sur linterface utilisateur et sur les interactions
entre lutilisateur et lapplication. Pour ces tests,
lutilisateur, sous observation, doit naviguer dans
lapplication en suivant divers scnarios.
Globalisation/Localisation : ces tests ont pour
but de vrifier que lapplication peut prendre
en charge plusieurs langues pour lentre
dinformations (globalisation) et laffichage
(localisation).
Accessibilit : ces tests ont pour but de vrifier
que lapplication est adapte aux utilisateurs
prsentant un handicap.
Documentation : ces tests ont pour but de
vrifier que les documents de support (manuels,
aide en ligne et documentation de formation)
sont corrects. Ils sont effectus en suivant une
procdure pas pas.
19
Normaliser les dfinitions et les
attentes des activits de test

La qualit dune application ne se mesure pas Outils de test

seulement ses fonctions et ses performances ;
elle doit galement rpondre certaines rgles. Un
logiciel de qualit ne fonctionnera pas seulement
efficacement mais il permettra aussi aux utilisateurs de
travailler efficacement. Les logiciels doivent rpondre
aux besoins de tous les utilisateurs et tant donn que
de plus en plus dutilisateurs accdent aux applications
partir dappareils mobiles et de divers navigateurs
partout dans le monde, lquipe charge des tests doit
avoir les comptences requises et disposer des outils
appropris pour automatiser ces tests.
La plupart des types de test ncessitent des outils et
des environnements spcifiques permettant de rduire
les oprations ncessaires ; cependant, cela ne signifie
pas que tous les tests peuvent tre automatiss
et la cration de tests ne reprsente que la moiti du
travail. Le processus dautomatisation ainsi que la
gestion des changements et de lintgration travers
de lquipe de dveloppement sont au cur de
lautomatisation. Les principaux outils sur le march
permettent de gnrer des cas de test partir des
cas dutilisation et de grer et de coordonner les
modifications entre eux.

Source: Gartner Rfrence G00162958,

Thomas E. Murphy,
25 novembre 2008

Test ou Assurance Qualit : pile ou face ? is published by IBM Corporation. Editorial supplied by IBM Corporation is independent of Gartner analysis. All Gartner
research is 2010 by Gartner, Inc. and/or its Affiliates. All rights reserved. All Gartner materials are used with Gartners permission and in no way does the use or
publication of Gartner research indicate Gartners endorsement of IBM Corporations products and/or strategies. Reproduction and distribution of this publication in
any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all
warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the
information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended
results. The opinions expressed herein are subject to change without notice.

20