Vous êtes sur la page 1sur 20

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 Le large ventail de comptences demandes aux
changement de perspective et des mthodes de test testeurs prouve que le testing est un mtier part
qui, au final, contribueront un logiciel de meilleure entire. Pour devenir un vrai professionnel du testing,
qualit. Selon Grady7, les testeurs trouveront un il faut une formation adapte, une exprience et une
dfaut toutes les quatre heures en moyenne lors de attitude spcifique qui permettront de challenger le
tests bote noire. logiciel.
Le rle de testeur est-il un mtier part En rsum, voici les trois observations importantes
entire ? pour le reste de cet article :
Avec le temps, les logiciels et les tests associs 1. Le processus de test est un processus majeur
deviennent de plus en plus complexes. Ceci a pour au sein des quipes de dveloppement. Ce
consquence une plus grande professionnalisation processus est fortement li, dpendant
des tests. et connect aux autres activits telles que
En effet, pour concevoir et produire les tests qui la dfinition et la gestion des exigences, la
valideront un logiciel de manire efficace et efficiente, conception, la gestion des changements et
le testeur doit : des configurations et autres disciplines. Cest
cet ensemble qui, mis en place correctement,
- connatre les mthodes statistiques, permettra damliorer la qualit, de rduire les
- avoir une bonne connaissance des mthodes dlais et les cots des projets.
de dveloppement et de la problmatique mtier 2. Une seule technique de test nest pas suffisante
adresse par le logiciel en dveloppement pour pour assurer la qualit dun logiciel. Au-del de
anticiper lapparition des dfauts, lapplication des techniques diffrentes de test,
- bien connatre et appliquer la multitude de cest lensemble de la chane de production du
techniques utilises pour tester le logiciel (test logiciel qui est responsable de la qualit de ces
de fonctionnalit, de performance, de fiabilit, de logiciels.
scurit, de non rgression, ), 3. Les professionnels du test doivent possder
- dfinir les bonnes stratgies de test selon les de nombreuses comptences pour raliser des
objectifs de lquipe projet, 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 Il existe plus de 200 techniques de test documentes
dfinitions importantes de vocabulaire. : test bote blanche, test fonctionnel, test de non
rgression, test exploratoire, test ax sur les risques,
Testing test de performance, test bas sur les cas dutilisation,
Le processus dutilisation dun systme ou dune test bas sur la table de dcision
composante sous des conditions bien dfinies qui,
au travers de lobservation et de lenregistrement des Motivateur de test
rsultats, permet de faire une valuation de certains La stratgie de test est guide par les motivateurs de
aspects de ce systme ou de ces composantes. test. Un motivateur de test est une information ou une
Le Testing valide la qualit dun systme ou dune combinaison dinformations qui motivent une action
composante. de test. Par exemple un motivateur de test peut tre
une exigence couvrir un risque de mise en vidence
Objectif du testing dun dysfonctionnement sur une fonctionnalit, la
La dfinition de lobjectif de testing (ou mission de prise en compte dune demande dvolution, la
test) influencera profondment la manire dont le vrification de correction dune anomalie,... Les
logiciel sera test. Lobjectif de testing fera partie motivateurs de test sont analyss lors de la dfinition
des exigences de testing. Voici quelques exemples de la stratgie de test. Ils aident dfinir les priorits
dobjectifs de test : de test et aligner lquipe de test sur ces priorits.
Trouver des scnarii dutilisation sre du produit
Test
(malgr les dfauts, trouver des scnarii o le
Le test est une activit dans laquelle un systme
logiciel fonctionne)
ou un composant est excut dans des conditions
Maximiser le nombre de dfauts trouvs spcifies, les rsultats sont observs ou enregistrs,
et lvaluation dun certain aspect du systme ou du
Aider la prise de dcision : livrer ou non le
composant est ralise.
produit logiciel
Le standard IEEE 829 dfinit le test comme :
Evaluer la qualit
- (A) un ensemble dun ou plusieurs cas de test,

- (B) un ensemble dune ou plusieurs procdures
En fonction des objectifs, les testeurs seront amens
de test,
choisir des approches de test diffrentes.
- (C) un ensemble dun ou plusieurs cas de test /
Stratgie de test des procdures de test8.
La stratgie de test (ou lapproche de test) spcifiera
comment atteindre lobjectif de manire efficace et Cas de test
la plus conomique possible. La stratgie de test Afin de pouvoir mettre en uvre un test, il est ncessaire
dfinira les techniques de test qui seront employes de connatre toutes les conditions dans lesquelles
par les testeurs ainsi que la faon dont elles seront lexcution aura lieu, la spcification de lensemble des
employes. Nanmoins, la meilleure stratgie de test entres et des rsultats attendus. Cest cela que nous
rpondra aux cinq critres suivants : appelons un cas de test (Figure 1). Le cas de test sera
la plus petite entit qui est toujours excute comme
Diversifie
une unit, du dbut la fin.
Axe sur les risques
La notion dun cas de test reste centrale dans le
Spcifique au produit testing. Le cas de test est une fondation pour la
conception et limplmentation de procdures de test.
Pratique
Il identifie et communique clairement les conditions
Dfendable

8http://wilma.vub.ac.be/~se1_0607/svn/bin/cgi/viewvc.cgi/documents/standards/IEEE/IEEE-STD-829-1998.pdf?revision=45

4
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 Lorganisation et lquipe projet


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

6
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 Source: IBM

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

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

Source: IBM
Figure 9 Les cas de test grs par IBM Rational Quality Manager

10
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 Mais cette vision densemble nest possible que
construire une suite de tests de non-rgression grce lintgration de testing sur le cycle de vie de
excute contre chaque nouvelle fabrication (build) dveloppement de lapplication.
livre aux testeurs. Tout problme dtect lors du
test est rapport via des demandes de correction LAssurance Qualit avec DFSS
soumises dans Rational Quality Manager et Le systme
accessibles dynamiquement au reste de lquipe de Aujourdhui, les quipements mdicaux qui permettent
dveloppement dans IBM Rational Team Concert. le diagnostic des maladies sont des systmes o la
composante principale est le logiciel. Cest grce au logiciel
Les rsultats de lexcution de plan de test sur une que les mdecins sont capables de faire un diagnostic
des itrations sont prsents en Figure 12. plus rapide et beaucoup plus prcis quauparavant.
IBM Rational Quality Manager propose des rapports Le logiciel que nous tudions reprsente une plateforme
visuels et synthtiques comme, par exemple, celui pour des applications qui permettent de dpister des
prsent en Figure 13. maladies en se basant sur des rsultats dexamens
Rsultats mdicaux. Ce logiciel est install sur une plateforme
Lexcution des cas de test permet de trouver des Linux spcialement configure. Il propose diverses
problmes et dvaluer la qualit globale du systme. fonctions comme la rcupration de donnes lies au
Etant donn que les exigences sont lies aux cas de dossier patient, la rcupration des examens effectus
test, il est possible : sur divers appareils, leur visualisation et leur traitement
dans le but deffectuer un diagnostic, un archivage, une
- de dterminer quelle est la couverture de ces impression et dautres fonctions spcifiques.
exigences par les tests,
La dmarche de dveloppement de logiciel est faite
- dapporter un jugement sur le fait que le logiciel dans un cadre normatif strict (rgulations FDA et autres)
sous le test se stabilise par rapport aux problmes et, pour minimiser les risques ports par le logiciel, ce
rapports dans le temps, dveloppement se fait en utilisant lapproche DMADV9
- dvaluer sil faut changer les techniques de test (Define Measure Analyse Design Verify) aussi connu
face une immunisation possible du systme par sous le nom de DFSS10 (Design For Six Sigma).
rapport la dtection de nouveaux problmes, etc.

Source: IBM
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
Source: IBM
Figure 13 Tableau de bord

Lorganisation de lquipe Cest une mesure qui est essentielle et critique vis--
Lquipe projet est compose dune dizaine dingnieurs vis de la qualit, appel un CTQ (Critical To Quality)
de dveloppement logiciel, dun chef de projet/ dans la terminologie de Six Sigma.
architecte, dun responsable dinstallation de produit, Les exigences sont dfinies dans des documents
dun responsable de test, de deux testeurs et dun qui sont grs par IBM Rational Requisite Pro. Ceci
responsable de configuration logicielle/fabrication. De permet de raliser la traabilit entre les exigences
plus, chaque ingnieur de dveloppement passe une et les lments de la conception, grce lintgration
demi-journe en tant que testeur afin de renforcer avec Rational Software Modeler. De plus, lintgration
lquipe de test et dacqurir une vision globale du entre RequisitePro, Rational ClearQuest et Rational
systme en utilisant la fonctionnalit du systme Quality Manager permet de maintenir les liens de
dveloppe par dautres ingnieurs. traabilit entre les exigences, les demandes de
Mise en place de lapproche DMADV vis-- changement et les tests sur lensemble du cycle
vis du test de vie de dveloppement. Cette traabilit est un
Phase DMADV : Dfinir et Mesurer (Define & Mesure) lment important pour le dveloppement car cest
une contrainte, un autre CTQ, impos par FDA sur
Afin dlaborer une architecture de logiciel robuste tous les appareils mdicaux vendus sur le territoire
qui rpondra aux exigences imposes sur le systme amricain. Tous les artefacts, y compris les exigences
et sur le processus de dveloppement, lquipe de sur lesquelles la baseline a t tablie, font lobjet dune
dveloppement a tudi lutilisation typique dun gestion de configuration avec Rational ClearCase.
mme type de systme par ces utilisateurs.
Pour garantir la qualit intrinsque du logiciel, les
Lquipe a constat que les mdecins travaillent avec testeurs sont appels valider les exigences afin
6 types dexamens diffrents. Ces examens sont dassurer leur testabilit. De plus, la testabilit du
gnrs par lquipement qui vient principalement de logiciel (autre CTQ) est lune des exigences vis--vis
quatre constructeurs majeurs (95% de cas tudis). De du systme.
plus, le systme doit se comporter de manire stable
lors de son utilisation permanente et ininterrompue
(sans redmarrage) pendant au moins 185 jours.

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 utiliss pour les communications et les mesures.
termes et approches en matire de qualit et de Bien que les termes dcrivant la plupart des types
ralisation de tests. Les responsables chargs de tests courants, tels que les tests de charge,
du dveloppement des applications peuvent de stress et de rgression, soient compris par le
sappuyer sur cette tude pour tablir un socle de plus grand nombre, dautres termes tels que les
comprhension commun afin qu tous les niveaux tests de recette utilisateur peuvent tre interprts
de lentreprise les approches appropries soient de diffrentes manires. Par consquent, il est
appliques pour des circonstances spcifiques. difficile dappliquer des mtriques cohrentes et de
rpondre avec la mme constance aux exigences
Constat des utilisateurs. Cette tude dresse une brve liste
Chaque entreprise utilise les mmes termes de des diverses activits de test, en donne une courte
test sa manire, ce qui se traduit par une certaine description et indique leur usage. Les entreprises
ambigut et un manque de clart concernant les doivent complter cette liste par des informations
attentes. provenant dautres organismes de dfinition de
Lvaluation de la qualit des logiciels ne se normes, notamment lISTQB (International Software
rsume pas identifier les dfauts ; il sagit dun Testing Qualifications Board), lISO (International
processus prenant en compte diffrents facteurs Organization for Standardization), lIEEE (Institute
tels que la scurit, lergonomie et lefficacit de of Electrical and Electronics Engineers), ou de
dveloppement. leurs fournisseurs doutils agrs. Lobjectif tant
de disposer dattentes ralistes et de dfinitions
Une approche oriente sur lassurance qualit
cohrentes.
ne doit pas se limiter aux activits de test, elle
doit se concentrer sur lamlioration continue Bien quil soit judicieux de raliser des tests le plus
des processus, la gestion et la traabilit des tt possible dans le cycle de vie, il nest pas utile
exigences, ainsi que la gestion des modifications. de commencer certains tests avant que le code
Elle doit galement viser supprimer la source ne soit prt. La planification des tests commence
des dfauts. lors de la conception des applications ou de leur
implmentation. Toutefois, les activits de test et
Les activits concernant lvaluation de la qualit
de vrification de la qualit ne se limitent pas au
doivent stendre sur lensemble du cycle de vie
test du code des applications ; la vrification de
dun projet.
la qualit doit commencer par la validation des
Recommandations spcifications (par exemple, la compltude et la
tablir des dfinitions standard pour les activits testabilit). En outre, les activits de vrification
de test et la description des dfauts. de la qualit ne dpendent pas uniquement de
lquipe charge de la ralisation des tests. Les
Mettre en uvre diverses activits de test pour entreprises informatiques ont souvent des attentes
garantir la qualit globale des logiciels. irralistes concernant les rsultats de certains tests
Favoriser la prvention des dfauts grce ou bien elles sous-estiment le travail requis pour
lassurance qualit plutt que deffectuer un quils soient efficaces.
contrle de qualit pur. Les entreprises ont tendance employer des
ANALYSE mtriques bases sur le nombre de bogues
dtects ; ce nest pas lobjectif du test de logiciels.
Dans le cadre de ses conversations avec les entreprises Lobjectif est de vrifier que le systme ragit
informatiques, Gartner a pu constater un manque de conformment aux exigences et quil se comportera
cohrence dans la terminologie utilise pour dcrire de mme dans son environnement de production.
le processus de qualit global des logiciels et les En sappuyant sur les meilleures pratiques en la
attentes concernant les diffrents types dactivits de matire, cela permet didentifier la source du dfaut
test. Les entreprises doivent comprendre les diffrents et den supprimer la cause, plutt que de supprimer
types de test disponibles et par consquent savoir plusieurs fois le mme dfaut. Cest le cur de
quels outils et quelles comptences employer pour lassurance qualit.
raliser des tests efficaces. En outre, il est crucial quun
vocabulaire prcis et des dfinitions standard soient

16
Assurance qualit ou contrle intervenants tels que lquipe charge de
linfrastructure et de lexploitation, lquipe de
qualit ? dveloppement, les utilisateurs et les analystes
De nombreuses entreprises utilisent indiffremment
des processus mtiers.
les termes assurance qualit et contrle qualit
. Lassurance qualit doit tre envisage comme Types de tests
une approche proactive visant amliorer la qualit. Test des exigences
Il ne sagit pas de rechercher seulement les dfauts Compltude : toutes les exigences
mais den rechercher la source afin de les supprimer. fonctionnelles et non fonctionnelles (telles
Le contrle qualit, quant lui, est un processus de que les performances, lenvironnement et
vrification ractif visant rechercher les dfauts. Il lintgration) sont-elles prises en compte ?
consiste vrifier et examiner le travail ralis.
Points dvaluation : Ies modalits visant
Dans son tude complte sur la vrification de la vrifier que les exigences sont respectes
qualit dans le domaine de la production, W. Edwards sont-elles claires ? Est-il possible de tester les
Deming dclare : Linspection dans le but de exigences ?
rechercher les mauvais lments et de les supprimer
est trop tardive, inefficace et coteuse. La qualit Alignement : le plan de test respecte-t-il
provient non de linspection mais de lamlioration les exigences en matire de planification,
du processus. Cela est avr pour les logiciels ; la dobjectifs et de priorits ?
recherche constante de dfauts une fois que le code Les entreprises mettant en uvre les meilleures
est cr est un processus de contrle qui intervient pratiques impliquent lquipe charge de lassurance
trop tard. Les entreprises ont besoin de lassurance qualit ds le dbut du projet. Une fois que les
qualit et du contrle qualit mais lassurance qualit exigences initiales sont runies pour chaque point
est plus efficace (voir les exemples dactivits de dlaboration, lquipe charge de lassurance
chaque processus dans le tableau 1) : qualit doit disposer dun point de contrle (avant
les phases de conception et de mise en uvre)
Tableau 1. Couverture de la mthode par phase pour vrifier quaucune exigence ne manque et que
toutes les exigences peuvent tre testes, ainsi que
Assurance qualit Contrle qualit
pour planifier les test en laboratoire. Si lquipe de
Audit de qualit Procdure pas pas test ne peut pas dterminer de quelle manire elle
vrifiera que le code fonctionne correctement, les
Dfinition du processus Test
exigences ne peuvent pas tre testes et il est fort
Slection des outils Inspections probable que la personne charge de la ralisation
des tests ne pourra que supposer.
Formation Vrification des points
de contrle Tests de performance
Performance : ces tests permettent de savoir
Source : Gartner (novembre 2008) o les goulots dtranglement se produisent,
ces tests sont raliss par des dveloppeurs,
Il existe diffrentes manires dutiliser les inspections, souvent laide doutils dits outils de
par exemple, dans une approche proactive, comme profilage.
indiqu dans la section Qualit du code plus bas. Charge : ces tests visent analyser les
Dans cette approche, des outils dvaluation ou des performances dune application mesure que
logiciels sont utiliss avant la phase de fabrication la charge ou que le nombre dutilisateurs ou
(build) de lapplication (et ventuellement au cours de de messages augmente.
la phase de conception et de codage) pour amliorer
en amont la conception et viter que les mmes erreurs Stress : en sappuyant sur les tests de
se reproduisent. Une entreprise favorisant lassurance charge, les tests de stress analysent ce qui
qualit peut galement se rendre compte que la se produit lorsque les ressources du systme
qualit ne relve pas uniquement de la responsabilit spuisent.
de lquipe charge des tests. Lassurance qualit
repose sur la contribution et la participation dautres

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

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