U IVERSITEacute DU QUEacuteBEC Agrave MO TREAL

ANALYSE COMPARATIVE DU TEST EXPLORATOIRE ET DU

TEST SCENARISE ETUDE EMPIRIQUE

MEacuteMOIRE

PREacuteSENTEacute

COMME EXIGENCE PARTIELLE

DE LA MAIcircTRISE EN INFORMATIQUE

PAR

NAIMA ANKOUD

DEacuteCEMBRE 2007

UNIVERSITEacute DU QUEacuteBEC Agrave MONTREacuteAL Service des bibliothegraveques

Avertissement

La diffusion de ce meacutemoire se fait dans le respect des droits de son auteur qui a signeacute le formulaire Autorisation de reproduire et de diffuser un travail de recherche de cycles supeacuterieurs (SDU-522 - Reacutev01-2006) Cette autorisation stipule que laquoconformeacutement agrave larticle 11 du Regraveglement no 8 des eacutetudes de cycles supeacuterieurs [lauteur] concegravede agrave lUniversiteacute du Queacutebec agrave Montreacuteal une licence non exclusive dutilisation et de publication de la totaliteacute ou dune partie importante de [son] travail de recherche pour des fins peacutedagogiques et non commerciales Plus preacuteciseacutement [lauteur] autorise lUniversiteacute du Queacutebec agrave Montreacuteal agrave reproduire diffuser precircter distribuer ou vendre des copies de [son] travail de recherche agrave des fins non commerciales sur quelque support que ce soit y compris lInternet Cette licence et cette autorisation nentraicircnent pas une renonciation de [la] part [de lauteur] agrave [ses] droits moraux ni agrave [ses] droits de proprieacuteteacute intellectuelle Sauf entente contraire [lauteur] conserve la liberteacute de diffuser et de commercialiser ou non ce travail dont [il] possegravede un exemplaireraquo

Il

REMERCIEMENTS

Je tiens agrave remercier vivement Monsieur Robert Dupuis professeur agrave juniversiteacute du Queacutebec agrave

Montreacuteal et directeur de ce travail de recherche davoir suggeacutereacute le sujet dactualiteacute de ce

meacutemoire et accepteacute de le diriger Je lui exprime ma profonde gratitude de mavoir fourni

assistance consei Is judicieux et encouragements

Je voudrais eacutegalement exprImer mes remerciements aux membres du jury qUI mont fait

lhonneur davoir bien voulu eacutevaluer mon travail

Jaimerais aussi remercier sincegraverement mes parents mes fregraveres ct ma sœur pour leur soutien

ct leur confiance Je tiens en particulier agrave remercier mon fregravere Hicham qui ma pousseacutee agrave

aller de lavant et faire des eacutetudes supeacuterieures Sans son soutien cc travail naurait jamais pu

ecirctre reacutealiseacuteje lui en serai eacuteternellement reconnaissante

Je tiens aussi agrave remercier mon amie Monia pour son appui assistance et encouragement Je

me dois de dire un merci particulier agrave Mlle Laurence Loisellc Dupuis qui a pris la peine de

lire ce meacutemoire eacutelfin de maider agrave con-iger les nombreuses falItes dorthogrltlphe qui sy

eacuteteacutelient glisseacutees

Enfin je remercie les autres personnes qui ont contribueacute dc pregraves ou de loin agrave cc travail

speacutecialement les eacutetudiants de cours lNF6 J 60 de la session dautomne 2005 pour avoir

accepteacute dc participer agrave notre eacutetude empilique

Cc travail est deacutedieacute agrave ma megravere

III

TABLE DES MATIEgraveRES

LISTE DES TABLEAUX viii

LISTE DES FIGURES ix

LISTE DES ABREacuteVIATIONS x

REacuteSUMEacute xi

INTRODUCTION 1

CHAPITRE 1 5

DEacuteFINITION DU SUJET DE RECHERCHE 5

11 EacuteNONCEacute DE LA PROBL~MATJQUL 5

12 MEacuteTHODE DE RECHERCHE 7

13 DEacuteFINITION DU PROJH 7

131 La motivation 8

132 La porteacutee 8

J 33 Lobjectif 8

134 Description des utilisateurs des reacutesultats de la recherche 9

135 Les limites du projet 1J

14 PLANIfICATION DU PROJET 11

CHAPITRE )J bullbullbullbullbullbullbullbullbullbullbullbullbullbullbullbullbull 13

TEST SCEacuteNARISEacute VUE DENSEMBLE 13

2 J CONCEPTS DE BASE ET TERMINOLOGJE 13

211 Terminologie 13

212 Cas de test 14

22 TEST SCEacuteNAR]S~ (SCRIPTED TESTING) 14

UNIVERSITEacute DU QUEacuteBEC Agrave MONTREacuteAL Service des bibliothegraveques

Avertissement

La diffusion de ce meacutemoire se fait dans le respect des droits de son auteur qui a signeacute le formulaire Autorisation de reproduire et de diffuser un travail de recherche de cycles supeacuterieurs (SDU-522 - Reacutev01-2006) Cette autorisation stipule que laquoconformeacutement agrave larticle 11 du Regraveglement no 8 des eacutetudes de cycles supeacuterieurs [lauteur] concegravede agrave lUniversiteacute du Queacutebec agrave Montreacuteal une licence non exclusive dutilisation et de publication de la totaliteacute ou dune partie importante de [son] travail de recherche pour des fins peacutedagogiques et non commerciales Plus preacuteciseacutement [lauteur] autorise lUniversiteacute du Queacutebec agrave Montreacuteal agrave reproduire diffuser precircter distribuer ou vendre des copies de [son] travail de recherche agrave des fins non commerciales sur quelque support que ce soit y compris lInternet Cette licence et cette autorisation nentraicircnent pas une renonciation de [la] part [de lauteur] agrave [ses] droits moraux ni agrave [ses] droits de proprieacuteteacute intellectuelle Sauf entente contraire [lauteur] conserve la liberteacute de diffuser et de commercialiser ou non ce travail dont [il] possegravede un exemplaireraquo

Il

REMERCIEMENTS

Je tiens agrave remercier vivement Monsieur Robert Dupuis professeur agrave juniversiteacute du Queacutebec agrave

Montreacuteal et directeur de ce travail de recherche davoir suggeacutereacute le sujet dactualiteacute de ce

meacutemoire et accepteacute de le diriger Je lui exprime ma profonde gratitude de mavoir fourni

assistance consei Is judicieux et encouragements

Je voudrais eacutegalement exprImer mes remerciements aux membres du jury qUI mont fait

lhonneur davoir bien voulu eacutevaluer mon travail

Jaimerais aussi remercier sincegraverement mes parents mes fregraveres ct ma sœur pour leur soutien

ct leur confiance Je tiens en particulier agrave remercier mon fregravere Hicham qui ma pousseacutee agrave

aller de lavant et faire des eacutetudes supeacuterieures Sans son soutien cc travail naurait jamais pu

ecirctre reacutealiseacuteje lui en serai eacuteternellement reconnaissante

Je tiens aussi agrave remercier mon amie Monia pour son appui assistance et encouragement Je

me dois de dire un merci particulier agrave Mlle Laurence Loisellc Dupuis qui a pris la peine de

lire ce meacutemoire eacutelfin de maider agrave con-iger les nombreuses falItes dorthogrltlphe qui sy

eacuteteacutelient glisseacutees

Enfin je remercie les autres personnes qui ont contribueacute dc pregraves ou de loin agrave cc travail

speacutecialement les eacutetudiants de cours lNF6 J 60 de la session dautomne 2005 pour avoir

accepteacute dc participer agrave notre eacutetude empilique

Cc travail est deacutedieacute agrave ma megravere

III

TABLE DES MATIEgraveRES

LISTE DES TABLEAUX viii

LISTE DES FIGURES ix

LISTE DES ABREacuteVIATIONS x

REacuteSUMEacute xi

INTRODUCTION 1

CHAPITRE 1 5

DEacuteFINITION DU SUJET DE RECHERCHE 5

11 EacuteNONCEacute DE LA PROBL~MATJQUL 5

12 MEacuteTHODE DE RECHERCHE 7

13 DEacuteFINITION DU PROJH 7

131 La motivation 8

132 La porteacutee 8

J 33 Lobjectif 8

134 Description des utilisateurs des reacutesultats de la recherche 9

135 Les limites du projet 1J

14 PLANIfICATION DU PROJET 11

CHAPITRE )J bullbullbullbullbullbullbullbullbullbullbullbullbullbullbullbullbull 13

TEST SCEacuteNARISEacute VUE DENSEMBLE 13

2 J CONCEPTS DE BASE ET TERMINOLOGJE 13

211 Terminologie 13

212 Cas de test 14

22 TEST SCEacuteNAR]S~ (SCRIPTED TESTING) 14

Il

REMERCIEMENTS

Je tiens agrave remercier vivement Monsieur Robert Dupuis professeur agrave juniversiteacute du Queacutebec agrave

Montreacuteal et directeur de ce travail de recherche davoir suggeacutereacute le sujet dactualiteacute de ce

meacutemoire et accepteacute de le diriger Je lui exprime ma profonde gratitude de mavoir fourni

assistance consei Is judicieux et encouragements

Je voudrais eacutegalement exprImer mes remerciements aux membres du jury qUI mont fait

lhonneur davoir bien voulu eacutevaluer mon travail

Jaimerais aussi remercier sincegraverement mes parents mes fregraveres ct ma sœur pour leur soutien

ct leur confiance Je tiens en particulier agrave remercier mon fregravere Hicham qui ma pousseacutee agrave

aller de lavant et faire des eacutetudes supeacuterieures Sans son soutien cc travail naurait jamais pu

ecirctre reacutealiseacuteje lui en serai eacuteternellement reconnaissante

Je tiens aussi agrave remercier mon amie Monia pour son appui assistance et encouragement Je

me dois de dire un merci particulier agrave Mlle Laurence Loisellc Dupuis qui a pris la peine de

lire ce meacutemoire eacutelfin de maider agrave con-iger les nombreuses falItes dorthogrltlphe qui sy

eacuteteacutelient glisseacutees

Enfin je remercie les autres personnes qui ont contribueacute dc pregraves ou de loin agrave cc travail

speacutecialement les eacutetudiants de cours lNF6 J 60 de la session dautomne 2005 pour avoir

accepteacute dc participer agrave notre eacutetude empilique

Cc travail est deacutedieacute agrave ma megravere

III

TABLE DES MATIEgraveRES

LISTE DES TABLEAUX viii

LISTE DES FIGURES ix

LISTE DES ABREacuteVIATIONS x

REacuteSUMEacute xi

INTRODUCTION 1

CHAPITRE 1 5

DEacuteFINITION DU SUJET DE RECHERCHE 5

11 EacuteNONCEacute DE LA PROBL~MATJQUL 5

12 MEacuteTHODE DE RECHERCHE 7

13 DEacuteFINITION DU PROJH 7

131 La motivation 8

132 La porteacutee 8

J 33 Lobjectif 8

134 Description des utilisateurs des reacutesultats de la recherche 9

135 Les limites du projet 1J

14 PLANIfICATION DU PROJET 11

CHAPITRE )J bullbullbullbullbullbullbullbullbullbullbullbullbullbullbullbullbull 13

TEST SCEacuteNARISEacute VUE DENSEMBLE 13

2 J CONCEPTS DE BASE ET TERMINOLOGJE 13

211 Terminologie 13

212 Cas de test 14

22 TEST SCEacuteNAR]S~ (SCRIPTED TESTING) 14

III

TABLE DES MATIEgraveRES

LISTE DES TABLEAUX viii

LISTE DES FIGURES ix

LISTE DES ABREacuteVIATIONS x

REacuteSUMEacute xi

INTRODUCTION 1

CHAPITRE 1 5

DEacuteFINITION DU SUJET DE RECHERCHE 5

11 EacuteNONCEacute DE LA PROBL~MATJQUL 5

12 MEacuteTHODE DE RECHERCHE 7

13 DEacuteFINITION DU PROJH 7

131 La motivation 8

132 La porteacutee 8

J 33 Lobjectif 8

134 Description des utilisateurs des reacutesultats de la recherche 9

135 Les limites du projet 1J

14 PLANIfICATION DU PROJET 11

CHAPITRE )J bullbullbullbullbullbullbullbullbullbullbullbullbullbullbullbullbull 13

TEST SCEacuteNARISEacute VUE DENSEMBLE 13

2 J CONCEPTS DE BASE ET TERMINOLOGJE 13

211 Terminologie 13

212 Cas de test 14

22 TEST SCEacuteNAR]S~ (SCRIPTED TESTING) 14

IV

23 BREgraveVE HISTOIRE DES TESTS 16

24 LES MODEgraveLES DE TEST 17

25 PROCESSUS DE TEST SCEacuteNAR1SEacute 20

251 La planification 23

252 Analyse et conception 24

253 Exeacutecution et eacutevaluation 29

26 CONCLUSION 29

CHAPITRE III 30

TEST EXPLORATOIRE VUE DENSEMBLE 30

31 DEacuteFINITIONS 30

32 PROCESSUS DE TEST EXPLORATOIRE 34

33 TEST EXPLORAT01RE GEacuteREacute PAR SESSION (SBTM) 35

34 LES STYLES ET LES TECHNIQUES DEXPLORATION 38

35 CONCLUSION 42

CHAPITRE IV 43

REVUE DE TRAVAUX RELIEacuteS 43

41 EacuteTUDE DE ITKONEN ET RAUTIAINEN ( 2005) 43

411 Les raisons dutilisation du test exploratoire 44

412 Les modes dutilisation du test exploratoire 45

413 Les beacuteneacutefices du test exploratoire 46

414 Les lacunes du test exploratoire 46

42 EacuteTUDE DE PETTY (2005) 47

43 EacuteTUDE DE LYNDSA Y ET VAN EEDEN (2003) 49

44 EacuteTUDE DE JAMES ET WOOD (2003) 53

45 EacuteTUDE DE AMLAND ET VAGA (2002) 56

46 SYNTHEgraveSE DES REacuteSULTATS DES EacuteTUDES PROPOS~I~S 57

CHAPITRE V 60

v

LEacuteTUDE EMPIRIQUE 60

51 MOTIVATIONDELEacuteTUDE 60

52 LA STRATEacuteGIE DE LEXPEacuteRIENCE 61

53 LE SCHEacuteMA DE LEXPEacuteRIENCE 63

531 Objectifs et hypothegraveses de lexpeacuterience 63

532 La conception expeacuterimentale 64

533 Les instruments de Jeacutexpeacuterience 64

534 Le traitement expeacuterimental 65

54 ANALYSE DES REacuteSULTATS DE LEXPEacuteRIENCE 67

541 AnaJyse des resulats de test exploratoire 67

542 Analyse des reacutesultats de TE et TS 70

55 CONCLUSION 73

CHAPITRE VI 74

CADRE CONCEPTUEL DE COMPARAISON 74

61 MISE EN CONTEXTE DE LEacuteTUDE COMPARATIVE 74

62 CADRE CONCEPTUEL DE COMPARAISON 76

621 Les caracteacuteristiques dutilisation 77

622 Les caracteacuteristiques de gestion 78

623 Les caracteacuteristiques techniques 78

624 Les caracteacuteristiques du personnel 78

625 La productiviteacute 79

63 CONCLUSION 81

CHAPITRE VII 82

ANALYSE COMPARATIVE DU TEST EXPLORATOJRE ET DU TEST SCEacuteNARJSEacute 82

71 COMPARAISON SeLON LES CARACTlR1STIQUES DUTILISATION 82

7 ]1 Les raisons dutilisation 82

712 Les caracteacuteristiques du logiciel 85

VI

713 Le type denvironnement daffaire 87

7IA Les ressources financiegraveres 88

715 Le temps de test disponible 89

72 COMPARAISON SELON LES CARACTEacuteRIST1QUES DE GESTION 91

721 La planification 91

722 Le controcircle et le suivi de progression de test 93

723 La communication dans le projet de test 94

72A La relation avec le client 96

73 COMPARAISON SELON lES CARACTEacuteRISTIQUES TeCHNIQUES 96

731 Les activiteacutes de test 97

732 Les risques du logiciel 100

733 La couverture de test 102

734 Loracle de test 103

74 COMPARAISON SELON LES CARACTEacuteRISTIQUES DU PeRSONNEL 106

7AI Les carateacuteristiques du testeur 106

75 COMPARAISON SELON lA PRODUCTIVITEacute 108

77 CONClUSiON 113

CHAPITRE VIII 114

ANALYSE DES REacuteSULATS 114

81 ANALYSE DES RESULTATS THEORIQUeS 114

82 ANALYSE DES REacuteSULTATS EMPIRIQUES 115

83 PISTES POTENTIELLES DE RECHERCHE 117

8A CONCLUSION ] 18

CONCLUSION 119

ANNEXE A 121

CADRE DE BASILI ADAPTEacute Agrave LA RECHERCHE EXPLORA TUumlIRE 121

ANNEXE B 124

vu

PLAN DE TEST IEEE829 124

ANNEXE C 127

SOIREacuteE DE TESTS 127

ANNEXE D 130

RAPPORT DE LA SESSION DE TEST 130

REacuteFEacuteRENCES ~ 131

YJJI

LISTE DES TABLEAUX

Tableau 11 Cadre de Basili adapteacute agrave la recherche exploratoil-e 7

Tableau 21 La matrice de traccedilabiliteacute 25

Tableau 31 Grille des tacircches de test exploratoire 34

Tableau 51 ANOVA des donneacutees collecteacutees de lexpeacuterience 73

Tableau 71 Le guide de seacutelection de lapproche de test III

IX

LISTE DES FIGURES

Figure 21 Le pourcentage des erreurs danalyse et de conception 17

Figure 22 Modegravele de test en V 18

Figure 23 Les pratiques de test Agile 20

Figure 24 Scheacutematisation des documents de preacuteparation de tests 22

Figure 25 Speacutecification de Cas de Test 26

Figure 31 Continuum repeacuterant lactiviteacute de test 33

Figure 32 Cadre dapplication de SBTM 37

Figure 33 Heuristic Test Strategy Model 40

Figure 41 Coucirct de documentation versus linnovation dans le test 55

Figure 52 Le traitement de test exploratoire 66

Figure 53 Les reacutesultats de test exploratoire 67

Figure 54 Importance de deacutefauts deacutetecteacutes avec le test exploratoire 68

Figure 55 LinOuence de lexpertise su r le test exploratoire 70

Figure 56 Reacutesultats des sujets aux TE ct TS 71

Figure 57 Repreacutesentation scheacutematique de lanalyse ANOVA 72

Figure 61 Le cadre conceptuel de comparaison 80

Figure 71 Les eacuteleacutements essentiels du test du logiciel 97

Figure 72 Les activiteacutes de test sceacutenariseacute 98

Figure 73 Les activiteacutes de test exploratoire 99

x

LISTE DES ABREacuteVIATIONS

COS Context Driven School

Institute ofElectrical and Electronics IEEE

Enginecrs

SBET Session Based Exploratory Testing

SBTM Session Based Test Management

SWEBOK Software Engineering Body ofKnowledge

UQAgraveM Universiteacute du Queacutebec Agrave Monlreacuteal

TE Test exploratoire

TS Test sceacutenariseacute

Xl

REacuteSUMEacute

Le test exploratoire (TE) est deacutefini comme lapprentissage la conception et jexeacutecution simultaneacutes des tests tout agrave fait lopposeacute du test sceacutenariseacute (TS) preacutedeacutefini Lapplicabiliteacute de cette nouvelle approche ne cesse pas daugmenter dans lindustrie du test de logiciel Malgreacute cette expansion et le succegraves de quelques entreprises qui souvrent dans le domaine de deacuteveloppement du logiciel dans ses expeacuteriences dadoption et dutilisation de TE les contextes et les facteurs favorables pour ladoption de lapproche dans une meacutethodologie de test ne sont pas toujours bien eacutetablis Labsence des preuves claires de sa productiviteacute annonceacutee par quelques praticiens dans la litteacuterature sajoute agrave la probleacutematique Ce travail est une eacutetude exploratoire visant deux objectifs Premiegraverement eacutetudier et analyser les contextes favorisant lutilisation de TE comme une meacutethodologie primaire de test agrave la place des tests sceacutenariseacutes en eacutelaborant une analyse comparative entre le TE et le TS Deuxiegravemement eacutevaluer sa productiviteacute dans une eacutetude empirique par rapport au TS Nous avons eacutelaboreacute un cadre conceptuel de comparaison dans lequel nous avons identifieacute cinq dimcnsions o Les caracteacuteristiques dutilisation les raisons de lutilisation les caracteacuteristiques du

logiciel le type denvironnement daffaires les ressources financiegraveres et le temps disponible pour les tests

o Les caracteacuteristiques de gestion la planifIcation le controcircle ct le suivi des tcsts la communication dans le projet de test ct la relation avec le client

o Les caracteacuteristiques techniques les activiteacutes de test joracle de test les nsques du logiciel ct la couverture de test

o Les caracteacuteristiques du personnel les caracteacuteristiques des testeurs la culture de lorganisation

o La productiviteacute le nombrc de deacutefagraveuts deacutetecteacutes limportance de deacutefauts deacutetecteacutes

Cc cadre a eacuteteacute utiliseacute comme base dans Janalyse comparative du TE et du TS Dans cette analyse nous avons compareacute une approche disciplineacutee de TS guideacute par les patrons de documentation IEEE 829 ct une approche librc scmi planifieacutee de TE rcpreacutesenteacutec par lapproche Session Based Exploratory Testing (SI3ET) Dans cette comparaison la productiviteacute a eacuteteacute eacutevalueacutee par le biais dunc eacutetudc cmpirique que nous avons mise en œuvre dans les laboratoires informatiques de LUQAgraveM Malgreacute les limites du contexte de cette eacutetude empirique nous avons pu deacutegager quelques conclusions utiles Les reacutesultats permettent de montrer que certains facteurs de contexte du projet de test peuvent empecirccher lutilisation de TE comme une meacutethode principale de test Nous avons conclu que labsence de controcircle de couverture de test restreint en plus le type des projets ougrave le TE pourrait ecirctre utiliseacute Aussi lexpertise ct les qualifications neacutecessaires pour exeacutecuter le TE pourraient cmpecirccher son utilisation dans les projets de tests ougrave ces qualifications sont manquantes Les reacutesultats de jeacutetude empirique ont supporteacute lhypothegravese relative agrave limportance des deacutefauts deacutetecteacutes Dautres recherches quantitatives sur la productiviteacute de TE sont neacutecessaires dont ce travail pourra servir comme point de deacutepart

Mots-cleacutes

Test Test seeacutenariseacute Test exploratoire Session Based Exploratory Test (SBET)

INTRODUCTION

La croissance rapide de jutilisation des systegravemes infonnatiseacutes dans tous les domaines donne

une importance cruciale au problegraveme des anomalies informatiques De nos jours les

ordinateurs aident les humains dans la plupart des aspects de notre vie quotidienne et les

applications informatiques sont rendues plus puissantes et complexes Agrave cet effet

limportance de produire du logiciel de grande qualiteacute et robuste est devenue primordiale

(Osterweil 1996) Or la forte demande de produits logiciels de qualiteacute fait que les

organisations sont en quecircte continuelle de moyens pouvant leur permettre de produire de la

qualiteacute dans les temps ct dans le cadre du budget Un des moyens est Je test du logiciel

Dans les modegraveles traditionnels de deacuteveloppcment le test est un processus important II

soutient Jassurance qualiteacute en fournissant dcs informations sur la qualiteacute du logiciel

deacuteveloppeacute ou modi fieacute Lactiviteacute de test dans ces modegraveles est extrecircmement laborieuse et

demande des ressources importantes allant de 50 agrave 60 du eoucirct de deacuteveloppement (Perry

2000) Cependant la concurrencc sans ccsse croissante oblige les entreprises agrave sadapter aux

changements du marcheacute dans des cycles de deacuteveloppement plus courts Tester un logiciel

dans telles conditions nest plus une tacircche facile seffectue souvent sous la pression de temps

ct de budget Cela force lindustrie informatique agrave chercher de nouvelles meacutethodes efficaces

de test pour eacutepargner temps el argcnt et en produisant des logiciels de qualiteacute

Une nouvelle pratique dc test qui a fait son apparition a la fin des anneacutees 80 avait remis en

eause la vision traditionnelle des tests Cette pratique se deacutefinit comme lapprentissage la

conception ct lexeacutecution simultaneacutee des tests Cette derniegravere est tout agrave fait lopposeacute de la

meacutethode habituelle et sceacutenariseacutee de test neacutecessitant la speacutecification des cas de tests deacutetailleacutes

et des reacutesultats preacutevus avant jcxeacutecution de tests

2

Au deacutebut cette nouvelle pratique a eacuteteacute confondue avec le test ad hoc qui est trop souvent le

synonyme dun processus improviseacute intuitif pour chercher les deacutefauts du logiciel (Bach

2003) En 1990 un groupe dexperts en tests connu sous le nom anglophone Context Driven

School (CDS) laquo Test piloteacute par le contexteraquo a adopteacute le terme anglophone Exploratory

Testing laquo test exploratoireraquo pour deacutecrire et nommer cc type de test qui est deacutecrit dabord par

Kaner ( 1988)

Depuis son apparition le test exploratoire (TE) a eacuteteacute preacutesenteacute comme une innovation dans

lindustrie du test Une innovation pouvant garantir un niveau defficaciteacute de lactiviteacute de test

qui ne pourrait pas ecirctre reacutealiseacute par le test sceacutenariseacute seul (TS) (Bach 2003 Kaner et Tinkham

2003a) Cependant quelques praticiens ne le voient pas de la mecircme faccedilon et considegraverent le

TE comme un test ad hoc deacuteguiseacute ou enveloppeacute sous le terme scientifique laquo explorationraquo

(Black 1999) Bach (2003) ne nie pas le fait que le TE est une pratique habituelle utiliseacutee

souvent inconsciemment par nimporte quel testeur qui utilise sa creacuteativiteacute pendant lactiviteacute

de test Linnovation de lapproche selon lui est dameacuteliorer la faccedilon avec laquelle ce testeur

effectue ses tests en se basant sur des techniques ct des modegraveles scientifiques dexplorations

Agrave cet efrct les praticiens ct les chercheurs se sont pencheacutes sur lameacutelioration de ces

techniques dans le but de faire du TE une discipline apprise comme nimporte quelle activiteacute

intellectuelle Enfin avec la tendance actuelle des meacutethodes agiles le TE a pu trouver sa

place dans Jindustrie du test (Bach 2003) Les laquo agilistesraquo ont adopteacute le TE compte tenu de

sa grande capaciteacute dadaptation avec les pratiques agiles (Kohl 2005)

Les grandes organisations de deacuteveloppement du logiciel ont commenceacute agrave consideacuterer le TE

comme une approche valide de test Microsoft a utiliseacute un type structureacute et documenteacute de TE

impleacutementeacute par Bach (1999) pour tester et certifier une application pour la compatibiliteacute et la

stabiliteacute avec Windows 2000 Dautres entreprises sajoutent continuellement parce quelles

cherchent des meacutethodes plus rentables de test Toutefois chacune delles adopte lapproche

dune faccedilon personnaliseacutee avec les contraintes de son contexte

Malgreacute le succegraves obtenu par quelques entreprises dans limplantation de TE les contextes

favorables pour uti liser et impleacutementer lapproche ne sont pas encore bien eacutetablis dans la

3

litteacuterature Nous nous sommes fixeacute comme objectif dans ce travail de recherche agrave explorer

ces contextes en analysant les eacutetudes de cas et les expeacuteriences professionnelles publieacutees

reacutecemment Nous avons proceacutedeacute agrave une analyse comparative entre les deux approches de test

le TS et TE pour faire ressortir les facteurs favorables pour utiliser chacune delles

Nous avons proceacutedeacute aussi agrave une eacutetude empirique dc la productiviteacute de TE annonceacutee dans la

litteacuterature surtout par les deux concepteurs de lapproche (Bach 2003 Bach et Kaner

2004) Nous avons eacutevalueacute la productiviteacute de lapproche en termes du nombre et de

limportance des deacutefauts quelle peut deacutetecter Malhcureuscment les limites de contexte ougrave

sest deacuterouleacute notre eacutetude empirique ne nous a pas permis de tirer des conclusions fiables et

geacuteneacuteraliseacutees sur cette productiviteacute Cependant nous avons pu deacutegager quelques indications

utiles

Dans la reacutealisation de ce travail de recherche nous avons ducirc confronter le problegraveme de la

peacutenurie des travaux de recherches ct de la litteacuterature qui traite Je sujct de TE Malgreacute que

cette approche ait eacuteteacute introduitc dans le domaine de test logiciel il y a plus dc vingt ans elle

na pu que reacutecemment attirer linteacuterecirct des chercheurs autres que les membres de CDS

(ltkonen ct Rautiainen 200S)Labsence des connaissances agrave ce sujet nous a obligeacutee agrave avoir

recours agrave notre jugement dans cette analyse comparative cn sappuyant sur notre

compreacutehension de tous les eacuteleacutements relieacutes agrave lactiviteacute de test Notre approche a eacuteteacute de

sappuyer sur la litteacuterature ainsi que sur divers concepts theacuteoriques

Dans le cadre de cette recherchc nous proceacutedons par une eacutetude cxploratoire pUisque les

connaissances dans le domaine que nous traitons dans cc travail de recherche ne sont pas

encore bien eacutetablies

Ce meacutemoire est composeacute de huit chapitres Dans le chapitre l nous deacutefinirons notre sujet de

recherche la probleacutematiquc la motivation la porteacutee lobjectif les utilisateurs ct les limites

du projet selon la meacutethode de (Abran ct al J 999) que nous avons adopteacutee pour la mise en

œuvre de cc travail de recherche Dans le chapitre Il nous preacutesenterons une vue densemble

de TS afin didentifier ses eacuteleacutemcnts fondamentaux ct de comprendre ses points de diffeacuterence

4

avec le TE Dans le chapitre Ill nous preacutesenterons une vue densemble de TE Puis dans le

chapitre IV nous proposerons une revue de litteacuterature de quelques eacutetudes de cas et

expeacuteriences dutilisation de TE dans lindustrie de test Le chapitre suivant deacutecrit leacutetude

empirique que nous avons meneacutee en laboratoire Nous preacutesenterons dans le chapitre VI le

cadre conceptuel de comparaison que nous avons deacuteveloppeacute dans le cadre de notre recherche

Le chapitre VlI preacutesentera notre analyse comparative de TE et TS Nous preacutesenterons des

suggestions et les contextes favorables pour utiliser le TE comme unc meacutethodologie primaire

de test Le dernier chapitre porte essentiellement sur les reacutesultats danalyse linterpreacutetation

de ces reacutesultats et les perspectives futures de recherche Enfin nous terminerons notre rapport

avec une conclusion

11

CHAPITRE 1

DEacuteFINITION DU SUJET DE RECHERCHE

Eacutenonceacute de la probleacutematique

Lapparition de test exploratoire (TE) dans le domaine du test du logiciel a susciteacute beaucoup

de controverse quant agrave sa validiteacute et agrave son efficaciteacute Pour certains praticiens le test

exploratoire est toujours le test ad hoc deacuteguiseacute sous le terme scientifique laquoexplorationraquo

(Black 1999) Selon Black (1999) Ic TE ne diffegravere pas de la technique laquo Error Guessing raquo

proposeacutee par Myers (l97) qui a toute fois preacuteciseacute quil ne sagit pas dune technique de test

mais seulement de lintuition Selon Bach (2003) le TE est une approche valide de test tout

comme le test sceacutenariseacute (TS) et il pourrait ecirctre dans certaines situations plus productif que le

TS La diffeacuterence sur la reconnaissance ct la valeur de TE qui est le chef dœuvre ct

linvention de la penseacutee Context Oriven School (CDS) a lanceacute un deacutebat entre les intervenants

preacuteconisant les principes de cette eacutecole de penseacutee ct les adheacuterents de la discipline

La philosophie de la penseacutee CDS est deacutetablir une relation consciente explicable et

autocritique entre le processus de test et le contexte de test Autrement dit le testeur devrait

ajuster ses solutions convenablement au problegraveme courant et ecirctre capable de controcircler son

processus de test ct dapporter des changements au moment voulu pendant le processus En

2001 les trois membres fondateurs de CDS Kaner Bach et Pettichord ont formuleacute les sept

principes cleacutes de leur discipline ct ils les ont publieacutes dans le premier livre portant sur les

pratiques et les ideacutees de ce groupe (Bach et al 2002) Il sagit des principes deacutecrits cishy

dessous (traduit de Bach et al 2002 p 261)

bull La valeur de nimporte quelle pratique deacutepend de son contexte

bull li ya de bonnes pratiques dans un contexte mais il ny a aucune mei Ileure pratique

6

bull Des personnes qui collaborent entre elles sont les parties les plus importantes de

nimporte quel contexte de projet de test

bull Les projets se deacuteroulent souvent dune maniegravere impreacutevisible

bull Le produit est une solution agrave un problegraveme Si le problegraveme nest pas reacutesolu le produit ne

pourra pas fonctionner

bull Un bon test logiciel est un processus intellectuel comportant plusieurs deacutefis

bull Seulement par les compeacutetences qui sexercent dune faccedilon coopeacuterative dans tout le

projet nous sommes capables de prendre les bonnes deacutecisions au bon moment pour

tester efficacement le produit

Par contre la discipline met laccent sur des principes diffeacuterents de ceux citeacutes ci-dessus

Entre autres la normalisation la documentation et le formalisme du processus constituent les

eacuteleacutements clefs du processus de test (Thompson 2003) Alors il ressort des principes de deux

eacutecoles que le CDS accentue le rocircle de la personne ses qualifications et la collaboration entre

les intervenants dans le projet de test tandis que la discipline accentue le rocircle du processus

sa gestion et sa mesure dans le projet de test En dautres telmes Ic test devrait ecirctre

preacutedictible enchacircsseacute dans un cadre de travail planifieacute et documenteacute dont la norme de

documentation IEEE 829 pourrait constituer une partie inteacutegrante (Swebok 2004)

Les deacutefenseurs des deux approches de test le TS et le TE ont lanceacute un deacutebat qui oppose le

formel contre jinformel les proceacutedures contre la liberteacute luniformiteacute contre la creacuteativiteacute et le

controcircle contre lefficaciteacute Les auteurs ct les praticiens de CDS annoncent quc le TE est une

approche productive qui pourrait constituer une meacutethode principale ct indeacutependante de test

(Bach 2003 Kaner 2006) Toutefois ces mecircmes praticiens nont pas identifieacute les contextes

favorables dutilisation de TE

De plus ils nont pas proposeacute des preuves concregravetes de sa productiviteacute largement annonceacutee

dans la litteacuterature agrave part quelques anecdotes et expeacuteriences veacutecues eacutelaboreacutees dans dcs

contextes personnels (Bach 2003)

7

12 Meacutethode de recherche

Dans le cadre de cette recherche exploratoire la deacutemarche meacutethodologique suivie est baseacutee

sur le cadre de Basili (Abran et al 1999) adapteacute aux eacutetudes de cas de type exploratoire Ce

travail est inclus sous le thegraveme de recherche exploratoire compte tenu du fait que les

problegravemes souleveacutes sont peu abordeacutes dans la litteacuterature Nous essayons de clarifier la base de

connaissances sur le TE et de trouver des pistes futures de recherche

Le cadre proposeacute est composeacute de quatre eacutetapes principales la deacutefinition la planification

lopeacuteration et linterpreacutetation Chaque phase deacutecrit les activiteacutes etou les livrables agrave

entreprendre afin datteindre les objectives de celle recherche Un modegravele de ce cadre est

preacutesenteacute dans le tableau 11 La deacutefinition du projet est preacutesenteacutee dans la scction qui suit La

structure suivie dans ce travail de recherche est proposeacutee dans lannexe A

Tableau 11 Cadre de Basili adapteacute agrave la recherche exploratoire (Abran ct al 1999)

1 Deacutelinition

Motivation Objet Objectif Utilisateurs

2 Planification

Etapes du projet Inlrants Livrables du projet

3 Opeacuteration

Analyse des documents Fcedback des praticiens Modegravele proposeacute

4 1nlerpreacutetation

Contexte Extrapolalion Travaux futurs

13 Deacutefinition du projet

La deacutefinition de la recherche agrave partir du cadre a permis deacutetablir la motivation la porteacutee les

obj ectifs de recherche les utilisateurs des reacutesultats de celle recherche et la planification du

projet de recherche

8

131 La motivation

La motivation principale de ce travail de recherche est dexplorer les apports du TE Il sagit

aussi dexplorer lampleur de la divergence entre les deux eacutecoles de penseacutees ]a discipline et

le CDS par le biais dune eacutetude comparative approfondie des meacutecanismes et des techniques

utiliseacutes dans le TS et dans le TE La productiviteacute du TE est fortement annonceacutee par quelques

praticiens ce qui nous a aussi motiveacutee agrave entreprendre une eacutetude empirique pour eacutevaluer la

validiteacute de ces annonces Nous voulons par cette recherche contribuer agrave ameacuteliorer le

processus de choix de lapproche convenable de test en deacuteveloppant un guide deacutevaluation

des facteurs de contexte de projet de test Ce guide va permettre de clarifier les contextes

favorables pour utiliser le TE comme une meacutethodologie primaire de test

132 La porteacutee

Cette eacutetude traite le test dynamique du logiciel selon lin proceacutedeacute boicircte noire Elle porte sur la

comparaison de deux approches de test le TE ct TS

133 Lobjectif

Lobjectif de notre eacutetude est de preacutesenter un ensemble de faits theacuteoriques et expeacuterimentaux

qui peuvent justifier une reacuteponse agrave notre question de recherche principale

bull Est-ce que le test exploratoire pourrait remplacer le test sceacutenoriseacute Si oui dans quels

contextes

Pour reacutepondre agrave la question principale de la recherche nous essayons dabord de trouver des

reacuteponses aux questions secondaires suivantes

1 Quels sont les facteurs de contexte de test qui influencent le choix de Japproche de

test

2 Parmi ces facteurs quels sont les facteurs de contexte de test favorables pour utiliser

leTE

Pour reacutepondre agrave toutes ccs questions nous avons effectueacute une analyse comparative de TE par

rappol1 au TS cn utilisant un cadre conceptuel de comparaison deacuteveloppeacute dans le cadre de ce

9

travail de recherche Ce cadre inclut des critegraveres ou des facteurs de comparaison formuleacutes agrave

partir des reacutesultats des eacutetudes de cas de TE proposeacutees dans la litteacuterature ct en sinspirant du

cadre de comparaison proposeacute par Tumer et Boehm (2004) Cette analyse comparative va

permettre de souligner les contextes favorables agrave chacune des deux approches de test Par la

suite nous avons conclu sur les contextes ougrave le TE peut remplacer le TS

Dans le cadre de cette eacutetude comparative nous avons proceacutedeacute agrave une eacutetude empirique de la

productiviteacute de TE Agrave cet effet nous avons reacutealiseacute une expeacuterience dans les laboratoires

informatiques de lUQAgraveM Lobjectif principal de cette expeacuterience eacutetait de veacuterifier la

productiviteacute de TE en telmes de nombre et dimpo11ance de deacutefauts qui pourraient ecirctre

deacutetecteacutes en utilisant cette meacutethode de test De plus cette eacutetude empirique a porteacute sur la

comparaison de la productiviteacute de TE par rapport au TS autrement dit lanalyse de leffet de

la technique de test (TE TS) sur la productiviteacute de lactiviteacute de test en utilisant un

eacutechantillon composeacute de 56 sujets (les eacutetudiants de cours INF6160 session de lautomne

2005) Chaque eacuteleacutement de leacutechantillon a appliqueacute les deux techniques de test sur un

programme choisi Dans notre plan expeacuterimental les mecircmes sujets sont utiliseacutes dans les deux

traitements Cc type deacutetude est qualifieacute de plan expeacuterimental agrave un seul facteur agrave mesures

reacutepeacuteteacutees laquoSingle Factor Experiments Having Reapted Measures on The Same Elementsraquo

Nous avons exploiteacute et analyseacute les reacutesultats de deux faccedilons diffeacuterentes la premiegravere

lexploitation des reacutesultats de TE collecteacutes de notre expeacuterience que nous comparons avec les

reacutesultats quantitatifs proposeacutes dans la litteacuterature La deuxiegraveme la comparaison des reacutesultats

collecteacutes des deux approches Nous avons proceacutedeacute agrave lanalyse de variance ANOVA proposeacute

par Wincr (197 J p 105)

En geacuteneacuteral notre eacutetude vise la clarification des connaissances concernant le TE et sinteacuteresse

tout particuliegraveremcnt agrave leacutevaluation de sa contribution dans le domaine du test logiciel Nous

voulons preacutesenter les faits et les arguments existant dans la litteacuterature accompagneacutes de nos

deacuteductions personnelles

134 Description des utilisateurs des reacutesultats de la recherche

Ce travail de recherche revecirct de linteacuterecirct pour plusieurs types dintervenants les chercheurs

10

en terme de contribution agrave louverture de nouvelles pistes de recherche pour les praticiens et

les entreprises en terme de productiviteacute et rentabiliteacute de jactiviteacute de test et gains financiers et

les enseignants en terme didentification des nouvelles matiegraveres pour le cours dc test du

logiciel

1341 Les chercheurs

Les reacutesultats de ce projet de recherche pourront ecirctre utiliseacutes par les chercheurs inteacuteresseacutes par

leacutetude de TE Comme domaine de recherche les contextes favorables pour utiliser le TE

nont pas eacuteteacute eacutetudieacutes Ainsi la productiviteacute du TE en termes du nombre et de limportance

des deacutefauts qui pourront ecirctre deacutetecteacutes a eacuteteacute peu eacutetudieacutee empiriquement Dougrave limportance

des pistes et des solutions proposeacutees dans ce travail de recherche Lcs reacutesu hats theacuteoriques et

empiriques de cette eacutetude pourront ecirctre reacuteutiliseacutes dans dautres reacutepeacutetitions empiriques et

travaux futurs afin denrichir les connaissances existantes sur le TE

1342 Les entreprises

Au nivcau pratique cette recherche sinscrit dans un courant de preacuteoccupation des praticiens

et des entreprises dans le domaine de test du logicicl qui voudraicnt adopter et adapter le TE

clans leurs meacutethodologies de test En effet les patriciens et les entreprises veilleront avec plus

dimportance sur la rentabiliteacute de lactiviteacute de test en reacuteduisant la dureacutee du cycle de test et en

diminuant les efforts consacreacutes aux tests Le guide de seacutelection de lapproche de test reacutesultant

de lanalyse comparative entre le TE et le TS vise lidentification des contextes favorabIes

pour utiliser chacune des deux approches de tcst afin datleindre la rentabiliteacute et la

productiviteacute voulues et de reacutepondre aux besoins des praticiens et les entreprises

1343 Les enseignants

Ce travail est destineacute aux enseignants par lidentification des nouvelles matiegravercs pour le

cours de test du logiciel Habituellement la matiegravere de ce cours traite seulement le TS du fait

quelle est la meacutethode habituelle de test dans lindustrie Or la croissance continue de

ladoption de TE justifie linclusion de celui-ci dans les cours de tests pour preacuteparcr les

eacutetudiants agrave reacutepondrc aux besoins de Jindustrie Lutilisation du guide de seacutelection eacutelaboreacute

II

dans le cadre de ce travail serait beacuteneacutefique pour aider les eacutetudiants agrave identifier et agrave

diffeacuterencier les contextes qui favorisent lutilisation de chacune des deux approches de test

135 Les limites du projet

Une limite importante du projet vient de la limitation de contexte de notre eacutetude empirique

Labsence dun contexte industriel ou nous pouvons effectuer notre eacutetude empirique nous a

pousseacutee de faire cette eacutetude dans un contexte acadeacutemique en utilisant des eacutetudiants comme

des sujets de lexpeacuterience et un petit programme comme instrument de lexpeacuterience au lieu

dutiliser un grand logiciel Ceci a influenceacute les reacutesui tats de lexpeacuterience

lA Planification du projet

Dans le but datteindre notre objectif principal nous avons identifieacute les phases suivantes

1 Nous proposons un modegravele de processus de TS en mettant laccent sur les livrables

de chaque eacutetape et la documentation eacutelaboreacutee Notre modegravele suit le standard de

documentation lEEE829 (1998) pour pouvoir contraster les deux penseacutees discuteacutees

dans ce travail agrave savoir la discipline et le CDS chacune est repreacutesenteacutee par sa

pralique successivement le TS et Je TE

2 Nous proposons lapproche Session Based Test Managcmenl (SBTM) qUI va

repreacutesenter le TE dans lanalyse comparative de TE et le TS

3 Nous eacutetudions les eacutetudes de cas et les expeacuteriences dutilisations de TE dans

lindustrie de test Nous deacuteduirons les facteurs qui ont influenceacute Jutilisation ct

ladoption de TE dans la pratique de test

4 Nous reacutealisons notre eacutetude empirique dans les laboratoires informatiques de lUQAgraveM

et nous traitons les donneacutees collecteacutees pendant cette expeacuterience

5 Deacuteveloppement de notre cadre conceptuel de comparaison qui va guider lanalyse

comparative de TE et le TS

12

6 Nous proceacutedons agrave une analyse comparative des deux approches de test le TS et le TE

selon le cadre de comparaison eacutelaboreacute et les reacutesultats de leacutetude empirique

7 Nous discutons les reacutesultats de lanalyse comparative Puis nous concluons les

contextes favorables pour utiliser le TE comme une meacutethodologie primaire de test

Nous terminons par leacutelaboration dun guide de seacutelection de lapproche dc test

Le chapitre 1preacutesente leacutetape 2 laquoPlanificationraquo de cadre de Basili Leacutetape 3 laquoOpeacuterationraquo de

ce cadre sera abordeacutee dans les chapitres Il 111 IV V VI et VII Leacutetape 4 laquoInterpreacutetationraquo

sera abordeacutee dans le chapitre VIII

CHAPITRE II

TEST SCEacuteNARISEacute VUE DENSEMBLE

Ce chapitre preacutesente les eacuteleacutements neacutecessaires agrave la compreacutehension du test sceacutenariseacute (TS) Dans

la premiegravere partie nous deacutefinissons le rs et nous preacutesenterons un bref historique du test du

logiciel Nous faisons ensuite un survol rapide de quelques modegraveles de test Par la suite nous

proposerons un modegravele du processus de TS baliseacute dans les patrons de la norme IEEE 829 et

nous terminons par une conclusion

2] Concepts de base et terminologie

211 Terminologie

Dans cette section nous proposons quelques deacutefinitions et certains termes et concepts

fondamcntaux du test logiciel Premiegraverement nous deacutefinissons les termes erreur deacutefaut et

deacutefaillance Ces termes sutilisent parfois dune faccedilon interchangeable pour deacutecrirc un

mauvais fonctionnement dans le logiciel Swebok (2004) a identifieacute une fautc ou deacutefaut

(Defeu FauI) comme la cause dun mauvais fonctionnement dans le logiciel ct leffet nonshy

deacutesireacute obscrveacute comme deacutefaillance (Faiure) Autrement dit les tests reacutevegravelent lcs deacutefaillances

causeacutees par un deacutefaut qui peut etou doit ecirctre enleveacute En fait Swebok a adopteacute les deacutefinitions

proposeacutees par IEEE agrave ces termes

bull Erreur (Error) Action humeacuteline produisant un reacutesultat incorrect (IEEE 729)

bull Deacutefaut (Defect Bug FanU) une imperfection dans un composanl ou un systegraveme qui

peUl conduirc agrave ce gu un composant ou un systegraveme nexeacutecute pas les fonctions requises

(IEEE 729)

Deacutefaillance (Failure) Fin de la capaciteacute du systegraveme ou du composant agrave effectuer la

fonction rcquise ou agrave Jcffectucr dans les limites speacutecifieacutecs (IEEE 729)

14

212 Cas de test

Cest un ensemble de valeurs dentreacutee de preacute-conditions dexeacutecution de reacutesultats attendus et

de post-conditions dexeacutecution deacuteveloppeacutes pour un objectif particulier tel quexeacutecuter un

chemin pm1iculier dun programme ou veacuterifier Je respect dune exigence speacutecifique (IEEE

610) La norme IEEE829 (1998) a deacutefini un cas de test comme un document indiquant les

entreacutees les reacutesultats preacutevus et les conditions dexeacutecution pour un article de test

Selon Kaner (2003) un cas de test est une question eacutelaboreacutee pour obtenir une information sur

le programme sous test Cette information se reacutevegravele par lexeacutecution du test relieacute agrave cette

question Cet auteur a citeacute deux conseacutequences indirectes de sa deacutefinition la premiegraverc est que

le cas de test devrait ecirctre capable de fournir une information utile au moment de lexeacutecution

Dc ce fait selon lauteur un cas de test eonccedilu au deacutebut de lactiviteacute de test ne pourra pas

reacuteveacuteler une information ulteacuterieurement dans le projet de test quand le logieiel deviendra plus

stable Cest lun des deacutesavantages du TS citeacute par Copeland (2004) La deuxiegraveme implication

que le cas de test ne devrait pas neacutecessairement deacutetecter un deacutefaut mais il suffit quil

fournisse unc information qui souvent megravene agrave la deacutetection dun deacutefaut scion lauteur

Leacutelaboration de ccttc deacutefinition nest pas arbitraire mais proposeacutee pour inclure le cas speacutecial

de cas de tcst cxploratoire (TE) et ee pour deux raisons la premiegravere est que les eas de tests

exploratoires se fondent sur leacutelaboration des questions agrave propos du logieiel sous test (Kaner

ct Tinkham 2003a) La deuxiegraveme est quun cas de test exploratoire ne devrait pas

obligatoiremcnt deacutetecter un deacutefaut mais il suffit quil reacutevegravele une information Cette

information pourrait ecirctre utiliseacutee pour concevoir un autre cas de test qui pouuait mener agrave la

deacutetcction dun deacutefaut (Kancr et Tinkham 2003a)

22 Test sceacutenariseacute (Scripted Tcsting)

Cest un test manuel qui sc fait typiquement par un testeur junior en suivant les eacutetapes et les

proceacutedures conccedilus par un testeur senior (Bach et aL 2002)Ces mecircmes auteurs ont souligneacute

plus tard dans plusieurs reprises que le test sceacutenariseacute pourrait ecirctre automatiseacute (Kaner 2006)

15

Selon Copland (2004) le test sceacutenariseacute est nimporte quelle activiteacute de test manuelle ou

automatiseacutee baseacutee sur la conception et Jenregistrement des scripts deacutetailleacutes de tests avant

lexeacutecution

Dans un TS la planification et la conception des tests se font avant leur exeacutecution Les cas et

les sceacutenarios de test typiquement mais pas neacutecessairement sont deacutefinis tocirct dans le cycle du

deacuteveloppement du logiciel selon le modegravele du cycle de vie utiliseacute On les preacutepare en se

basant habituellement sur le document des speacutecifications des exigences du logiciel dans un

proceacutedeacute de test boicircte noire sans accegraves au code ou sur la logique interne du programme dans

un proceacutedeacute boicircte blanche avec accegraves au code ou une combinaison des deux Les cas de tests

sont alors exeacutecuteacutes par un autre testeur que celui qui les a conccedilus quand le logiciel devient

disponible pour les tests

Historiquement le test sceacutenariseacute a eacutemergeacute en tanl quune phase dans le premier modegravele de

deacuteveloppement en cascade (Royce 1970) Dans ce modegravele le deacuteveloppement est deacutecomposeacute

en plusieurs eacutetapes seacutequentielles dont chacune possegravede des critegraveres dentreacutee et de sortie

preacutecis et des livrables bien deacutetermineacutes Alors le test est lune de ces eacutetapes son rocircle est

deacutevaluer si les exigences sont bien comprises et speacutecifieacutees (Validation) et que la conception

est correctement implanteacutee par le code (Veacuterification) Reacutecemment le TS a franchi des

nouvelles dimensions que ccllcs connues dans Ics anneacutees 70 Alors nimporte quelle

meacutethodologie de deacuteveloppement mecircme les plus agiles peuvent Jutiliser nimporte ougrave la

reacutepeacutetitiviteacute lobjectiviteacute et lauditabiliteacute sont neacutecessaires ct importantes dans le processus de

test du logiciel (CopeJand 2004)

Selon Copeland (2004) la reacutepeacutetitiviteacute signifie que les lests ou les proceacutedures de tests sont

suffisamment deacutetailleacutees pour quils puissent ecirctre exeacutecuteacutes par quelquun autre que leur auteur

original En cc qui concerne lobjectiviteacute elle signifie que la creacuteation de tests ne deacutepend pas

seulement de la creacuteativiteacute et la compeacutetence de son concepteur mais quils sont baseacutes sur des

prineipes de conception bien deacutetermineacutes deacuteriveacutes agrave partir des exigences du logiciel les cas

dutilisations ct les standards agrave respecter dans le projet de test Quant agrave lauditabiliteacute ellc

signifie la traccedilabiliteacute bidirectionnelle entre les speacutecifications dexigences et les cas de tests

16

Cette traccedilabiliteacute permet de mesurer formellement la couvel1ure de test qui sera abordeacutee dans

les sections qui suivent

23 Bregraveve histoire des tests

Myers (1979) a identifieacute le test logiciel en tant quune action dexeacutecuter un programme ou un

systegraveme dans le but de deacutetecter ses deacutefauts Agrave leacutepoque cette deacutefinition a eacuteteacute probablement la

meilleure disponible Elle refleacutetait les pratiques de cette peacuteriode ou le test apparaicirct seulement

agrave la fin du cycle de deacuteveloppement visant principalement la deacutetection des erreurs Puis en

1988 la deacutefinition de test logiciel a changeacute en faveur de leacutevaluation de la qualiteacute du logiciel

plutocirct quun simple processus pour reacuteveacuteler les erreurs Hetzel (1988) a deacutefinit le test comme

une activiteacute dont son but est deacutevaluer et valider les fonctionnaliteacutes du logiciel Reacutecemment

le test est perccedilu comme une activiteacute exeacutecuteacutee pour eacutevaluer et ameacuteliorer la qualiteacute du logiciel

en identi fiant ses deacutefauts et ses problegravemes (Swebok 2004) Par cette deacutefinition Swebok

ajoute lameacutelioration de la qualiteacute du logiciel agrave leacutevaluation de la qualiteacute et agrave la recherche des

deacutefauts Cette meacutethode connue actuellement sous le tenne de laquo test preacuteventifraquo (Craig ct

Jaskiel 2002 Swebok 2004 Perry 2000) Selon Swebok (2004) le test devrait encadrer

lensemble du deacuteveloppement et de la maintenance Cl ecirctre en soi une partie importante de la

construction du produit logiciel

La philosophie de test preacuteventif dicte que le test pourrait ameacuteliorer la qualiteacute du logiciel sil

apparaicirct assez tocirct dans le cycle de deacuteveloppement ]1 sagit de la creacuteation de cas de tests pour

valider les exigences et la conception avant mecircme le codage du logiciel Cela permet de

deacutetecter les faiblesses potentielles et les erreurs dans les premiegraveres phases de deacuteveloppement

et de reacuteduire le coucirct de correction des deacutefauts sachant que plus lerreur est deacutecouverte tocirct

dans le processus moins elle colite cher agrave corriger ct plus lerreur se situe au deacutebut du cycle

de deacuteveloppement plus eUe colite cher agrave corriger ulteacuterieurement dans le cycle (Boehm J981

Pressman J997) Selon Perry (2000) la plupaJ1 des erreurs deacutetecteacutees pendant la phase de test

pourraient ecirctre attribueacutees agrave des erreurs danalyse et de conception Elles repreacutesentent

approximativement tel quillustreacute sur la figure 21 les deux tiers des erreurs failes pendant le

deacuteveloppement du logiciel En conseacutequence la preacuteparation du plan ct des proceacutedures de test

sceacutenariseacute tocirct dans le cycle de deacuteveloppement permettent de fournir des informations utiles

17

aux concepteurs en identifiant les erreurs tocirct dans le projet comme les oublis ou les

incoheacuterences de conception avant que ces erreurs se transforment agrave des deacutefauts dans le code

Figure 21 Le pourcentage des erreurs danalyse et de conception (Adapteacute ct traduit de Perry 2000 pAS)

Erreurs de codage

64

Erreurs danalyse et de conception

Dans les meacutethodes agiles lactiviteacute de test est incorporeacutee dans chaque iteacuteration du processus

de deacuteveloppement et constitue une partie inteacutegrante essentielle de la construction du logiciel

(Boehm et Turner 2004) De ce fait nous croyons que les meacutethodes agiles satisfont aussi les

aspects principaux de la deacutefinition proposeacutee par Swebok (2004)

A part une vue exploratoire non traditionnelle propose le test comme une activiteacute

dinvestigation et dexpeacuterimentation Selon Bach ct Kaner (2004) le test est une investigation

dont Jobjectif est de reacuteveacuteler des informations sur la qualiteacute du produit agrave tester Cette

deacutefinition vise principalement linclusion de TE qui se base sur linvestigation et le

questionnement

24 Les modegraveles de test

Le modegravele en V constitue leacutetat de lart dans le domaine de test du logiciel Cest le modegravele

le plus utiliseacute et traiteacute dans la litteacuterature de test (Craig et Jaskiel 2002 Perry 2000) Cc

modegravele tel quillustreacute agrave la figure 22 divise le processus de test en plusieurs niveaux

effectueacutes conjointement avec jimplantation du logiciel Il commence par le test de petits

morceaux ct avance vers des plus grands refleacutetant diffeacuterents points de vues de test a

diffeacuterents niveaux de deacutetail

18

Figure 22 Modegravele de test en V (Adapteacute et traduit de Pyhajarvi ct aL 2003)

[ Exgence Jr-o---------t~[ AcceplaUon J li( ~

Speacutecifications Systegraveme

~

Conception Inteacutegration

~ ~

Codage Uniteacute~

Speacutecification ----J~ Planification ----J~ Test

Ce modegravele identifie des activiteacutes de test agrave chaque eacutetape du cycle de vie Le test unitaire est au

niveau Je plus bas dans la hieacuterarchie Lobjectif geacuteneacuteral de ce niveau de test est de trouver les

deacutefauts dans la logique dans les donneacutees et dans les algorithmes de chaque module pris

individuellement Apregraves Je test unitaire viennent les tests dinteacutegration ces derniers sont

effectueacutes pour trouver les deacutefauts dinterfaces entre les uniteacutes En remontant dans la

hieacuterarchie le niveau suivant les tests dinteacutegration est le test du systegraveme Ce dernier est le

processus de tester le systegraveme entier afin de veacuterifier le produit par rapport aux speacutecifications

des exigences Finalement le test dacceptation prend place afin de deacuteterminer si le logiciel

reacutepond aux exigences et aux attentes du client

La force de ce modegravele est quil permet de planifier et de preacuteparer les cas de test tregraves tocirct dans

le cycle du deacuteveloppement degraves que labstraction des exigences est connue Ce fait aide dans

la deacutetection des erreurs de conception et de speacutecification Autrement il permettait de deacutetecter

les erreurs avant quils se transforment agrave des deacutefauts dans le code cest ce quest connu

actuellement SOllS le terme de test preacuteventif Cependant celle force ramegravene avec elle une

19

faiblesse importante Cette faiblesse se traduit par la rigiditeacute de modegravele aux changements En

effet souvent la documentation utiliseacutee pour planifier et preacuteparer les cas de tests nest pas

assez mucircrie au deacutebut du projet de deacuteveloppement Par conseacutequent la possibiliteacute que le

logiciel se change ulteacuterieurement dans le cycle de deacuteveloppement est forte probable Ceci

neacutecessite la mise agrave jour de tous les artefacts du test deacutejagrave conccedilus qui est souvent tregraves coucircteux

Selon Bach et al (2002) les revues et les inspections pourraient ecirctre plus efficace dans la

deacutetection des erreurs des exigences et la conception que de concevoir des cas tests qui ne

seront jamais exeacutecuteacutes

Derniegraverement avec lapparition des meacutethodes agiles le modegravele de test en V ne peut plus

suivre cette nouvelle tendance du deacuteveloppement (Pyhajarvi et al 2003) En reacuteaction le test

Agile a fait son apparition Cest une meacutethode de test suivie dans les projets agiles de

deacuteveloppement (Marick 2003) Cet auteur a preacuteciseacute que la communication ct la collaboration

entre les testeurs les deacuteveloppeurs et le client constituent les principes essentiels du test

agile Le rocircle du testeur nest plus pareil agrave celui des modegraveles traditionnels ougrave le testeur

soccupe seulement de la veacuterification et la validation du logiciel deacuteveloppeacute Cela nous amegravene

vers un rocircle plus constructif du logiciel gracircce aux informations et aux feedbacks utiles que le

testeur pourrait fournir aux deacuteveloppeurs au fur ct agrave mesure sur la qualiteacute de lapplication

deacuteveloppeacutee agrave chaque iteacuteration Souvent le testeur utilise le TE pour tester le logiciel et fournir

cc feedbaek (Pettichord 2004)

La communication entre le testeur agile et le client est aussi tregraves importante (Marick 2003)

Souvent le testeur devrait collaborer avec le client pour identifier les sceacutenarios dutilisation

neacutecessaires agrave leacutelaboration des tests dacceptation Cela fournira une revue implicite aux

exigences et aide agrave bien visualiser le logiciel En fait le testeur peut assurer un fecdback tregraves

tocirct sur quelques aspects du logiciel tels que lutilisabiliteacute et dautres fonctionnaliteacutes aux

deacuteveloppeurs

Selon Hcndrickson (2005) le testeur a deux rocircles dans le test Agile testeur et designer Les

pratiques de test agile peuvent ecirctre reacutesumeacutees sur la figure ci-dessous

20

Figure 23 Les pratiques de test Agile (Adapteacute et traduit de Hendrickson 2005)

Dans une seule iteacuteration

Testeur

Tests unitaires Test exploratoire

automatiseacutes Tests dacceptations

automatiseacutes manuel

Reacutepresente des Fournit unRpent~ l exigences speacutecifications feedback

exeacutecutables exeacutecutables addtiOllllcl

Tel quillustreacute agrave la figure 23 le TE constitue une partie inteacutegrante et essentielle de test agile

25 Processus de test sceacutenariseacute

Pour faire la diffeacuterence entre le TS et le TE nous preacutesentons dans cette section un processus

de TS sans speacutecifier une meacutethodologie preacutecise Nous nous inteacuteressons seulement aux aspects

qUI nous permettrons de mener notre eacutetude comparative Nous avons choisi de suivre Je

standard IEEE 829 Selon Copland (2004) cetle norme de documentation est la meilleure

dans le domaine du test qui peut illustrer les aspects principaux de lapproche sceacutenariseacutee Ce

choix a eacuteteacute influenceacute aussi par nos besoins de contraster une vue sceacutenariseacutee disciplineacutee et

formelle avec une autre exploratoire et libre

La norme de documentation IEEE 829 de test du logiciel est une tentative de rassembler les

vues et preacutesenter quelques meilleures ideacutees de la pratique afin de mieux controcircler lactiviteacute

de test La nonne a eacuteteacute reacuteviseacutee et mise agrave jour en 1998 Elle deacutecrit huit documents qui peuvent

ecirctre diviseacutes en trois cateacutegories selon (Copeland 2004) les documents de preacuteparation des

tests produits avant le deacuteveloppement du logiciel les documents dexeacutecution des tests et les

21

documents de compleacutetude des tests Chacune de ces cateacutegories est composeacutee de documents

suivants

bull Documents de preacuteparation de tests

bull Plan de test

bull Speacutecification de conception de tests

bull Speacutecification de cas de tests

bull Speacutecification de proceacutedure de tests

bull Documents dexeacutecution de tests

bull Rapport de transmission darticle de test

bull log (registre) de test

bull Documents de compleacutetude de test

Rapport dincident de test

bull Rappol1 de sommaire de tests

La nonne IEEE 829 (1998) a citeacute quclques avantages de son utilisation

o Lutilisation des documents de tcsts standardiseacutes pourraient faciliter la communication

entre Ies intervenants de projct du deacuteveloppement en fournissant un protocole de

reacutefeacuterence commun

o Le standard IEEE 829 pourrait servIr comme un outil de veacuterification et deacutevaluation

(Check List) au processus de test

o Un ensemble de documents normaliseacutes selon cette norme pourrait eacutegalement fournir une

base pour leacutevaluation des pratiques de documentation de test du logiciel

o Lutilisation des documents selon la norme IEEE 829 permettrait de controcircler le

processus de test Cela reacutesulte de laugmentation de la visibiliteacute dc chaque phase du

processus

22

Figure 24 Scheacutematisation des documents de preacuteparation de tests (Adapteacute et traduit de

Copeland 2004 p189)

Plan de test

Speacuteci1iumlcation

de Conception de Test

1 S peacuteci fica lion

Speacutecification de Proceacutedure

de Cas de Test de Test

~------------~-Rapport de - Exeacutecution des -

transmission -~ _ tests _

darticle de test -------------

bull

Rapport

-~Log de test dincident de test

1 Rapport de~ Se reacutefeumlre agrave Sommaire de - -_ ___ EntreacuteeSortie

test

Dans notre eacutetude nous nous inteacuteresserons seulement aux documents de preacuteparation de tests

du fait quils constituent le principal point de divergence entre le TS et le TE La figure 24

montre les doeuments devraient ecirctre creacuteeacutees avant jexeacutecution de tests Souvent ces documents

sont creacuteeacutes parallegravelement agrave limpleacutementation du logiciel dans les vues preacuteventives de test

(Craig ct Jaskiel 2002) Cest lune des forces de TS qui pourrait sintroduire tregraves tocirct dans le

cycle de vie du logiciel et preacutevenir les erreurs et les ambiguiumlteacutes pendant la phase de

speacutecification des exigences et la conception avant quils se transforment agrave des deacutefauts dans le

code

Notons que les documents du test sont eacutegalement sujets agrave une validation Cela peut ecirctre

reacutealiseacute par une reacutevision formelle agrave ccs documents Agrave cet effet Jutilisation de la norme pouna

faciliter eacutenormeacutement la mise en place de cette validation (Craig et Jaskiel 2002) Cependant

23

selon Bach et al (2002) la norme pourrait nuire agrave la qualiteacute de test effectueacute Du fait que les

testeurs consacrent le temps limiteacute du test agrave la creacuteation dune documentation lourde et non

neacutecessaire au 1ieu de linvestir dans le test du logiciel

Selon (Swebok 2004 Pyhajarvi et al 2003 Craig et Jaskiel 2002 Perry 2000) le

processus de test comporte les eacutetapes suivantes la planification lanalyse et la conception de

tests lexeacutecution el leacutevaluation de tests Nous aHons aborder dans les sections qui suivent

chacune de ces eacutetapes en mettant laccent sur les documents creacuteeacutes et les eacuteleacutements

fondamentaux speacutecifieacutes dans ces documents

251 La planification

La planification de lactiviteacute de test peut commencer au moment de la formulation des

besoins se deacutevelopper et se raffiner pendant la phase de conception du logiciel Ce processus

de planification donne naissance a un plan de lesl qui deacutecrit les items (composants) et les

caracteacuteristiques de qualiteacute (fonctionnaliteacute performance utilisabiliteacute etc) qui devraient ecirctre

testeacutes ainsi que les responsabiliteacutes les livrables et les besoins environnementaux requis et

leacutecheacuteancier de projet de test Sachant que ce plan de test peut ecirctre creacutee au niveau de projet

(Master Test Plan) ou au niveau secondaire (unitaire inteacutegration systegraveme acceptation etc)

Cela deacutepend de la complexiteacute de logiciel et de lorganisation de projet Il faut noter que celle

planification est une activiteacute continue seffectue tout au long du cycle de deacuteveloppement

Alors les reacutesultats de lactiviteacute de test sont utiliseacutes pour mesurer les risques el modifier le

plan si neacutecessaire

Le patron du plan de test de la norme IEEE 829 deacutefinit 16 clauses deacutecrites ci-dessous la

description deacutetailleacutee de chaque clause est preacutesenteacutee dans lannexe B

1 Identificateur du plan de test

2 Introduction

3 Items de test

4 Caracteacuteristiques agrave tester

5 Caracteacuteristiques qui ne devraient pas ecirctre testeacutees

6 Approche de test

24

7 Critegravere de passageeacutechec

8 Critegravere de suspension et conditions de reprise

9 Livrables du test

10 Tacircches du test

Il Besoins environnementaux

12 Responsabiliteacutes

13 Besoins en personnel et formation

14 Ceacutedule

15 Risques et contingences

16 Acceptations

Le patron du plan de test preacutesenteacute ci dessus foumit un croquis ou une structure de base du

plan de test quil peut ecirctre adapteacute selon les besoins de chaque organisation Pratiquement la

plupart des plans proposeacutes dans la litteacuterature divisent la clause risque et contingence en deux

clauses seacutepareacutees la premiegravere deacutecrit les risques lieacutes au logiciel et la deuxiegraveme les risques lieacutes

au projet de test et ses contingences (Craig et Jaskiel 2002) En effet la rapiditeacute suivie dans

le deacuteveloppement et limpossibiliteacute de tester le logiciel exhaustivement ont pousseacute les

intervenants dans le domaine du test agrave utiliser les risques du logiciel pour focaliser la strateacutegie

et identifier la prioriteacute des items de test 11 sagit de faire une analyse de risques au deacutebut de

projet de test en se basant sur les speacutecifications dexigences (Craig Jaskiel 2002) Elle

permet aussi de deacuteterminer les zones agrave risques et les parties potentielles qui auraient tendance

agrave avoir plus derreurs et qui devraient ecirctre testeacutees rigoureusement Selon ces mecircmes auteurs

les reacutesultats de cette analyse doivent ecirctre revus occasionnellement pendant le projet de test

du fait que les speacutecifications les ressources la porteacutee de test et dautres facteurs dans le projet

peuvent se changer Dailleurs le risque des composants qui ont subi des changements

devient naturellement plus grand agrave chaque version Cette analyse de risques pourrait servir

aussi dans la mise en place de contingences convenables lorsquun eacuteveacutenement inattendu

survient et empecircche jexeacutecution normale du plan de test

252 Analyse et conception

La conception de tests est la premiegravere eacutetape de deacuteveloppement de tests Le processus

25

danalyse et de conception de tests se consiste de trois eacutetapes agrave savoir concevoir les tests en

identifiant les conditions de tests speacutecifier les cas de tests et speacutecifier les proceacutedures de tests

Alors pendant lanalyse la documentation de base disponible dans cette eacutetape tels que les

documents de speacutecification des exigences et de conception doivent ecirctre analyseacutes

soigneusement pour deacuteterminer les items ou les articles gui devraient ecirctre testeacutes Une

condition de test est deacutefinie comme un article ou un eacuteveacutenement qui peut ecirctre veacuterifieacute par un ou

plusieurs cas de tests tel que une fonction ou caracteacuteristique de qualiteacute

Pendant la speacutecification de cas de tests les donneacutees de tests sont deacuteveloppeacutees et deacutecrites en

deacutetail en utilisant une ou plusieurs techniques de conception de tests (Beizer 1995 Craig

Jaskiel 2002) Le choix dune technique deacutepend de la nature du systegraveme agrave tester les objectifs

viseacutes et le risque global de lexeacutecution (Craig Jaskiel 2002) Cette phase se conclut par la

production de trois livrables Speacutecification de Conception de Test Speacutecification de Cas de

Tes et Speacutecification de Proceacutedure de Test Elle se conclut aussi par leacutelaboration de la

matrice de traccedilabiliteacute qui trace les exigences vers les cas de tests (Craig Jaskiel 2002)

Tableau 21 La matrice de traccedilabiliteacute

Cas de test 1 Cas de test 2 Cas de test 3 Cas de test 4

Exigence J X X X X

Exigence 2 X Exigence 3 X X X

Exigence 4 X X

Totale 2 4 3 1

La matrice de traccedilabiliteacute permet de tracer les cas de tests sur les exigences Cela fournit un

moyen pour identifier les exigences qui ne sont pas bien testeacutees Autrement cest un outil

pour mesurer la couvel1ure de tests (sera eacutevoqueacute en deacutetail dans le chapitre VU)

Cette matrice permettait aussi danalyser limpact de changements sur les exigences et donne

une ideacutee du volume de travail neacutecessaire pour mettre agrave jour les cas de tests deacutejagrave conccedilus (Bach

et aL 2002)

26

2521 Speacutecification de Conception de test

Speacutecification de Conception de Test est un document speacutecifiant les conditions de tests

(eacuteleacutements de couverture) pour un article de test lapproche deacutetailleacutee du test et lidentification

des cas de tests de haut niveau associeacutes (IEEE 829 1998) Il compolie les eacuteleacutements suivants

J Identificateur de Speacutecification de Conception de Test (un nom unique pour distinguer le

document parmi tous les autres)

2 Caracteacuteristiques agrave tester (identifie es items et les caracteacuteristiques objets de celte

Speacutecification de Conception de test

3 Raffinements de lapproche (identifie les deacutetails de la technique de test et de lapproche

proposeacutee dans le plan de test)

4 Identification de tests (fournit un identificateur unique et une courte description des cas

de tests associeacutes agrave celte Speacutecification de Conception de test)

S Critegravere de succegraveseacutechec de test (critegravere utiliseacute pour deacuteterminer si une caracteacuteristiques

passe ougrave eacutechoue Je test)

En fait le document de Speacutecification de Conception de Test est unc miniature de plan de test

Son rocircle cst de regrouper les cas dc tests semblables destineacutes agrave tester une ou plusieurs

caracteacuteristiques du logiciel Ici quillustreacute sur la figure 2S

Figure 25 Speacutecification de Cas de Test

PIgtln de lest]

Speacutecilicirceation SpeacutecifiCgtltion peacutecifieation de Conception de Conception de Conception

de test de test de test ~ T

Cns de lesl 01 Cas de lest 02

1 i

27

Par la suite les speacutecifications de chaque cas de test speacutecifieacute dans le document Speacutecification de

Conception de Test devraient ecirctre deacutetermineacutees

2522 Speacutecification de Cas de Test

Le but de Speacutecification de Cas de Test est didentifier les deacutetails de chaque cas de test citeacute

dans la Speacutecification de Conception de Test Le patron IEEE 829 de Speacutecification de Cas de

Test deacutecrit les eacuteleacutements suivants

1 Identificateur de Cas de Test (un nom unique qui distingue ce cas de test parmi tous

les autres)

2 Items de test (items et caracteacuteristiques objets du cas de test)

3 Speacutecification des entreacutees (speacutecifie les entreacutees requises par ce cas de test)

4 Speacutecification des sorties (speacutecifie les reacutesullats preacutevus de lexeacutecution de cas de test)

5 Besoins environnementaux (mateacuteriel speacutecial ou logiciel neacutecessaire pour exeacutecuter ce

cas de test)

6 Exigences proceacutedurClles speacuteciales (identifie nimporte quelle proceacutedure speacuteciale

neacutecessaire pour insta11er lenv ironnement de test)

7 Deacutependances inter-cas (cite les cas de test qui doivent ecirctre exeacutecuteacutes avant ce cas de

test)

Comme nous venons de le voir les reacutesullats attendus devraient faire partie de Speacutecification

de Cas de Test Ces reacutesultats constituent loracle de test dans le TS

Selon Craig et Jaskiel (2002) japproche IEEE 829 requiert une documentation complegravete de

chaque cas de test cest la raison pour laquelle elle est utiliseacutee dans les systegravemes agrave grand

risque Selon ces mecircmes auteurs le patron ne constitue pas un bon choix pour tester les

systegravemes dynamiques et instables En effet la norme de documentation IEEE 829 demande

un effort important dans la creacuteation des cas de tests et quelques changements introduits sur le

logiciel peuvent rcndre ces cas dc tests invalides

Par contre ce patron constitue un bon choix dans les organisations dynamiques qUI se

caracteacuterisenl par le changement freacutequent de leur personnel ou qui ont du personnel

inexpeacuterimenteacute

28

Par la suite les cas de test conccedilus se mettent dans un ordre exeacutecutable dans le troisiegraveme

document de standard de documentation lEEE 829 de phase de conception la Speacutecification

de Proceacutedure de test Ces proceacutedures de tests sont deacuteveloppeacutees agrave pal1ir des documents de

Speacutecification de Conception de Test et Speacutecification de Cas de Test Le document de

Speacutecification de Proceacutedure de test deacutecrit comment le testeur junior devra exeacutecuter

physiquement le test Une Speacutecification de Proceacutedure de Test pourrait inclure plus quun seul

cas de test

2523 Speacutecification de Proceacutedure de Test

La Speacutecijicatian de Proceacutedure de Test est un document speacutecifiant la seacutequence dactions pour

lexeacutecution dun test Ce document connu aussi sous le terme script de tests ou script de tests

manuels (JEEE 829) La norme deacutefinit dix eacutetapes qui peuvent ecirctre utiliseacutees dans lexeacutecution

de tests qui sont deacutecrites ci- dessous

1 Objet de la proceacutedure

2 Exigences speacuteciales

3 Eacutetapes de la proceacutedure

bull Log comment enregistrer les reacutesultats

bull Set Up comment preacuteparer l exeacutecut ion de la proceacutedure

bull Stcm comment deacutebuter lexeacutecution de la proceacutedure

bull Proceed actions de la proceacutedure

Measure comment les mesures seront effectueacutees

bull Shut Down comment suspendre la proceacutedure de test

bull Restart comment redeacutemarrer la proceacutedure de test

bull Stop comment effectuer un arrecirct ordonneacute de lexeacutecution

bull Wrap Up comment restaurer lenvironnement

bull Contingencies comment traiter les anomalies durant lexeacutecution

Nous pouvons constater de la description ci-dessus que le script de la proceacutedure deacutecrit en

deacutetail les eacutetapes dexeacutecution de tesl ct ne laisse rien agrave la volonteacute du testeur qui exeacutecute le test

Cest lune dcs critiques proposeacutes par les membres dc COS contre le TS Selon eux ce script

transforme le testeur en robot exeacutecutant les tacircches sans aucune reacuteflexion critique

29

253 Exeacutecution et eacutevaluation

Lexeacutecution des tests conccedilus se fait selon le planning deacutecrit dans le plan de test Pendant

lexeacutecution des tests le testeur junior enregistre les reacutesultats de lexeacutecution dans les

documents proposeacutes par IEEE 829 Registre de test Rapport dincident de test Les deacutefauts

sont enregistreacutes dans un systegraveme de suivi des bogues Agrave la fin de lactiviteacute de test le

document de standard IEEE 829 Rapport de synthegravese de Test syntheacutetise les activiteacutes et les

reacutesultats de test de la version testeacutee du logiciel

26 Conclusion

Nous avons donneacute dans ce chapitre un aperccedilu global sur la plupart des aspects touchant au TS

en mettant laccent sur les principales eacutetapes du processus de TS Il apparaicirct que le processus

sceacutenariseacute est visible planifieacute incluant plusieurs meacutetriques pouvant faciliter la mesure de

lefficaciteacute de lactiviteacute de test Mais dans la pratique le processus de test du logiciel ne se

passe pas toujours de la mecircme faccedilon quc dans la theacuteorie speacutecifiquement le test des systegravemes

dynamiques et changeants Sajoute agrave ce problegraveme le fail que les testeurs ninterviennent quagrave

la fin de la chaicircne de deacuteveloppement dans les modegraveles traditionnels Par conseacutequent lactiviteacute

de test seffectuera souvent sous des pressions du temps de coucirct ct le besoin de livrer le

logiciel Agrave cet effet les compagnies de deacuteveloppement de logiciels ont commenceacute agrave chercher

des meacutethodes pouvant mieux sadapter avec ces reacutealiteacutes Le TE constitue une de ces

meacutethodes il fera Je sujet de prochain chapitre

CHAPITRE III

TEST EXPLORATOIRE VUE DENSEMBLE

Ce chapitre propose une vue densemble du test exploratoire en preacutesentant briegravevement les

aspects fondamentaux de cette approche Nous commenccedilons par la deacutefinition de test

exploratoire (TE) puis laccent sera mis sur lapproche de test laquoSession Based Test

Managementraquo (SBTM) et ses meacutecanismes principaux Enfin quelques techniques ct styles

dexploration seront deacutecrits et nous terminerons par une conclusion

31 Deacutefinitions

Au deacutebut des anneacutees 90 les membres de Context Oriven School (CDS) ont commenceacute agrave

utiliser le terme laquoexploratoireraquo pour deacutecrire cette nouvelle pratique de test Cette

terminologie a eacuteteacute publieacutee dabord par Kaner (1988)

laquo () At some point youll stop formoly planning and documenting new tests until the next test cycle You can keep testing Run new tests as you think of them without spending much time preparing or explaining the tests Trust your instincts ln this example you quick~y reached the switch point from formol ta inarmai testing becallse the program crashed sa saon SOll7ething moy be fllndamenta~v wrong l(so the progral71 wil be redesigned Creoting new test series nm is risky They may hecome obsolete with the next version of the prngram Rother thon gomhling away the planning time tlY some exploratOlY tests whatever cames to mind raquo dapreacutes (Kaner 1988)

Comme nous pouvons le constater lauteur a deacutefinit le TE comme la conception et

lexeacutecution de tests agrave temps reacuteel degraves quune nouvelle ideacutee de test seacutemerge sans perdre du

temps dans la planification et la preacuteparation de tests formels qui pourront devenir obsolegravetes agrave

la prochaine version vue linstabiliteacute du systegraveme

31

Agrave loccasion du 7egraveme atelier de Los Altos sur le test du logiciel les praticiens ct les

chercheurs participants ont tous collaboreacute pour deacutefinir le TE Ils ont accentueacute certaines des

caracteacuteristiques communes de leurs vues et se sont mis daccord sur les caracteacuteristiques de

TE citeacutees ci dessous (Kaner Tinkham 2003a)

bull Interactif

bull Combinaison de la cognition et lexeacutecution

bull Creacuteatif

bull Megravene agrave des reacutesultats rapides

bull Diminue larchivage des documents de test

En 2002 dans le premier livre qui preacutesente les ideacutees et les principes de la penseacutee laquotest piloteacute

par le contexteraquo CDS Bach et al(2002) ont deacutefini le terme exploration comme une

interrogation deacutetermineacutee cest agrave dire une navigation avec une mission geacuteneacuterale sans itineacuteraire

sceacutenariseacute

laquoBy exploration we mean purposejiil wandering navigaling Ihrough a space wilh a general mission bul wilhoU a pre-seripIed roule Exploralion involves conlinuols learning and experimenling ()gtgt dapregraves (Bach ct al 2002)

Ces mecircmes auteurs ont preacutesenteacute le TE comme une technique de test ougrave le testeur apprend le

produit logiciel son marcheacute ses risques et ses deacutefauts anteacuterieurs tout au long de lactiviteacute de

test pour concevoir des nouveaux tests plus puissants gracircce agrave leacutevolution et agrave la maturiteacute de

ses connaissances (Bach et al 2002)

Kaner et Tinkham (2003a) ont deacutefini le TE comme nimporte quelle activiteacute de test dans la

mesure ougrave le testeur controcircle activement la conception des tests Pendant que ces tests

sexeacutecutent il utilise linformation reacutesultante pour concevoir de nouveaux tests Par cette

proposition les auteurs tendent agrave geacuteneacuteraliser la deacutefinition au test sceacutenariseacute (TS) qui pourrait

ecirctre exeacutecuteacute dans certaines situations dune faccedilon exploratoire comme nous allons le voir

dans les lignes qui suivent

Cependant la deacutefinition la plus freacutequente dans la litteacuterature est celle donneacutee par Bach (2003)

32

11 deacutefinit le TE comme lapprentissage la conception et lexeacutecution simultaneacutee des tests

Le TE a eacuteteacute reconnu par le guide Swebok (2004) comme une technique valide de test

Cependant il relie lefficaciteacute de TE agrave la connaissance de lingeacutenieur logiciel ou le testeur

Dapregraves les deacutefinitions ci-dessus nous pouvons deacuteduire les proprieacuteteacutes maicirctresses de TE

bull Lapprentissage lexploration la conception et lexeacutecution des tests se font

simultaneacutement Autrement dit les tests ne sont pas deacutefinis agrave lavance comme les cas de

tests seeacutenariseacutes

bull Lactiviteacute de test est guideacutee agrave chaque moment par les reacutesultats des tests anteacuterieurs dans

une boucle interactive dappreacutehension du logiciel sous test

Le TE nexige pas la disponibiliteacute des exigences du logiciel du fait quil se fonde sur

lexploration et lapprentissage pendant le test

bull Centreacutee autour de la deacutetection des deacutefauts cest-agrave-dire orienteacute vers le reacutesultat plutocirct que

la preacuteparation la documentation ct larchivage des cas de tests

Nous pouvons constater de ces proprieacuteteacutes quil y une diffeacuterence claire entre le TE et le TS La

reacutealiteacute des pratiques de test deacutemontre que cette diffeacuterence est inaperccedilue du fait que mecircme

une activiteacute de TS pourrait ecirctre exeacutecuteacutee dune faccedilon exploratoire Un exemple clair de telle

situation apparaicirct quand le testeur deacutevie de ses proceacutedures de tests et utilise lexploration

pour explorer un deacutefaut pendant lexeacutecution de ses tests sceacutenariseacutes (Kaner Tinkham 2003a)

Nous pouvons donc conclure que nimporte quelle activiteacute de test logiciel reacutealiseacutee par un ecirctre

humain pourrait ecirctre exploraoire agrave un certain degreacute Selon Bach (2003) nimporte quel effort

de test tombe quelque part sur un continuum (figure 31) dont un des pocircles repreacutesente le TS

ougrave le testeur suit exactement les proceacutedures de tests sceacutenariseacutes dans chaque deacutetail et lautre

pocircle repreacutesente le TE le plus libre (Freestyle Exploratory Testing) ougrave les ideacutees de test

eacutemergent au moment de leur exeacutecution

33

Figure 31 Continuum repeacuterant lactiviteacute de test (Adapteacute et traduit de Bach 2007)

Test Test

sceacutenariseacute Scripts vagues Fragments de Chartes Rocircles

exploratoire libre

cas de tests 1 1

La figure 31 situe plusieurs variantes de test entre les deux paradigmes le TE et le TS

Chacune de ces variantes accentue un niveau de formalisme de deacutetail de documentation et

de controcircle par rapport au TE libre Elle pourrait prendre la forme des rocircles ou des

responsabiliteacutes pour chaque membre de Jeacutequipe de test sur une partie du logiciel Elle

pourrait prendre aussi la forme des chal1es qui sont plus preacutecises que les rocircles Ces chartes

identifient la dureacutee de Ja mission avec une liste preacutecise des items agrave tester Les deux derniers

types sont les deux modegraveles de TE les plus proches de TS Tout dabord les fragments de cas

de test qui poulTaient speacutecifier les mecircmes eacuteleacutements que Speacutecification de Cas de Tes dans la

norme IEEE 829 sans speacutecifier toutefois les deacutetails fins comme le eas de test sceacutenariseacute

Quant aux scripts vagues ils sont plus preacutecis que les fragments de cas de test et similaires

aux proceacutedures Ils contiennent les eacutetapes agrave suivre pour accomplir la mission de tesl mais

sont moins deacutetailleacutees que celles-ci ct neacutecessitent de lexploration pour les accomplir Avant

de fermer celle parenthegravese notons que certaines organisations ont uti liseacute les patrons JEEE

829 speacutecialement les speacutecificalions des cas de tests pour inteacutegrer le TE dans leurs pratiques

de test avant lintroduction du concept de laquoSession Based Test Managemenl raquo (Amland et

Vaga 2002)

34

32 Processus de test exploratoire

Le processus de TE est un processus tridimensionnel Tel quillustreacute sur le tableau 31 ces

dimensions sont produit qualiteacute et techniques (Bach 2003) Selon lauteur un testeur

exploratoire teste un produit logiciel eacutevalue sa qualiteacute en utilisant diverses techniques

Chaque case dans la grille ci-dessous repreacutesente un aspect du proceSSllS de TE Le testeur

exploratoire peut choisir nimporte quel point de deacutepart et suivre nimporte quel chemin dans

la grille jusquagrave la fin de la session de test il condition que les neuf tacircches soient couvertes

pendant le cycle de test et gue chacune des trois activiteacutes principales apprentissage

conception de tests et exeacutecution de tests donnent un reacutesultat tangible

Tableau 31 Grille des tacircches de test exploratoire (Adapteacute ct traduit dAmland 2002a)

Grille des Apprentissage Conception de Exeacutecution de tests tacircches tests

Produit Deacutecouvrir les eacuteleacutements du Deacutecider quoi tester Observer le (couverture) produit comportement du

nrnrlilil

Qualiteacute Deacutecouvrir comment le produit Penser aux Evaluer le (Oracle) devrait fonctionner problegravemes de comportement

qualiteacute possibles contre les preacutevisions

Techniques Deacutecouvrir les techniques de Choisir et appliquer Configurer et conception des tests qui les techniques de exercer le produit peuvent ecirctre utiliseacutees conception de tests

bull Les notes de Les tests Les problegravemes

tests trouveacutes

Selon Bach (200 J) le TE peut ecirctre pratiqueacute selon un plan preacutevu qui nest pas neacutecessairement

rigoureux Du fait quun plan rigoureux exige la certitude et implique la perfection Cellcs-ci

ne pourraient pas ecirctre atteintes dans une activiteacute de TE qui se fonde sur lexploration ct

lapprentissage du logiciel pour identifier cc qui doit ecirctre testeacute Cependant Bach signale

35

quun bon TE est une activiteacute planifieacutee et la preacuteparation de quelques notes sur la strateacutegie agrave

suivre et les eacuteleacutements du logiciel agrave aborder dans le test pourraient ecirctre tregraves utiles

En ce qui concerne les types de TE deux types ont eacuteteacute traiteacutes dans la litteacuterature le premier

est le test exploratoire libre (Freestyle Exploratory Testing) Cest un test qui se fait sur des

intervalles limiteacutes de temps quon appelle sessions chacune munie dune charte La charte

deacutecrit la mission de test et parfois identifie quelques tactiques et techniques de test pouvant

ecirctre utiliseacutees pour exeacutecuter cette mission La cha11e pourrait ecirctre choisie par le testeur ou

assigneacutee par le responsable du test Les reacutesultats officiels de ce type sont constitueacutes seulement

des bogues deacutetecteacutes pendant la session de test (Bach 2003) Le deuxiegraveme type de TE est le

test exploratoire geacutereacute par session (Session Based Test Management SBTM) Cest une

approche structureacutee de TE introduite par Jonathan Bach (2000) pour controcircler le TE libre

Dans ce type de TE les reacutesultats officiels sont constitueacutes des bogues deacutetecteacutes dans la session

de test et un rapport de session qui fait lobjet dune eacutevaluation par Je responsable de test Les

meacutecanismes et les meacutetriques de ce type de TE vont ecirctre eacutevoqueacutes en deacutetail dans la section qui

suit

33 Test exploratoire geacutereacute par session (SBTM)

Lapparition du TE dans sa version originale cest-agrave-dire tel que preacutesenteacute au deacutebut un

processus libre et informel a susciteacute beaucoup de critiques de la part des praticiens et des

professionnels Ces critiques eacutetaient centreacutees sur le manque de controcircle et de mesure qui sont

importants et cruciaux dans Jindustrie de test de logiciel En effet le fait que le TE ne soit

pas sceacutenariseacute ni reacutepeacutetitif et qu j] deacutepend fortement de la creacuteativiteacute du testeur a rendu difficile

le controcircle et le suivi de la progression de projet de test Compte tenu de ces faiblesses les

intervenants dans le domaine de test ont trouveacute difficile dessayer ou dintroduire le TE tel

que preacutesenteacute la premiegravere fois comme une meacutethodologie de tes

Pour paJJier ces problegravemes Jonathan Bach (2000) a proposeacute une nouvelle approche de TE

nommeacute Test geacutereacute par session (Session Based Test Management (SBTM) Le but de

lapproche est de rendre Je TE plus responsable (Accountable) ct dintroduire la mesure et le

controcircle neacutecessaires pour la gestion de projet de test Lideacutee principale de la meacutethode SBTM

est de planifier et diviser la mission geacuteneacuterale de test en plusieurs sessions Une session est un

36

intervalle de temps ininterrompu qUI pourrait durer de 60 agrave 120 minutes (BachJ

2000)Chaque session est identifieacutee par une charte qui deacutecrit la mission de test agrave remplir

Nous pouvons dire que cest un plan de haut niveau son rocircle est de speacutecifier les tacircches de test

agrave remplir ainsi que quelques tactiques et techniques pour les exeacutecuter Notons que la

granulariteacute de deacutetails de chaque charte varie selon limportance de celle-ci en termes de

risque et de la difficulteacute de la mission

Selon Jonathan Bach (2000) chaque session devrait ecirctre diviseacutee cn trois eacutetapes qUI

comportent autant de meacutetriques pour controcircler la porteacutee de travail du testeur Ces meacutetriques

sont

bull Preacuteparation de test le pourcentage du temps de la session consacreacute agrave linstallation

de lenvironnement de test (configurer mateacuteriels de test lire quelques manuels etc)

bull Conception et exeacutecution de tests le pourcentage du temps de la session passeacute dans

lexploration et le test

investigation et rapport de bogues Je pourcentage du temps de la session passeacute dans

la recherche et linvestigation lors de lapparition dun comportement inattendu du

logiciel Plus le temps passeacute sur le rapport des bogues

Le testeur devrait rapporter aussi lestimation du temps passeacute sur la chartc par rapport au

temps passeacute sur laquo lopportuniteacute raquo Lopportuniteacute cest le test effectueacute par le testcur qui nest

pas inclus dans la charte de session puisque le rocircle de lapproche SBTM scion Jonathan

Bach (2000) est dintroduire le controcircle et la mesure sur le TE libre tout en gardant ses

aspects essentiels que soient limprovisation lexploration et la creacuteativiteacute

De plus le rapport de session devrait rapporter les bogues les problegravemes et Ics notes Les

problegravemes sont les questions et les obstacles relieacutes au processus du test Quant aux notes

elles preacutesentent des ideacutees et des pistes qui peuvent amener agrave la creacuteation de nouveaux chartes

de test Le rapport de chaque session fait alors lobjet dune eacutevaluation pendant le deacutebriefing

avec le responsable du test

37

Figure 32 Cadre dapplication de SBTM (Inspireacute de James et Wood 2003)

Identification des chartes de

test

~ __ ________J___ _ __ ~

1 ------ 1 Estimation de Deacutefinition de 1 leffort de test ~ la session ou 1 1

neacutecessaire Ajustement

Planification continue 1

1____shy _shy -i-_shy - _-- ___j

Non La charte compleacuteteacutee

oui

Tel quillustreacute agrave la figure 32 au deacutebut de Jactiviteacute du test le responsable du test identifie les

chartes de tests et leffon neacutecessaire pour accomplir chacune delles Apregraves Jexeacutecution de

chacune de ces chartes le responsable rencontre le testeur pour eacutevaluer son travail Suite agrave ce

deacutebriefing Ic responsable deacutecidera si lexeacutecution de cbarte est compleacuteteacutee ou si la session

devrait ecirctre ajusteacutee et prolongeacutee pour compleacuteter le test de charte Le responsable du test

pourrait aussi ajouter de nouvelles chal1es pour explorer les notes rapporteacutees par le testeur

De ce fait le processus didentification de chanes est un processus de planification continue

(Wood ct James 2003) se change reacuteguliegraverement pendant lactiviteacute de test au fur et agrave mesure

que des nouvelles infonnations apparaissent pendant Jexeacutecution des chanes Les reacutesultats de

sessions de tests sont la plupart du temps rassembleacutes dans une base de donneacutees Ainsi le

pourcentage de sessions compleacuteteacutees les bogues rapporteacutes et le rendement des testeurs

38

pourraient ecirctre retraceacutees par les responsables du test Les renseignements sur la progression et

le statut de lactiviteacute de test pourraient ecirctre disponibles agrave chaque moment de projet En effet

les mesures collecteacutees pendant Je test et le deacutebriefing permettent destimer la productiviteacute ou

le rendement de chaque membre de leacutequipe de test pendant le projet de test en cours Cela

avec le nombre de sessions compleacuteteacutees pourrait aider dans lestimation de quantiteacute du travail

restante avant la fin du cyc le de test

Une expeacuterience dutilisation de cette approche a eacuteteacute preacutesenteacutee par (Lyndsay et van Eeden

2003) Les auteurs ont proposeacute des meacutethodes pour controcircler la porteacutee de test et eacutevaluer et

mesurer la couverture de test Les reacutesultats de cette expeacuterience seront abordeacutes en deacutetail dans

le chapitre IV

34 Les styIes ct les techniques dexploration

Depuis lapparition de TE plusieurs praticiens et chercheurs se penchaient sur leacutelaboration

des techniques et des modegraveles dexploration (Bach et Jonathan Bach 2006 Bach et Kaner

2004 Amland 2002b) Dans cette perspective Amland (2002b) ont proposeacute quelques styles

et techniques pour effectuer le TE lis incluent entre autres

bull Les intuitions sont les ideacutees que le testeur pourrait geacuteneacuterer en se basant sur ses

preacutedictions ses compeacutetences et son expertise

bull Les modegraveles il sagit de certains diagrammes et modegraveles qui peuvent aider le testeur

dans lappreacutehension du logiciel et la conception de tests Ils incluent entre autres

o Diagramme darchitecture consiste agrave construire ou concevoir un diagramme

darchitecture du logiciel sous test incluant ses interfaces son flux de donneacutees et

ainsi de suite En pratique ce travail se fait la plupart du temps pendant des reacuteunions

de groupe cntre les testeurs et les programmeurs Souvent lidentification de chartes

de tests et les responsabiliteacutes se fait agrave cette eacutetape ougrave chaque testeur deacutetermine sa

mission convenablement aux parties du logiciel comprises

39

o Digrammes deacutetats consiste agrave creacuteer un diagramme repreacutesentant jes modes

opeacuterationnelles les actions et les entreacutees possibles du logiciel Selon Amland (2002b)

ce digramme est un outil utile pour exposer les contradictions du logiciel

o Modegraveles de deacutefaillances consiste agrave utiliser un catalogue de bogues typiques pour

concevoir les cas de tests Le testeur exploratoire peut utiliser ses expeacuteriences

anteacuterieures pour construire ce catalogue ou utiliser en un de la litteacuterature (Kaner et

aL 1999)

bull Exemples il sagit de certains exemples dutilisation du systegraveme qui peuvent indiquer

les anomalies ct les deacutefauts existants Ils incluent entre autres

o Les cas dutilisations il sagit de deacuteterminer les utilisateurs du systegraveme et les tacircches

fonctionnelles pour chacun dentre eux ensuite on creacutee des tests qui reflegravetent leurs

utilisations

o Opeacutera savon il sagit de geacuteneacuterer des sceacutenarios dutilisations du systegraveme sous test en

exageacuterant dans quelques-unes de ses aspects par exemple en utilisant des valeurs

extrecircmes (limites) pour le mecircme sceacutenario

bull Les interfeacuterences il sagit de certaines actions qui peuvent nuire agrave Jexeacutecution normale

du systegraveme comme des arrecircts subits la concurrence avec dautres systegravemes etc Ces

interreacuterences peuvent reacuteveacuteler des deacutefauts dans le logiciel

bull Gestion derreurs il sagit de veacuterifier que Je 10gicieJ gegravere bien les erreurs dutilisation

autrement dit de veacuterifier que les messages derreurs se deacuteclenchent au bon moment et

SOllS les bonnes conditions

Il faut rappeler que le questionnement constitue le cœur de TE Il constitue la base de

nimporte quelle tcchnique ou style dexploration La qualiteacute du TE effectueacute deacutepend de la

qualiteacute des questions geacuteneacutereacutees agrave propos du produit sous test (Bach 2003 Kaner Tinkham

40

2003b Kaner Amland 2002b) Dans le but de faciliter la tacircche du testeur exploratoire dans

leacutelaboration des questions et des strateacutegies efficaces quelques praticiens et chercheurs ont

proposeacute quelques modegraveles comme le modegravele danalyse proposeacute par Bach (1996) qui est

illustreacute agrave la figure 33 et les modegraveles dattaques du logiciel proposeacutes par Whittaker (2003)

Figure 33 Heuristic Test Strategy Model (Adapteacute et traduit de Bach 1996)

Lenvironnement du projet de test

Les critegraveres de Les techniques de Les eacuteleacutements du qualiteacute test logiciel

Qualiteacute perccedilue

Ce modegravele preacutesente quatre secteurs principaux chacun eacutetant un indicateur que le testeur peut

utiliser pour deacuteterminer linformation dont jl a besoin pour concevoir une strateacutegie de test

Lobjectif immeacutediat de ce modegravele est donc de guider la reacuteflexion des testeurs exploratoires

lorsquils creacuteent les tests Ses principaux composants sont

bull Lenvironnement de projet inclut les ressources les contraintes et dautres facteurs

qui peuvent aider ou nuire au processus de conception et dexeacutecution des tests

(client calendrier eacutequipement etc)

bull Les eacuteleacutements du produit sont les aspects visibles ou invisibles du produit comme les

structures de donneacutees les interfaces etc

41

bull Les critegraveres Je qualiteacute sont les nonnes et les caracteacuteristiques de qualiteacute que le logiciel

devrait respecter Ces critegraveres permettent au testeur de deacuteterminer les problegravemes dans

le logiciel sous test

bull Les techniques de tests sont les strateacutegies neacutecessaires pour concevoir les tests Le

choix des techniques de test deacutepend de lenvironnement de projet les eacuteleacutements du

produit sous test el les critegraveres de qualiteacute viseacutes dans le projet de test en cours

bull La qualiteacute perccedilue est le reacutesultat preacutevu du test

Lenvironnement de projet les critegraveres de qualiteacute et les eacuteleacutements du produit sont tous

combineacutes avec les techniques de test afin de deacuteterminer la qualiteacute perccedilue du produit Selon

Kaner et Bach (2004) le modegravele aide le testeur exploratoire agrave deacuteterminer ce qui est doit ecirctre

testeacute Ainsi les attributs de qualiteacute les plus importants dans le projet (les types de problegravemes

agrave chercher pendant lactiviteacute de test) les aspects de projet qui pourraient faciliter ou

contrarier lactiviteacute de test en cours La reacuteflexion sc]on ces trois axes pourrait geacuteneacuterer des

ideacutees de test inteacuteressantes qui peuvent ecirctre mises en œuvre en respectant les contraintes et les

ressources du projet

Nous croyons que les secteurs deacutecrits dans cc modegravele danalyse sont semblables et ont les

mecircmes utiliteacutes que les secteurs identifieacutes dans le plan de test IEEE 829 (Annexe B)

Cependant le choix dun style speacutecifique dexploration ou tactique particuliegravere de TE deacutepend

selon Kaner et Tinkham (2003b) de facleurs deacutecrits ci-dessous

bull Les expeacuteriences anteacuterieures

bull Les qualifications

bull La personnaliteacute SUl10ut le modegravele dapprentissage

bull Les connaissances anteacuterieures sur lapplication sous test

Selon ces mecircmes auteurs le facteur le plus pertinent est le modegravele dapprentissage qUi

repreacutesente la faccedilon dont la personne choisit et traite linformation (Kaner Tinkham 2003b)

Cependant cette hypothegravese est theacuteorique et nest pas toujours confirmeacutee par une eacutetude

empIrIque

42

35 Conclusion

Nous avons donneacute dans ce chapitre un aperccedilu global sur la plupart des aspects touchant au

TE en commencent par sa deacutefinition et les concepts principaux du son processus Puis nous

avons preacutesenteacute lapproche SBTM et ses meacutecanismes En terminant nous avons proposeacute

quelques techniques et modegraveles dexploration Tout le mateacuteriel dont nous avons discuteacute dans

ce chapitre a eacuteteacute eacutelaboreacute dans le but daider et encourager les testeurs ct les organisations agrave

adopter le TE Mais comment les entreprises vont adopter cette nouvelle approche et quels

sont les motifs et les raisons qui les ont pousseacutees agrave essltlyer et utiliser le TE en mettant agrave

leacutecart la pratique sceacutenariseacutee habitueJJe Nous allons proposer des reacuteponses agrave toutes ces

questions dans la revue de litteacuterature de quelques travaux et eacutetudes de cas dans le chapitre

qui suit

41

CHAPITRE IV

REVUE DE TRAVAUX RELIEacuteS

Dans ce chapitre nous allons preacutesenter une revue des travaux de recherches acadeacutemiques et

professionnelles traitant du test exploratoire (TE) Dans la premiegravere partie nous deacutecrirons les

reacutesultats de la seu le recherche acadeacutemique existante agrave date Elle met laccent sur les raisons et

les faccedilons dutilisation de TE et recense les beacuteneacutefices ct les impcrfcctions perccedilus par les

praticiens dans lindustrie de test Puis nous proposerons quelques expeacuteriences dutilisations

de TE qui ont fait lobjet de plusieurs confeacuterences internationales Noire but sera de deacutefinir et

de comprendre comment et pourquoi les praticiens adoptent et adaptent le TE dans lindustrie

de test Cela va nous permettre didentifier les facteurs influenccedilant ladoption ct ladaptation

de lapproche dans lindustrie Ces facteurs vont nous aider dans la construct ion de notre

cadre comparatif qui va guider notre analyse comparative entre les deux approches le test

seeacutenariseacute (TS) et le test exploratoire (TE)

Eacutetude de Itkonen et Rautiainen ( 2005)

La croissance remarquable dutilisation de TE dans lindustrie de test logiciel el la promotion

eacutetendue de son efficaciteacute par quelques praticiens ont motiveacute les auteurs I1koncn Cl Rautiaincn

(2005) agrave eacutetudier lapproche afin de deacutevoiler ses beacuteneacutefices annonceacutes Ils ont retenu la question

suivante laquo pourquoi ct comment les compagnies utilisent-elles le TE raquo pour aborder leur

recherche Dans le but de reacutepondre agrave cette question ils ont entrepris trois eacutetudes de cas

descriptives aupregraves de trois entreprises finlandaises Une dentre elles est petite avec environ

10 employeacutes travaillant dans le deacuteveloppement du logiciel ct na quun seul produit sur le

marcheacute au moment de lenquecircte Sa meacutethodologie de test sc fonde sur le TE due agrave

limmaturiteacute de son processus de deacuteveloppement Les deux autres entreprises sont

moyennes avec environ 30 et 40 employeacutes dans le deacuteveloppement du logiciel Ses produits

44

ont eacuteteacute sur le marcheacute pe~dant plusieurs anneacutees Leurs meacutethodes de test incluent les deux

approches de test le TE et le TS

Itkonen et Rautiainen (2005) ont eacutelaboreacute sept interviews theacutematiques semi-slruclureacutees avec

les praticiens effectuant le TE dans les trois entreprises Ils ont intervieweacute successivement un

seul testeur de la plus petite entreprise participante dans leacutetude qui avait utiliseacute le TE

seulement deux fois avant (entrevue Puis quatre testeurs de la deuxiegraveme entreprise ougrave le TE

a eacuteteacute introduit dans la meacutethodologie de test six mois avant les entrevues Enfin deux testeurs

de la plus grande entreprise dans lenquecircte ou le TE avait eacuteteacute utiliseacute et ameacutelioreacute pendant

quatre ans Les auteurs ont utiliseacute des thegravemes et des questions ouvertes et neutres afin de

recueillir les opinions et les expeacuteriences reacuteelles des intervenants en mettant lemphase sur les

raisons et les modes dutilisation du TE dans les trois entreprises eacutetudieacutees En mecircme temps

ils ont recenseacute les imperfections et les beacuteneacutefices du TE tels que perccedilus par les praticiens

Parallegravelement agrave leur eacutetude descriptive ltkonen et Rautiainen (2005) ont recueilli des donneacutees

quantitatives sur le TE afin den mesurer la productiviteacute

411 Les raisons dutilisation du test exploratoire

Les reacutesultats de cette eacutetude ont indiqueacute que Je TE est utiliseacute pour les raisons ugrave savoir

bull La difficulteacute de concevoir des cas de test sceacutenariseacutes deacutetailleacutes ugrave cause de jinterdeacutependance

entre les uniteacutes logiciel

bull Le besoin de tester Je logiciel du point de vue de lutilisateur final

bull Le besoin dexploiter la creacuteativiteacute et lexpeacuterience des testeurs dans la deacutetection des

deacutefauts importants

bull Le besoin de fournir aux deacuteveloppeurs un feedback rapide sur les nouvelles uniteacutes

logicielles

bull La capaciteacute du TE de sadapter aux contraintes des environnements dynamiques de

deacuteveloppement et les situations ougrave les exigences du logiciel manquent

45

412 Les modes dutilisation du test exploratoire

Les auteurs Itkonen et Rautiainen (2005) ont identifieacute en se basant sur les informations

recueillies aupregraves des intervieweacutes cinq modes dutilisation principaux de TE dans les trois

eacutetudes de cas reacutealiseacutees Selon les constations de ItkQnen et Rautiainen (2005) lintuition a eacuteteacute

utiliseacutee comme technique de base dans Je TE Aucune autre strateacutegie ou technique speacutecifique

dexploration na eacuteteacute utiliseacutee parmi celles proposeacutees par (Kaner et Bach 2004) Les auteurs

ont identifieacute les modes dutilisation suivants

Test exploratoire baseacute sur session deux des trois entreprises eacutetudieacutees utilisent le TE geacutereacute

par session connu sous Je terme Session Based Exploratory Testing (SBET) Il consiste agrave

utiliser le principe de la technique SBTM proposeacute dans le chapitre JIl sans impleacutementer les

meacutetriques de gestion proposeacutees par (Jonathan Baeh 2000)

Test fonctionnel dune uniteacute logicielle Il sagit de tester une uniteacute logicielle individuelle

directement apregraves limpleacutementation de celle-ci pour produire un fccdback rapide aux

deacuteveloppeurs tregraves tocirct dans le cycle de vie du logiciel

Test exploratoire fumigatoire (Smoke Exploratory Testing) Cc typc dc TE est utiliseacute par

la plus grande entreprise participante dans leacutetudc Il consiste agrave cxplorcr chaque vcrsion du

systegraveme agrave tester par leacutequipe de test avant le deacutebut de test sceacutenariseacute pour formuler une vue

globale sur la qualiteacute du systegraveme et sassurer que les reacuteparations sont proprement

impleacutementeacutees ct que les fonctions les plus cruciales fonctionnent sans se preacuteoccuper des

petits deacutetails

Test exploratoire de reacutegression deux des trois entreprises eacutetudieacutees utilisent Ic TE dans le

tcst de reacutegression pour veacuterifier que les modifications nont pas causeacute deffets inattendus agrave

dautres parties du logiciel 11 sagit dexplorer le systegravemc dans unc courte session sans

aucune planification Les reacutesultats de cette session sont informcllcmcnt communiqueacutes aux

deacuteveloppcurs En fait la limitation de ressources el du temps ont eacuteleacute les motifs principaux

pour utiliser Je TE dans un test de reacutegression au lieu dutiliser le lcsl de reacutegression habituel

par une reacutepeacutetition seacutelective des cas de tests deacutejagrave conccedilus

46

Test exploratoire libre ce type de test est perccedilu par les intervieweacutes dans la grande

entreprise comme une pratique systeacutematique et naturelle qui devrait se faire pendant

lexeacutecution des cas de test sceacutenariseacutes

413 Les beacuteneacutefices du test exploratoire

En ce qui concerne les beacuteneacutefices perccedilus de TE tous les intervieweacutes ont il lustreacute que la

souplesse et la flexibiliteacute de lapproche leur permettrait de tester en profondeur les uniteacutes

logicielles qui ne pourront pas ecirctre traiteacutees dans les cas de tests sceacutenariseacutes comme les

interdeacutependances entre les anciennes et les nouvelles uniteacutes logicielles (ltkonen ct

Rautiainen 2005) Selon les constatations de ces mecircmes auteurs la productiviteacute en terme de

nombre des deacutefauts deacutetecteacutes et limportance de ces deacutefauts a eacuteteacute perccedilue comme un beacuteneacutefice

Cependant les intervieweacutes ont relieacute la productiviteacute agrave lexpertise des testeurs dans le TE Ils

affirment que le TE ne poulTa pas ecirctre productif si le testeur na pas dcs connaissances

adeacutequates dans le domaine daffaire du logiciel agrave tester Ils ajoutent que la diffeacuterence dans

lattitude pendant le test joue un rocircle crucial dans la productiviteacute perccedilue de TE En effet le

testeur tend plus agrave veacuterifier lexactitude entre les reacutesultats observeacutes ct les reacutesultats preacutevus

identifieacutes dans les cas de test sceacutenariseacutes dans une activiteacute de TS Par contre dans le TE le

testcur aborde le logiciel avec une attitude laquo offensiveraquo Autrement dit il cherche les

deacutefaillances avec de la curiositeacute et un œil critique (ltkonen et Rautiainen 2005) Les

reacutepondants ont affirmeacute aussi que le TE est productif seulement dans les courtes peacuteriodes cie

test en consideacuterant le nombre dheures utiliseacutees et le nombrc de deacutefauts deacutetecteacutes Tandis quagrave

long terme il ne pourrait pas ecirctre productif agrave cause de la difficulteacute destimcr la couverture de

tests pendant lactiviteacute de test Par la suite quelques parties ou caracteacuteristiques du logiciel

peuvent ecirctre livreacutees sans ecirctre testeacutees (ltkonen et Rautiainen 2005)

414 Les lacunes du test exploratoire

Selon les constations de 1lkonen et Rautiainen (2005) la couverture limiteacutec est la plus grande

lacune de TE

Ccci a eacuteteacute mentionneacute par lous les intervieweacutes dans lenquecirctc quils ont entreprise

47

Les reacutesultats ont montreacute que la deacutependance de TE agrave la creacuteativiteacute et agrave lexpeacuterience des testeurs

a eacuteteacute perccedilue aussi comme un deacutesavantage du TE du fait que le TE est sujet aux erreurs

humaines

Malgreacute la profondeur et la rigueur de cette recherche elle est limiteacutee par le nombre et la taille

des entreprises participantes Ceci apparaicirct clairement agrave plusieurs reprises dans la recherche

ougrave les reacutesultats obtenus concernent une seule entreprise parmi les trois participantes Donc

nous ne pouvons pas savoir si les reacutesultats obtenus sont geacuteneacuteraux ou des cas isoleacutes En ce qui

concerne la productiviteacute de lapproche dans la deacutetection de deacutefauts la recherche na pas

proposeacute des preuves fiables En fait les donneacutees quantitatives collecteacutees ne peuvent pas ecirctre

deacutefinitives Agrave cause de labsence des donneacutees quantitativcs du TS qui pourraient constituer

une base de comparaison Leacutetude est quand mecircme un apport utile agrave lenrichissement de la

litteacuterature sur les justifications et les modes dutilisation du TE

42 Eacutetude de Petty (2005)

Petty (2005) preacutesente une expeacuterience dutilisation de lapproche Session Based Exploratory

Testing (SBET) comme une meacutethodologie primaire de test en remplacement dc la meacutethode

sceacutenariseacutee habituelle Cette derniegravere se trouvait incapable de sadapter aux changements

freacutequents des exigences du logiciel Alors lintroduction de la meacutethode SBET a eacuteteacute perccedilue

comme une solution vu les frustrations accumuleacutees de Jutilisation dc TS Ces reacutealiteacutes

reacutesident dans le changement continu des exigences et labsence du temps suffisant de test du

logiciel La meacutethode SBET adopteacute par Petty (2005) est inspireacutee dans unc grande partie de

celle proposeacutee par Jonathan Bach (2000) Cette meacutethodc a permis aux testeurs decirctre agiles

dans le sens ougrave ils ont eacuteteacute capables de sadapter agrave lincertitude et au changement de logiciel et

de tester adeacutequatement le logiciel agrave un coucirct optimal

Selon les constatations de Petty (2005) la chose la plus inteacuteressante dans la meacutethode SBET

est quelle a eacutelimineacute le besoin de retravailler ct de mettre agrave jour les cas dc tests sceacutenariseacutes

apregraves chaque changement du logiciel Ce temps selon lauteur a pu ecirctre invcsti dans le test et

Jameacutelioration de qualiteacute du produit logiciel

48

Petty (2005) a utiliseacute des pairs cest-agrave-dire que deux personnes sassoient agrave seul ordinateur et

exeacutecutent la mecircme mission de test Chacune de ces paires est composeacutee dun testeur et dun

deacuteveloppeur Selon les constatations de lauteur lutilisation de lapproche SBET en pair a

ameacutelioreacute consideacuterablement la qualiteacute de test effectueacute En effet dans une session de test par

pairs un membre de la paire peut se concentrer sur la conception des tests et lautre sur

lenregistrement et la reacutedaction de notes Les rocircles des membres de la paire sont eacutechangeacutes

plusieurs fois pendant la session Cela augmente la creacuteativiteacute et la concentration du membre

qui conccediloit les tests et eacutelimine la distraction qui pourrait ecirctre causeacute par lenregistrement des

notes Aussi la collaboration et le pa11age des connaissances tacites des membres de leacutequipe

pendant la session ont ameacutelioreacute la compreacutehension et lapprentissage du logiciel sous test

Notons que lutilisation de deacuteveloppeurs dans les pairs a permis de corriger les deacutefauts en

temps reacuteel sans avoir besoin denregistrer beaucoup de notes de session ni de les reproduire

ulteacuterieurement

Selon les constations de Petty (2005) le fait que lapproche SBET soit baseacutee sur lexploration

et lapprentissage a pousseacute les testeurs agrave simpliquer plus dans Je processus de conception et

de clarification des exigences pour pouvoir comprendre le produit logiciel et son domaine

daffaire Cela a eu des reacutepercussions positives sur la qualiteacute des tests effectueacutes et sur la

capaciteacute de deacutetecter des deacutefauts ulteacuterieurement pendant le test Les testeurs sont devenus plus

capables de diffeacuterencier entre un deacutefaut et un comportement normal du logiciel Ce concept

est connu sous le terme doracle de test Il sera abordeacute plus en deacutetail dans le chapitre VII

Selon les constatations de Petty (2005) lapproche SBET a eacuteteacute tregraves efficace dans le cas de

leur projet de test Ce projet se caracteacuterisait par le changement Uumleacutequent des exigences qui

sonl souvent communiqueacutees verbalement Par la suite la meacutethode SBET lui a permis de

pouvoir reacutepondre agrave ces changements rapidement Selon les constatations de lauteur le moral

de leacutequipe de test a augmenteacute consideacuterablement pendant le test du logiciel Agrave cause de

leacutelimination du fardeau habituel de la mise agrave jour des cas de tests lors de changement du

logiciel La communication entre les testeurs et les deacuteveloppeurs sest ameacutelioreacutee et

transformeacutee dune relation dadversiteacute agrave une relation de collaboration Cependant lauteur

souligne que la reacuteussite de la meacutethode SBET deacutepend fortement de lexpeltise et les

49

connaissances de domaine daffaires des membres de leacutequipe de test Petty (200S) souligne

aussi que la capaciteacute dapprentissage est plus rapide en TE quen TS Mais selon lauteur

cette capaciteacute deacutepend encore des personnes impliqueacutees

Linnovation de la meacutethode preacutesenteacutee par Petty (200S) est Jutilisation de paires composeacutees

des testeurs et des deacuteveloppeurs Cela permet de corriger les deacutefauts pendant les tcsts sans

avoir le besoin de les reproduire ulteacuterieurement La participation de testeurs dans la phase de

clarification et de deacutefinition dexigences a permis dameacuteliorer la qualiteacute de Joracle de test

Toutefois lauteur na pas preacutesenteacute de donneacutees quantitatives sur la productiviteacute de Japproche

SBET et le degreacute dameacutelioration reacutealiseacute par lintroduction de lapproche dans la

meacutethodologie de test En plus la taille de lentreprise ougrave sest deacuterouleacutee lexpeacuterience est petite

ce qui simplifie eacutenormeacutement la communication et la collaboration entre les testeurs et les

deacuteveloppeurs Par contre dans les grandes entreprises le projet de test est souvent seacutepareacute du

processus de deacuteveloppement (Pyhajarvi et aL 2003) Par conseacutequent nous ne pouvons pas

savoir si la faccedilon dadoption de lapproche SBET proposeacutee par Petty (200S) pourrait

sappliquer dans les grandes entreprises Cependant cette eacutetude est un apport utile agrave

lenrichissement de la litteacuterature sur les modes dadoption du TE surtout dans les petites

entreprises de deacuteveloppement du logiciel

43 Eacutetude de Lyndsay et van Eeden (2003)

Les auteurs Lyndsay et van Eeden (2003) deacutecrivent leur expeacuterience reacuteussie dans la mise en

oeuvre de la technique Session Based Exploratory Testing (SBET) Cette mise en oeuvre a

pris place dans une petite entreprise anglaise en sinspirant des travaux de Jonathan Bach

(2000) qui sont deacutejagrave abordeacutes dans le chapitre lll Lobjectif principal de limpleacutementation de

lapproche SBET eacutetait dintroduire le controcircle et la mesure sur jactiviteacute de lest ad-hoc

existant dans lentreprise (test exploratoire libre selon Bach (2003) parce que les testeurs

enregistrent les deacutefauts deacutetecteacutes dans le Bug Tracking System) Le choix de la technique

SBET eacutetait pour reacutepondre agrave un mandat dameacutelioration de la qualiteacute dune petite application

Web deacutejagrave testeacute en utilisant le test ad hoc tout en restant dans la limite des ressources

existantes Alors le manque du temps et de personnel ont pousseacute les auteurs agrave utiliser

lapproche SBET au lieu dutiliser un TS que les ressources disponibles ne le pcrmctlcnt pas

50

La meacutethode proposeacutee par Lyndsay et van Eeden (2003) se fonde sur les quatre eacuteleacutements cleacutes

citeacutes ci-dessous

Controcircle de la porteacutee du test Pour geacuterer la porteacutee de test les auteurs ont introduit le

concept de point de test Le terme point de test sous-entend une partie ou plusieurs concepts

du logiciel sous test neacutecessitant lexploration et la conception de plusieurs cas de test pour

remplir la mission de test de ce point Lobjectif de lintroduction de ce concept est davoir le

controcircle sur la porteacutee de test pendant le test de chaque version du logicieL Autrement dit ecirctre

capable de deacuteterminer ce qui doit ecirctre testeacute dans chaque version En effet labsence dune

liste de test deacutetermineacutee dans le processus ad hoc existant et labsence des exigences dans

lensemble de projet du deacuteveloppement a rendu difficile lidentification du volume de test

neacutecessaire de chaque version ou apregraves chaque changement En effet avant lintroduction de

lapproche SBET la porteacutee de test a eacuteteacute guideacutee par les deacutefauts trouveacutes et par les preacutedictions ct

les intuitions de testeurs sur les secteurs du logiciel devant ecirctre testeacutes Donc une liste de point

de test va permettre de seacutelectionner les parties devant ecirctre testeacutees de chaque version Ainsi

une liste de points de test va permettre deacutevaluer le statut et la progression de projet de test

simplifier la communication agrave linteacuterieur et agrave lexteacuterieur de leacutequipe de test deacuteviter la

duplication du travail agrave linteacuterieur de leacutequipe de test dans le sens ou une partie poulTait ecirctre

lesteacutee par plusieurs testeurs (Lyndsay et van Eeden 2003)

Controcircle du travail de leacutequipe de test les auteurs ont proposeacute le concept de test en session

pour controcircler le travail accompli par chaque testeur La session est un intervalle non

interrompu Dans une session de test le testeur se charge de lexeacutecution dune ou plusieurs

points de test et rapporte les deacutefauts trouveacutes et les questions rencontreacutees pendant lexploration

agrave la fin de la session de test Les questions megravenent souvent agrave des nouvelles pistes pour la

conception de dautres points de test Ce rapport de test fera lobjet dune revue et une

discussion avec le responsable de test Ce dernier eacutevalue le travail accompli par le testeur et

le guide vers dautres astuces ou strateacutegies si neacutecessaire (Lyndsay et van Eeden 2003)

Mesure de la couverture de tests selon Lyndsay et van Eeden (2003) la couverture de test

consiste agrave mesurer ce qui a eacuteteacute testeacute comme proportion de ce qui poulTait ecirctre testeacute

51

Selon ces mecircmes auteurs labsence des exigences documenteacutees et de cas de test sceacutenaliseacute a

rendu impossible dutiliser les meacutethodes formelles habituelles de mesure de couverture de

test dans lactiviteacute de test effectueacute par lapproche de test SBET (ces meacutethodes seront

abordeacutees en deacutetail dans le chapitre VII) Face agrave ceci les auteurs ont proposeacute une technique de

mesure de couverture de tests qui sadapte avec les caracteacuteristiques speacuteciales de lapproche

SBET Leur technique fondeacutee sur lestimation et leacutevaluation subjective de laquola testabiliteacuteraquo

sous-entend le pourcentage testeacute ou couvert par les tests de chaque point de test dans la

session de test Apregraves lexeacutecution de la session de test le responsable de test eacutevaluera le

travail accompli par le testeur et en mecircme temps veacuterifiera le pourcentage estimeacute de la

testabiliteacute rapporteacute par le testeur de chaque point de test Si le pourcentage est insuffisant et le

risque associeacute a ce point de test exige un pourcentage supeacuterieur leffort de test neacutecessaire

pour accomplir ce point de test est re-estimeacute (Lyndsay et van Eeden 2003) En calculant la

testabiliteacute de chaque point de test les auteurs ont pu calculer la couverture globale du produit

logiciel sous test agrave nimporte quel moment du processus de test en utilisant la formule

suivante

Couverture de test = la somme de temps de points de test compleacuteteacuteslestimation de la

somme de temps neacutecessaire pour accomplir les points de test restants

Mesure et hieacuterarchisation de risque les auteurs Lyndsay et van Eeden (2003) ont mesureacute

le risque de chaque point de test en terme de la probabiliteacute doccurrence dune deacutefaillance

associeacutee agrave ce point de test et )impact de cette deacutefaillance sur le fonctionnement du logiciel

Cela leur permis de classifier et destimer leffort neacutecessaire pour tester chaque point de test

et de prioriser les tacircches du test Autrement dit les points de test repreacutesentant plus de risque

recevront plus de tests

Selon les auteurs Lyndsay et van Eeden (2003) lintroduction de lapproche a eu des reacutesultats

immeacutediats et des reacutesultats agrave long terme En ce qui concerne les reacutesultats immeacutediats leacutequipe

de test a pu produire une meacutetrique de couverture utile degraves la premiegravere utilisation de

Japproche SBET Ce fait a eu une reacutepercussion positive sur la qualiteacute du produit parce que

les parties agrave grands risques du logiciel ont reccedilu plus dattention et plus de tests Lutilisation

52

de lapproche SBET a permis de controcircler le travail des testeurs apregraves lexeacutecution de chaque

session sans avoir le besoin decirctre sur place pendant le test En ce qui concerne la

productiviteacute les auteurs nont pas pu tirer de conclusions fiables agrave cause de labsence des

mesures quantitatives avant lintroduction de lapproche SBET

Cependant mecircme avec laugmentation du nombre derreurs trouveacutees dans les cinq mois qui

suivent lutilisation de SBET les auteurs Lyndsay et van Eeden (2003) nont pas pu savoir si

cette augmentation due a ljntroduction de lapproche SBET ou laugmentation de la

complexiteacute de lapplication et lajout de nouvelles fonctionnaliteacutes A long terme les auteurs

Lyndsay et van Eeden (2003) ont remarqueacute que le produit est devenu plus stable et que le

nombre de deacutefauts trouveacutes a diminueacute dune faccedilon signi ficative bjen que de nouvelles

fonctionnaliteacutes sajoutent toujours Aussi ils nont pas pu savoir si cette reacuteduction provenait

de Jameacutelioration de la qualiteacute du code ou de lincapaciteacute de lapproche SBET agrave deacutetecter

dautres deacutefauts Toutefois selon Lyndsay et van Eedcn (2003) lintroduction de la technique

a eu une reacutepercussion positive sur tout le projet de deacuteveloppement du fait quelle a inciteacute les

responsables de projet de deacuteveloppement agrave ameacuteliorer la globaliteacute du processus de

deacuteveloppement surtout la documentation Selon ces mecircmes auteurs quelques reacutesul1ats

intangibles ont eacuteteacute perccedilus suite agrave Jintroduction de SBET JI sagit de lameacutelioration de la

visibiliteacute agrave linteacuterieur et lexteacuterieur du processus de tcst

En geacuteneacuteral selon les auteurs Lyndsay et van Eeden (2003) lapproche SBET a eacuteteacute tregraves

efficace dans le cas de leur projet de test Elle a permis dintroduire Je controcircle et la mesure

sur le processus ad hoc existant Ces mecircmes auteurs soulignent que la meacutethode a permis

dencourager la communication entre les membres du test au lieu dutiliser la documentation

pour le faire Ils ajoutent que le deacutebriefing utiliseacute dans lapproche SBET apregraves lexeacutecution de

chaque session de test a permis de former les testeurs et leur apprendre les techniques de

tests Toutefois ils affirment que cetle meacutethode pourrait ecirctre moins efficace dans un

environnement de deacuteveloppement plus sophistiqueacute ]Is soulignent aussi que la qualiteacute de test

effectueacute deacutepend de la creacuteativiteacute et lexpertise des membres de leacutequipe de test

53

La taille et la nature de lapplication qui a eacuteteacute le sujet de cette eacutetude ne permettent pas de

geacuteneacuteraliser les reacutesultats de cette eacutetude La meacutetrique de couverture proposeacutee dans leacutetude est

subjective et deacutepend aussi de lexpertise du testeur Mais les ideacutees et les techniques de

mesures proposeacutees sont inteacuteressantes et initient plusieurs pistes de recherches afin

dameacuteliorer ladoption de lapproche SBET

44 Eacutetude de James et Wood (2003)

Les auteurs Wood et James (2003) deacutecrivent leur expeacuterience dutilisation de lapproche

Session Based Exploratory Testing (SBET) Alors lapproche SBET a eacuteteacute introduite pour

tester un logiciel destineacute agrave ecirctre utiliseacute dans les appareils meacutedicaux Les auteurs ont eu recours

agrave la technique SBET pour deux raisons la premiegravere raison est la moindre cougravet de lapproche

SBET qui leur a permis de lutiliser comme une meacutethode compleacutementaire agrave la meacutethode

sceacutenariseacutee de test Cette derniegravere a un coucirct consideacuterable agrave cause des frais de documentation

des tests Cette documentation doit ecirctre deacutetailleacutee et rigoureuse dans le domaine du test des

logiciels meacutedicaux afin de respecter les normes de la qualiteacute du systegraveme (Quality System

Regulation) La deuxiegraveme raison est que les auteurs ont cu besoin dune meacutethode de test

pouvant introduire linnovation et la creacuteativiteacute dans le test en leur permettant de deacutetecter les

erreurs manqueacutees par lapproche sceacutenariseacutee

Les auteurs ont utiliseacute lapproche SBET comme une meacutethode de test compleacutementaire agrave la

meacutethode sceacutenariseacutee principale Cette derniegravere est baseacutee sur la validation des exigences et la

veacuterification de code du logiciel sous test Le test de validation est centreacute sur la couverture des

exigences et le respect des standards Ccci neacutecessite une traccedilabiliteacute accrue entre les

proceacutedures de tests et les exigences initiales Selon James et Wood (2003) ce type de test ne

met pas lemphase sur la deacutetection des deacutefauts tant que le respect des exigences ct les normes

du domaine de deacuteveloppement du logiciel meacutedical Le test de veacuterification est baseacute sur la

couverture de code Ce type de couverture cherche agrave satisfaire un critegravere de couverture de

code par exemple 80 des blocs de code doivent avoir au moins un test qui les parcourt

Autrement lexeacutecution dun maximum de lignes de code possibles pour eacuteviter quun bogue

reste dans le logiciel agrave cause dune ligne de code non exeacutecuteacutee pendant les tests Selon James

ct Wood (2003) le test de veacuterification ne met pas Jaccent sur la deacutetection de deacutefauts tant gue

la couverture de code par les tests

54

Les faiblesses des deux meacutethodes de test le test de validation et le test de veacuterification ont

motiveacute les auteurs agrave introduire lapproche SBET dans le but de deacutetecter les deacutefauts qui

peuvent ecirctre manqueacutes par ces meacutethodes de test

James et Wood (2003) ont organiseacute le test en sinspirant de la meacutethode proposeacutee par Jonathan

Bach (2000) deacutejagrave preacutesenteacutee dans le chapitre III Au deacutebut ils ont planifieacute les chartes de test

et ont estimeacute leffort neacutecessaire pour rempl ir chacune dentre elles Pendant lexeacutecution de

chaque charte le testeur devrait enregistrer les deacutefauts deacutetecteacutes ct les opportuniteacutes

rencontreacutees Notant quune opportuniteacute sous-entend des nouvelles pistes de test deacutecouvertes

pendant Jexploration qui pourraient donner lieu agrave la creacuteation de nouvelles chartes Agrave la fin

de lexeacutecution de chaque charte les auteurs deacutebriefent le testeur pour eacutevaluer les reacutesultats

rapporteacutes et mettre agrave jour le plan des chartes si neacutecessaire

Selon Wood et James (2003) lapproche SBET est une meacutethode de test tregraves efficace dclns le

domaine de deacuteveloppement des logiciels meacutedicaux du fait quelle pourrait deacutetecter les

deacutefauts pouvant ecirctre manqueacutes par les autres meacutethodes de test Un autre avantage de la

meacutethode SBET signaleacute par ces mecircmes auteurs est la documentation produite pendant les tests

qui est tregraves appreacutecieacutee dans Je domaine de deacuteveloppement du logiciel meacutedical Les auteurs

soulignent que lapproche SBET a encourageacute la creacuteativiteacute cr linllovation de testeurs Cela a

pennis de deacutetecter des deacutefauts impol1ants dans le logiciel agrave moindre coucirct par rapport aux

meacutethodes sceacutenariseacutees traditionnelles tel quillustreacute agrave la figure 4 J

55

Figure 41 Coucirct de documentation versus linnovation dans le test (Adapteacute et traduit de

James et Wood)

r---------- -Qgt 1 1

1 Session Based 1 Qgt

-GS Exploratory ~

1 testino 1~ ------1----------~

= C

C 0 -c

sect 2-~

1l 1l 1

Test de verificatioo

1

1 J r----------

0 c 1 1 -= J -~

Test de -0 1 Validation 1 -(1)

0 1 1I

1 1J

Reacuteduit Moyenne Itleveacute

Coftt typique de documentation

En ce qui concerne la productiviteacute de lapproche SBET les auteurs James et Wood (2003)

soulignent quelle est plus efficace que les deux approches sceacutenariseacutees utiliseacutees le test de

veacuterification et le test de validation en se basant sur les reacutesultats publieacutes par (Joncs TCJones

1998) Ces reacutesultats ont montreacute que le test dutilisabiliteacute est plus efficace que le test de

veacuterification et le test de validation En faisant lanalogie entre Je test dutilisabiliteacute et le

SBET les auteurs ont pu conclure que lapproche SBET est plus cfficace que la meacutethode

sceacutenariseacutee cest agrave dire plus efficace que le test sceacutenariseacute de validation et de veacuterification En

effet selon James et Wood (2003) le test duti]isabiliteacute et Japproche SBET sont semb1abJes

agrave cause de trois raisons la premiegravere est que les deux se fondent sur le manuel dutilisateur la

deuxiegraveme que les deux seffectuent sur des pctitcs peacuteriodes seacutepareacutees connues sous le terme

de laquosession de testraquo et la troisiegraveme que les deux utilisent les talents et la creacuteativiteacute de testeurs

Toute fois James et Wood (2003) ont souligneacute que la qualiteacute de test effectueacute deacutepend des

qualifications et Jexpertise des testeurs qui exeacutecutcnt les tests Selon cs auteurs la meacutethode

SBET ne fournit quun protocole ou une structure dorganisation et de gestion mais ne

garantit pas la qualiteacute de test effectueacute ]Is ont souligneacute aussi que le rocircle de responsable de test

est crucial et infiuence la qualiteacute globale de test effectueacute du fait que ccst lui qui identifie et

56

deacutetermine la liste des eacuteleacutements de test et le contenu des chartes Par conseacutequent la couverture

de test de haut niveau deacutepend des compeacutetences et de lexpertise du responsable du test

Cette eacutetude montre que le TE pourrait ecirctre utiliseacute mecircme dans les domaines de test le plus

critique comme une meacutethode compleacutementaire agrave la meacutethode sceacutenariseacutee Agrave cause de sa valeur

ajouteacutee et son innovation dans la deacutetection des deacutefauts pouvant ecirctre manqueacutes par les

meacutethodes sceacutenariseacutees traditionnelles Cependant leacutetude na pas preacutesenteacute des donneacutees

quantitatives sur la productiviteacute de lapproche SBET et le degreacute dameacutelioration reacutealiseacute de

qualiteacute du logiciel testeacute

45 Eacutetude de Amland et Vaga (2002)

Les auteurs Amland et Vaga (2002) deacutecrivent une eacutetude de cas dutiJisation de TE en tant

quune strateacutegie de test primaire dans une entreprise norveacutegiennc Lintroduction de

japproche eacutetait pour tester un portail Web Linstabiliteacute et le changement freacutequent des

exigences et le manque du temps eacutetant les motifs principaux quc ont pousseacute les auteurs agrave

chercher une approche de test qui peut sadapter avec les contraintes changeantes de leur

projet de test a la place de lapproche sceacutenariseacutee habituelle qui eacutetait incapable de sadapter agrave

ces contraintes

En effet au deacutebut les auteurs ont commenceacute la preacuteparation de plan de test et des cas de test

formels neacutecessaires pour la mise en œuvre dune approche de test sceacutenariseacute Agrave cause de

labsence des exigences du systegraveme les auteurs ont utiliseacute le TE libre pour se renseigner sur

le logiciel planifier et concevoir les cas de tests Cependant les deacuteveloppeurs ou les auteurs

ont eu le mandat de tester le logiciel deacuteveloppeacute ont continueacute dintroduire des changements au

code De ce fait selon Amland et Vaga (2002) lapproche sceacutenariseacutee de test ne pourra pas

ecirctre rentable dans leur cas parce quapregraves chaque changement dans Je logiciel ils devront

retravailler les artefacts de test deacutejagrave conccedilus

Agrave cet effet Amland et Vaga (2002) ont deacutecideacute dutiliser le TE Cependant les auteurs ont

reacutealiseacute que la meacutethode de gestion ct de controcircle de TE a un rocircle deacutecisif dans la reacuteussite de

leur projet de test surtout si tout le temps disponible pour le test est seulement de deux jours

57

Alors Amland et Vaga (2000) ont geacutereacute le TE dune faccedilon proche de la meacutethode proposeacutee par

Jonathan Bach (2000) Ils ont preacutepareacute des directives pour les sept pairs participantes dans le

test dacceptation de portail En fait ces directives ont eacuteteacute eacutelaboreacutees agrave partir de plan de test

formel deacutejagrave conccedilu Ce plan identifie deacutejagrave les items du logiciel agrave tester et les items ne doivent

pas ecirctre testeacutes Ces items ont eacuteteacute utiliseacutes pour controcircler la couverture de tests Avant le deacutebut

de test les testeurs ont suivi une fonnation de deux jours puis un briefing de 20 minutes a eacuteteacute

mis en oeuvre pour annoncer aux testeurs les secteurs fonctionnels principaux quils doivent

tester En plus un controcircle aupregraves de testeurs pendant le deacuteroulement de test a aideacute les

auteurs dans la direction des testeurs en cas de deacuteraillement sur les directives

Selon les constatations de Amland et Vaga (2002) lexpeacuterience dutilisation de TE a eacuteteacute

fructueuse Toutefois ils affirment que la creacuteativiteacute et les connaissances des testeurs ct du

responsable du test chargeacute de la seacutelection de la liste des items agrave test cr sont essentielles dans le

TE et peuvent innuencer la qualiteacute du test

Malgreacute la reacuteussite de cette eacutetude de cas la taille ct la nature de lapplication ne permettent pas

de geacuteneacuteraliser les reacutesultats obtenus ni de tirer des conclusions fiables Toutefois cette

expeacuterience a introduit une situation reacuteelle ou le TE a eacuteteacute impleacutementeacute pour confrontcr les

contraintes changeantes de projet de test Cette eacutetude de cas nous a montreacute que les artefacts

seeacutenariseacutes formels pourront servir dans limpleacutementation de TE sans avoir lobligation

dutiliser les techniques proposeacutees par Jonathan Bach (2000) et Lyndsay et van Eeden (2003)

46 Synthegravese des reacutesultats des eacutetudes proposeacutees

Les eacutetudes que nous avons preacutesenteacutees dans ce chapitre nous ont pelmis de tirer plusieurs

conclusions dapregraves des expeacuteriences reacuteelles dutilisation de TE Ainsi elles nous ont permis

de comprendre comment les praticiens et les professionnels dans Jindustrie de test perccediloivent

le TE comment ils limpleacutementent dans la pratique pourquoi ils lutilisent les difficulteacutes et

les lacunes rencontreacutees lors de lutilisation de TE et finalement deacutelaborer une vue globale et

commune agrave partir de toutes les eacutetudes proposeacutees

58

Nous avons constateacute que les praticiens ne considegraverent que lapproche SBET comme un TE

tandis que le TE libre est consideacutereacute comme un test ad hoc (Lyndsay et van Eeden 2003

Amland et Vaga 2002) Ainsi tous les auteurs dans les eacutetudes de cas que nous avons

preacutesenteacutees adoptent une forme personnaliseacutee de lapproche SBET Autrement dit les auteurs

organisent lactiviteacute de test dans des sessions de test de dureacutee deacutetermineacutee chacune delles

produit des notes qui font lobjet dune eacutevaluation par le responsable de test Nous avons

constateacute aussi que ces eacutetudes ne mentionnent pas les techniques utiliseacutees pendant

lexploration et les tests malgreacute la diversiteacute des techniques proposeacutees par les concepteurs de

TE Kaner et Bach (2004) dont quelques-unes deacutejagrave eacutevoqueacutees dans le chapitre Ill En fait dans

la plupart des eacutetudes les testeurs utilisent leurs intuitions pour deacutetecter les deacutefauts nous

pourrons mecircme dire quil sagit dun test ad hoc planifieacute et structureacute

Toutes les eacutetudes que nous avons preacutesenteacutees dans ce chapitre ont montreacute que les changements

freacutequents du logiciel la pression de temps et la limitation de ressources en tcrme de budget

de test et de personnel sont les raisons principales pour utiliser le TE plus particuliegraverement

Japproche SBET Certaines eacutetudes (Itkonen et Rautiainen 2005 Lyndsay et van Eeden

2003 Amland et Vaga 2002) ont signaleacute Je manque de controcircle de couverture de test comme

une lacune du TE Toutes les eacutetudes (ltkonen et Rautiainen 2005 Petty 2005 Lyndsay et

van Eeden 2003 Wood et James 2003 Amland et Vaga 2002) ont signaleacute que la qualiteacute du

TE effectueacute deacutepend des quai ifications et de la creacuteativiteacute des testeurs De plus deux de ces

eacutetudes ajoutent que la qualiteacute de TE deacutepend aussi des compeacutetences et des qualifications du

responsable de test (Wood ct James 2003 Amland et Vaga 2002) La planification et le

controcircle de lapproche SBET ont eacuteteacute mentionneacutes comme dcs facteurs impol1ants de succegraves de

lactiviteacute de test (Lyndsay et van Eeden 2003 Wood ct James 2003 Amland et Vaga

2002)

En geacuteneacuteral nous avons constateacute que toutes les eacutetudes de cas ont eacuteteacute faites sur des petites

applications et avec des petites eacutequipes de test La collaboration et la communication entre

les membres de leacutequipe de test la concentration sur laccomplissement du travail de test

plutocirct que la documentation et la gestion de processus ont eacuteteacute les eacuteleacutements cleacutes de lapproche

SBET Ceux-ci nous ont pousseacute de faire janalogie enlre le deacuteveloppement du logiciel el le

59

test du logiciel autrement dit lanalogie entre lagiliteacute et la discipline du processus de

deacuteveloppement et linformaliteacute et la discipline de processus de test Nous allons aborder en

deacutetail au cours de notre eacutetude comparative dans le chapitre VII cette analogie que nous avons

lexploiteacutee pour construire notre cadre conceptuel de comparaison qui va nous permettre de

comparer les deux approches de test le TE et le TS

51

CHAPITRE V

LEacuteTUDE EMPIRIQUE

Dans ce chapitre nous preacutesentons les eacutetapes principales de notre eacutetude empIrIque Tout

dabord nous proposerons la motivation de leacutetude et la strateacutegie que nous avons choisie pour

laborder Puis nous preacutesenterons le scheacutema conceptuel de lexpeacuterience Par la suite nous

analyserons les reacutesultats recueillis et nous conclurons

Motivation de leacutetude

Depuis son apparition dans lindustrie du test Je test exploratoire (TE) se fait preacutesenter

comme une approche productive qui pourrait augmenter lefficaciteacute de Jactiviteacute de test en

termes de nombre et dimportance de deacutefauts deacutetecteacutes Selon Bach (2003) le TE pourrait ecirctre

plus productif que le test sceacutenariseacute (TS) Cependant lauteur na pas preacutesenteacute de preuves de

cette reacuteclamation agrave palt quelques anecdotes et expeacuteriences personnelles Un tour rapide sur

les reacutecentes publications de Kaner sur son site l montre que le TE se fait traiter comme une

innovation scientifique qui exploite et optimise la creacuteativiteacute et lexpertise du testeur dans la

deacutetection des deacutefauts importants qui ne pourraient pas ecirctre deacutetecteacutes par le TS Selon Kaner et

Bach (2005) Je TS transforme les testeurs en robots inefficaces Ces arguments nous ont

motiveacutee agrave faire une eacutetude empirique pour eacutevaluer la productiviteacute du TE Tout dabord nous

allons comparer les reacutesultats de TE recueillis de Jexpeacuterience avec les reacutesultats quantitatifs

publieacutes par ltokens et Rautiainen (2005) Puis nous proceacutederons agrave une analyse comparative

empirique enlre le TE et le TS en se basant sur les reacutesultats de notre eacutetude

Cependant dans la mise en ouvre de notre eacutetude empirique nous avons eacuteteacute confronteacutee au

1 wwwtcstingeducationorg

61

problegraveme du contexte expeacuterimental En effet dans un contexte industriel nous pouvons

utiliser comme instrument de lexpeacuterience un logiciel professionnel cest agrave dire un logiciel

deacuteveloppeacute dans Jindustrie de deacuteveloppement du logiciel Ce logiciel pourrait ecirctre testeacute avec

deux groupes un utilise le TS et lautre le TE Les donneacutees pourraient ecirctre recueillies

pendant Jactiviteacute de test et sur le site de production du logiciel testeacute Par la suite lanalyse

des reacutesultats de lexpeacuterience doit ecirctre faite sur deux niveaux le premier est de comparer le

nombre et limportance des deacutefauts deacutetecteacutes avant la livraison du logiciel cest agrave dire agrave la fin

de lactiviteacute de test Le deuxiegraveme est de comparer le nombre et limportance des deacutefauts

deacutetecteacutes apregraves Ja livraison du logiciel cest agrave dire dans le site dutilisation du logiciel testeacute

Cette strateacutegie pennettrait de mesurer la productiviteacute pendant et apregraves lactiviteacute de test Or la

mise en place dune telle expeacuterience neacutecessite lengagement dune entreprise de

deacuteveloppement du logiciel agrave participer agrave lexpeacuterience et agrave divulguer les informations de son

activiteacute de test Malheureusement nous navons pas pu trouver une entreprisc pour se plier agrave

ces contraintes Cela nous a obligeacutee agrave concevoir une nouvelle strateacutegie pour notre expeacuterience

dans le contexte acadeacutemique ougrave nous avons deacutecideacute de la faire

52 La strateacutegie de lexpeacuterience

Dans un contexte acadeacutemique lexpeacuterience pourrait ecirctre entreplise de deux faccedilons

diffeacuterentes la premiegravere consiste agrave faire lexpeacuterience de la mecircme faccedilon que si elle se deacuteroulait

dans le contexte industriel cest agrave dire nous divisons les sujets en deux groupes dont un

exeacutecute le TE et lautre le TS Nous pouvons mecircme aller plus loin et utiliser japproche

SBET pour controcircler la couverture de test et eacuteviter que les deacutefauts deacutetecteacutes soient dupliqueacutes

Quant au TS il poulTait ecirctre exeacutecuteacute de la mecircme faccedilon quen industrie Alors chaque sujet

exeacutecute des cas de tests correspondant agrave une partie du logiciel Finalement nous analysons le

nombre et limportance des deacutefauts rappol1eacutes pour deacuteterminer lapproche la plus efficace

Malheureusement nous navons pas pu utiliser cette strateacutegie pour deux raisons la taille du

programme utiliseacute dans lexpeacuterience et le manque dexpeacuterience des expeacuterimentateurs En

effet nous avons ducirc utiliser un petit programme dans lexpeacuterience afin de simplifier la

mission des sujets pendant Jactiviteacute de TE Cela pour eacutevitcr dobtenir des reacutesultats nuls qui

peuvent reacutesulter de lexeacutecution de TE si nous utilisons un trop grand logiciel

62

La deuxiegraveme raIson du choix de notre strateacutegie est le manque dexpeacuterience chez les

participants Ces sujets sont des eacutetudiants agrave lUQAgraveM Ils possegravedent une expeacuterience des tests

et de ses techniques limiteacutee agrave la couverture de ces matiegraveres dans le programme offert agrave

lUQAgraveM Nous avons cependant choisi les eacutetudiants du cours INF6160 Qualiteacute processus et

produits parce que cest dans ce cours que ces sujets sont abordeacutes le plus profondeacutement Cela

ne nous a quand mecircme pas permis dorganiser lactiviteacute de test de la mecircme faccedilon

professionnelle deacutecrite ci- dessus Lexpeacuterience consiste agrave utiliser les mecircmes sujets pour

exeacutecuter dabord le TE et le TS ensuite afin deacuteviter que les sujets apprennent les cas de tests

sceacutenariseacutes et les reacutepegravetent par la suite dans le TE Agrave cet effet nous avons programmeacute

Jexpeacuterience dans une seacuteance de cours de 2 heures 45 minutes pour exeacutecuter chacune de deux

approches de test Les eacutetudiants ont pris connaissance du deacuteroulement de lexpeacuterience dans

une seacuteance anteacuterieure ougrave le professeur a preacutesenteacute aux eacutetudiants une vue densemble du TE

Le sujet de lexpeacuterience et ses reacutesultats a constitueacute une partie de travail de session de cours

lNF6160 Alors chaque eacutetudiant participant dans lexpeacuterience a ducirc rappol1er ses reacutesultats et

les conclusions quil a pu tirer de Jexpeacuterience concernant les deux approches de test le TE

et le TS dans un rapport de fin de session Ceci a motiveacute les sujets agrave deacutelecter le maximum des

deacutefauts possibles el nous a garanti que les eacutetudiants ont pris Jexpeacuterience au seacuterieux

Nous avons proposeacute aux 56 sujets participants dans lexpeacuterience le programme agrave tester

accompagneacute de quelques modegraveles et techniques dexploration (Annexe C) pour les guider

pendant le TE et eacuteviter dobtenir des reacutesultats nuls Puis nous leur avons proposeacute les cas de

tests sceacutenariseacutes que nous avions preacutepareacute pour lactiviteacute de TS Alors tous les sujets ont

exeacutecuteacute les mecircmes cas de tests

Dans notre plan expeacuterimental les mecircmes sujets ont eacuteteacute utiliseacutes dans les deux traitements Ce

type deacutetude est qualifieacute de plan expeacuterimental agrave facteur unique agrave mesures reacutepeacuteteacutees sur les

mecircmes eacuteleacutements laquo Single Factor Experiments Having Reapted Measures on The Same

Elementsraquo (Winer 197 J p 105) Les reacutesultats ont eacuteteacute exploiteacutes de deux faccedilons di ffeacuterentes

la premiegravere lexploitation des reacutesultats de TE collecteacutes de notre expeacuterience et la deuxiegraveme

lexploitation des reacutesultats des deux activiteacutes de test et la comparaison des reacutesultats collecteacutes

Agrave cet effet nous utilisons dans celte analyse comparative lanalyse de variance ANOVA

63

proposeacute par Winer (1971 p lOS) Celte analyse nous a permet deacutevaluer leffet de

traitement cest agrave dire lapproche de test (T8 TE) sur la performance des sujets Celte faccedilon

de faire nous a permis deacutevaluer la productiviteacute de chacune des deux approches de test Cela a

aussi permis dexplorer la validiteacute de lhypothegravese proposeacutee par Kaner et Bach (2005) qui cite

que les testeurs juniors ne pourraient pas reproduire les cas de tests de la mecircme faccedilon que

lauteur ou le concepteur de ces cas de tests (le testeur senior) Aussi nous a permis

danalyser et de comparer les reacutesultats de TE de notre eacutetude empirique avec les reacutesultats des

travaux de recherches proposeacutes dans la litteacuterature par Itokens et Rautiainen (2005)

53 Le scheacutema de lexpeacuterience

531 Objectifs et hypothegraveses de lexpeacuterience

Comme le soulignent Lait et Rambach (1997) lidentification preacutecise des buts de leacutetude est

cssentielle agrave la mise en œuvre dune eacutetude expeacuterimentale Cette identification permet de

planifier et deacuteterminer les deacutetails de la perspective ou la strateacutegie suivie pour que lexpeacuterience

atteigne ses buts speacutecifieacutes De ce fait les aspects agrave eacutevaluer et les meacutetrigues agrave utiliser devront

ecirctre preacuteciseacutes et bien identifieacutes avant le deacutebut de lexpeacuterience Dans notre cas le but de

lexpeacuterience est de comparer la productiviteacute de TE et le T8 en termes de nombre et

dimportance des deacutefauts deacutetecteacutes Cela nous a permis deacutenoncer les hypothegraveses suivantes

Notre hypothegravese primaire est

Hl - le test exploratoire est plus efficace en terme de nombre de deacutefauts deacutetecteacutes que le test

sceacutenanseacute

Lhypothegravese nulle correspondante agrave celte hypothegravese est

Ho - il ny a pas de diffeacuterence entre le test exploratoire et le test sceacutenariseacute quant au nombre

de deacutefauts deacutetecteacutes

Notre hypothegravese secondaire est

H2 - le test exploratoire permet de deacutetecter des deacutefauts plus importants point de vue graviteacute

que le test sceacutenariseacute

64

532 La conception expeacuterimentale

Dans cette section nous preacutesentons la conception expeacuterimentale que nous avons faite pour

notre eacutetude empirique La conception et lanalyse de lexpeacuterience sont traiteacutees complegravetement

par (Winer 197 J) qui eacuteteacute utiliseacute comme reacutefeacuterence dans plusieurs eacutetudes expeacuterimentales

anteacuterieures (Wood et a1 ]997) Avant dintroduire les deacutetails de la conception choisie nous

deacutefinissons certains termes neacutecessaires agrave la compreacutehension de la conception de notre

expeacuterience

bull Variable indeacutependante est le facteur qui influence les reacutesultats de lexpeacuterience cest agrave

dire le facteur causal La manipulation des valeurs prises par cette variable permet

deacutetudier les effets de ces diffeacuterentes valeurs sur les reacutesultats Dans notre eacutetude la variable

indeacutependante est lapproche de test et ses valeurs possibles sont le TE et le TS

bull Variable deacutependante mesure les effets de la manipulation des variables indeacutependantes

Dans notre expeacuterience elle correspond au nombre et la seacuteveacuteriteacute des deacutefauts deacutetecteacutes

Dans notre expeacuterience nous al10ns eacutetudier leffet de lapproche de test (TE TS) surmiddot la

productiviteacute de lactiviteacute de test en utilisant un eacutechantillon composeacute de 56 sujets Chaque

eacuteleacutement de leacutechantillon applique les deux techniques de test sur le mecircme programme agrave

tester Donc nous avons un seul facteur qui peut influencer les reacutesultats de lexpeacuterience qui

est lapproche de test (TE TS) Selon (Winer J971) les contraintes de notre eacutetude empirique

correspondent agrave la conception proposeacutee par lauteur sous lexpression laquo expeacuterience agrave facteur

unique a mesures reacutepeacuteteacutees sur les mecircmes eacuteleacutementsraquo (Single Factor Experiments Having

Repeated Measures on the Same Elements)

533 Lcs instruments de leacutexpeacuterience

Les instruments de lexpeacuterience sont constitueacutes dun seul programme dans les deux activiteacutes

de test le TE el le TS JI sagit dun prognllnme de gestion des messages deacuteveloppeacute avec le

langage de programmation Jav3 Nous avons choisi le programme pour que sa taille et sa

complexiteacute facilitentmiddot lexeacutecution des deux techniques de test aux sujets (les eacutetudiants de cours

(NF 6160)

65

534 Le traitement expeacuterimental

En ce qui concerne le TS les sujets ont reccedilu en entreacutee le programme et les cas de tests que

nous leur avons conccedilus en utilisant un test fonctionnel (boicircte noire) Les sOlties sont les

deacutefauts deacutetecteacutes

Figure 51 Le traitement de test sceacutenariseacute

Les cas de tests

Les deacutefautsExeacutecution des cas deLe programme deacutetecteacutestests

Tel quillustreacute sur la figure 51 les sujets ont reccedilu les cas de test ct les ont exeacutecuteacutes dans une

session de 45 minutes Ils ont eacuteteacute informeacutes de ne pas produire de cas de tests additionnels

pendant lexeacutecution des cas de tests pour eacuteviter dintroduire le TE dans le TS Alors pendant

lexeacutecution des cas de test les sujets comparent les reacutesultats de sOl1ies observeacutes avec les

reacutesultats deacutecrits dans le script de cas de test Si les deux reacutesultats ne correspondent pas le

sujet doit enregistrer ct deacutecrire le comportement observeacute pendant lexeacutecution de ce cas de

test pour que nous puissions sassurer quil sagit vraiment dun deacutefaut et eacuteviter une

mauvaise interpreacutetation du comportement du programme

En ce qui concerne le TE nous Javons programmeacute dans une session de 45 minutes Les

sujets dans cette session de test exploratoire ont utiliseacute quelques modegraveles et techniques

dexploration que nous Jeur avons preacutepareacutes en avance (Annexe C) en se basant sur les

techniques proposeacutees par Amland (2002) afin de faciliter leur mission et les guider dans le

test

66

Figure 52 Le traitement de test exploratoire

Le programme

~ pprentissage concpetion et exeacutecu tion ----~ Les deacutefauts deacutetecteacutes

des tests ~ -----~----

Tel quillustreacute sur la figure 52 les sujets ont reccedilu le programme en entreacutee Leur mission eacutetait

dapprendre le programme concevoir et exeacutecuter les tests et rapportent Jes deacutefauts deacutetecteacutes

Le reacutesultat de lexeacutecution de TE est une liste des deacutefauts deacutetecteacutes (Annexe D) Pendant

Jexeacutecution de TE les sujets ont classifieacute les deacutefauts deacutetecteacutes selon leur graviteacute en suivant une

Jiste de classification de deacutefauts que nous leur avons fournie avant le deacutebut de lactiviteacute de

TE Cette liste classifie la graviteacute des deacutefaillances en trois niveaux

o fatale lapplication est inopeacuterable complegravetement (Crash)

o Moyenne lapplication fonctionne malS cel1aines fonctions sont inopeacuterables ou

certains reacutesultats sont erroneacutes

o Mineure limpact est rmneur sur Jutilisation du systegraveme comme certains formats

sont erroneacutes bien que les reacutesultats soient corrects ou encore le deacutelai de reacuteponse est

supeacuterieur de ce gui atlendu dune telle application

Apregraves lexpeacuterience nous avons re-classifieacute les deacutefauts rapporteacutes par les expeacuterimentateurs pour

eacuteviter des erreurs qui peuvent se reacutesulter sur une mltluvaise classification

67

54 Analyse des reacutesultats de lexpeacuterience

541 Analyse des resulats de test exploratoire

Avant de proceacuteder agrave une analyse comparative des reacutesultats de TE et TS nous analysons tout

dabord des reacutesultats de test exploratoire en termes de nombre et limportance des deacutefauts

deacutetecteacutes et nous les avons compareacutes avec les reacutesultats rapporteacutes dans la rccherche dltokens et

Rautiainen (2005)

5411 La productiviteacute de TE selon le nombre de deacutefauts deacutetecteacutes

Lanalyse et le traitement des donneacutees de TE recueillis pendant leacutetude empirique nous ont

permis de deacutevelopper une ideacutee estimative de la productiviteacute de TE en tcrme de nombre de

deacutefauts deacutetecteacutes (figure 53)

Figure 53 Les reacutesultats de test exploratoire

12

10

Nombre de

sujets

o 4 7 10 13 16

Nombre de deacutefauts

Les reacutesultats preacutesenteacutes agrave la figure 53 montrent que plus que la moitie (66lt) des sujets ont

reacuteussi agrave deacutetecter entre 6 agrave 9 deacutefauts La moyenne est de 95 deacutefauts par sujet Cette moyenne

est tregraves proche de celle proposeacutee par leacutetude de Itokens et Rautiainen (2005) Selon les

donneacutees quantitatives collecteacutees par ces auteurs dans la petite cntreprise dont son contexte de

deacuteveloppement est immature (plus proche de notre contextc de test) la moyenne reacutealiseacutee est

de 87 deacutefauts dans une session de 60 minutes

68

5412 La productiviteacute selon limportance de deacutefauts

Lanalyse et le traitement des donneacutees de TE recueillis pendant leacutetude empirique nous ont

permis davoir aussi une ideacutee sur limportance de deacutefauts qui pouvant ecirctre deacutetecteacutes

(figure64)

Figure 54 Importance de deacutefauts deacutetecteacutes avec le test exploratoire

10

lZ3 Fatale Grave D Mineure

Nous pouvons constater agrave partir des reacutesultats preacutesenteacutes sur la figure 54 que le pourcentage

des deacutefauts graves deacutetecteacute par les sujets avec le TE est plus que la moitieacute de tous les deacutefauts

deacutetecteacutes Tandis que seulement J0 des deacutefauts deacutetecteacutes sont fatales Les auteurs Jtokens et

Rautiainen (2005) ont rapporteacute un pourcentage de 15 des deacutefauts fatals deacutetecteacutes dans une

session de 60 minutes Cest un pourcentage tregraves proche du pourcentage reacutealiseacute dans notre

eacutetude empirique si nous prenons en consideacuteration la diffeacuterence dans les programmes utiliseacutes

dans leur eacutetude de cas et notre expeacuterience

La figure 54 montre que 70 des deacutefauts deacutetecteacutes pendant lexpeacuterience avec le TE sont des

deacutefauts importants cest agrave dire sont des deacutefauts fatals ou graves qui pounont empecirccher le

fonctionnement normal du programme sous test Par contre 50 des deacutefauts deacutetecteacutes avec le

TS sont des deacutefauts mineurs cest agrave dire des deacutefauts qui ne pourront pas empecirccher le

programme de fonctionner Ainsi la moitieacute des deacutefauts deacutetecteacutes avec le TS sont des deacutefauts

69

importants dont 45 des deacutefauts sont des deacutefauts graves et seulement 5 des deacutefauts sont

fatals De ce fait nous pouvons conclure que le TE permet de deacutetecter des deacutefauts plus

importants que le TS Eacutevidement les reacutesultats de TS deacutependent des connaissances et des

compeacutetences du concepteur des cas de test (lauteur de ce travail de recherche) Agrave cet effet

un autre concepteur peut aboutir agrave des reacutesultats diffeacuterents

Pendant lexpeacuterience nous avons constateacute que la boucle dapprentissage et les feedbacks

instantaneacutes durant Jactiviteacute de test constituent les raisons principales des reacutesultats

performants du TE En effet les sujets ont commenceacute lapprentissage ct la conception des cas

de test deacutes quils ont reccedilu le programme agrave tester Au fur et agrave mesure quils avancent dans leur

mission de TE ils conccediloivent des tests plus productifs et plus performants qui leur

permettent de deacutetecter des deacutefauts plus importants Cela gracircce aux feedbacks deacuteriveacutes des

tests exeacutecuteacutes ulteacuterieurement pendant lactiviteacute de TE et les connaissances accumuleacutees depuis

le deacutebut de la mission de TE

Nous croyons aussi que la diversiteacute des compeacutetences et les qualifications des sujets

participants dans lexpeacuterience a contribueacute aussi aux reacutesultats performants en TE En fait la

participation de plusieurs compeacutetences ou personnes dans le test donne des reacutesultats meilleurs

que lorsque la conception des cas de test est faite par une ou deux personnes seulement Nous

pouvons conclure de cette discussion que le TE permet de deacutetecter des deacutefauts plus

importants point de vue seacuteveacuteriteacute que le TS Autrement que notre hypothegravese secondaire H2

ne peut pas ecirctre rejeteacutee

Cependant nous avons constateacute que quelques sujets dans lexpeacuterience ont pu deacutetecter des

deacutefauts plus importants que ceux deacutetecteacutes avec le TS Nous croyons que limportance des

deacutefauts trouveacutes avec le TE deacutepend de la creacuteativiteacute et les qualifications de testeur Agrave cet effet

nous avons eacutetudieacute dans notre eacutetude empirique linfluence des connaissances en

programmation en Java comme un facteur repreacutesentant lexpertise ct les qualifications de

sujet sur les reacutesultats de TE effectueacute

En effet nous avons choisi ce facteur parce que nous croyons que le niveau de connaissance

70

en java repreacutesente bien la familiariteacute de leacutetudiant avec la programmation et les techniques de

deacutebogage donc implicitement son expertise et ses qualifications neacutecessaires pour exeacutecuter sa

mission pendant le TE (figure55)

Figure 55 Linfluence de lexpertise sur le test exploratoire

fi) -lt1)

14

u lt1) 12

-lt1) 0 10 fi) l

~ 8 lt1) 0

lt1) 6 0

lt1) c 4 c lt1) 2 0

~ 0

Jamais vu Introduction Intermeacutediaire Avanceacute

Connaissance en Java

Les reacutesultats preacutesenteacutes agrave la figure 55 montrent que la moyenne de deacutefauts deacutetecteacutes est plus

eacuteleveacutee pour un niveau de connaissance eacuteleveacute en Java La faible diminution pour le niveau

intermeacutediaire pourrait ecirctre expliqueacutee par la difficulteacute de situer le niveau de connaissance en

Java Notons que la Jiberteacute de TE a eacuteteacute signaleacutee par plusieurs sujets comme un avantage du

TE qui leur permet dapprofondir et dameacuteliorer leurs tests en temps reacuteel

542 Analyse des reacutesultats de TE et TS

Cette section aborde les reacutesultats rapporteacutes de lexpeacuterience de deux approches de test le TS

ct le TE Notre ideacutee est danalyser et de comparer la performance des sujets dans les deux

meacutethodes de test Autrement dit eacutevaluer la productiviteacute de TE par rapport au TS en

comparant le nombre de deacutefauts deacutetecteacutes par chaque sujet en utilisant le TE et le TS Le

traitement des reacutesultats recueillis de lexpeacuterience nous a donneacute le graphe 56

71

Figure 56 Reacutesultats des sujets aux TE et TS

Les sujets

-TE --TS

Nous pouvons constater de la figure 56 que le TE est plus productif que Je TS Cependant la

limitation de contexte de lexpeacuterience reacutesidant dans la taille du programme de jexpeacuterience et

le manque dexpel1ise des expeacuterimentateurs ne permet pas de tirer des conclusions fiables et

de geacuteneacuteraliser les reacutesultats obtenus

5421 Analyse de variance ANOVA

La figure 56 montre que les sujets ont eacuteteacute plus performants et productifs en TE quen TS

Dans eette section nous allons prouver statiquement ces reacutesultats en utilisant lanalyse de

variance ANOY A

Lanalyse de variance ANOYA laquo ANalysis Of VArianceraquo est une meacutethode statistique

permettant de comparer la moyenne de plusieurs populations Elle permet de savoir si une ou

plusieurs variables deacutependantes sont en relation avec une ou plusieurs variables dites

indeacutependantes (Winer ]97 J)

Dans un plan dexpeacuterience agrave mesures reacutepeacuteteacutees un mecircme sujet est mesureacute sous chacun des

niveaux dun traitement expeacuterimental Comme dans notre eacutetude ougrave chaque sujet est mesureacute

deux fois sous le TE puis le TS Dans ce type de plan leffet de lapproche de test

72

exploratoire sur le sujet k est compareacute avec la reacuteponse de mecircme sujet dans le TS Dans ce

plan chaque sujet devient son propre controcircle agrave travers les deux traitements expeacuterimentaux

(les deux approches de test dans notre cas)

Figure 57 Repreacutesentation scheacutematique de lanalyse ANOVA (Adapteacute et traduit de

Winer 1971)

Variation totale dl=kn-l

Varaition intershy Variation intrashyindividus individus

dl=n-I dl=n(k-I)

Variation intershyVariation reacutesiduelle

traitement dl=(n-I)(k-I)

dl~k-l

dl degreacute de liberteacute

La deacutecomposition de la variance selon (Winer 1971)

o Variation totale = Variation inter-individus + Variation intra-individus

o Somme carreacutes totale de la deacuteviation (SC Totale) = Somme carreacutes inter-individus +

Somme calTeacutes intra-individus

o Variation intra-individus = Variation inter-traitement + Variation reacutesiduelle cest agrave

dire

Somme carreacutes intra individus = Somme carreacutes inter-traitements + Somme

reacutesiduelle des carreacutes

Dans notre cas nous reacutesumons les calculs de lanalyse de variance ANOVA agrave mesures

73

reacutepeacuteteacutees sur les donneacutees collecteacutees de notre eacutetude empirique dans le tableau ci dessous

Tableau 51 ANOVA des donneacutees collecteacutees de lexpeacuterience

La source de variation Somme des carreacutees SC dl Carreacute moyen Test-F

Inter-individus 84145 55

Intra-individus 837 56

Inter-traitement 37296 1 37296 458

Reacutesiduelle 46404 55 814

La valeur critique pour un Test F avec (157) degreacutes de liberteacute cst 712 Or dapregraves le calcul

nous avons trouveacute que le test F = 458 Puisque cette valeur est supeacuterieur de 712 nous

rejetons lhypothegravese nulle HO et nous conservons lhypothegravese H 10rdapregraves la repreacutesentation

graphique des reacutesultats de Jexpeacuterience figure 66 nous pouvons constater que le TE est plus

productif en terme de nombre des deacutefauts deacutetecteacutes que le TS Par la suite nous concluons que

1hypothegravese Hl est valide ct que le TE est plus productif que le TS

55 Conclusion

Lanalyse statistique des reacutesultats de leacutetude empirique nous a permis de conclure que la

performance des sujets dans Jexeacutecution de TE est supeacuterieure que leur performance dans

lexeacutecution de TS Par la suite nous avons conclu que le TE est plus productif en terme de

nombre des deacutefauts deacutetecteacutes que le TS Ainsi nous avons conclu que le TE pourraient

deacutetecter des deacutefauts plus importants point de vue graviteacute que le test sceacutenariseacute

61

CHAPITRE VI

CADRE CONCEPTUEL DE COMPARAISON

Dans la revue de litteacuterature nous avons compileacute quelques eacutetudes de cas et expeacuteriences

dutilisations du TE dans lindustrie de test logiciel Nous avons preacutesenteacute un aperccedilu des

raisons que ont motiveacute les praticiens agrave utiliser le TE les faccedilons dont ils ont adopteacute et geacutereacute le

TE et les facteurs qui ont influenceacute ses reacutesultats dans la pratique Cela nous emmegravene dans ce

travail de recherche agrave eacutetudier plus profondeacutement et dune faccedilon geacuteneacuterale ces facteurs dans le

cadre dune eacutetude comparative des deux approches de test le TE et le TS Dans ce chapitre

nous preacutesenterons le contexte de notre eacutetude comparative Puis nous proposerons notre cadre

conceptuel de comparaison Ce cadre va guider notre analyse comparative de TE et TS NOlis

le deacutevelopperons en se basant sur la litteacuterature et les eacutetudes de cas des praticiens et

chercheurs dans lindustrie de test Agrave cet effet les recherches theacuteoriques ct empiriques

anteacuterieures preacutesenteacutees dans la revue de la litteacuterature seront consideacutereacutees

Mise en contexte de leacutetude comparative

Avant de preacutesenter le cadre comparatif de cette analyse nous proposons le contexte geacuteneacuteral

de notre analyse comparative et les choix que nous avons ducirc faire pour rendre possible une

comparaison et une discussion coheacuterente Tout dabord nous choisissons le type de test qui

va repreacutesenter chacune des deux approches dans cette eacutetude comparative En effet eacutetant

donneacute que les deux approches peuvent ecirctre repreacutesenteacutees sur un continuum (Figure 21) la

diffeacuterentiation entre le TE et le TS est difficile et imperceptible sans la speacutecification de type

choisi dc chacun dentre eux De ce fait nous avons choisi de repreacutesenter le TS par un

processus de test baliseacute dans les patrons de standard de documentation IEEE 829 que nous

avons proposeacute dans le chapitre Il Ce choix est motiveacute par notre besoin de normaliser

lanalyse et la comparaison Ainsi nous pourrons comparcr un processus f0l1ement planifieacute ct

75

disciplineacute de test avec un autre processus semi-planifieacute et libre (SBET) Quant au TE nous

avons choisi de le repreacutesenter par lapproche Session Based Exploratory Testing (SBET)

Cette forme de TE dapregraves la revue de la litteacuterature que nous avons preacutesenteacute dans le chapitre

IV est la plus adopteacutee dans lindustrie de test du logiciel comme une meacutethode primaire de test

(ltkonen et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003 Wood et James

2003) tandis que le TE libre est toujours consideacutereacute comme un test ad hoc (Lyndsay van

Eeden 2003) 11 faut noter que mecircme avec le choix de lapproche SBET nous restons dans la

limite de notre comparaison de TE et TS puisque le TE libre constitue Je cœur de lapproche

SBET La seule diffeacuterence entre les deux types est les notes produites agrave la fin de la session

dans le SBET Or ce sont ces notes qui ont favoriseacute son utilisation dans Jindustrie mecircme lagrave

ougrave les tests sont le plus documenteacutes et formels tel le domaine du logiciel meacutedical (James et

Wood 2003)

Lanalyse comparative des deux approches le TE et le TS va nous permettre de ressortir les

contextes favorables pour utiliser le TE agrave la place de la meacutethode sceacutenariseacutec habituelle de test

(TS) En fait on peut dire quun contexte est lensemble des facteurs speacutecifiques de projet de

test du logiciel Par exemple dire que le logiciel agrave tester est petit repreacutesente un facteur de

contexte deacutetermineacute selon le facteur laquo Caracteacuteristiques du logiciel agrave tester raquo

Notre comparaIson est restreinte au type de test boicircte nOIre du fait que Je TE est une

technique de test boicircte noire (Craig et Jaskiel 2002 Kaner et al 2002) Dans ce type de test

on ne sinteacuteresse pas agrave laspect impleacutementation du code mais uniquement au comportement

du logiciel

Nous voulons signaler aussi que dans notre analyse comparative nous ne consideacuterons que

les modegraveles traditionnels de deacuteveloppement On a vu les modegraveles agiles de deacuteveloppement

constituent un cas reacuteel ougrave Je TE et le TS automatiseacute sont utiliseacutes ensemble pour tester le

logiciel (section 24) Or dans notre eacutetude nous voulons identifier les contextes ougrave le TE

pourrait ecirctre utiliseacute comme une meacutethode primaire de test agrave la place de TS Agrave cet effet les

modegraveles agi les ne seront pas consideacutereacutes dans cette eacutetude

76

Dans ce chapitre et les chapitres suivants nous utilisons labreacuteviation laquo TE raquo pour deacutesigner

lapproche SBET afin dalleacuteger le texte

62 Cadre conceptuel de comparaison

La comparaison entre le TS et le TE est peu abordeacutee dans la litteacuterature Les travaux qui ont

traiteacute le sujet eacutetaient plus axeacutes sur la proposition et la promotion des avantages de TE par

rapport au TS (Kaner 2006 Bach 2003) Pour cela nous nous sommes fixeacute comme objectif

dans ce travail de recherche de comparer dune faccedilon neutre les deux approches en mettant

laccent sur les apports et les contextes ougrave le TE pourrait remplacer le TS Nous tentons par le

biais de cette eacutetude comparative dexplorer ces contextes en se basant sur nos deacuteductions

personnelles tireacutes de la base theacuteorique de test du logiciel et la revue de litteacuterature des travaux

de praticiens dans Jindustrie de test (Chapitre IV) et sur leacutetude empirique preacutesenteacutee au

chapitre preacuteceacutedent

Tout dabord afin que notre analyse eomparative soit meneacutee agrave bien nous preacutesenterons notre

cadre conceptuel de comparaison Ce cadre doit permettre de guider et focaliser notre analyse

comparative entre le TE et le TS Il regroupe les critegraveres autour desquels la discussion et

lanalyse seront centreacutees Lidentification des facteurs de comparaison a eacuteteacute deacuteveloppeacutee dune

part en se basant sur les reacutesultats des expeacuteriences dutilisation du TE par les chercheurs et les

praticiens preacutesenteacutes dans la litteacuterature Nous nous sommes aussi inspireacutes des facteurs

proposeacutes par Boehm et Turner (2004)

Le cadre proposeacute par Boehm et Turner (2004) a pour objectif la comparaison des approches

agiles et les approches disciplineacutees de deacuteveloppement du logiciel Or notre comparaison

pourrai1 ecirctre vue aussi comme la comparaison entre deux meacutethodes de test disciplineacute et agile

ougrave le TS repreacutesente la meacutethode disciplineacutee et le TE la meacutethode laquoagileraquo On entend par agile

le fait que le TE se caracteacuterise par les deux caracteacuteristiques essentielles de lagiliteacute identifieacutee

dans (Boehm Turner 2004) La premiegravere eacutetant sa capaciteacute de reacutepondre ou de sadapter

rapidement aux changements du logiciel agrave tester (ltkonen ct Rautiainen 2005 Petty 2005

Lyndsay et van Eedcn 2003 Amland et Vaga 2002) La deuxiegraveme est la leacutegegravereteacute de la

documentation utiliseacutee ct produite pendal1t le TE

77

Le cadre proposeacute par Boehm et Turner (2004) est axeacute sur quatre dimensions agrave savoIr

Caracteacuteristiques dutilisations caracteacuteristiques de gestion caracteacuteristiques techniques et

caracteacuteristiques du personnel Or une meacutethode de test du logiciel doit ecirctre adapteacutee agrave un

contexte particulier (Craig et Jaskiel 2002 Perry 2000) Ce contexte se reacutesulte de

linteraction de plusieurs facteurs relieacutes aux objectifs principaux de lactiviteacute de test les

ressources financiegraveres techniques humaines et organisationnelles existantes Agrave cet effet le

cadre de comparaison de deux meacutethodes de test se composait de mecircmes dimensions citeacutees

par Boehm et Turner (2004) Notre cadre de comparaison va regrouper les axes de

comparaisons suivantes caracteacuteristiques d uti lisations caracteacuteristiques de gestion

caracteacuteristiques techniques et caracteacuteristiques de personnels Cependant il nous revient de

deacuteterminer les facteurs de comparaison associeacutes agrave chaque dimension De plus nous ajoutons

une cinquiegraveme dimension traitant la productiviteacute dc lactiviteacute de test puisque la veacuterification

dc la productiviteacute de TE est lun des objectifs principaux de ce travail de recherche Alors

notre cadre conceptuel de comparaison se constitue des dimensions et facteurs suivants

preacutesenteacutes dans les sections ci-dessous

621 Les caracteacuteristiques dutilisation

Selon Turner et Boehm (2004) les caracteacuteristiques dutilisations repreacutesentent les aspects et les

types de projets approprieacutes pour chaque approche du deacuteveloppement Ils ont identifieacute sous

cette dimension les facteurs suivants les objectifs principaux dutilisation de chaque

approche du deacuteveloppement la taille de projet du deacuteveloppement en termes de nombre de

personnes participants dans le projet la complexiteacute le volume du logiciel et le type

denvironnement daffaire ougrave se deacuteveloppe le projet Dans notre cas les caracteacuteristiques

dutilisation regroupent les facteurs suivants

bull Les raisons dutilisation ou les motivations pour utiliser chacune de deux approches de

tesl le TE ct le TS

bull Les caracteacuteristiques du logiciel agrave tester en termes de la taille de la complexiteacute et de la

crit ical iteacute

bull Le type denvironnement daffaire ougrave se produit le projet de test

78

bull Les ressources financiegraveres

bull Le temps disponible pour remplir lactiviteacute de test

622 Les caracteacuteristiques de gestion

Selon les auteurs Boehm el Turner (2004) les caracteacuteristiques de gestion deacutecrivent les faccedilons

de geacuterer Je projet du deacuteveJoppement dans Ies deux meacutethodes du deacuteveloppement agiles et

disciplineacutees Ils ont identifieacute sous cette dimension les facteurs suivants La planification et le

controcircle de projet de deacuteveloppement la relation avec Je client et la communication dans le

projet du deacuteveloppement Dans notre cas de recherche cette dimension de comparaison

regroupe les mecircmes facleurs discuteacutes par Boehm et Turner mais dans Je cadre de projel de

test Il sagit de la planification de tesl le controcircle et le suivi de la progression de test la

communication dans le projet de test el Ja relation avec le client

623 Les caracteacuteristiques techniques

Selon Boehm et Turner (2004) les caracteacuteristiqucs techniques deacutecrivent comment chacune de

deux meacutethodes du deacuteveloppement agile et disciplineacute abordent les eacutetapes essentielles du cycle

de deacuteveloppement du logiciel la speacutecification des exigences Je deacuteveloppement el le test

Dans notre cas cette dimension deacutecrit comment les deux approches de test le TE et le TS

abordent les eacutetapes essentielles de lactiviteacute de test Selon (Pyhajarvi el al 2003 Swebok

2004 Craig et Jaskiel 2002 Perry 2000) ces activiteacutes sont la planification de tests la

conception de tests lexeacutecution de tests Toutefois les activiteacutes de test deacutecoulent selon

(Bolton et aL 2005) de trois facteurs loracle de test les risques du logiciel agrave lester et la

couverture du test Ces eacuteleacutements seront donc discuteacutes sous cette rubrique

624 Les caracteacuteristiqucs du pClSonnel

Les auteurs Boehm et Turner (2004) abordent sous cette dimension les caracteacuteristiques du

personnel impliqueacute dans les projets de deacuteveloppement qui pouvaient favoriser JutiJisation de

chacune de deux approches de deacuteveloppement agile et disciplineacute Ils ont identifieacute les facteurs

suivants les caracteacuteristiques du client les caracteacuteristiques des deacuteveloppeurs et la culture de

lorganisation ougrave se deacuteroule le projet de deacuteveloppement Dans notre analyse comparative de

79

TE el le TS cette dimension ugravee comparaIson regroupe les facleurs suivants les

caracteacuteristiques des testeurs et la culture de lorganisation ougrave se deacuteroule le projet de test

625 La productiviteacute

Nous avons ajouteacute cette dimension agrave notre cadre vu limportance de cet aspect dans notre

travail de recherche Ce critegravere constitue le centre de cc travail de rechercbe agrave cause de la

productiviteacute du TE annonceacutee dans la litteacuterature surtout par les praticiens du CDS (Bach

2003 Kaner 2006) Les facteurs dc cette dimension sont le nombre de deacutefauts deacutetecteacutes et

limporlance de deacutefauts deacutetecteacutes par chacunc des dcux approches de test le TE et le TS Ces

facteurs de comparaison vont ecirctre traiteacutes dc dcux faccedilons theacuteoriquc cn se basant sur la

1itteacuterature et empirique ou expeacuterimenta le en se basant sur les reacute su hats dc notre eacutetude

cmplfJque

En reacutesumeacute notre cadre comparatif sc compose dcs dimensions et des facteurs de

comparaison illustreacutes sur la figurc 6)

80

Figure 61 Le cadre conceptuel de comparaison

1 Les raisons dutilisation 1 1

1 Les caracteacuteristiques du ~ 1 logiciel 1Les caracteacuteristiques

dutilisation 1 Le type denvironement daffaire1 1

1 Les ressources finacieacuteres 1 1

=-1 Le temps de test disponible 1

1 La planification ~ 1 1

1 Le controcircle et le suivi de progression de test1 1Les caracteacuteristiques

de gestion 1 La communication dans le 1 ~ 1 projet de test

1 La relation avec le client 1 1

1 Les activiteacutes de test 1 1

Les caracteacuteristiques

1 1

Les risques du logiciel 1

techniques 1 La couverture de test 1 1

1 ~ 1 Loracle de test

1

1 Les caracteacuteristiques du testeur1 1Les caracteacuteristiques

du personnel -J La c1uture de lorganisation 1

1 Le nombre de deacutefauts ~ 1 deacutetecteacutes 1

La productiviteacute 1 Limportance de deacutefauts

~ 1 deacutetecteacutes 1

81

63 Conclusion

Au cours de ce chapitre nous avons preacutesenteacute un cadre conceptuel de comparaison Nous

avons identifieacute et deacutefini dans ce cadre cinq dimensions principales de comparaison les

caracteacuteristiques dutilisation les caracteacuteristiques de gestion les caracteacuteristiques techniques

les caracteacuteristiques du personnel la productiviteacute Chacune de ces dimensions se deacutecompose

en plusieurs facteurs Ces facteurs vont nous servir dans notre analyse comparative du TE ct

du TS qui sera abordeacutee dans le chapitre qui suit

CHAPITRE VII

ANALYSE COMPARATIVE DU TEST EXPLORATOIRE ET DU TEST SCEacuteNARISEacute

Dans ce chapitre nous allons poursuIvre notre discussion plus en deacutetails sur les factcurs

influenccedilant ladoption et ladaptation de test exploratoire (TE) dans le cadre dune analyse

comparative des deux approches de test le test exploratoire (TE) et le test sceacutenariseacute (TS)

Nous COmparons les deux approches en se basant sur les facteurs deacutevaluation de notre cadre

conceptuel de comparaison que nous avons deacuteveloppeacute dans Je chapitre preacuteceacutedent Lobjectif

de ce preacutesent chapitre est didentifier les contextes de test ougrave le TE pourrait ecirctre utiliseacute en

remplaccedilant la meacutethode habituelle sceacutenariseacutee de test En terminant nous proposons un guide

de seacutelection de lapproche de test Ce guide reacutecapitule les reacutesultats de notre analyse

comparative et tente de baliser une deacutemarche danalyse pouvant ecirctre inteacutegreacutee agrave la reacuteflexion

strateacutegique des entreprises lors de choix de lapproche de test

71 Comparaison selon les caracteacuteristiques dutilisation

Dans cette section nous allons discuter les caracteacuteristiques dutilisation speacutecifiques pour

chacune des deux approches de test le TE et le TS Tout dabord nous aborderons les raisons

dutilisation de chacune des deux approches de test Puis nous discutons linfluence des

caracteacuteristiques du logiciel agrave tester sur le choix de lapproche de test Ces caracteacuteristiques

regroupent la taille du logiciel sa complexiteacute et sa criticiteacute Ensuite nous discuterons

linfluence de type denvironnement daffaire sur le choix de lapproche de test Finalement

nous aborderons linfluence des facteurs le temps de test disponible et les ressources

financiegraveres sur le choix de Japproche de test

711 Les raisons dutilisation

La raison principale de lutilisation du TE comme une approche primaire de test eacutetait pour

83

saccommoder agrave Jinstabiliteacute du logiciel deacuteveloppeacute etou labsence des exigences du logiciel

(Itkonen et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003 Amland et Vaga

2002) Ces eacutetudes ont montreacute que le TE sadapte agrave de telles situations Cette adaptation

se~plique par la possibiliteacute dutiliser le TE sans avoir besoin dutiliser les exigences du

logiciel En effet le TE nexige pas lexistence dexigences formelles du fait que les chal1es

de tests (le contenu de la mission de chaque session de test) pourraient ecirctre identifieacutees en

utilisant nimporte quelle source dinformation existante mises agrave part les exigences du

logiciel Les auteurs Kaner et Bach (2004) ont deacutecrit plusieurs reacutefeacuterences peuvent servir

pendant lidentification des chartes Souvent le manuel dutilisateur est utiliseacute pour identifier

ces chartes Ces chartes identifient seulement les grandes lignes de la mission de test agrave

accomplir Par conseacutequent lintroduction des changements sur le logiciel sous test ne

pourrait introduire que des mises agrave jour minimes au pire des cas comme lajout de nouvelles

chal1es correspondant aux nouvelles fonctionnaliteacutes ajouteacutees au logiciel

Parmi les principes de leacutecole CDS on retrouve que les projets se deacuteroulent souvent dune

maniegravere impreacutevisible Ceci implique que lapproche de test devrait sadapter agrave cette

impreacutevisibiliteacute A cet effet nous pouvons constater que lobjectif principal du TE est de

sadapter agrave Jimpreacutevisibiliteacute de projet de test du fait quil est baseacute sur les principes de CDS

La recherche meneacutee par les auteurs Itkonen et Rautiainen (2005) a deacutevoileacute dautres raisons

d uti lisation du TE agrave savoir premiegraverement la possibiliteacute de tester le systegraveme du point de vue

de lutilisateur autrement dit tester la combinaison de plusieurs sceacutenarios dutilisation du

logiciel Deuxiegravemement la difficulteacute de concevoir des cas de tests sceacutenariseacutes deacutetailleacutes agrave cause

de linterdeacutependance entre plusieurs uniteacutes logicielles Troisiegravemement la possibiliteacute

dexploiter la creacuteativiteacute et lexpertise des testeurs dans la deacutetection des deacutefauts imponants

Finalement la limitation du temps de test et les ressources financiegraveres disponibles

Par contre les raisons dutilisation de TS ne pourraient pas ecirctre deacutenombreacutees dans une liste

deacutetermineacutee de raisons dutilisation Du fait que le TS constitue toujours la meacutethode

habituelle et naturelle de test dans plusieurs entreprises Cependant nous avons constateacute

dapregraves notre revue de litteacuterature que Je TS ne saccommode pas facilement aux changements

84

du logiciel En effet nimporte quel changement dans le logiciel neacutecessite la mise agrave jour de

tous les artefacts de test deacutejagrave conccedilus toucheacutes par ce changement Leffort neacutecessaire pour

mettre agrave jour ces artefacts augmente proportionnellement avec laugmentation de niveau de

deacutetail de ces artefacts Lutilisation de standard de documentation IEEE 829 dans le TS

neacutecessite aussi un eff0l1 significatif pour mettre agrave jour les artefacts de test deacutejagrave conccedilus (Craig

et Jaskiel 2002 Petty 2005) Notant que le volume de modifications neacutecessaire accroicirct

propol1ionnellement avec le volume de changements introduit sur le logiciel Or avec la

culture rapide du deacuteveloppement du logiciel actuelle les praticiens tendent souvent agrave

commencer le deacuteveloppement du logiciel le plus tocirct possible avant que les exigences soient

stables et mucircries afin de reacuteduire le temps de mise en marcheacute Par la suite la probabiliteacute

dintroduire des changements ulteacuterieurs sur le logiciel est fort possible parfois assez

nombreux

Agrave cet effet nous pouvons constatcr que la stabiliteacute de projet du deacuteveloppement pourrait ecirctre

lune des raisons essentielles pour utiliser le TS Notant que mecircme le TE pourrait ecirctre utiliseacute

dans ce type de projet Dans une telle situation dautres facteurs pourront influencer le choix

de lapproche convenable dc tcst agrave saVOir ladoption de lorganisation du modegravele

dameacutelioration de processus logicicl comme le CMMI (Capability Maturity Model

Integration) Dans ce genre dc processus la documentation ct la mesure constituent des

eacuteleacutements fondamentaux Par conseacutequent Je TS constitue le choix ideacuteal dans ce type de projet

de deacuteveloppement Le domaine daffaire de quelques types de projet du deacuteveloppement exige

lutilisation de TS Autrement la neacutecessiteacute dune documentation deacutetailleacutee de Jactiviteacute de test

exige lutilisation de TS comme les projets de test dapplications critiques par exemple Par

la suite le besoin de documentation de processus de test pourrait ecirctrc lune des raisons pour

utiliser le TS

Nous concluons de cettc discussion que Je TE est plus approprieacute dans les projets dc

deacuteveloppement instables gracircce agrave sa grande capaciteacute dadaptation agrave limpreacutevisibiliteacute de projet

dc test Tandis que Je TS est plus approprieacute dans les projets dc deacuteveloppement stables et qui

ont besoin de documenter et mesurer lactiviteacute de test

85

712 Les caracteacuteristiques du logiciel

7121 La taille du logiciel

Il apparaicirct que le TE est plus approprieacute dans les petits et moyens projets de test Cest agrave dire

le test des petites et moyennes applications Cela sexplique par leffort neacutecessaire pour la

gestion et le controcircle de TE En effet la gestion de TE neacutecessite que le responsable de test

deacutebriefe chaque testeur apregraves lexeacutecution de chaque session de test afin d eacuteva luer et

dapprouver les reacutesultats de la session Or ceci ne semblait pas ecirctre facile dans une grande

eacutequipe Nous avons constateacute ceci agrave travers les travaux de la litteacuterature que nous avons

preacutesenteacute dans le chapitre IV Alors tous les logiciels qui ont eacuteteacute lobjet des eacutetudes de cas

eacutetaient des petites applications deacuteveloppeacutees par des petites ou moyennes entreprises (ltkonen

et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003 Amland et Vaga 2002)

Selon Lyndsay et van Eeden (2003) la collaboration et le partage ues connaissances entre les

membres de leacutequipe de test peuvent ameacuteliorer la qualiteacute de TE effectueacute Cependant nous

croyons que la collaboration est plus facile entre les membres dune petite eacutequipe de test

quentre les membres dune grande eacutequipe

Par contre le TS est plus approprieacute dans les grands projets de test associeacutes agrave des grands

projets du deacuteveloppement En effet dans ces projets le projet de test constitue souvent un

sous projet organiseacute et geacutereacute seacutepareacutement du projet de deacuteveloppement du logieiel (Pyhajarvi et

al 2003) Agrave cet effet la planification et la documentation sont les moyens de gestion et de

communication agrave linteacuterieur et agrave lexteacuterieur de projet de test Sajoute agrave ceci le fait que les

grands projets puissent seacutetaler sur plusieurs mois Par la suite la meacutemorisation et

lenregistrement des cas de test sont neacutecessaires afin de maintenir et tester lapplication dans

les phases ulteacuterieures du deacuteveloppement dune faccedilon rentable (Beizer 1990)

Nous concluons que le TE est plus approprieacute dans les petits et moyens projets de test cest-agraveshy

dire le test des petits et moyens logiciels Tandis que le TS est plus approprieacute dans les grands

projets de test cest-agrave-dire pour les grands logiciels

86

7122 La complexiteacute du logiciel

La complexiteacute du logiciel fait reacutefeacuterence agrave la difficulteacute de compreacutehension et dappreacutehension du

logiciel Autrement dit la compreacutehension du logiciel nest pas agrave la porteacutee de tous les testeurs

dans le projet Par exemple un logiciel qui impleacutemente une nouvelle technologie Alors le

TE ne semblait pas le meilleur choix dans cette situation puisque lapprentissage et

lappreacutehension du logiciel neacutecessaires pour remplir lactiviteacute de TE ne pourront pas ecirctre agrave la

porteacutee de tous les testeurs dans le projet de test Le TS pourrait ecirctre la meilleure strateacutegie

dans ce cas de test du fait que les cas de tests pourraient ecirctre conccedilus par des experts dans la

technologie impleacutementeacutee et exeacutecuteacutes par des testeurs novices

Il faut noter que parfois les logiciels complexes se deacuteveloppent en collaboration entre

plusieurs compagnies (Kaner et al 1999) Dans une telle situation le TS repreacutesente le bon

choix surtout sil est documenteacute par le standard de la documentation IEEE 829 La

documentation de lactiviteacute de test permet de veacuterifier et dinspecter formellement la qualiteacute

de test effectueacute au niveau de chaque entreprise participante dans le deacuteveloppement du

logicieL Le standard IEEE 829 peut introduire un protocole commun de communication entre

les entreprises paJ1icipantes dans le projet du deacuteveloppement (IEEE829 1998)

Nous concluons que le TS est plus approprieacute dans les projets de test de logiciel complexe

Tandis que lutilisation de TE dans tels projets deacutepend des compeacutetences ct de leXpeJ1ise des

testeurs impliqueacutes dans le projet

7123 La criticaliteacute du logiciel

En ce qui concerne le test des logiciels critiques seulement le TS pourrait ecirctre utiliseacute En

effet pour les logiciels critiques comme les logiciels temps reacuteel ou embarqueacutes seulement les

meacutethodes seeacutenariseacutees peuvent ecirctre utiliseacutees Lun des eacuteleacutements essentiels de ces meacutethodes de

tests est la documentation deacutetailleacutee de lactiviteacute de test Cette documentation fera lobjet de

plusieurs eacutevaluations et inspections afin de sassurer de la qualiteacute de lactiviteacute de test

effectueacutee Dans certaines situations la documentation ct lactiviteacute de test devront suivre des

normes et des standards speacutecifiques dans quelques domaines daffaires Nous avons constateacute

87

ce fait agrave travers leacutetude ugravee cas ugravee James et Wood (2003) preacutesenteacute dans le chapitre IV Les

deux auteurs ont utiliseacute le TE comme une meacutethode compleacutementaire agrave Japproche sceacutenariseacutee

habituelle Cette derniegravere devait suivre les normes de qualiteacute du systegraveme (Quality System

Regulation) dans le domaine de construction dappareils meacutedicaux

Il faut rappeler que mecircme Bach et al (2002) ont signaleacute que les pnnclpes et les leccedilons

preacutesenteacutes dans (Bach et al 2002) de leacutecole de penseacutee Context Driven School (CDS)

concernent les logiciels commerciaux seulement Agrave cet effet nous croyons que le TE

sapplique lui aussi agrave ce type de logiciels du fait quil est baseacute sur les mecircmes principes de

leacutecole

Nous concluons de cette discussion que seule le TS pourrait ecirctre utiliseacute dans le test des

logiciels cri tiques

713 Le type denvironnement daffaire

Le type denvironnement daffaire pourrait influencer le choix de lapproche de test entre le

TE et le TS Dapregraves notre revue de litteacuterature nous avons constateacute que le TE sadapte

faci lement aux changements du logiciel agrave tester Par la suite nous pouvons constateacute que le

TE est plus approprieacute dans les environnements dynamiques Le dynamisme fait reacutefeacuterence au

dynamisme de la technologie utiliseacutee dans le deacuteveloppement du logiciel ouet de la volatiliteacute

des besoins du client Agrave linverse le TS ne sadapte pas facilement aux environnements

dynamiques De fait que la maintenance des artefacts de test neacutecessite du temps et des

ressources financiegraveres consideacuterables qui ne sont pas souvent disponibles dans la pratique du

test surtout dans les petites ct moyennes entreprises Dailleurs nous avons constateacute cela agrave

travers notre revue de litteacuterature La deacutecouverte et lutilisation de TE ont eacuteteacute motiveacutees dans la

plupart des eacutetudes de cas que nous avons preacutesenteacutees par lincapaciteacute de TS agrave reacutepondre aux

besoins des praticiens dans la limite du temps ct des ressources disponibles (Petty 2005

Amland et Vaga 2002)

Le TS sadapte tregraves bien aux environnements stables Dans ces environnements les artefacts

de test peuvent ecirctre speacutecifieacutes tocirct dans le processus du deacuteveloppement dans la limite des

88

ressources disponibles et aucun coucirct suppleacutementaire de changement nest neacutecessaire Le TS

est plus approprieacute aussi dans dautres types denvironnements daffaires comme les logiciels

eacutevolutifs et les logiciels deacuteveloppeacutes sous contrat Dans ce type denvironnements le plan de

test et les cas de tests uevraient ecirctre Jivreacutes avec le logiciel Parfois le client deacutetermine et

neacutegocie la structure le format et le niveau de deacutetail de ces artefacts dans le contrat Il pourrait

exiger lutiliseacuteltion de la norme de documentation IEEE 829 dans quelques situations (Kaner

et al 1999)

Les logiciels deacuteveloppeacutes dans quelques domaines dindustrie exigent Jutilisation de TS agrave

cause de la neacutecessiteacute dune documentation deacutetailleacutee de processus de test Souvent cest le cas

dans le test des logiciels qui peuvent causer des pertes importantes en cas de deacutefaillance du

logiciel dans le site de production Alors la documentation de test pourrait constituer un outil

de deacutefense dans les causes judiciaires (Kaner et al 1999)

Nous pouvons conclure de cette analyse que le TE est plus approprieacute dans les

environnements dynamiques Par contre le TS est plus approprieacute dans les environnements

stables eacutevolutifs ou sous contrat et ceux qui neacutecessitent la documentation deacutetailleacutee du

processus de test

714 Les ressources financiegraveres

Nous avons constateacute dapregraves notre revue de lilteacuterature que les ressources financiegraveres

disponibles dans Je projet de test jouent un rocircle important et crucial dans le choix de

lapproche de test (ltkonen et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003

Amland Vaga 2002)

Le TS neacutecessite des ressources financiegraveres importantes La preacuteparation la conception des cas

de tests et la documentation du processus de test occasionnent des frais significatifs En effeL

leffort neacuteccssaire en nombre de personnesjours pendant le processus de test est plus grand

en TS quen TE Ce fait empecircche lutilisation de TS quand le budget de test est serreacute

(Lyndsay van Eeden 2003) Contrairement le TE ne neacutecessite pas une documentation

rigoureuse pendant le processus de test agrave pm1 un investissement minime dans le processus

didentification des cbaI1es de tests La moindre coucirct dc TE a eacuteteacute signaleacute par les praticiens qui

89

ont utiliseacute lapproche dans lindustrie de test (Petty 2005 Lyndsay Van Eeden 2003 James

Wood 3003)

Cependant la diffeacuterence dans les coucircts entre le TE et le TS apparaicirct clairement lors de

lintroduction des changements sur le produit sous test Alors la maintenance des artefacts de

tests sceacutenariseacutes a un coucirct suppleacutementaire qui augmente en fonction du volume de

changements introduits Par contre le changement du logiciel dans une activiteacute de TE ne

pourrait geacuteneacuterer que quelques changements sur les chartes existantes tel que lajout des

nouvelles chartes Par la suite le TE ne geacutenegravere pas des coucircts suppleacutementaires importants

comme le TS En fait le coucirct moindre de TE eacutetait le principal motif de la deacutecouverte et de

lutilisation de cette approche par les professionnels et les praticiens dans lindustrie de test

(Petty 2005 Amland Vaga 2002)

Nous concluons de cette discussion que le TE est plus approprieacute dans les projets de test agrave

ressources financiegraveres limiteacutees Tandis que le TS est plus approprieacute dans les projets de test

qui ont des ressources financiegraveres importantes pour suppol1er ses frais

715 Le temps de test disponible

Le temps disponible pour accomplir lactiviteacute de test est lun des facteurs essentiels pouvant

influencer le choix de lapproche de test (ltkonen et Rautiainen 2005 Petty 2005 Lyndsay

et van Eeden 2003 Amland Vaga 2002) Le TS neacutecessite du temps consideacuterable pour la

planification et la conception des cas de tests avant Je deacutebut de Jexeacutecution physique des tests

Toutefois avec la tendance preacuteventive actuelle de test du logiciel la planification et la

conception de cas de tests sceacutenariseacutes peuvent commencer degraves le deacutebut de projet du

deacuteveloppement parallegravelement avec limpleacutementation du logiciel Agrave cet effet il y a toujours

suffisamment de temps pour planifier et preacuteparer les cas de tests sceacutenariseacutes Le problegraveme de

temps se pose lors de Jintroduction de changements sur le logiciel ulteacuterieurement dans le

cycle du deacuteveloppement cest-agrave-dire le changement de la conception du logiciel apregraves

leacutelaboration des cas de tests associeacutes agrave celle-ci Dans ce cas le temps neacutecessaire pour mettre

agrave jour les artefacts de test deacutejagrave conccedilus ct le temps disponible pour tester le logiciel pourrait

avoir une incidence sur le deacuteroulement normal de Jactiviteacute de lest qui peul changer

90

subtilement vers un test ad hoc ou dans la meilleure des cas au TE En effet la preacuteparation

des cas de tests tocirct dans le processus nest pas toujours fructueuse parce que les exigences ne

sont pas toujours stables au deacutebut du projet de deacuteveloppement Par la suite la planification et

la preacuteparation des cas de tests en se basant sur ces speacutecifications changent souvent et geacutenegraverent

des modifications et des mises agrave jour eacutenormes Aussi lemplacement des testeurs agrave la fin de

la chaicircne du deacuteveloppement cest-agrave-dire sur Je chemin critique de livraison du logiciel

sajoute au problegraveme que nous venons de citer Alors les testeurs accumulent les retards faits

au deacutebut de la chaicircne du deacuteveloppement et se retrouvaient souvent dans des situations

difficiles ougrave ils doivent faire de compromis entre le temps disponible pour le test la qualiteacute

attendue du logiciel et le budget Dans de telles situations souvent les praticiens renoncent

aux cas de tests sceacutenariseacutes et sen remettent au TE (Petty 2005 Bach et al 2002) Le TE leur

permet dinvestir le temps disponiblc dans le test du logiciel au lieu de mettre agrave jour les cas

de tests sceacutenariseacutes Selon Bach et al (2002) la preacuteparation des cas de tests pendant la phase

de conception du logiciel est une perte du temps du fait que ces cas de tests pourraient ecirctre

deacutesuets ulteacuterieuremcnt dans le cyclc du deacuteveloppement

Par contre le TE nc neacutecessite pas beaucoup du temps pour la preacuteparation de cha11es de test ]]

suffi t que le responsable de test preacutepare les chartes de tests en se basant sur nimporte quelle

source dinformation disponible (Kaner et Bach 2004) Nous pouvons dire quc cest

eacutequivalent agrave la preacuteparation dun plan de test selon le patron IEEE 829 puisque lobjectif dans

les deux cas est didentifier ce qui doit ecirctre testeacute les responsabiliteacutes lestimation de leffort

neacutecessaire pour remplir chaque mission dans le processus de tcst Notons quavant

lintroduction de la technique Session Based Exploratory Testing (SBET) Amland et Vaga

(2002) ont utiliseacute un plan de test sceacutenariseacute pour identifier les chartes des sessions de tests

exploratoires

Nous concluons de cette discussion que le TE est plus approprieacute dans les projets de test ougrave il

ya peu de temps pour le tcst surtout si les ressources financiegraveres ne permettent pas dajouter

de personnel ou de fairc dautres contingences Tandis que le TS est plus approprieacute dans les

projets de test ougrave il ya suffisamment de temps pour la preacuteparation ct la planification de test

91

72 Comparaison selon les caracteacuteristiques de gestion

Dans cette section nous abordons les eacuteleacutements principaux de gestion de lactiviteacute de test dans

les deux approches de test le TS et le TE Il sagit de la planification de test le controcircle et le

suivi de la progression de test la communication dans le projet de test et la relation avec le

client

721 La planification

Selon Joffice queacutebeacutecois de la langue franccedilaise la planification est un ensemble de deacutecisions

ayant pour but deacutetablir un ordre dapplication ugravees actions avant leur exeacutecution Dans cette

section nous allons discuter comment Ics deux approches abordent la planification en se

basant sur eelle deacutefinition

En ce qui concerne le TS lactiviteacute de test est piloteacutee par le plan de test eacutelaboreacute au deacutebut du

projet de test Ce plan situe les activiteacutes de test dans la strateacutegie globale de livraison du

logiciel La preacuteparation de plan dc test pcut commencer au moment de la formulation des

besoins et se deacuteveloppcr et se raffiner pendant la phase de conception du logiciel Cela

sinclut dans le cadre de test preacuteventif Ce type de test dicte que la planification de TS peut

preacutevenir les erreurs dans la phase de conception avant que celles ci se transforment agrave des

deacutefauts dans le code (Craig et Jaskiel 2002 Perry 2002 Swebok 2004) Alors du processus

de planification reacutesulte le plan de test Ce plan deacutecrit les items et les caracteacuteristiques

(fonctionnaliteacute performance utilisabiliteacute etc) qui devraient ecirctre testeacutes les caracteacuteristiques

qui ne devraient pas ecirctre testeacutees les responsabiliteacutes les livrables les besoins

environnementaux et leacutecheacuteancier du projct de test Par la suite tous les deacutetails des tests sont

identifieacutes et rigoureusement planifieacutes avant le deacutebut de leur exeacutecution En fait le plan de test

dans une activiteacute de TS vise deux objectifs essentiels le premier la planification de lactiviteacute

de test Je deuxiegraveme leacutetablissement des canaux de communications entre les intervenants agrave

linteacuterieur et lexteacuterieur du projet de test Selon (IEEE 829 1998) lutilisation de standard

IEEE 829 pourrait ameacuteliorer la qualiteacute de ces canaux de communication

Le TE introduit lui aussi la planification mais avec un rocircle et une signification diffeacuterents Au

deacutebut de lactiviteacute de test le responsable de test identifie une liste des items agrave tester Ces

92

itcms constituent les chartes de tests (deacutejagrave eacutevoqueacute dans le chapitre III) Cependant il ne sagit

pas dune identification complegravete de toutes les chal1es avant le deacutebut de lexeacutecution de test

mais dune planification preacuteliminaire agrave quelques chartes de test en se basant sur les

informations disponibles au deacutebut du projet de test Ce plan sameacuteliore pendant le

deacuteroulement du projet de test gracircce aux notes reacutesu hant de Jexeacutecution de chartes de test

Autrement dautres chartes de test sajoutent au fur et agrave mesure que les chartcs preacuteliminaires

sexeacutecutent En effet pendant lexeacutecution de charte de test le testeur peut explorer nimpone

quel panie du logiciel et rapporter ses constations el ses observations dans les notes de

session ce que Jonathan Bach (2000) appelle laquoOpportuniteacuteraquo Ces notes font lobjet dune

eacutevaluation avec le responsable de test Suite agrave cette eacutevaluation le responsable de test pourrait

ajouter des nouvelles chartes correspondant et mettre agrave jour le plan de chartes Selon James

et Wood (2003) la planification de TE est une planification continue (Figure32) Dans la

mecircme perspective Copeland (2003) classifie la planification de TE comme une planification

adaptative qui se change agrave chaque moment agrave la venue de nouvelles informations pendant le

processus de test alors que la planification sceacutenariseacutec est une pIani fication classique qui

identifie toutes les actions et les deacutetails de test avant lexeacutecution de ces actions

Nous pouvons constater que la planification dans une activiteacute de TE constitue un moyen de

controcircle et dencadrement de processus En fait il nc sagit pas dune planification telle

quelle est deacutefinie par le dictionnaire ougrave toutes les actions devraient ecirctre speacutecifieacutees avant leur

exeacutecution Mais cest une planification introduite par Jonathan Bach (2000) pour geacuterer

lactiviteacute de test et introduire le controcirclc ct la mesure sur le TE libre Donc il sagit dune

planification qui vise lexeacutecution de la mission de test du logiciel plutocirct que la documentation

ct larchivage en texte Nous pouvons constater aussi que la planification de TS est plus

cenaine et rigoureuse que la planification de TE En effet la planification de TS tend agrave

preacuteciser tous les deacutetails fins du processus de test avant le deacutebut de Icur exeacutecution tandis que

le TE tend agrave preacuteciser Jessentiel du processus de test et compte sur Jexploration des testeurs

pendant lexeacutecution des sessions de test pour raffiner et ameacuteJiorcr le plan initial

Nous concluons de cette discussion que Ic TS est plus approprieacute dans les projcts de test qui

neacutecessitent une planification cel1aine et rigoureuse de lactiviteacute de test Par exemple les

93

situations ougrave la plate-forme de test est disponible seulement par intermittence Comme un

projet client serveur ougrave les serveurs configureacutes devraient ecirctre partageacutes par lactiviteacute de test et

le deacuteveloppement La logistique dune telle situation peut exiger lutilisation de TS qui

pourrait fournir une planification rigoureuse de lactiviteacute de test pour profiter au maximum du

temps limiteacute pour les tests (Bach 2003) Par contre le TE est plus approprieacute dans Ics projets

de test flexibles

722 Le controcircle et le suivi de progression de test

Lobjectif de controcircle et du suivi du test est de foumir un retour et une visibiliteacute sur les

activiteacutes de test Les informations agrave suivre peuvent ecirctre recueillies manuellement ou

automatiquement et peuvent ecirctre utiliseacutees pour eacutevaluer les critegraveres de sonies comme la

couvenure de test Des mesures peuvent aussi ecirctre utiliseacutees pour eacutevaluer lavancement par

rapport au ca lendrier et au budget planifieacutes

Selon Craig et JaskieJ (2002) le controcircle et le suivi du test sont panni les problegravemes auxquels

le responsable devrait faire face dans un projet de test Alors le responsable devrait trouver

une meacutethode pour retracer ou suivre le deacuteroulement de lactiviteacute de test Par la suitc il devrait

ecirctre capable de faire un rapport sur le statut des tests agrave nimporte que 1 moment tant que le

produit est toujours sous test ]1 devrait aussi pouvoir reacutepondre aux questions typiqucs qui se

posent reacuteguliegraverement pendant les tests

bull Comment se deacuteroulent les tests

bull Quel est le pourcentage des tests accomplis

bull Qucl est le pourcentage des tests reacuteussis

Le TS se precircte tregraves bien agrave la mesure Un nombre total de cas de tests peut ecirctre calculeacute et une

meacutetrique de test peut ecirctrc creacuteeacutee mesurant par exemple Je pourcentage des cas de tests qui ont

eacuteteacute exeacutecuteacutes Des meacutethodes speacutecifiques proposeacutees dans la 1illeacuterature permellent de mesurer la

progression de lactiviteacute de TS et de preacutevoir la date de livraison du logiciel en se basant sur le

nombre de cas de tests restants avant la compleacutetude de lactiviteacute de test (Kan 2001 Craig et

Jaskiel 2002)

94

Quant au TE les mesures collecteacutecs pendant le test et le deacutebriefing permettent destimer la

productiviteacute ou le rendement de chaque membre de leacutequipe de test pendant le projct de test

en cours Cela avec le nombre de sessions compleacuteteacutees pourrait aider dans lestimation de la

quantiteacute du travail restant avant la fin du cycle de test (Jonathan Bach 2000) Notons que le

sujet du controcircle de la progression nest pas toujours bien abordeacute dans la litteacuteraturc agrave part ce

meacutecanisme proposeacute par Jonathan Bach (2000) Toutefois ce meacutecanisme aide sculcmcnt dans

leacutelaboration dune estimation de la quantiteacute du travail restant avant la fin du cycle dc test Il

ne sagit que dune estimation la preacutevision se basant sur cette estimation eacutetant incertaine

Nous pouvons conclure de cette discussion que le controcircle et le suivi de la progression de test

dans le TS est mesurable alors quil nest quun estimeacute En conseacutequence nous concluons que

le TS est plus approprieacute dans les projets de tests qui ont un eacutecheacuteancier fixe alors que le TE

est approprieacute dans les projets de test qui ont un eacutecheacuteancier flexible et toleacuterant au retard qui

pourrait reacutesulter dune mauvaise estimation

723 La communication dans le projet de test

Le TE mise fOl1ement sur les connaissances tacites et sur les compeacutetenccs interpersonnelles

Comme nous avons deacutejagrave vu dans la revue de litteacuterature le TE est baseacute sur les connaissances

tacites du testeur et son expertise (Itkonen et Rautiainen 2005 Petty 2005 Lyndsay ct van

Eeden 2003 Wood et James 2003) Les compeacutetences interpersonnelles jouent aussi un rocircle

important dans la qualiteacute du travail (Lyndsay et van Eeden 2003) la communication eacutetant

essentielle dans le TE Nous avons constateacute dapregraves notre revue de litteacuterature que la

communication et leacutechange des connaissances interviennent de diffeacuterentes faccedilons dans le

TE La premiegravere est Je partage des connaissances entre le testeur et dautres intervenants hors

de leacutequipe de test comme le client En effet le testeur chargeacute de lexeacutecution dune mission

de TE pourrait collecter les informations neacutecessaires sur le logiciel agrave tester agrave paI1ir des

reacuteunions ou des discussions avec diffeacuterents intervenants dans le projet de deacuteveloppemcnt du

logiciel agrave tester afin de comprendre et dapprcndre le logiciel el ses caracteacuteristiques

fonctionnelles (Kaner et Bach 2004)

La deuxiegraveme forme dc communication est entre testeurs et responsablc du test Ce dcmier

devrait deacutebriefer chaquc testeur apregraves Jexeacutecution dc chacune des chartes dc test pour eacutevaluer

95

le travail accompli Alors pendant le deacutebriefing le responsable pourrait eacutechanger ses

connaissances avec le testeur pour le guider (Jonathan Bach 2004 Lyndsay et van Eeden

2003) La communication pourrait aussi prendre la forme dune collaboration entre les

testeurs La communication entre les membres de leacutequipe de test pourrait ameacuteliorer la

qualiteacute de TE effectueacute En effet de bons canaux de communication permettent deacutechanger les

expeacuteriences et les connaissances dans leacutequipe de faccedilon agrave ce que les membres plus

expeacuterimenteacutes aident et encadrent les membres moins expeacuterimenteacutes (Lyndsay et van Eeden

2003)

La troisiegraveme forme deacutechanges des connaissances peut apparaicirctre pendant la session de test

entre deux personnes qui se chargent de lexeacutecution de la mecircme mission de test deacutefinie sous

le terme de laquotest par pairesraquo Nous avons noteacute cela agrave travers les eacutetudes de cas que nous avons

proposeacute dans la revue de litteacuterature parfois entre deux testeurs (Amand et Vaga 2002) ou

entre un testeur et un deacuteveloppeur (Petty 2005)

Le TS au contraire se mise beaucoup sur les connaissances explicitement documenteacutees La

communication entre les praticiens dans le projet de test est centreacutee autour dcs livrables bien

deacutetermineacutes En effet souvent les testeurs chargeacutes de la conception (testeurs seniors)

communiquent avec les testeurs chargeacutes de lexeacutecution des tests (testeurs juniors) par les

proceacutedures de test Ces derniers communiquent reacuteciproquement par les rapports dincidents

En ce qui concerne la communication entre les testeurs et les deacuteveloppeurs dans la plupart

des cas la communication se fait agrave travers laquole Bug Traeking System raquo le systegraveme qui

enregistre les deacutefauts deacutetecteacutes Nous notons que dans quelques situations il regravegne une

relation difficile entre les deacuteveloppeurs et les testeurs (Bach et al 2002) du fait que les

deacuteveloppeurs sentent que les testeurs deacutetruisent leur travail et se sentent responsables des

deacutefaillances deacutetecteacutees

Nous pouvons conclure que la gesti on de TE se fonde sur la communication entre les

intervenants dans le projet de test mecircme la qualiteacute des tests effectueacutes deacutepend de la qualiteacute de

communication entre le responsable des tests et les testeurs tandis que la gestion dans le TS

se fonde sur la documentation

96

En conseacutequence il semble que les contextes supportant la communication informelle sont

plus approprieacutes et favorables au TE

724 La relation avec le client

Selon Kaner et Bach (2004) la conversation avec le client pourrait ecirctre une source

dinformation importante pour la compreacutehension et lappreacutehension du logiciel dans une

activiteacute de TE Agrave cet effet une bonne relation avec le client est essentielle dans le TE Par

contre celte relation nest pas neacutecessaire dans une activiteacute de TS du fait que les cas de test

sont conccedilus agrave partir des exigences du systegraveme Cependant il est faux de dirc que celte

relation entre le testeur et le client nest pas souhaiteacutee dans le TS Selon Craig et Jaskiel

(2002) le client peut jouer un rocircle important dans lactiviteacute de TS par la participation dans les

reacuteunions didentification de la liste des risques du logiciel Ceci pourrait optimiser et orienter

lactiviteacute de test vers les risques importants du logiciel

Nous concluons de celte discussion quune bonne relation avec le client est essenticllc dans le

TE et pourrait ameacuteliorer la compreacutehension du logiciel Par contre elle est souhaiteacutee ct non

obligatoire dans le TS

73 Comparaison selon les caracteacuteristiques techniques

Nous allons discuter dans cette section des caracteacuteristiques techniques de deux approches de

test le TE et le TS Ces caracteacuteristiques portent sur le processus de test les activiteacutes de test

les artefacts creacutees et les eacuteleacutements neacutecessaires pour le bon deacuteroulement de test Nous allons

cssayer de deacuteceler comment les deux approches de test le TE et le TS abordent chaquc eacutetapc

de lactiviteacute de test Selon (Swebok 2004 Pyhajarvi ct aL 2003 Craig et Jaskicl 2002

Perry 2000) les activiteacutes de test comportent les eacutetapes suivantes la planification la

conception dc tests et lexeacutecution de tests Toutefois ces activiteacutes sont influenceacutees selon

(Bolton 2005) par trois facteurs agrave savoir les risqucs du logiciel Joracle de tcst ct la

couverture de test tel quillustreacute sur la figure 71

97

Figure 71 Les eacuteleacutements essentiels du test du logiciel (Bolton Kaner et Bach 2005)

Les risques du logiciel

Les activiteacutes de test 1 La couvertu~ Ee d~ t~)

731 Les activiteacutes de test

En ce qui concerne le TS les cas de test sont conccedilus au deacutebut de lactiviteacute de test

principalement agrave partir des exigences du logiciel Chaque cas de tcst devrait ecirctre sous le

controcircle de la gestion de configuration du logiciel et inclure les reacutesultats preacutevus dc chaque

test (Swebok 2004 Perry 2000 Hetzel 1988) La conception ct la planification pourraient

commencer en parallegravele avcc le projet de deacuteveloppement

Tel quillustreacute agrave la figure 72 la preacuteparation de plan de test et des cas de test se font par le

testeur souvent un testeur senior en utilisant les entreacutees speacutecifiques de projet de test en

cours Alors ces entreacutees peuvent inclure les exigences du logiciel les standards ct les normes

agrave respecter qui varient selon le domaine de test Dans certaines situations le test peut ecirctre

guideacute par divers objectifs comme les risques du logiciel ou les cas dutilisations pour

identifier les prioriteacutes de test et focaliser sa strateacutegie (Swebok 2004) Quant aux tcchniques

de tesl elles sont choisies selon la nature du logiciel sous test lefficaciteacute et la preacutecision

souhaiteacutees (Craig el Jaskiel 2003 Biezer J990)

Sajoutenl agrave ces entreacutees citeacutees ci dessus les compeacutetences et les quaI ifications du testeur

senior chargeacute de la conception de tests ses connaissances comme les connaissances du

98

domaine du logiciel agrave tester ses expeacuteriences anteacuterieures ses connaissances techniques et ses

qualiteacutes personnelles Linteraction de toutes les entreacutees permet didentifier le plan et les cas

de test Le pourcentage de cOLlvel1ure de test atteint pourrait ecirctre mesureacute agrave cc niveau du

processus de test agrave laide de a matrice de traccedilabiliteacute figure 2

Figure 72 Les activiteacutes de test sceacutenariseacute (Adapteacute et traduit de Bach 2006)

Les entreacutees Les connaissances du domaine Les sorties Les expeacuteriences anteacuterieures Les connaissances techniques Les qualiteacutes personnelles

Les Les cas Le plan

risques dutilisations de test

Les Les standards Les cas de

exigences tests

Les techniques de La couverture Seacuteparation dans le temps

tests et fou dans lespace

Les entreacutees Les sorties

Rapports

Les cas de dincidents tests

Systegraveme sous test

99

Les cas de tests sont souvent exeacutecuteacutes ulteacuterieurement par des testeurs juniors quand le

logiciel devient disponible pour le test Ces testeurs se chargent de Jexeacutecution des proceacutedures

de test Ces derniegraveres deacutecrivent tous les deacutetails fins neacutecessaires agrave lexeacutecution des tests

incluant les reacutesultats preacutevus comme nous lavons deacutejagrave proposeacute dans le chapitre II Il suffit

que les testeurs comparent les reacutesultats preacutevus et les reacutesultats observeacutes En cas dapparition

dune deacutefaillance le testeur rapporte les reacutesultats dans le rapport dincident preacutevu agrave cet effet

selon la norme IEEE 829

Figure 73 Les activiteacutes de test exploratoire (Adapteacute et traduit de Bach 2006)

Les entreacutees Les connaissances du domaine Les sorties Les expeacuteriences anleacuterieures Les connaissances techniques Les qualiteacutes personnelles La charte de

session

Rapport de session Nimporte quelle

documentation existante o Les Deacutefauts

les exigences le manuel

dutilisateur E-mail o Les notes

Les techniques de o Ips nrnhlpmls

test

Systegraveme sous test

Par contre tel quillustreacute agrave la figure 73 les cas de tests de TE sont conccedilus pendant le test En

effet le testeur reccediloit en entreacutee la charte de la session de test qui identifie les grandes lignes

de sa mission de test Il doit sinformer sur le logiciel en utilisant nimporte quelle source

dinformation existante dans le projet de test en cours comme Je manuel dutilisateur des

discussions avec le client et les deacuteveloppeurs et dautres Par la suite il doit identifier les

techniques convenables de test Parfois ces techniques de test peuvent ecirctre mentionneacutees dans

la charte de test selon la complexiteacute ct le risque ditems agrave tester traiteacutes dans la charte Alors

100

pendant lexeacutecution de sa mission le testeur apprend explore conccediloit et exeacutecute les tests

(Bach 2003) Chaque cas de test beacuteneacuteficie de (information obtenue de tests anteacuterieurs et la

maturiteacute des connaissances accumuleacutees agrave chaque moment de lactiviteacute de test (Bach et aL

2002) Les reacutesultats de la session de test sont rapporteacutes dans le rapport de la session Ce

rapport fera lobjet dun deacutebriefing avec le responsable de test afin de valider le travail

effectueacute par le testeur

Nous concluons de cette discussion que le TS est plus approprieacute dans les projets de test

favorisant la reacutepeacutetitiviteacute et lauditabiliteacute de tests Par contre le TE est plus approprieacute dans les

projets de test favorisant la creacuteativiteacute et ladaptabiliteacute agrave chaque moment de processus de test

732 Les risques du logiciel

Selon le dictionnaire de loffice queacutebeacutecois de la langue franccedilaise le risque informatique est la

probabiliteacute plus au moins grande de voir une menace informatique se transformer en

eacuteveacutenement reacuteel entraicircnant une perte II se mesure agrave la fois par la probabiliteacute doccurrence

dune menace et par limpact de sa reacutealisation Dans la litteacuterature de test du logiciel le risque

du logiciel se deacutefinit comme la probabiliteacute doccurrence et limpact de la reacutealisation dune

deacutefaillance dans le logiciel (Craig et ]askiel 2002 Lyndsay et van Eeden 2003)

Limpossibiliteacute de test complet du logiciel (Pressman 1997 Kaner 1997 Hetzel 1988) et

les cycles de deacuteveloppement de plus en plus courts ont pousseacute les intervemmts dans le

domaine de test du logiciel agrave chercher des techniques leur permettant dexploiter le temps

consacreacute au test dune faccedilon optimale telle que lanalyse de risque du logiciel Selon

Swcbok (2004) les diffeacuterentes eacutetapes de tests pourraient ecirctre guideacutees par les risques associeacutes

au logiciel pour identifier sa prioriteacute et focaliser sa strateacutegie Ces risques sont identifieacutes par le

biais dune analyse qui pourrait ecirctre faite pendant la phase de preacuteparation de lactiviteacute de test

Cette analyse permet de deacuteterminer les eacuteleacutements du logiciel les plus susceptibles de contenir

le plus de deacutefauts Les reacutesultats de cette activiteacute sont utiliseacutes pendant le planning pour

deacuteterminer la strateacutegie de test les prioriteacutes et la profondeur de test neacutecessaire (Craig et

]askiel 2002 Lyndsay et van Ecdcn 2003 Perry 2000)

Le standard de documentation IEEE 829 a identifieacute une section dans le patron de plan de test

101

pour les risqucs ct contingences En fait cette section nidentifie que les risques pouvant

empecirccher le deacuteroulement normal de plan de test Dans la pratique de test les entreprises

divisent celle clause de plan de test a deux clauses une traite les risques pouvant empecirccher

lexeacutecution normale de plan de test ainsi les contingences convenables pour les surmonter

lautre traitc et identifie les risques du logiciel (Craig et Jaskiel 2002) et cite les proceacutedures agrave

entreprendre dans le test pour minimiser ses probabiliteacutes docculTence et ses impacts en cas

de reacutealisation

Dans une activiteacute de TS lanalyse de risques associeacutes au logiciel se fait agrave partir de documents

des exigenccs et de conception du logiciel Le livrable de cette phase est une matrice de

risque montrant le degreacute de risque acceptable pour chaque fonction ou secteur du logiciel et

sa criticiteacute aux affaires (Craig et Jaskiel 2002) Par la suite lapproche de test et leffort de

test neacutecessaire de chaque eacuteleacutement de cette matrice pourront ecirctre fixeacutes et documcnteacutes selon le

degreacute de risque calculeacute Ainsi les cas de test conccedilus pourront ecirctre revus et inspecteacutes par

plusieurs intervenants dans le projet de test autant de fois que neacutecessaire pour sassurer de la

profondeur et la couverture de tests des zones risqueacutees du logiciel

Selon (Bach 2003 Kaner et Tinkham 2003) le TE pourrait ecirctrc guideacute par une liste de

risques Lc responsable de test identifie cette 1iste en se basant sur nimporte quclle reacutefeacuterence

ou source dinformation existant dans Je projet de test (Jonathan Bach 2004 Lyndsay et van

Eeden 2003) Suite agrave cette identification les chartes com~spondant aux eacuteleacutements de cette

liste seront plus deacutetai lIeacutees que les autres chartes et pourront mecircme deacutecrire les techniques agrave

utiliser pcndant le tcst (Jonathan Bach 2004) Cependant le degreacute au bas niveau pour lequel

chaque eacuteleacutement de la liste est testeacute ne pourrait pas ecirctre assureacute mecircme avec les notes de session

et le deacutebriefing avec le responsable Par conseacutequent le TE pOl1e le risque que certaines parties

de grands risques ne soient pas testeacutecs correctement

Nous concluons de cette discussion que lauditabiliteacute de TS assure que les risques du logiciel

soient bien testeacutes par conseacutequent le TS pourrait ecirctre plus approprieacute dans les projets de test

preacutescntent un niveau eacuteleveacute de risque Tandis que le TE ne garantit pas que les secteurs agrave

risque soicnt bicn couvel1s

102

733 La couverture de test

La couverture de test est la mesure de ce qui a eacuteteacute testeacute proportionnellement agrave ce qui pourrait

ecirctre testeacute (Kaner 1996) Cest le degreacute exprimeacute en pourcentage selon lequel un eacuteleacutement de

couverture (les exigences lignes de code branches etc) a eacuteteacute exeacutecuteacute lors dune suite de

tests Cest une meacutetrique importante dans lactiviteacute de test logiciel Sa pertinence reacuteside dans

Je fait quil permet deacutevaluer la qualiteacute des tests effectueacutes et de savoir si le logiciel a subi

assez de tests (Swebok 2004) Pratiquement la mesure de la couverture des exigences et de

la couverture du code sont les deux formes de mesures de couverture les plus utiliseacutees et

discuteacutees dans la litteacuterature et les plus supporteacutees par les outils dans le domaine de test du

logiciel

La matrice de traccedilabiliteacute (Figure 21) constitue la premiegravere forme de mesure de couverture en

type de test boicircte noire En effet cette matrice montre agrave quel degreacute chaque exigence ou

caracteacuteristique du logiciel (la fiabiliteacute lutilisabiliteacute etc) a eacuteteacute testeacutee en illustrant le nombre

de cas de tests qui la couvre (Craig et Jaskiel 2002 Bach et al 2002) Puis des inspections et

des revues formelles des cas de tests permettent deacutevaluer la qualiteacute des cas de tests conccedilus et

de sassurer que les secteurs identifieacutes pendant lanalyse de risque du logiciel sont bien

couverts par Ics tests (Craig ct Jaskiel 2002)

La deuxiegraveme forme est la mesure de eouvcI1ure de code Cest une meacutethode danalyse qui

deacutetermine quelles parties du programme ont eacuteteacute exeacutecuteacutees (couvertes) par une suite de tests et

quelles parties ne lont pas eacuteteacute par exemple la couverture des lignes de code des deacutecisions

ou des conditions Dans Je type de test de type boicircte noire la couverture de lignes de code

sutilise souvent en utilisant un logiciel outil appeleacute laquomoniteur de testraquo Ce moniteur mesure

ou calcule le pourcentage de lignes de code exeacutecuteacute lors de lexeacutecution des cas de tests

sceacutenariseacutes (Kaner et al 1999 Marick 1997) Alors si le pourcentage mesureacute est insuffisant

des cas de tests peuvent ecirctre ajouteacutes afin datteindre le pourcentage viseacute

Bach (2003) a mentionneacute que les chartes de tests peuvent ecirctre identifieacutees selon une liste ou

matrice de couverture cest-agrave-dire une liste des eacuteleacutements du logiciel agrave recouvrir dans le test

Cependant la couverture de bas niveau ne pouvait pas ecirctre mesureacutee du fait que les meacutethodes

103

traditionnelles que nous venons de citer dans le TS ne pourraient pas ecirctre utiliseacutees dans le TE

En conseacutequence la couverture du test nest pas claire ni mesurable dans le TE Les auteurs

Itkonen et Rautiainen (2005) ont mentionneacute que ce manque de mesure de couverture est la

plus grande lacune du TE Lindsay et van Eeden (2003) ont proposeacute une technique pour

mesurer la couverture de test que nous avons deacutecrite dans la revue de litteacuterature Quoique la

technique soit innovatrice son succegraves deacutepend aussi de Jexpeltise de testeur et de sa capaciteacute

de faire un bon jugement sur Je pourcentage couvert par les tests pendant la session de test

Dun autre point de vue la mesure de couverture est tregraves utile pour la prise de deacutecision de

larrecirct de test En effet une des choses les plus difficiles dans le test de logiciel est de savoir

quand le logiciel est suffisamment testeacute et precirct agrave ecirctre livreacute Eacutevidemment le logiciel est bien

testeacute quand tous les bogues sont trouveacutes Cependant impossible de savoir sils sont tous

trouveacutes Ce problegraveme a eacuteteacute reconnu par Dijstra en 1972 par sa citation ceacutelegravebre qui deacuteclare que

laquole test du programme peut ecirctre utiliseacute pour montrer la preacutesence des bogues mais jamais

pour montrer leur absenceraquo De ce fait le recours aux critegraveres permettant la prise de deacutecision

de larrecirct de tests reste neacutecessaire Selon Copeland (2004) les critegraveres les plus utiliseacutes dans

la pratique sont le budget le calendrier de test et la couverture de tests En conseacutequence la

couverture fournit un appui utile pour la prise de deacutecision de larrecirct de tests (Swebok 2004)

Toutefois les praticiens dans lindustrie de test qui ont utiliseacute le TE comme une

meacutethodologie primaire de test et les auteurs fondateurs de lapproche (Bach et al 2002)

nont pas preacutesenteacute les meacutecanismes et les techniques quils ont utiliseacutes pour prendre la

deacutecision darrecircter le test

Nous concluons de cette discussion que la mesure de couverture de test ne peut pas ecirctre

mesureacutee dans le TE Par conseacutequent le TE nest pas approprieacute dans les projets de test qui

neacutecessitent que la couverture de test soit mesureacutee

734 Loracle de test

Selon Hoffman (1999) le test du logiciel est la comparaison du comportement du logiciel

avec le comportement attendu de celui-ci Ce compol1cmcnt attendu est connu sous Je terme

laquoOrac leraquo

104

Nous allons aborder dans cette section les faccedilons deacutelaboration de loracle de test dans le les

deux approches de test le TS et le TE

Selon Swebok (2004) un oracle de test est nimporte quel agent humain ou meacutecanique qui

statue si un programme sest comporteacute correctement dans un test donneacute et produit en

conseacutequence un verdict de passage ou eacutechec de test Selon Biezer (1990) un oracle de test est

nimporte quel programme processus ou ensemble de donneacutees qui speacutecifient les reacutesultats

preacutevus

Dans une approche sceacutenariseacutee leacutevaluation de comportement du logiciel sous test est deacutejagrave

intrinsegraveque aux cas des tests qui mentionnent les reacutesultats preacutevus Ccs reacutesultats servent

comme un oracle et guident le testeur pendant le test Cet oracle de test est de type

entreacuteesortie (Biezer 1990) cest-agrave-dire le testeur devrait exeacutecuter le logiciel en utilisant les

entreacutees speacutecifieacutees dans Je cas de test puis comparer les reacutesultats observeacutes aux sorties

speacutecifieacutees dans le cas de tesl Sils sont semblables le logiciel passe le test sinon il eacutechoue le

test

Selon Bach (1999) loracle de test est une strateacutegie eacutelaboreacutee au moment du test pour

deacuteterminer si un comportement observeacute du logiciel est correct ou non Alors nous pouvons

constater de cette deacutefinition que Joracle de test dans Je TE sc construit en temps reacutee) pendant

le tesl Le testeur formule une ideacutee sur le comportement normal et correct du logiciel en se

basant sur ses intuitions et anticipations ses compeacutetences et sa compreacutehension du logiciel agrave

tester

Afin de faciliter et guider la reacuteflexion de testeur exploratoire pendant la session de test Bach

et Kaner (2005) ont proposeacute une liste des heuristiques Ces demiegraveres pourraient aider le

testeur agrave construire Joracle de test en se basant sur la veacuterification de la coheacuterence selon

plusieurs dimensions Chacune de ces dimensions exploite un aspect particulier de contexte

de projet de test pour savoir si le comportement observeacute apregraves lexeacutecution dun test donneacute est

normal ou non par la suite prendre une deacutecision dc passage ou deacutechec dc tesl

105

Cette liste inclut

bull Coheacuterence du logiciel le comportement de chaque fonction est coheacuterent avec le

comportement de dautres fonctions comparables du logiciel ou avec le pattern

fonctionnel

bull Coheacuterence par rapport aux logiciels comparables le comportement de chaque

fonction du logiciel est coheacuterent avec le comportement dautres fonctions de logiciels

comparables

Coheacuterence avec lhistorique le comportement actuel du logicicl est coheacuterent avec

son comportement anteacuterieur

bull Coheacuterence avec limage de lorganisation le comportement du logiciel est coheacuterent

avec limage que lorganisation voulait projeter

bull Coheacuterence avec les exigences le comportement est coheacutercnt avec la documentation

existante et ce qui est annonceacute sur le produit

bull Coheacuterence avec les speacutecifications et les reacutegulations le comportement cst coheacuterent

avcc les exigences et les normes qui devaient ecirctre respecteacutees dans le projet de test

Coheacuterence avec les attentes de Jutilisatcur le cOmpoJ1ement est coheacuterent avec ce que

lutilisateur attend du logiciel

bull Coheacuterence avec Jobjectif du produit le comportemcnt cst coheacuterent avec le but

apparent et la fonction globale du produit

Dans la mecircme perspective Whittaker (2003) a proposeacute un modegravele intituleacute laquo Fault Modelraquo

pour guider le testeur dans Jeacutelaboration de loracle de test Lideacutee principale de ce modegravele est

que le logiciel a quatre capaciteacutes principales acccptcr les entreacutees enregistrer les donneacutees

traiter les donneacutees entreacutees et enregistreacutees ct produire des sorties Donc si le logiciel ne fait

pas lune de ces eacutetapes correctement pendant lexeacutecution dun cas de test il eacutechoue le test Ce

modegravele fait paJ1ie dcs techniques citeacutees et rccommandeacutees par Bach et Kaner (2004) Ces

106

meacutecanismes sajoutent agrave dautres qui visent la simplification de la mission de testeur pendant

la session de test ainsi que lameacutelioration des reacutesultats de TE Mais une question qui se pose

est-ce que nimporte quel testeur pourrait ecirctre capable dutil iser toutes ces techniques Il

semblerait que ces tcchniques neacutecessitent un testeur compeacutetent et expeacuterimenteacute

Dun autre point de vue selon Kaner (2004) la speacutecification des reacutesultats preacutevus de chaque

test dans le TS pourrait avoir des conseacutequences neacutegatives sur lefficaciteacute de lactiviteacute de test

Selon cet auteur le logiciel ou le systegraveme informatique pourrait eacutechoucr de plusieurs faccedilons

impreacutevues Par conseacutequent loracle entreacuteesortie de TS pourrait desservir au lieu de servir

dans le test parce quil peut empecirccher la deacutetection des deacutefauts non preacutevus dans le cas de test

Nous concluons de cette discussion que le TS permet davoir le mecircme oracle de test chaque

fois que les cas de test sont exeacutecuteacutes li permet aussi de veacuterifier le logiciel formcllement par

rapport ses speacutecifications Par contre loracle de TE est variable et permet dc comparer le

logiciel contre les preacutevisions du testeur

74 Comparaison selon les caraeacuteteacuteristiques du personnel

Dans cette section nous allons discuter de linflucncc des caracteacuteristiqucs du personncl sur le

choix de lapproche de test Les caracteacuteristiqucs du personncl rcgroupcnt deux factcurs les

caracteacuteristiques du testeur et la culture de lorganisation ougrave se deacuteroulc Ic projet de test

74J Les carateacuteristiques du testeur

En geacuteneacuteral tel quillustreacute sur les figures 72 et 73 les deux approches le TE et le TS

neacutecessitent des qualifications et des compeacutetences pour que le test soit efficace et attcigne ses

objectifs La diffeacuterence reacuteside dans le niveau dapplication de ces compeacutetences En effet dans

une activiteacute de TS nimporte quel testeur peut exeacutecuter les proceacutedures de tests Ces

proceacutedures sont deacutecomposeacutees en eacutetapes claires et faciles agrave suivre comme nous lavons deacutejagrave

eacutevoqueacute dans le chapitre Il Par conseacutequent lexeacutecution des tests sceacutenariseacutes nexige pas des

testeurs tregraves expeacuterimenteacutes et fortement habiles et mecircme un testeur qui vient juste de

commencer sa carriegravere en test logiciel pourrait faire face (Craig Jaskiel 2002)

Par contre la conception des cas de tests exige la compeacutetence Donc cest agrave ce niveau que

107

les qualifications et lexpertise sont neacutecessaircs Parcc quil y a un deacutelai entre la creacuteation des

cas de tests et leur exeacutecution diffeacuterents testeurs peuvent concevoir et exeacutecuter les cas de

tests De ce fait les tests peuvent ecirctre conccedilus par des testeurs compeacutetents ou mecircme par un

seul testeur expert ct ecirctre deacuteleacutegueacutes agrave plusieurs moins expeacuterimenteacutes Bref il ny a aucun

besoin davoir seulement des tesleurs experts dans une eacutequipe de test sceacutenariseacute

Par contre le TE neacutecessite des compeacutetences et de qualifications importantes pour la

conception et lexeacutecution des tests (Itkonen et Rautiainen 2005 Petty 2005 Swebok 2004

Lyndsay et van Eeden 2003 James et Wood 2003 Amland et Vaga 2002) Selon Kaner

(2004) nimporte quelle activiteacute de test neacutecessite la creacuteativiteacute et les compeacutetences pour ecirctre

efficace incluant le TS Selon ce mecircme auteur les cas de tests sceacutenariseacutes peuvent limiter la

creacuteativiteacute de testeur et la transformer en un robot exeacutecutant les tacircches demandeacutees sans aucune

reacuteflexion critique surtout si le rendement du testeur est eacutevalueacute par le nombrc de cas de test

exeacutecuteacutes et par les erreurs deacutetecteacutees Dans une telle si tuation le testeur se concentre sur

lexeacutecution des proceacutedures de test et eacutevite la deacuteviation ellimprovisation

Dans le but de montrer les effets neacutegatifs de TS sur la creacuteativiteacute du testeur Kaner et son

eacutequipe (Kaner et Bach 2005) ont eacutelaboreacute plusieurs expeacuteriences et recherches dans les

laboratoires de Florida Institut sur des souris dont les deacutemonstrations sont disponibles dans

(Kaner et Bach 2005) Ces recherches ont prouveacute que les proceacutedures de test pourraient

empecirccher le testeur de voir dautres problegravemes non speacutecifieacutes dans les proceacutedures mais qui

peuvent apparaicirctre pendant lexeacutecution agrave cause du fait que le testeur se concentre seulement

sur les reacutesultats identifieacutes dans les proceacutedures de tests Cela est connu en psychologie sous le

terme anglophone laquoInattentional Blindnessraquo (Mack et Rock 2000) Selon Kaner (2004) le TE

aide le testeur agrave apprendre de nouvelles meacutethodes ct strateacutegies de test en lui permettant

dameacuteliorer sa capaciteacute danalyse et de reacuteflexion critique Selon les constations de Petty

(2005) la possibiliteacute dapprentissage dans le TE est plus grande que celle en TS

Nous concluons que le TE est approprieacute dans les projets de test ayant des testeurs compeacutetents

et experts Tandis que le TS est plus approprieacute dans les projets de test que ont un nombre

limiteacute de testeurs expelis et plusieurs non expeacuterimenteacutes

108

742 La culture de lorganisation

La culture de lorganisation pourrait fortement influencer le choix de lapproche de test

Selon Craig et laskiel (2002) un processus de TS ne pourrait pas ecirctre mis en place sil

nexistait pas un proccssus de deacuteveloppement formel et bien structureacute qui supporte le projet

de test Souvent les entreprises qui utilisent les bonnes pratiques et les meacutethodes disciplineacutees

de deacuteveloppement favorisent plus lutilisation de TS qui convient plus avec leur

meacutethodologie de deacuteveloppement Tandis que les entreprises qui possegravedent des processus

immatures ou chaotiques de deacuteveloppement ne pourraient pas utiliser le TS Ces entreprises

favorisent souvent des meacutethodes de test informelles comme le TE (Lyndsay van Eeden

2003 ltkonen et Rautiainen 2005)

Nous concluons gue le TS est plus approprieacute dans les projets de test des entreprises favorisant

la discipline Tandis gue le TE est plus approprieacute dans les entreprises qui ont des processus de

deacuteveloppement immatures et qui sappuient sur les compeacutetences et la creacuteativiteacute du personnel

pour mener les activiteacutes de deacuteveloppement ct eacuteviter le chaos

75 Comparaison selon la productiviteacute

Dans cette section nous allons comparer les deux approches de test le TS et le TE selon le

facteur de laquola productiviteacute raquo Nous discutons la productiviteacute en termes du nombre de deacutefauts

deacutetecteacutes et de limportance de deacutefauts deacutetecteacutes

Depuis son apparition dans Je domaine du test le TE sest fait promouvoir comme une

meacutethode efficace Selon Bach (2003) le TE pourrait ecirctre plus productif que le TS Cependant

il ny a aucune preuve jusquagrave maintenant dans la litteacuterature prouvant cette productiviteacute agrave part

quelques anecdotes et expeacuteriences veacutecues des praticiens

Theacuteoriquement lefficaciteacute pourrait ecirctre perccedilue autrement gue baseacutee seulement sur la base du

compte des deacutefauts trouveacutes Selon Copeland (2004) le TS est plus avantageux que Je TE du

fait quil pourrait sintroduire tocirct dans le cycle du deacuteveloppement du logiciel En effet dans

les vues preacuteventives actuelles le TS peut commencer des le deacutebut de projet du

deacuteveloppement Par la suite il pourrait deacutelecter les erreurs dans la conception et les exigences

avant que ces derniegraveres ne se transforment en des deacute1agraveuts dans le logiciel Par contre le TE

109

ne pourrait sintroduire quapregraves le codage du logiciel De ce point de vue nous pouvons

conclure que le TS est plus efficace que le TE vu sa capaciteacute de preacutevenir les deacutefauts Dun

autre point de vue selon (Copland 2004 Kaner 2003) les cas de tests sceacutenariseacutes deviennent

laquofatigueacutesraquo cest-agrave-dire incapables de deacutetecter de nouveaux deacutefauts dans les cycles ulteacuterieurs

de test Par conseacutequent le TE pourrait ecirctre plus efficace dans cette situation

Les auteurs Itkonen Rautiainen (2005) ont tenteacute de collecter des donneacutees quantitatives

pouvant leur donner une ideacutee de la productiviteacute de TE Malheureusement les donneacutees

collecteacutees neacutetaient pas fiables Sajoute agrave ce fait labsence des reacutesultats de TS pouvant servir

comme une reacutefeacuterence de comparaison Dans les autres eacutetudes de cas que nous avons

proposeacutees dans la revue de litteacuterature les praticiens ont tous rappol1eacute que leur expeacuterience

dans Jutilisation de TE comme une approche primaire de test a eacuteteacute fmetueuse et reacuteussie

Cependant ils nont pas preacutesenteacute des donneacutees quantitatives sur lefficaciteacute reacutealiseacutee et les

reacutesultats obtenus

Quant agrave notre expeacuterience qui sest deacuterouleacutee dans les laboratoires informatiques de lUQAgraveM

nous navons pas pu tirer des conclusions fiables et geacuteneacuteraliseacutees agrave cause des limites du

contexte de lexpeacuterience Cette limite est causeacutee par la taille du programme utiliseacute dans

lexpeacuterience choisi pour faciliter la tacircche des sujets et eacuteviter les reacutesultats nuls Le contexte ne

nous a pas permis daborder lactiviteacute de test dune faccedilon professionnelle Le manque

dexpeacuterience des sujets dans le domaine de test du logiciel sajoute aussi aux limitations de

contexte Ces limitations ont influenceacute les reacutesultats de lexpeacuterience Cela est appam

clairement dans les reacutesultais de TS obtenus Quoique nous ayons proposeacute aux sujets les

mecircmes sceacutenarios de cas de test nous avons constateacute que les sujets ont interpreacuteteacute les reacutesultats

observeacutes diffeacuteremment ct ils ont eu de la difficulteacute agrave classifier les deacutefagraveuts deacutetecteacutes

correctement Nous avons dailleurs duuml les reclasser apregraves lexpeacuterience

Les reacutesultats recueillis de cette eacutetude empirique nous a permis de conclure que le TE est plus

productif en terme de nombre des deacutefauts deacutetecteacutes que le TS Ainsi nous avons conclu que Je

TE pourraient deacutetecter des deacutefauts plus importants point de vue graviteacute que le test sceacutenariseacute

110

76 Discussion et synthegravese

Dans ce chapitre nous avons compareacute les deux approches de test Je TE et le TS selon les

facteurs du cadre de comparaison que nous avions eacutelaboreacute Dans cette section nous allons

reacutecapituler les reacutesultats et conclure Le tableau ci-bas reacutecapitule les reacutesultats de notre analyse

comparative Il inclut les facteurs principaux qui doivent ecirctre pris en compte pendant la

seacutelection de lapproche de test pour eacuteviter de proposer une solution inadeacutequate

En fait ce tableau constitue un guide de seacutelection de lapproche de test parmi les deux

discuteacutes dans ce travail de recherche agrave savoir le TE ct le TS Alors ce guide identifie

comment chaque facteur de contexte de test sapplique agrave chacune des deux approches de test

En analysant chaque facteur dun contexte de test pm1iculier suivant ce guide (Tableau 71)

nous pouvons savoir si le contexte est favorable pour utiliser le TE agrave la place de la meacutethode

traditionnelle sceacutenariseacutee Ce guide tente de baliser une deacutemarche danalyse pouvant ecirctre

inteacutegreacutee agrave la reacuteflexion strateacutegique des entreprises pendant la seacutelection de [approche de test

Ainsi il pourrait aider agrave comprendre les apports et les besoins de TE ce qui va permettre

dassimiler et adopter lapproche

JJ1

Tableau 71 Le guide de seacutelection de lapproche de test

Facteurs Test sceacutenariseacute Test exploratoire

1 Caracteacuteristiques dutilisation

Les raisons La stabiliteacute de projet de Linstabiliteacute de projet de dutilisation deacuteveJoppement le besoin de deacuteveloppement labsence des

documenter et mesurer lactiviteacute eXlgences de test

Les caracteacuteristiques du logiciel

La taille du logiciel Les grands logiciels Les logiciels petits et moyens La complexiteacute du Plus approprieacute Deacutepend des compeacutetences logiciel existant dans le projet de test La criticiteacute du logiciel Exigeacute Ne devrait pas ecirctre utiliseacute

Le type Stable eacutevolutif sous contrat et Dynamique denvironnement nimporte quel environnement daffaire qui neacutecessite une documentation

deacutetailleacutee des tests Les ressources Ressources importantes Ressources raisonnables ou financiegraveres limiteacutees Le temps de test Temps consideacuterable requis Peu de temps requis disponible

2 Caracteacuteristiques de gestion

La planification Rigoureuse classique et cel1aine Adaptative continue non rigoureuse

Le controcircle et le suivi Mesurable Estimeacute de progression de test La relation avec le Souhaiteacutee Essentielle peut ameacuteliorer la client qualiteacute du test La communication Souhaiteacutee Essentielle la qualiteacute de test dans le projet de test effectueacute deacutepend de la qualiteacute de

communication existante dans le projet de test

3 Caracteacuteristiques techniques

Les activiteacutes de test Reacutepeacutetitives audi tables Creacuteatives adaptatives

Loracle de test Fixe deacuteriveacute agrave partir des Variable deacuteriveacute agrave partir des exigences du logiciel et les preacutevisions du testeur standards

Les risques du logiciel La couverture de tous les risques La couverture de tous les risques est assureacutee nest pas assureacutee

112

Facteurs Test sceacutenariseacute Test exploratoire

3 Caracteacuteristiques techniques

La couverture de test Mesureacutee Nest pas assureacutee ni mesureacutee

4 Caracteacuteristiques du personnel

Les caracteacuteristiques Testeurs compeacutetents et experts Nombre limiteacute dexperts et du testeur plusieurs non expeacuterimenteacutes La culture de Disciplineacutee Immature lorganisation

5 Productiviteacute

Le nombre des Moins productive que le TE Plus productive que le TS deacutefauts deacutetecteacutes Limportance des Moins importants que ceux qui Importants et critiques sil est deacutefauts deacutetecteacutes pourraient ecirctre deacutetecteacutes avec le exeacutecuteacute par des personnes

TE compeacutetentes

Or les facteurs identifieacutes nont pas tous le mecircme poids ni la mecircme importance dans le

contexte de test Nous avons constateacute dapregraves notre analyse comparative que la couve11urc de

test est le facteur le plus important dans le contexte de test Du fait que les autres facteurs

sont inter-relieacutes dune maniegravere ou dune autre avec la couverture du tes Aussi nous avons

constateacute que les qualifications et les compeacutetences existantes dans les projets de test pourraient

influencer le choix de lapproche de tes Alors dans les projets de test ougrave les qualifications

personnelles sont insuffisantes il apparaicirct difficile dutiliser le TE Nous pouvons conclure

que le TE pourrait remplacer Je TS dans nimporte quel projet de test ougrave le controcircle de la

couverture ne constitue pas une exigence et ougrave les compeacutetences ct les quaJificati~ns du

personnel aident agrave utiliser le TE

Pourtant il est difficile de cerner un contexte ougrave une seule approche de test palmi le TS et le

TE conviendrai Agrave cet effet nous croyons quune approche hybride peut convenir mieux ougrave

certaines parties du logiciel pourraient ecirctre testeacutees en utilisant le TS et dautres en utiJisantle

TE Ainsi la meacutethodologie de test pourrait beacuteneacuteficier des avantages de chacune des deux

approches

113

77 Conclusion

Au cours de ce chapitre nous avons compareacute et analyseacute les deux approches de test selon le

cadre comparatif de comparaison que nous avons eacutelaboreacute dans le chapitre preacuteceacutedent Nous

sommes revenues sur les reacutesultats de leacutetude empirique que nous avons meneacutee dans le cadre

de ce travail de recherche afin deacutevaluer empiriquement la productiviteacute de test exploratoire

en termes du nombre et de limportance de deacutefauts deacutetecteacutes Lanalyse comparative selon les

facteurs du cadre de comparaison nous a permis de ressortir les contextes favorables pour

utiliser le TE comme une meacutethodologie primaire de test agrave la place de la meacutethode sceacutenariseacutee

habituelle En terminant nous avons eacutelaboreacute un guide de seacutelection de lapproche dc test Ce

guide reacutecapitule les reacutesultats de lanalyse comparative et tente de baliser une deacutemarche

danalyse pouvant ecirctre inteacutegreacute agrave la reacuteflexion strateacutegique des entreprises pendant la seacutelection

de lapproche de test

CHAPITRE VIII

ANALYSE DES REacuteSULATS

Cc chapitre preacutesente une analyse des reacutesultats de lanalyse comparative preacutesenteacutee au chapitre

preacuteceacutedent et les reacutesultats de leacutetude empirique preacutesenteacutee dans le chapitre V Ce chapitre fait

aussi ressortir la contribution de leacutetude et les pistes potentielles de recherche

8] Analyse des reacutesultats theacuteoriques

Lanalyse comparative du TE et du TS que nous avons effectueacutee dans le chapitre preacuteceacutedent

nous a permis didentifier les facteurs de contexte pouvant influencer le choix de lapproche

de test Nous avons identifieacute comment chaque facteur sapplique dans le cadre de chacune

des deux approches Agrave cet effet nimporte quel contexte de test pourrait ecirctre analyseacute selon les

facteurs identifieacutes dans le guide de seacutelection de lapproche de test (tableau 71) Cela permet

de savoir a priori lapproche la plus approprieacutee aux besoins du contexte de test

Selon Copeland (2004) le TS pourrait ecirctre utiliseacute nimporte ougrave lobjectiviteacute la reacutepeacutetitiviteacute et

lauditabiliteacute sont neacutecessaires (Section 22) Bach (2003) a mentionneacute que le TE pourrait ecirctre

plus productif que le TS dans certaines situations Or ces situations nont pas eacuteteacute identifieacutees

dans aucune eacutetude Dans notre recherche nous avons eacutetudieacute ces situations dans Je cadre

dune analyse comparative theacuteorique et empirique entre le TE et le TS selon un cadre de

comparaison (figure5l) que nous avons deacuteveloppeacute afin de guider notre analyse comparative

des deux approches Par le biais de celle analyse comparative nous avons pu eacutetudier

identifier et analyser les contextes qui favorisant ladaptation et [utilisation de TE comme

une meacutethodologie indeacutependante de test Notre eacutetude a mis en eacutevidence que dautres facteurs

que ceux identifieacute par Copland (2004) pourraient favoriser lutilisation de TS Toutefois

] 15

nous avons constateacute que la couverture du test ct les qualifications et lexpertise des

personnels preacutesents dans le contcxte de test sont les deux facteurs les plus importants

La premiegravere contribution dc cette recherche est de preacutesenter un guide de seacutelection de

lapproche de test qui reacutecapitule tous les facteurs du contexte de test et comment ils

sappliquent dans le cadre du TS et du TE Ce guide pourrait ecirctre inclus dans la reacuteflexion

strateacutegique des entreprises pour seacutelectionner lapproche le mieux approprieacutee agrave nimporte quel

contexte de test li constituc aussi un outil denseignement de TE qui peut aider les eacutetudiants

agrave mieux comprendre et agrave mieux diffeacuterencier les contextes favorables pour utiliser chacune des

deux approches

82 Analyse des reacutesultats empiriques

Leacutevaluation empirique de la productiviteacute de TE na pas eacuteteacute bien abordeacutee dans les travaux de

recherches Bach (2003) a proposeacute les reacutesultats de ces expeacuteriences veacutecues comme preuves de

la productiviteacute du TE Les auteurs Jtkonen et Rautiainen (2005) ont collecteacute des donneacutees

quantitatives de TE de deux petites entreprises qui utilisent le TE comme une meacutethode

primaire de test Toutcfois ccs donneacutees ne sont pas fiables ni repreacutesentatives agrave cause de

labsence de donneacutees quantitatives de TS dans les deux cas qui pourraient ecirctre consideacutereacutees

comme reacutefeacuterence afin de prouver la productiviteacute de TE Labsence des eacutetudes empiriques

dans la litteacuterature nous a obligeacute agrave consideacuterer les reacutesultats dJtkonen et Rautiainen (2005) dans

notre eacutetude comparative

Loriginaliteacute de notre eacutetude empirique reacuteside dans la conception innovatrice que nous avons

choisie pour Jeffectuer Cette conception nous a permis deacutevaluer plusieurs aspects

o La productiviteacute de TE cn terme du nombre et de limportance des deacutefauts deacutetecteacutes

pendant lcxpeacuterience puis la comparaison des reacutesultats de lexpeacuterience avec les reacutesultats

rapporteacutes par les auteurs ltkonen et Rautiainen (2005)

o Lcffct dc la technique dc tcst (TE TS) sur la perfUumllmance des sujets pendant lactiviteacute

de test De cette faccedilon nous avons pu eacutevaluer la capaciteacute des sujets dexeacutecuter et de

116

reproduire les cas de tests dc la mecircme faccedilon preacutevue par le concepteur (lauteur ltle ce

travail) Cela nous a pennis dexplorer Jhypothegravese de Kaner et Bach (2005) qui cite que

le testeur dans le TS ne pourrait pas reproduire les cas de test de la mecircme faccedilon que leur

conceptcur Nous avons aussi pu explorer la deuxiegraveme hypothegravese de Kaner et Bach qui

cite que le TS empecircche le testeur dapercevoir dautres deacutefauts que ceux qui sont

documenteacutes dans le cas de test Ce pheacutenomegravene est connu dans le domaine de psychologie

sous le terme anglophone laquoInattentional Blindnessraquo (Mack et Rock 2000)

Lanalyse des reacutesultats recueillis de lexpeacuterience a montreacute que la moyenne des deacutefauts

deacutetecteacutes est de 95 dans une session de 45 minutes Cette moyenne est proche de eelle

proposeacutee par la reeherche des auteurs Itkonen et Rautiainen (2005) soit 87 dans une session

de 60 minutes

En ce qui concerne limportance des deacutefauts deacutetccteacutes par le TE nous avons conclu que plus

que la moitieacute des deacutefauts deacutetecteacutes ont eacuteteacute des deacutefauts graves tandis que les deacutefauts fatals ont

constitueacute 10 de total des deacutefauts deacutetccteacutes Les auteurs ltokens et Rautiainen (2005) ont

rapporteacute un pourcentage dc 15 des deacutefauts fatales deacutetecteacutes dans une session de 60 minutes

Ce pourcentage est proche de pourcentage que nous avons obtenu dans notre eacutetude

empirique si nous prenons en consideacuteration la diffeacuterence dans les programmes utiliseacutes Nous

avons aussi eacutetudieacute dans notre eacutetude empirique JinOuence de lexpertise de testeur sur les

reacutesultats de TE Agrave cet effet nous avons eacutetudieacute la relation entre le niveau de connaissance en

Java et Je nombre des deacutefauts deacutetecteacutes Notons que le niveau de connaissance en Java

repreacutesente dans notre eacutetudc empirique lcxpe11isc ct les qualifications de lexpeacuterimentateur

Alors les reacutesultats ont montreacute que la moyenne de deacutefauts deacutetecteacutes croicirct en fonction de niveau

de connaissance en Java

En ee qui concerne la productiviteacute du TE par rapport au TS nous avons conclu que le TE est

plus productif que le TS du fait que la performancc des sujets dans le TE a eacuteteacute supeacuterieure de

celle reacutealiseacutee dans le TS Par la suite nous avons conclu que le TE a un effet positif sur le

rendement des sujets en comparaison avec le TS Ces reacutesultats appuient les hypothegraveses de

117

Kancr ct Bach (2005) Toutcfois la limitation de contexte de leacutetude empirique a affaibli la

validiteacute externe des reacutesultats De ce fait ces reacutesultats ne pourront pas ecirctre geacuteneacuteraliseacutes

Les reacutesultats quantitatifs de cette eacutetude empirique all1S1 que sa conception constituent la

deuxiegraveme contribution de notre travail de recherche Nous pensions que les conclusions tireacutees

de cette eacutetude sont susceptibles de sappliquer dans des reacuteplications futures et les chercheurs

inteacuteresseacutes par leacutevaluation de la productiviteacute de TE empiriquement pourront reacuteutiliser notre

eacutetude empirique eomme eacutebauche pour leurs eacutetudes

83 Pistes potentielles de recherche

Le but de ee travail eacutetait deacutevaluer empiriquement la productiviteacute de TE et dexplorer les

contextes qui favorisent son utilisation agrave la place de la meacutethode sceacutenariseacutee habituelle Suite a

cette recherche plusieurs avenues meacuteriteraient decirctre approfondies

o Enrichir le guide de seacutelection de lapproche de test

Nous avons consideacutereacute dans le deacuteveloppement du guide de seacutelection de lapproche de test les

facteurs qui ont influenceacute les reacutesultats de lutiJisation de TE dans lindustrie Or avec la

croissance de ladoption et de ladaptation du TE par les entreprises dautres facteurs

pourront apparaicirctre Lessai de ce guide dans Jindustrie pourrait engendrer aussi des

feedbacks et des apports utiles Agrave cet effet il serait inteacuteressant de veacuterifier si dautres facteurs

peuvent sappliquer et venir enrichir le guide

o Reacuteplication de leacutetude empirique dans un contexte industriel

Le contexte acadeacutemique ou sest deacuterouleacute Jeacutetude empIrIque a influenceacute neacutegativement la

validiteacute externe de lexpeacuterience et a constitueacute sa limite majeure Pour deacutepasser cette limite il

serait inteacuteressant de reprendre leacutetude dans un contexte industriel en utilisant plusieurs projets

de test Ainsi leacutevaluation de la productiviteacute pourrait ecirctre faite sur deux eacutetapes pendant

lactiviteacute de test et apregraves lactiviteacute de test cest agrave dire dans Je site de production de chacun des

logiciels qui faisaient Jobjet de cette eacutetude

118

o Explorer Jinfluence de lexpertise et les connaissances du domaine sur la qualiteacute de

TE

Il serait inteacuteressant deacutetudier linfluence de lexpertise et les connaissances du domaine sur la

qualiteacute de TE effectueacute en termes du nombre des deacutefauts deacutetecteacutes et de limportance de ces

deacutefauts dans un contexte industriel en utilisant le nombre danneacutees dexpeacuterience dans le

domaine du test comme une meacutetrique de lexpertise

84 Conclusion

Au eours de ce chapitre nous avons effectueacute L1ne analyse et preacutesenteacute une discussion des

reacutesultats de notre recherche dans laquelle nous avons situeacute ses contributions au niveau

theacuteorique et empirique Par la suite nous avons preacutesenteacute des pistes de recherche futures dans

lesquelles nous avons identifieacute dautres probleacutematiques qui peuvent ecirctre utiles en vue

dinitier des travaux futurs de recherches

CONCLUSION

Nous avons eacutetudieacute dans ce travail deux approches de test du logiciel le test exploratoire (TE)

et le test sceacutenariseacute (TS) La partie theacuteoriquc de cc travail a eu comme but lexploration des

contextes du test ougrave le TE pourrait remplacer le TS et ecirctre utiliseacute comme une meacutethodologie

primaire du test La partie empirique a eu pour objectif leacutevaluation de la productiviteacute de TE

annonceacutee dans la litteacuterature

Apregraves la deacutefinition du sujet de recherche nous avons preacutesenteacute une vue densemble de TS et

de TE successivement Par la suite nous avons preacutesenteacute une revue de litteacuterature de quelques

eacutetudes de cas et expeacuteriences dutilisation de TE dans lindustrie du test Cest ainsi que nous

avons identifieacute les facteurs influenccedilant ladoption et ladaptation de TE dans la pratique du

test Par la suite nous avons preacutesenteacute les reacutesultats de leacutetude empirique que nous avons

meneacutec dans les laboratoires de lUQAgraveM Puis nous avons eacutelaboreacute un cadre conceptuel de

comparaison dans lequel nous avons identifieacute les dimensions principales de notre analyse

comparative de TE et TS Ce cadre pourra servir dans dautres eacutetudes compmatives des

approches du test

Lanalyse comparative reacutealiseacutee a permis de ressortir les facteurs contextuels favorables pour

utiliser chacune des deux approches du test Entre autres nous avons montreacute que le TE nest

pas approprieacute dans les projets de test neacutecessitant que la couverture de test soit mesureacutee

Aussi nous avons montreacute quc la deacutependance de TE agrave lexpertise et les qualifications du

testeur rend difficile son utilisation dans les contextes ougrave les qualifications ct les compeacutetences

du personnel sont insuffisantes Agrave cet effet Nous avons conclu que le TE pourrait remplacer

le TS dans nimporte quel projct de test ougrave le controcircle de la couverture ne constitue pas une

exigence etougrave les compeacutetences et les qualifications du personnel permettcnt dutiliser le TE

Notre eacutetude empirique a montreacute la productiviteacute de TE en tennes de nombre et Jimportance

des deacutefauts deacutetecteacutes Toutefois nous ne pouvons pas geacuteneacuteraliser les reacutesultats obtenus dans

120

cette eacutetude agrave cause de la limitation du contexte ou sest deacuterouleacute notre expeacuterience Agrave cet effet

nous reportons cette question agrave des travaux futurs de recherches de preacutefeacuterence dans des

contextes industriels

Au niveau pratique ce travail de recherche sinscrit dans un courant de preacuteoccupation des

entreprises qui ont agrave la recherche des meacutethodes du test plus efficaces qui pounaient sadapter

avec la culture rapide actuelle de deacuteveloppement du logiciel Il est agrave noter que cette eacutetude

constitue une ouverture sur le deacuteveloppement dun guide visant Jadaptation de TE dans

lindustrie du test Nous espeacuterons que le guide de seacutelection de Japproche de test aide les

entreprises et les praticiens agrave mieux choisir leur approche de test selon leur contexte du test

Nos objectifs personnels eacutetaient dexplorer les apports de TE et deacutevaluer sa productiviteacute

fortement mise de lavant par les praticiens de CDS Lanalyse comparative de TE ct le TS

nous a pousseacutee agrave approfondir nos connaissances dans Je domaine du test logiciel pour que

nous puissions identifier les apports et les lacunes de chacune des deux approches Ce travail

nous a permis de deacutecouvrir limportance de lactiviteacute du test dans le processus de

deacuteveloppement logiciel Cela nous a montreacute les diffeacuterents cocircteacutes de test du logiciel ses deacutefis

son cocircteacute quasi artistique matheacutematique et critique Bref nous avons trouveacute un autre domaine

dinteacuterecirct outre que la programmation et le deacuteveloppement

ANNEXE A

CADRE DE BASILI ADAPTEacute Agrave LA RECHERCHE EXPLORATOIRE

Les tableaux preacutesenteacutes dans celle annexe reacutecapitulent les phases du projet de recherche selon

le cadre de Basili agrave la recherche exploratoire adapteacute par Abran et al (J 999)

1 Deacutefinition Motivation Porteacutee Objectif Utilisateurs

J Explorer les Comparaison theacuteorique Reacutepondre agrave la question - Les chercheurs et apports de TE et empirique de TE et principale de recherche les praticiens

TS selon un proceacutedeacute Est-ce que le TE pourrait inteacuteresseacutes al eacutetude 2 Explorer de tesl boicircte noire remplacer Je test du TE lampleur de la sceacutenariseacute Si oui dans quel divergence enlre contexle - Les entreprises les deux vues deacutesirant mettre en

oeuvre ces 3Eacutevaluer la approches de test productiviteacute dc TE

4Eacutelaborer un guide de seacutelection de lapproche de test

122

2 Planification du projet Les eacutetapes Les intrants Les livrables

1 Proposer dun modegravele du La norme IEEE 829 - Un cadre conceptuel de processus de TS comparaison des approches

de test 2Eacutelaborer un cadre de comparaIson - Les reacutesultats quantitatifs de

leacutetude empirique 3 Faire leacutetude comparative empirique de TE et TS - Un guide deacutevaluation des

facteurs de contexte de projet 4 Faire leacutetude comparative de test pour le choix dune de TE et TS en se basant sur approche de test le cadre eacutelaboreacute et les reacutesultats empirique

5 Analyser et discuter des reacutesultats

3 Ooeacuteration Analyse des documents Feedback des Modegraveles proposeacutes

praticiens

1 Identifier les facteurs qui ont Cadre conceptuel de comparaison des influenceacute ladoption et ladaptation approches de test qui inclut les cinq de TE dans lindustrie dimensions agrave savoir

2 Analyser leacutetude comparative de 1 Les caracteacuteristiques dutilisations Boehm et Turner

2 Les caracteacuteristiques du logiciel agrave 3 Eacutetudier et analyser les tester connaissances theacuteoriques de test du logiciel 3 Les caracteacuteristiques de gestion

4 Eacutetudier et analyser les apports et 4 Les caracteacuteristiques du personnel les meacutecanismes de TE

5 La productiviteacute

Proposition dun guide de seacutelection de lapproche de test

]23

4 Interpreacutetation

Contexte dinterpreacutetation Extrapolation des reacutesultats Travaux futurs

) La comparaison theacuteorique - Les reacutesultats de Jeacutetude empirique sont - Reacuteplication de et empirique des deux limiteacutes Ils deacutependent du contexte leacutetude empirique et approches de test le TE et acadeacutemique ougrave sest deacuterouleacutee comparative de TE le TS a eacuteteacute reacutealiseacutee lexpeacuterience et TS dans un

environnement 2 Lanalyse comparative de - Lanalyse comparative entre le TE et le industriel TE et TS selon les facteurs TS est associeacutee au cadre de comparaison de notre cadre conceptuel de eacutelaboreacute dans ce travail de recherche et les - Leacutetude de comparaison a permis reacutesultats de leacutetude empirique Agrave cet linfluence des didentifier les contextes effet celte analyse est limiteacutee et en partie connaissances du favorables pour utiliser le subjective Elle deacutepend des domaine et TE agrave la place de TS connaissances et de Jexpeacuterience de lexpeliise de testeur

auteure dans le domaine de test du sur les reacutesu Ilats de 3 Lanalyse comparative a logiciel TE permis deacutelaborer un guide de seacutelection de lapproche - Lameacutelioration du de test guide de seacutelection de

lapproche de test 4 Cette recherche pourrait eacutelaboreacute dans ce contribuer agrave mieux travail de recherche comprendre le TE Elle facilite Jadoption de TE au sein des entreprises qui oeuvrent dans le domaine du deacuteveloppement

ANNEXEB

PLAN DE TEST IEEE829 (ADAPTEacute ET TRADUIT DE IEEE 8291998)

1 Identificateur de plan de test

bull Identificateur unique de document qui pourrait le distinguer des autres documents

2 Introduction

bull lintroduction pourrait inclure les paragraphes suivants

Description du logiciel sous test ce paragraphe donne un aperccedilu du logiciel

ses opeacuterations maintenance histoire son code ct toute autre information

pertinente

Une liste de reacutefeacuterences agrave dautres documents utiles pour la compreacutehension du

plan de test Selon la norme IEEE 829 les reacutefeacuterences aux documents

suivants sils existent doivent ecirctre mentionneacutees

o Autorisation du projet

o Plan du projet de deacuteveloppement

o Plan dassurance qualiteacute

o Plan de gestion de configuration

o Politique pertinente de la compagnie et du client

o Normes pertinentes de la compagnie du client ou de lindustrie

3 Items de test

bull Identifie les items agrave tester incluant leur versionniveau de reacutevision

125

4 Caracteacuteristiques agrave tester

bull Identifie les caracteacuteristiques agrave tester telles que fonctionnaliteacute performance seacutecuriteacute

portabiliteacute etc

5 Caracteacuteristiques qui ne doivent pas ecirctre testeacutees

bull Identifie les caracteacuteristiques qui nc vont pas ecirctre testeacutees ainsi les raisons de ce fait

6 Approche

bull Propose la strateacutegie globale de test afin dassurer gue tous les items et leurs

caracteacuteristiques seraient testeacutes adeacutequatement

7 Critegravere de passageeacutechec

Deacutefinit le critegravere de passage et deacutechec de test de chaque item

8 Critegravere de suspension et conditions de reprise

bull Deacutefinit les circonstances dans lesquelles le test pourrait ecirctre arrecircteacute ct les conditions

pour quil reprenne (deacutefauts critiques gui neacutecessitent la re-conception cnvironnement

de test incomplet etc)

9 Livrable du test

bull Identifie les documents de test ainsi que les autres livrables devant ecirctre produits au

cours du projet de test (ex speacutecifications de conception de test speacutecifications de cas

de test speacutecifications de proceacutedure de test registre de test rapport dincident de

tcst rappol1 de synthegravese de test matrice de traccedilabiliteacute etc)

10 Tacircche de test Identifie les tacircches de test et linterdeacutependance entre clics ainsi que la

dureacutee et les rcssources requises pour les accomplir

126

II Besoins environnementaux

bull Speacutecifie lenvironnement requis pour accomplir lactiviteacute de test incluant mateacuteriel

logiciel outils etc

12 Responsa biliteacutes

Identifie la responsabiliteacute ct la tacircche de chaque membre de [eacutequipe de test

13 Besoins en personnel et en formation

bull Les personnes et les qualifications neacutecessaires pour reacutealiser le plan

14 Calendrier

bull Speacutecifie les eacutetapes importantes dans le plan de projet de deacuteveloppement ainsi que les

items qui devraient ecirctre transmis agrave chaque eacutetape

15 Risques ct contingences

bull Identifie les risques qui peuvent empecirccher le suivi du plan et les mesures agrave prendre

pour les surmonter

16 Approbation

ANNEXE C

SOIREacuteE DE TESTS

Document remis aux participant(e)s

Lobjcctif premIer de cet exercIce est daugmenter votre niveau dexpeacuterience dans

Jexeacutecution de tests preacutepareacutes par dautres et dans le domaine des tcsts exploratoires Pour ce

faire vous uti liserez dabord jusquagrave 2000 lapproche des tests exploratoires agrave laide des

directives donneacutees dans la section suivante Dans la deuxiegraveme partie de la sOireacutee vous

exeacutecuterez des tests sceacutenariseacutes qui vous seront remis agrave 2000

Dans les dcux cas vous prendrez en note sur les formulaires ci-joints (voir Annexe D) les

deacutefauts que vous constaterez Par la suite vous compleacuteterez les rapports demandeacutes en

reacutepondant aux questions proposeacutees Toutes ces informations serviront de base agrave un travail de

maicirctrise sur les diffeacuterences entre le TE et le test sceacutenariseacute

Quelques directives et informations pour exeacutecuter le TE

Deacutefinition du programme

IJ sagit dun gestionnaire simple de messages Chaque message contient les informations

suivantes eacutemelleur destinataire sujet du message texte du message et une information

suppleacutementaire qui indique si le message a eacuteteacute lu ou non eacutelimineacute ou non Pour chaque

message le logiciel allribue un numeacutero automatiquement supeacuterieur agrave 100 Le programme

utilisc un tablcau de taille 10 pour geacuterer les messages Le programme doit afficher un

message un message derreur si on tente de geacuteneacuterer plus de 10 messages

Les directives agrave utiliser

Nous proposons cer1aines techniques qui peuvent vous aider dans vos tests exploratoires

128

Vous pouvez choisir une ou plusieurs de ces techniques Vous necirctes pas obligeacutes de les

appliquer strictement et vous avez toujours la possibiliteacute dintroduire vos propres techniques

Cependant rappelez-vous que le but de lexercice est de deacutecouvrir le plus possible de bogues

importants de faccedilon agrave ameacuteliorer la qualiteacute du logiciel

o Exeacutecution du programme en utilisant des donneacutees valides (parmi les choix afficheacutes

dans le menu principal) pour avoir une ideacutee sur ses fonctions et ses caracleacuteristiques

principales

o Suivez votre intuition et explorez le programme si vous avez une ideacutee sur les types

derreurs quil peut inclure

o Essayez de geacuteneacuterer des questions sur la capaciteacute du programme daccomplir certaines

fonctions que vous sont apparu essentielles mais toujours dans le cadre de la

description ci-dessus Essayez ensuite de transformer chaque queslion en un jeu

dessai (cas de test)

o Geacuteneacuterez diffeacuterents sceacutenarios dutilisation de logiciel Ensuite essayez dexplorer les

aspects de vos sceacutenarios par exemple utilisez diffeacuterentes valeurs dentreacutee surtout

les valeurs extrecircmes (limites) pour le mecircme sceacutenario

o Veacuterifiez les messages derreurs du programme autrement dit veacuterifiez sils se

deacuteclenchent au bon moment et sous les bonnes conditions

o Choisissez une variable puis essayez de tracer son flux dans le programme Les

meacutethodes quellcs lutilisent ainsi que ses interactions avec dautres variables

Ensuite utilisez ces informations pour interfeacuterer avec la variable

o Choisissez une tacircche parmi les fonctionnaliteacutes du programme et essayez de deacutecrire

eacutetape par eacutetape comment elle est accomplie et manipuleacutee dans le logiciel puis essayez

dimproviser et de concevoir des techniques pour la tester (par exemple en utilisant

des valeurs dentreacutees qui peuvent pousser la fonction dans dautres chemins)

o Utilisez un diagramme deacutetats pour deacutecrire les diffeacuterentes actions et transitions que

129

lapplication peut prendre pour toutes les entreacutees possibles Essayez ensuite de

trouver les contradictions dans Je modegravele

La proceacutedure

bull Le travail doit ecirctre fait individuellement et aucun contact avec un(e) autre eacutetudiant(e)

nest permis durant toute lactiviteacute de test

bull Notez Jheure de deacutebut et de fin de vos tests exploratoire

bull Durant votre activiteacute de test agrave chaque fois que vous trouvez un bogue inscrivez les

informations demandeacutees dans la liste que vous a eacuteteacute remise Vous devez deacutecrire en

deacutetail lerreur Vous devez deacutecrire briegravevement comment vous avez reacutealiseacute quil sagit

dune eueur par exemple labsence dun menu ou changement dans la valeur de

sortie preacutevue etc Vous devez aussi classer lerreur selon sa graviteacute Ces

informations sont aussi donneacutees avec Je fonnulaire dinscription des deacutefectuositeacutes

ANNEXE D

RAPPORT DE LA SESSION DE TEST

Nom de leacutetudiant(e)

bull Comment eacutevaluez-vous vos connaissances en Java

Niveau Jamais vu Introduction Intermeacutediaire Avanceacute Expeacuterimenteacute

Estimation

bull Classification

On classifie la seacuteveacuteriteacute des erreurs en trois niveaux

o Fatale (F) Japplication est inopeacuterable complegravetement (Crash)

o Grave (G) lapplication fonctionne mais certaines fonctions sont inopeacuterables ou certains reacutesultats sont erroneacutes

o Mineure (M) limpact est mineur sur Jutilisation du systegraveme ex certains formats sont erroneacutes bien que les reacutesultats soient corrects ou encore les deacutelais sont supeacuterieurs agrave ce quon attend dune telle application

Noubliez pas de prendre des notes sur les techniques dexploration que vous utilisez

Description de lerreur Classification

REacuteFEacuteRENCES

Abran Alain Lucie Laframboise et Pierre Bourque 1999 laquo A Risk Assessment Method and Grid for Software Engineering Measurement Programsraquo Montreacuteal Universiteacute du Queacutebec agrave Montreacuteal

Amland Stale et Jarle Vaga 2002 laquo Managing High Speed Web Testing raquo In Software Quality and Software Testing in Internet Times sous la dir de Meyerhoff Dirk Begona Laibarra Rob Van Der Pouw Kraan et Alan Wallet P 23-30 Berlin Springcr

Amland Stale 2002a laquoExploralory Testing Planning Execution and Documentationraquo Version (120) wwwtestingeducationorg

Amland Stale 2002b laquoExploratory Testing Stylesraquo Version (120) wwwtestingeducationorg

Bach James 2007 laquoRapid Software Testing raquo Version (132) wwvvsatisficccom

Bach James et Jonathan Bach 2006 laquoExploratory Testing Dynamics raquo Version 16

Bach James 2003 laquoExploratory Testing Explained raquoVersion (13)

Bach James Bret Pettichord ct Cem Kaner 2002 Lessons Learned in Sofiware Testing New York Johon Wiley amp Sons

Bach James 2001 laquoExploratory Testing and Planning Mythraquo (StickymindsCom) 19 mars

Bach James 1999 laquoGeneral Functionality and Stability Test Procedureraquo wwwsatisficecom

Bach James J996 laquoHeuristic Test Strategy Moderaquo wwwsntisficccom

Bach Jonathan 2000 laquo Session Bascd Test Management raquo SofilVare Testing and Quality Engineering novembre

Basili Victor Richard Selby ct David Hutchens J986 laquoExperimentation in Software Engineeringraquo IEEE Transactions on software engineering vol J 2 no 7 p 733-743

J32

Beedle Mike et al 200 J laquoManifesto for Agi le Software Developmentraquo Consulteacute janvier 2007 httpagilemanifcstoorg

Black Rex 1999 Managing the Testing Process Redmond (Wachington) Microsoft Press

Beizer Boris 1995 Black Box Testing Techniques for Functional Testing of Software and Systems New York Johon Wiley amp Sons

Beizer Boris 1990 Software Testing Techniques 2 eeacuted New York Van Nostrand Reinhold

Boehm Barry W et Richard Turner 2004 Baancing Agility and Discipline Boston Addison-Wesley

Boehm Barry W 198 1Software Engineering Economics Upper Sadd le River (NJ) Prentice-Hall

Bolton Michael James Bach et Cem Kaner 2005 laquo Rapid Testing ExpJained raquo International Quality Conference 200SToronto octobre

Copeland Lee 2004 A Practitioners Guide 10 Software Tesl Design Boston Artcch HOllse Publ ishers

Craig Rick et Stefan Jaskiel 2002 Systematic Sojiware Tesling Boston Artech Housc Publishers

Hendriekson Elizabeth 2005 laquo Agile Testing raquo Video de Googlc wwwgooglecom

Hetzel William C1988 The Campete Guide la Sojiware Tesling 2 C eacuted New York Johon WiJeyamp Sons

Hoffman Douglas 1999 laquoHeuristie Test Oraclesraquo Sofiware Testing and Quairy Engineering marsavril wwwsoftwnrequalitymcthodscomPapersSTOE20Heuristicpdf

ltkonen Juha et Kristian Rautiainen 2005 laquo Exploratory Testing A Multiple Case Studyraquo Empirica Software Engineering 2005 1l1lernationa Symposium novembre

1EEE829 1998 Standardfor Soflware Test Documentotion New York IEEE press

lEEE729 1983 laquolEEE Computer Society 1EEE Standard Glossary of Software Engineering TerminoJogyraquo

133

JEEE610 1990 laquoIEEE Standard Glossary of Software Engineering TerminologyraquoJEEE STD6102

James David et Bill Wood 2003 laquoApplying Session Based Testing to Medical Softwareraquo Medical Deviceamp Dignostic lndustry mai

Jones TCapers 1998 Estimating Software Costs New York McGraw-Hill pSS4

Kan Parrish et Manlove 2001 laquoIn-process Metrics for Software Testingraquo IBM Systems Journa vol 40 no 01

Kaner Cern 2006 laquoExploratory Testing after 23 Yearsraquo Conference of the Association for Software Testing Indianapolis (US) wwwTestingeducationcom

Kaner Cern et James Bach 2005 laquo Scripting An Jndustry Worst Practice raquo Back Box Testing Course wwwTestingeducationcom

Kaner Cern 2004 laquoThe Ongoing Revolution in Software Teslingraquo Software Test amp Performance Conference (Baltimore MD 7-9 deacutecembre 2004) wwwTcstingeducationcom

Kaner Cern et James Bach 2004 laquoThe Nature of Exploratory Teslingraquo Software Tesling Day University Tampere Finland consulteacute le 15012007

Kaner Cern 2003 laquoWhat is a Good Test Case raquo STarEast Conference May 2003 httpwwwkanercompdfsGoodTestpdf

Kaner Cern et Andy Tinkham 2003a laquoExploring Exploratory Testingraquo STarEast Conference on Software Testing Analysis and Review (Orlando FL May 12-16 2003)

Kaner Cern et Andy Tinkham 2003b laquoLearning Style and Exploratory Testingraquo Pacifie Northwest Software Quality Conference (Portland OR October 13- J 52003)

Kaner Cern Jack Falk ct Hung Quoc Nguyen 1999 Testing Computer Sojiware 2 e eacuted New York John Wiley and Sons

Kaner Cern 1997 laquo The lmpossibiity of Complete teting raquo Low of Sofiware Quairy Coumn Software QA vol 04 no 04 hltpvwwkancrcompdfslimposspdf

Kaner Cem1996 laquoSoftware Negligence and Testing Coverageraquo Sofiware QA quartery vol 02 no 03 p 18 httpwwwkanercomcovcragchtm

Kaner Cern 1988 Testing Computer Sojiware 1 erceacutedi New York McGraw-Hill

Kohl Jonathan 2005 laquoExploratory Tesling on Agile Teamsraquo InformitCom 18 Novembre httpwwwinformitcomartielcs

134

Lindsay James et Neil Van Eeden 2003 laquoAd ventures in Session Based Testingraquo Version 12 hltplwwwworkroom-productionscomlpapcrsAiSBTv 12pdf

Lott Christopher et Rombach Dieter J997 laquo Repeatable software engineering experiments for comparing defect detection techniquesraquo Empirical Software Engineering vol 0 l no 03 p241-277

Mack Arien et Irvin Rock 2000 laquoInaltentional Blindnessraquo Cambridge (MA) Bradford BooksMIT press

Marick Brian 2003 laquo Agile Methods and Agile Testing raquoSoftware Testing and Quality Engineering vol 03 no 05

Myers Glenford J 1979 The Art ofSoftware Testing 1 ere eacutedi New York Johon Wiley

Osterweil Leon 1996 laquoStrategie directions in software quality raquo ACM Computing SUIveys vol 04 no 04

Perry William E 2000 Effective Methodsfor Software Testing 2 C eacutedi Johon WiJey and Sons

Petty Kenn 2005 laquoReflections on the Use of Session Based Exploratory Testing as the Primary Test Methodology for Software in an Agile Environmentraquo lndianapolis Workshops on Software Testing hltpwwwiwst2007comlimagcsRefleelions on the use of SessionshyBased Exploratory Tcsting in an_ Agile _Environmcntdoc

Pettichord Brel 2002 laquoAgile testing What is it Can it work raquo Consulteacute Janvier 2007 wwwPeltichordcom

Pressman Roger 1997 Software Engineering A Practitioner s Approach 4 Ceacutedi New York MeGraw-Hill

Pyhajarvi Maarct KJistian Rautiainen ct Juha ltkonen 2003 laquolncreasing understanding of the modern testing perspective in software product development projects raquo IEEE Computer Society Proceedings of the Hawaii International Conference on System Sciences

Royce Wiston J 970 laquoManaginw the Development of Large Software Systems Concepts and Techniquesraquo Reprinted in 9 International Conference in Software Engineering Los1

Alamitos (CA) IEEE Computer Society Press p 328-338

SWEBOK 2004 laquo Guide to the Software Engineering Body of Knowledge raquo IEEE Computer Society Version 2004 httpwWvswcbokorg

13S

Thompson Neil 2003 laquoBest Practices and Context-Driven Building a Bridgeraquo International Conference on Software Testing Analysis and Review StarEast FJorida StickyMinds Magazine

Whittaker James A 2003 How to Break softwaremiddot A Practica Guide to Testing Boston Addison Wisely

Winer Ben James 1971 Statistica Principes in Experimental Design 2 e eacutedi New York McGraw Hill

Wood Murray Marc Roper Andrew Brooks et James Miller 1997 laquo Comparing and Combining Software Defect Detection Techniques A Replicated Empirical Study raquo ACM SIGSOFT Proceeding on the Foundations of Software Engineering NdegS Zurich SUISSE (22091997) vol 22 no 6 New York Springer-Verlag (ACM Press)

v

LEacuteTUDE EMPIRIQUE 60

51 MOTIVATIONDELEacuteTUDE 60

52 LA STRATEacuteGIE DE LEXPEacuteRIENCE 61

53 LE SCHEacuteMA DE LEXPEacuteRIENCE 63

531 Objectifs et hypothegraveses de lexpeacuterience 63

532 La conception expeacuterimentale 64

533 Les instruments de Jeacutexpeacuterience 64

534 Le traitement expeacuterimental 65

54 ANALYSE DES REacuteSULTATS DE LEXPEacuteRIENCE 67

541 AnaJyse des resulats de test exploratoire 67

542 Analyse des reacutesultats de TE et TS 70

55 CONCLUSION 73

CHAPITRE VI 74

CADRE CONCEPTUEL DE COMPARAISON 74

61 MISE EN CONTEXTE DE LEacuteTUDE COMPARATIVE 74

62 CADRE CONCEPTUEL DE COMPARAISON 76

621 Les caracteacuteristiques dutilisation 77

622 Les caracteacuteristiques de gestion 78

623 Les caracteacuteristiques techniques 78

624 Les caracteacuteristiques du personnel 78

625 La productiviteacute 79

63 CONCLUSION 81

CHAPITRE VII 82

ANALYSE COMPARATIVE DU TEST EXPLORATOJRE ET DU TEST SCEacuteNARJSEacute 82

71 COMPARAISON SeLON LES CARACTlR1STIQUES DUTILISATION 82

7 ]1 Les raisons dutilisation 82

712 Les caracteacuteristiques du logiciel 85

VI

713 Le type denvironnement daffaire 87

7IA Les ressources financiegraveres 88

715 Le temps de test disponible 89

72 COMPARAISON SELON LES CARACTEacuteRIST1QUES DE GESTION 91

721 La planification 91

722 Le controcircle et le suivi de progression de test 93

723 La communication dans le projet de test 94

72A La relation avec le client 96

73 COMPARAISON SELON lES CARACTEacuteRISTIQUES TeCHNIQUES 96

731 Les activiteacutes de test 97

732 Les risques du logiciel 100

733 La couverture de test 102

734 Loracle de test 103

74 COMPARAISON SELON LES CARACTEacuteRISTIQUES DU PeRSONNEL 106

7AI Les carateacuteristiques du testeur 106

75 COMPARAISON SELON lA PRODUCTIVITEacute 108

77 CONClUSiON 113

CHAPITRE VIII 114

ANALYSE DES REacuteSULATS 114

81 ANALYSE DES RESULTATS THEORIQUeS 114

82 ANALYSE DES REacuteSULTATS EMPIRIQUES 115

83 PISTES POTENTIELLES DE RECHERCHE 117

8A CONCLUSION ] 18

CONCLUSION 119

ANNEXE A 121

CADRE DE BASILI ADAPTEacute Agrave LA RECHERCHE EXPLORA TUumlIRE 121

ANNEXE B 124

vu

PLAN DE TEST IEEE829 124

ANNEXE C 127

SOIREacuteE DE TESTS 127

ANNEXE D 130

RAPPORT DE LA SESSION DE TEST 130

REacuteFEacuteRENCES ~ 131

YJJI

LISTE DES TABLEAUX

Tableau 11 Cadre de Basili adapteacute agrave la recherche exploratoil-e 7

Tableau 21 La matrice de traccedilabiliteacute 25

Tableau 31 Grille des tacircches de test exploratoire 34

Tableau 51 ANOVA des donneacutees collecteacutees de lexpeacuterience 73

Tableau 71 Le guide de seacutelection de lapproche de test III

IX

LISTE DES FIGURES

Figure 21 Le pourcentage des erreurs danalyse et de conception 17

Figure 22 Modegravele de test en V 18

Figure 23 Les pratiques de test Agile 20

Figure 24 Scheacutematisation des documents de preacuteparation de tests 22

Figure 25 Speacutecification de Cas de Test 26

Figure 31 Continuum repeacuterant lactiviteacute de test 33

Figure 32 Cadre dapplication de SBTM 37

Figure 33 Heuristic Test Strategy Model 40

Figure 41 Coucirct de documentation versus linnovation dans le test 55

Figure 52 Le traitement de test exploratoire 66

Figure 53 Les reacutesultats de test exploratoire 67

Figure 54 Importance de deacutefauts deacutetecteacutes avec le test exploratoire 68

Figure 55 LinOuence de lexpertise su r le test exploratoire 70

Figure 56 Reacutesultats des sujets aux TE ct TS 71

Figure 57 Repreacutesentation scheacutematique de lanalyse ANOVA 72

Figure 61 Le cadre conceptuel de comparaison 80

Figure 71 Les eacuteleacutements essentiels du test du logiciel 97

Figure 72 Les activiteacutes de test sceacutenariseacute 98

Figure 73 Les activiteacutes de test exploratoire 99

x

LISTE DES ABREacuteVIATIONS

COS Context Driven School

Institute ofElectrical and Electronics IEEE

Enginecrs

SBET Session Based Exploratory Testing

SBTM Session Based Test Management

SWEBOK Software Engineering Body ofKnowledge

UQAgraveM Universiteacute du Queacutebec Agrave Monlreacuteal

TE Test exploratoire

TS Test sceacutenariseacute

Xl

REacuteSUMEacute

Le test exploratoire (TE) est deacutefini comme lapprentissage la conception et jexeacutecution simultaneacutes des tests tout agrave fait lopposeacute du test sceacutenariseacute (TS) preacutedeacutefini Lapplicabiliteacute de cette nouvelle approche ne cesse pas daugmenter dans lindustrie du test de logiciel Malgreacute cette expansion et le succegraves de quelques entreprises qui souvrent dans le domaine de deacuteveloppement du logiciel dans ses expeacuteriences dadoption et dutilisation de TE les contextes et les facteurs favorables pour ladoption de lapproche dans une meacutethodologie de test ne sont pas toujours bien eacutetablis Labsence des preuves claires de sa productiviteacute annonceacutee par quelques praticiens dans la litteacuterature sajoute agrave la probleacutematique Ce travail est une eacutetude exploratoire visant deux objectifs Premiegraverement eacutetudier et analyser les contextes favorisant lutilisation de TE comme une meacutethodologie primaire de test agrave la place des tests sceacutenariseacutes en eacutelaborant une analyse comparative entre le TE et le TS Deuxiegravemement eacutevaluer sa productiviteacute dans une eacutetude empirique par rapport au TS Nous avons eacutelaboreacute un cadre conceptuel de comparaison dans lequel nous avons identifieacute cinq dimcnsions o Les caracteacuteristiques dutilisation les raisons de lutilisation les caracteacuteristiques du

logiciel le type denvironnement daffaires les ressources financiegraveres et le temps disponible pour les tests

o Les caracteacuteristiques de gestion la planifIcation le controcircle ct le suivi des tcsts la communication dans le projet de test ct la relation avec le client

o Les caracteacuteristiques techniques les activiteacutes de test joracle de test les nsques du logiciel ct la couverture de test

o Les caracteacuteristiques du personnel les caracteacuteristiques des testeurs la culture de lorganisation

o La productiviteacute le nombrc de deacutefagraveuts deacutetecteacutes limportance de deacutefauts deacutetecteacutes

Cc cadre a eacuteteacute utiliseacute comme base dans Janalyse comparative du TE et du TS Dans cette analyse nous avons compareacute une approche disciplineacutee de TS guideacute par les patrons de documentation IEEE 829 ct une approche librc scmi planifieacutee de TE rcpreacutesenteacutec par lapproche Session Based Exploratory Testing (SI3ET) Dans cette comparaison la productiviteacute a eacuteteacute eacutevalueacutee par le biais dunc eacutetudc cmpirique que nous avons mise en œuvre dans les laboratoires informatiques de LUQAgraveM Malgreacute les limites du contexte de cette eacutetude empirique nous avons pu deacutegager quelques conclusions utiles Les reacutesultats permettent de montrer que certains facteurs de contexte du projet de test peuvent empecirccher lutilisation de TE comme une meacutethode principale de test Nous avons conclu que labsence de controcircle de couverture de test restreint en plus le type des projets ougrave le TE pourrait ecirctre utiliseacute Aussi lexpertise ct les qualifications neacutecessaires pour exeacutecuter le TE pourraient cmpecirccher son utilisation dans les projets de tests ougrave ces qualifications sont manquantes Les reacutesultats de jeacutetude empirique ont supporteacute lhypothegravese relative agrave limportance des deacutefauts deacutetecteacutes Dautres recherches quantitatives sur la productiviteacute de TE sont neacutecessaires dont ce travail pourra servir comme point de deacutepart

Mots-cleacutes

Test Test seeacutenariseacute Test exploratoire Session Based Exploratory Test (SBET)

INTRODUCTION

La croissance rapide de jutilisation des systegravemes infonnatiseacutes dans tous les domaines donne

une importance cruciale au problegraveme des anomalies informatiques De nos jours les

ordinateurs aident les humains dans la plupart des aspects de notre vie quotidienne et les

applications informatiques sont rendues plus puissantes et complexes Agrave cet effet

limportance de produire du logiciel de grande qualiteacute et robuste est devenue primordiale

(Osterweil 1996) Or la forte demande de produits logiciels de qualiteacute fait que les

organisations sont en quecircte continuelle de moyens pouvant leur permettre de produire de la

qualiteacute dans les temps ct dans le cadre du budget Un des moyens est Je test du logiciel

Dans les modegraveles traditionnels de deacuteveloppcment le test est un processus important II

soutient Jassurance qualiteacute en fournissant dcs informations sur la qualiteacute du logiciel

deacuteveloppeacute ou modi fieacute Lactiviteacute de test dans ces modegraveles est extrecircmement laborieuse et

demande des ressources importantes allant de 50 agrave 60 du eoucirct de deacuteveloppement (Perry

2000) Cependant la concurrencc sans ccsse croissante oblige les entreprises agrave sadapter aux

changements du marcheacute dans des cycles de deacuteveloppement plus courts Tester un logiciel

dans telles conditions nest plus une tacircche facile seffectue souvent sous la pression de temps

ct de budget Cela force lindustrie informatique agrave chercher de nouvelles meacutethodes efficaces

de test pour eacutepargner temps el argcnt et en produisant des logiciels de qualiteacute

Une nouvelle pratique dc test qui a fait son apparition a la fin des anneacutees 80 avait remis en

eause la vision traditionnelle des tests Cette pratique se deacutefinit comme lapprentissage la

conception ct lexeacutecution simultaneacutee des tests Cette derniegravere est tout agrave fait lopposeacute de la

meacutethode habituelle et sceacutenariseacutee de test neacutecessitant la speacutecification des cas de tests deacutetailleacutes

et des reacutesultats preacutevus avant jcxeacutecution de tests

2

Au deacutebut cette nouvelle pratique a eacuteteacute confondue avec le test ad hoc qui est trop souvent le

synonyme dun processus improviseacute intuitif pour chercher les deacutefauts du logiciel (Bach

2003) En 1990 un groupe dexperts en tests connu sous le nom anglophone Context Driven

School (CDS) laquo Test piloteacute par le contexteraquo a adopteacute le terme anglophone Exploratory

Testing laquo test exploratoireraquo pour deacutecrire et nommer cc type de test qui est deacutecrit dabord par

Kaner ( 1988)

Depuis son apparition le test exploratoire (TE) a eacuteteacute preacutesenteacute comme une innovation dans

lindustrie du test Une innovation pouvant garantir un niveau defficaciteacute de lactiviteacute de test

qui ne pourrait pas ecirctre reacutealiseacute par le test sceacutenariseacute seul (TS) (Bach 2003 Kaner et Tinkham

2003a) Cependant quelques praticiens ne le voient pas de la mecircme faccedilon et considegraverent le

TE comme un test ad hoc deacuteguiseacute ou enveloppeacute sous le terme scientifique laquo explorationraquo

(Black 1999) Bach (2003) ne nie pas le fait que le TE est une pratique habituelle utiliseacutee

souvent inconsciemment par nimporte quel testeur qui utilise sa creacuteativiteacute pendant lactiviteacute

de test Linnovation de lapproche selon lui est dameacuteliorer la faccedilon avec laquelle ce testeur

effectue ses tests en se basant sur des techniques ct des modegraveles scientifiques dexplorations

Agrave cet efrct les praticiens ct les chercheurs se sont pencheacutes sur lameacutelioration de ces

techniques dans le but de faire du TE une discipline apprise comme nimporte quelle activiteacute

intellectuelle Enfin avec la tendance actuelle des meacutethodes agiles le TE a pu trouver sa

place dans Jindustrie du test (Bach 2003) Les laquo agilistesraquo ont adopteacute le TE compte tenu de

sa grande capaciteacute dadaptation avec les pratiques agiles (Kohl 2005)

Les grandes organisations de deacuteveloppement du logiciel ont commenceacute agrave consideacuterer le TE

comme une approche valide de test Microsoft a utiliseacute un type structureacute et documenteacute de TE

impleacutementeacute par Bach (1999) pour tester et certifier une application pour la compatibiliteacute et la

stabiliteacute avec Windows 2000 Dautres entreprises sajoutent continuellement parce quelles

cherchent des meacutethodes plus rentables de test Toutefois chacune delles adopte lapproche

dune faccedilon personnaliseacutee avec les contraintes de son contexte

Malgreacute le succegraves obtenu par quelques entreprises dans limplantation de TE les contextes

favorables pour uti liser et impleacutementer lapproche ne sont pas encore bien eacutetablis dans la

3

litteacuterature Nous nous sommes fixeacute comme objectif dans ce travail de recherche agrave explorer

ces contextes en analysant les eacutetudes de cas et les expeacuteriences professionnelles publieacutees

reacutecemment Nous avons proceacutedeacute agrave une analyse comparative entre les deux approches de test

le TS et TE pour faire ressortir les facteurs favorables pour utiliser chacune delles

Nous avons proceacutedeacute aussi agrave une eacutetude empirique dc la productiviteacute de TE annonceacutee dans la

litteacuterature surtout par les deux concepteurs de lapproche (Bach 2003 Bach et Kaner

2004) Nous avons eacutevalueacute la productiviteacute de lapproche en termes du nombre et de

limportance des deacutefauts quelle peut deacutetecter Malhcureuscment les limites de contexte ougrave

sest deacuterouleacute notre eacutetude empirique ne nous a pas permis de tirer des conclusions fiables et

geacuteneacuteraliseacutees sur cette productiviteacute Cependant nous avons pu deacutegager quelques indications

utiles

Dans la reacutealisation de ce travail de recherche nous avons ducirc confronter le problegraveme de la

peacutenurie des travaux de recherches ct de la litteacuterature qui traite Je sujct de TE Malgreacute que

cette approche ait eacuteteacute introduitc dans le domaine de test logiciel il y a plus dc vingt ans elle

na pu que reacutecemment attirer linteacuterecirct des chercheurs autres que les membres de CDS

(ltkonen ct Rautiainen 200S)Labsence des connaissances agrave ce sujet nous a obligeacutee agrave avoir

recours agrave notre jugement dans cette analyse comparative cn sappuyant sur notre

compreacutehension de tous les eacuteleacutements relieacutes agrave lactiviteacute de test Notre approche a eacuteteacute de

sappuyer sur la litteacuterature ainsi que sur divers concepts theacuteoriques

Dans le cadre de cette recherchc nous proceacutedons par une eacutetude cxploratoire pUisque les

connaissances dans le domaine que nous traitons dans cc travail de recherche ne sont pas

encore bien eacutetablies

Ce meacutemoire est composeacute de huit chapitres Dans le chapitre l nous deacutefinirons notre sujet de

recherche la probleacutematiquc la motivation la porteacutee lobjectif les utilisateurs ct les limites

du projet selon la meacutethode de (Abran ct al J 999) que nous avons adopteacutee pour la mise en

œuvre de cc travail de recherche Dans le chapitre Il nous preacutesenterons une vue densemble

de TS afin didentifier ses eacuteleacutemcnts fondamentaux ct de comprendre ses points de diffeacuterence

4

avec le TE Dans le chapitre Ill nous preacutesenterons une vue densemble de TE Puis dans le

chapitre IV nous proposerons une revue de litteacuterature de quelques eacutetudes de cas et

expeacuteriences dutilisation de TE dans lindustrie de test Le chapitre suivant deacutecrit leacutetude

empirique que nous avons meneacutee en laboratoire Nous preacutesenterons dans le chapitre VI le

cadre conceptuel de comparaison que nous avons deacuteveloppeacute dans le cadre de notre recherche

Le chapitre VlI preacutesentera notre analyse comparative de TE et TS Nous preacutesenterons des

suggestions et les contextes favorables pour utiliser le TE comme unc meacutethodologie primaire

de test Le dernier chapitre porte essentiellement sur les reacutesultats danalyse linterpreacutetation

de ces reacutesultats et les perspectives futures de recherche Enfin nous terminerons notre rapport

avec une conclusion

11

CHAPITRE 1

DEacuteFINITION DU SUJET DE RECHERCHE

Eacutenonceacute de la probleacutematique

Lapparition de test exploratoire (TE) dans le domaine du test du logiciel a susciteacute beaucoup

de controverse quant agrave sa validiteacute et agrave son efficaciteacute Pour certains praticiens le test

exploratoire est toujours le test ad hoc deacuteguiseacute sous le terme scientifique laquoexplorationraquo

(Black 1999) Selon Black (1999) Ic TE ne diffegravere pas de la technique laquo Error Guessing raquo

proposeacutee par Myers (l97) qui a toute fois preacuteciseacute quil ne sagit pas dune technique de test

mais seulement de lintuition Selon Bach (2003) le TE est une approche valide de test tout

comme le test sceacutenariseacute (TS) et il pourrait ecirctre dans certaines situations plus productif que le

TS La diffeacuterence sur la reconnaissance ct la valeur de TE qui est le chef dœuvre ct

linvention de la penseacutee Context Oriven School (CDS) a lanceacute un deacutebat entre les intervenants

preacuteconisant les principes de cette eacutecole de penseacutee ct les adheacuterents de la discipline

La philosophie de la penseacutee CDS est deacutetablir une relation consciente explicable et

autocritique entre le processus de test et le contexte de test Autrement dit le testeur devrait

ajuster ses solutions convenablement au problegraveme courant et ecirctre capable de controcircler son

processus de test ct dapporter des changements au moment voulu pendant le processus En

2001 les trois membres fondateurs de CDS Kaner Bach et Pettichord ont formuleacute les sept

principes cleacutes de leur discipline ct ils les ont publieacutes dans le premier livre portant sur les

pratiques et les ideacutees de ce groupe (Bach et al 2002) Il sagit des principes deacutecrits cishy

dessous (traduit de Bach et al 2002 p 261)

bull La valeur de nimporte quelle pratique deacutepend de son contexte

bull li ya de bonnes pratiques dans un contexte mais il ny a aucune mei Ileure pratique

6

bull Des personnes qui collaborent entre elles sont les parties les plus importantes de

nimporte quel contexte de projet de test

bull Les projets se deacuteroulent souvent dune maniegravere impreacutevisible

bull Le produit est une solution agrave un problegraveme Si le problegraveme nest pas reacutesolu le produit ne

pourra pas fonctionner

bull Un bon test logiciel est un processus intellectuel comportant plusieurs deacutefis

bull Seulement par les compeacutetences qui sexercent dune faccedilon coopeacuterative dans tout le

projet nous sommes capables de prendre les bonnes deacutecisions au bon moment pour

tester efficacement le produit

Par contre la discipline met laccent sur des principes diffeacuterents de ceux citeacutes ci-dessus

Entre autres la normalisation la documentation et le formalisme du processus constituent les

eacuteleacutements clefs du processus de test (Thompson 2003) Alors il ressort des principes de deux

eacutecoles que le CDS accentue le rocircle de la personne ses qualifications et la collaboration entre

les intervenants dans le projet de test tandis que la discipline accentue le rocircle du processus

sa gestion et sa mesure dans le projet de test En dautres telmes Ic test devrait ecirctre

preacutedictible enchacircsseacute dans un cadre de travail planifieacute et documenteacute dont la norme de

documentation IEEE 829 pourrait constituer une partie inteacutegrante (Swebok 2004)

Les deacutefenseurs des deux approches de test le TS et le TE ont lanceacute un deacutebat qui oppose le

formel contre jinformel les proceacutedures contre la liberteacute luniformiteacute contre la creacuteativiteacute et le

controcircle contre lefficaciteacute Les auteurs ct les praticiens de CDS annoncent quc le TE est une

approche productive qui pourrait constituer une meacutethode principale ct indeacutependante de test

(Bach 2003 Kaner 2006) Toutefois ces mecircmes praticiens nont pas identifieacute les contextes

favorables dutilisation de TE

De plus ils nont pas proposeacute des preuves concregravetes de sa productiviteacute largement annonceacutee

dans la litteacuterature agrave part quelques anecdotes et expeacuteriences veacutecues eacutelaboreacutees dans dcs

contextes personnels (Bach 2003)

7

12 Meacutethode de recherche

Dans le cadre de cette recherche exploratoire la deacutemarche meacutethodologique suivie est baseacutee

sur le cadre de Basili (Abran et al 1999) adapteacute aux eacutetudes de cas de type exploratoire Ce

travail est inclus sous le thegraveme de recherche exploratoire compte tenu du fait que les

problegravemes souleveacutes sont peu abordeacutes dans la litteacuterature Nous essayons de clarifier la base de

connaissances sur le TE et de trouver des pistes futures de recherche

Le cadre proposeacute est composeacute de quatre eacutetapes principales la deacutefinition la planification

lopeacuteration et linterpreacutetation Chaque phase deacutecrit les activiteacutes etou les livrables agrave

entreprendre afin datteindre les objectives de celle recherche Un modegravele de ce cadre est

preacutesenteacute dans le tableau 11 La deacutefinition du projet est preacutesenteacutee dans la scction qui suit La

structure suivie dans ce travail de recherche est proposeacutee dans lannexe A

Tableau 11 Cadre de Basili adapteacute agrave la recherche exploratoire (Abran ct al 1999)

1 Deacutelinition

Motivation Objet Objectif Utilisateurs

2 Planification

Etapes du projet Inlrants Livrables du projet

3 Opeacuteration

Analyse des documents Fcedback des praticiens Modegravele proposeacute

4 1nlerpreacutetation

Contexte Extrapolalion Travaux futurs

13 Deacutefinition du projet

La deacutefinition de la recherche agrave partir du cadre a permis deacutetablir la motivation la porteacutee les

obj ectifs de recherche les utilisateurs des reacutesultats de celle recherche et la planification du

projet de recherche

8

131 La motivation

La motivation principale de ce travail de recherche est dexplorer les apports du TE Il sagit

aussi dexplorer lampleur de la divergence entre les deux eacutecoles de penseacutees ]a discipline et

le CDS par le biais dune eacutetude comparative approfondie des meacutecanismes et des techniques

utiliseacutes dans le TS et dans le TE La productiviteacute du TE est fortement annonceacutee par quelques

praticiens ce qui nous a aussi motiveacutee agrave entreprendre une eacutetude empirique pour eacutevaluer la

validiteacute de ces annonces Nous voulons par cette recherche contribuer agrave ameacuteliorer le

processus de choix de lapproche convenable de test en deacuteveloppant un guide deacutevaluation

des facteurs de contexte de projet de test Ce guide va permettre de clarifier les contextes

favorables pour utiliser le TE comme une meacutethodologie primaire de test

132 La porteacutee

Cette eacutetude traite le test dynamique du logiciel selon lin proceacutedeacute boicircte noire Elle porte sur la

comparaison de deux approches de test le TE ct TS

133 Lobjectif

Lobjectif de notre eacutetude est de preacutesenter un ensemble de faits theacuteoriques et expeacuterimentaux

qui peuvent justifier une reacuteponse agrave notre question de recherche principale

bull Est-ce que le test exploratoire pourrait remplacer le test sceacutenoriseacute Si oui dans quels

contextes

Pour reacutepondre agrave la question principale de la recherche nous essayons dabord de trouver des

reacuteponses aux questions secondaires suivantes

1 Quels sont les facteurs de contexte de test qui influencent le choix de Japproche de

test

2 Parmi ces facteurs quels sont les facteurs de contexte de test favorables pour utiliser

leTE

Pour reacutepondre agrave toutes ccs questions nous avons effectueacute une analyse comparative de TE par

rappol1 au TS cn utilisant un cadre conceptuel de comparaison deacuteveloppeacute dans le cadre de ce

9

travail de recherche Ce cadre inclut des critegraveres ou des facteurs de comparaison formuleacutes agrave

partir des reacutesultats des eacutetudes de cas de TE proposeacutees dans la litteacuterature ct en sinspirant du

cadre de comparaison proposeacute par Tumer et Boehm (2004) Cette analyse comparative va

permettre de souligner les contextes favorables agrave chacune des deux approches de test Par la

suite nous avons conclu sur les contextes ougrave le TE peut remplacer le TS

Dans le cadre de cette eacutetude comparative nous avons proceacutedeacute agrave une eacutetude empirique de la

productiviteacute de TE Agrave cet effet nous avons reacutealiseacute une expeacuterience dans les laboratoires

informatiques de lUQAgraveM Lobjectif principal de cette expeacuterience eacutetait de veacuterifier la

productiviteacute de TE en telmes de nombre et dimpo11ance de deacutefauts qui pourraient ecirctre

deacutetecteacutes en utilisant cette meacutethode de test De plus cette eacutetude empirique a porteacute sur la

comparaison de la productiviteacute de TE par rapport au TS autrement dit lanalyse de leffet de

la technique de test (TE TS) sur la productiviteacute de lactiviteacute de test en utilisant un

eacutechantillon composeacute de 56 sujets (les eacutetudiants de cours INF6160 session de lautomne

2005) Chaque eacuteleacutement de leacutechantillon a appliqueacute les deux techniques de test sur un

programme choisi Dans notre plan expeacuterimental les mecircmes sujets sont utiliseacutes dans les deux

traitements Cc type deacutetude est qualifieacute de plan expeacuterimental agrave un seul facteur agrave mesures

reacutepeacuteteacutees laquoSingle Factor Experiments Having Reapted Measures on The Same Elementsraquo

Nous avons exploiteacute et analyseacute les reacutesultats de deux faccedilons diffeacuterentes la premiegravere

lexploitation des reacutesultats de TE collecteacutes de notre expeacuterience que nous comparons avec les

reacutesultats quantitatifs proposeacutes dans la litteacuterature La deuxiegraveme la comparaison des reacutesultats

collecteacutes des deux approches Nous avons proceacutedeacute agrave lanalyse de variance ANOVA proposeacute

par Wincr (197 J p 105)

En geacuteneacuteral notre eacutetude vise la clarification des connaissances concernant le TE et sinteacuteresse

tout particuliegraveremcnt agrave leacutevaluation de sa contribution dans le domaine du test logiciel Nous

voulons preacutesenter les faits et les arguments existant dans la litteacuterature accompagneacutes de nos

deacuteductions personnelles

134 Description des utilisateurs des reacutesultats de la recherche

Ce travail de recherche revecirct de linteacuterecirct pour plusieurs types dintervenants les chercheurs

10

en terme de contribution agrave louverture de nouvelles pistes de recherche pour les praticiens et

les entreprises en terme de productiviteacute et rentabiliteacute de jactiviteacute de test et gains financiers et

les enseignants en terme didentification des nouvelles matiegraveres pour le cours dc test du

logiciel

1341 Les chercheurs

Les reacutesultats de ce projet de recherche pourront ecirctre utiliseacutes par les chercheurs inteacuteresseacutes par

leacutetude de TE Comme domaine de recherche les contextes favorables pour utiliser le TE

nont pas eacuteteacute eacutetudieacutes Ainsi la productiviteacute du TE en termes du nombre et de limportance

des deacutefauts qui pourront ecirctre deacutetecteacutes a eacuteteacute peu eacutetudieacutee empiriquement Dougrave limportance

des pistes et des solutions proposeacutees dans ce travail de recherche Lcs reacutesu hats theacuteoriques et

empiriques de cette eacutetude pourront ecirctre reacuteutiliseacutes dans dautres reacutepeacutetitions empiriques et

travaux futurs afin denrichir les connaissances existantes sur le TE

1342 Les entreprises

Au nivcau pratique cette recherche sinscrit dans un courant de preacuteoccupation des praticiens

et des entreprises dans le domaine de test du logicicl qui voudraicnt adopter et adapter le TE

clans leurs meacutethodologies de test En effet les patriciens et les entreprises veilleront avec plus

dimportance sur la rentabiliteacute de lactiviteacute de test en reacuteduisant la dureacutee du cycle de test et en

diminuant les efforts consacreacutes aux tests Le guide de seacutelection de lapproche de test reacutesultant

de lanalyse comparative entre le TE et le TS vise lidentification des contextes favorabIes

pour utiliser chacune des deux approches de tcst afin datleindre la rentabiliteacute et la

productiviteacute voulues et de reacutepondre aux besoins des praticiens et les entreprises

1343 Les enseignants

Ce travail est destineacute aux enseignants par lidentification des nouvelles matiegravercs pour le

cours de test du logiciel Habituellement la matiegravere de ce cours traite seulement le TS du fait

quelle est la meacutethode habituelle de test dans lindustrie Or la croissance continue de

ladoption de TE justifie linclusion de celui-ci dans les cours de tests pour preacuteparcr les

eacutetudiants agrave reacutepondrc aux besoins de Jindustrie Lutilisation du guide de seacutelection eacutelaboreacute

II

dans le cadre de ce travail serait beacuteneacutefique pour aider les eacutetudiants agrave identifier et agrave

diffeacuterencier les contextes qui favorisent lutilisation de chacune des deux approches de test

135 Les limites du projet

Une limite importante du projet vient de la limitation de contexte de notre eacutetude empirique

Labsence dun contexte industriel ou nous pouvons effectuer notre eacutetude empirique nous a

pousseacutee de faire cette eacutetude dans un contexte acadeacutemique en utilisant des eacutetudiants comme

des sujets de lexpeacuterience et un petit programme comme instrument de lexpeacuterience au lieu

dutiliser un grand logiciel Ceci a influenceacute les reacutesui tats de lexpeacuterience

lA Planification du projet

Dans le but datteindre notre objectif principal nous avons identifieacute les phases suivantes

1 Nous proposons un modegravele de processus de TS en mettant laccent sur les livrables

de chaque eacutetape et la documentation eacutelaboreacutee Notre modegravele suit le standard de

documentation lEEE829 (1998) pour pouvoir contraster les deux penseacutees discuteacutees

dans ce travail agrave savoir la discipline et le CDS chacune est repreacutesenteacutee par sa

pralique successivement le TS et Je TE

2 Nous proposons lapproche Session Based Test Managcmenl (SBTM) qUI va

repreacutesenter le TE dans lanalyse comparative de TE et le TS

3 Nous eacutetudions les eacutetudes de cas et les expeacuteriences dutilisations de TE dans

lindustrie de test Nous deacuteduirons les facteurs qui ont influenceacute Jutilisation ct

ladoption de TE dans la pratique de test

4 Nous reacutealisons notre eacutetude empirique dans les laboratoires informatiques de lUQAgraveM

et nous traitons les donneacutees collecteacutees pendant cette expeacuterience

5 Deacuteveloppement de notre cadre conceptuel de comparaison qui va guider lanalyse

comparative de TE et le TS

12

6 Nous proceacutedons agrave une analyse comparative des deux approches de test le TS et le TE

selon le cadre de comparaison eacutelaboreacute et les reacutesultats de leacutetude empirique

7 Nous discutons les reacutesultats de lanalyse comparative Puis nous concluons les

contextes favorables pour utiliser le TE comme une meacutethodologie primaire de test

Nous terminons par leacutelaboration dun guide de seacutelection de lapproche dc test

Le chapitre 1preacutesente leacutetape 2 laquoPlanificationraquo de cadre de Basili Leacutetape 3 laquoOpeacuterationraquo de

ce cadre sera abordeacutee dans les chapitres Il 111 IV V VI et VII Leacutetape 4 laquoInterpreacutetationraquo

sera abordeacutee dans le chapitre VIII

CHAPITRE II

TEST SCEacuteNARISEacute VUE DENSEMBLE

Ce chapitre preacutesente les eacuteleacutements neacutecessaires agrave la compreacutehension du test sceacutenariseacute (TS) Dans

la premiegravere partie nous deacutefinissons le rs et nous preacutesenterons un bref historique du test du

logiciel Nous faisons ensuite un survol rapide de quelques modegraveles de test Par la suite nous

proposerons un modegravele du processus de TS baliseacute dans les patrons de la norme IEEE 829 et

nous terminons par une conclusion

2] Concepts de base et terminologie

211 Terminologie

Dans cette section nous proposons quelques deacutefinitions et certains termes et concepts

fondamcntaux du test logiciel Premiegraverement nous deacutefinissons les termes erreur deacutefaut et

deacutefaillance Ces termes sutilisent parfois dune faccedilon interchangeable pour deacutecrirc un

mauvais fonctionnement dans le logiciel Swebok (2004) a identifieacute une fautc ou deacutefaut

(Defeu FauI) comme la cause dun mauvais fonctionnement dans le logiciel ct leffet nonshy

deacutesireacute obscrveacute comme deacutefaillance (Faiure) Autrement dit les tests reacutevegravelent lcs deacutefaillances

causeacutees par un deacutefaut qui peut etou doit ecirctre enleveacute En fait Swebok a adopteacute les deacutefinitions

proposeacutees par IEEE agrave ces termes

bull Erreur (Error) Action humeacuteline produisant un reacutesultat incorrect (IEEE 729)

bull Deacutefaut (Defect Bug FanU) une imperfection dans un composanl ou un systegraveme qui

peUl conduirc agrave ce gu un composant ou un systegraveme nexeacutecute pas les fonctions requises

(IEEE 729)

Deacutefaillance (Failure) Fin de la capaciteacute du systegraveme ou du composant agrave effectuer la

fonction rcquise ou agrave Jcffectucr dans les limites speacutecifieacutecs (IEEE 729)

14

212 Cas de test

Cest un ensemble de valeurs dentreacutee de preacute-conditions dexeacutecution de reacutesultats attendus et

de post-conditions dexeacutecution deacuteveloppeacutes pour un objectif particulier tel quexeacutecuter un

chemin pm1iculier dun programme ou veacuterifier Je respect dune exigence speacutecifique (IEEE

610) La norme IEEE829 (1998) a deacutefini un cas de test comme un document indiquant les

entreacutees les reacutesultats preacutevus et les conditions dexeacutecution pour un article de test

Selon Kaner (2003) un cas de test est une question eacutelaboreacutee pour obtenir une information sur

le programme sous test Cette information se reacutevegravele par lexeacutecution du test relieacute agrave cette

question Cet auteur a citeacute deux conseacutequences indirectes de sa deacutefinition la premiegraverc est que

le cas de test devrait ecirctre capable de fournir une information utile au moment de lexeacutecution

Dc ce fait selon lauteur un cas de test eonccedilu au deacutebut de lactiviteacute de test ne pourra pas

reacuteveacuteler une information ulteacuterieurement dans le projet de test quand le logieiel deviendra plus

stable Cest lun des deacutesavantages du TS citeacute par Copeland (2004) La deuxiegraveme implication

que le cas de test ne devrait pas neacutecessairement deacutetecter un deacutefaut mais il suffit quil

fournisse unc information qui souvent megravene agrave la deacutetection dun deacutefaut scion lauteur

Leacutelaboration de ccttc deacutefinition nest pas arbitraire mais proposeacutee pour inclure le cas speacutecial

de cas de tcst cxploratoire (TE) et ee pour deux raisons la premiegravere est que les eas de tests

exploratoires se fondent sur leacutelaboration des questions agrave propos du logieiel sous test (Kaner

ct Tinkham 2003a) La deuxiegraveme est quun cas de test exploratoire ne devrait pas

obligatoiremcnt deacutetecter un deacutefaut mais il suffit quil reacutevegravele une information Cette

information pourrait ecirctre utiliseacutee pour concevoir un autre cas de test qui pouuait mener agrave la

deacutetcction dun deacutefaut (Kancr et Tinkham 2003a)

22 Test sceacutenariseacute (Scripted Tcsting)

Cest un test manuel qui sc fait typiquement par un testeur junior en suivant les eacutetapes et les

proceacutedures conccedilus par un testeur senior (Bach et aL 2002)Ces mecircmes auteurs ont souligneacute

plus tard dans plusieurs reprises que le test sceacutenariseacute pourrait ecirctre automatiseacute (Kaner 2006)

15

Selon Copland (2004) le test sceacutenariseacute est nimporte quelle activiteacute de test manuelle ou

automatiseacutee baseacutee sur la conception et Jenregistrement des scripts deacutetailleacutes de tests avant

lexeacutecution

Dans un TS la planification et la conception des tests se font avant leur exeacutecution Les cas et

les sceacutenarios de test typiquement mais pas neacutecessairement sont deacutefinis tocirct dans le cycle du

deacuteveloppement du logiciel selon le modegravele du cycle de vie utiliseacute On les preacutepare en se

basant habituellement sur le document des speacutecifications des exigences du logiciel dans un

proceacutedeacute de test boicircte noire sans accegraves au code ou sur la logique interne du programme dans

un proceacutedeacute boicircte blanche avec accegraves au code ou une combinaison des deux Les cas de tests

sont alors exeacutecuteacutes par un autre testeur que celui qui les a conccedilus quand le logiciel devient

disponible pour les tests

Historiquement le test sceacutenariseacute a eacutemergeacute en tanl quune phase dans le premier modegravele de

deacuteveloppement en cascade (Royce 1970) Dans ce modegravele le deacuteveloppement est deacutecomposeacute

en plusieurs eacutetapes seacutequentielles dont chacune possegravede des critegraveres dentreacutee et de sortie

preacutecis et des livrables bien deacutetermineacutes Alors le test est lune de ces eacutetapes son rocircle est

deacutevaluer si les exigences sont bien comprises et speacutecifieacutees (Validation) et que la conception

est correctement implanteacutee par le code (Veacuterification) Reacutecemment le TS a franchi des

nouvelles dimensions que ccllcs connues dans Ics anneacutees 70 Alors nimporte quelle

meacutethodologie de deacuteveloppement mecircme les plus agiles peuvent Jutiliser nimporte ougrave la

reacutepeacutetitiviteacute lobjectiviteacute et lauditabiliteacute sont neacutecessaires ct importantes dans le processus de

test du logiciel (CopeJand 2004)

Selon Copeland (2004) la reacutepeacutetitiviteacute signifie que les lests ou les proceacutedures de tests sont

suffisamment deacutetailleacutees pour quils puissent ecirctre exeacutecuteacutes par quelquun autre que leur auteur

original En cc qui concerne lobjectiviteacute elle signifie que la creacuteation de tests ne deacutepend pas

seulement de la creacuteativiteacute et la compeacutetence de son concepteur mais quils sont baseacutes sur des

prineipes de conception bien deacutetermineacutes deacuteriveacutes agrave partir des exigences du logiciel les cas

dutilisations ct les standards agrave respecter dans le projet de test Quant agrave lauditabiliteacute ellc

signifie la traccedilabiliteacute bidirectionnelle entre les speacutecifications dexigences et les cas de tests

16

Cette traccedilabiliteacute permet de mesurer formellement la couvel1ure de test qui sera abordeacutee dans

les sections qui suivent

23 Bregraveve histoire des tests

Myers (1979) a identifieacute le test logiciel en tant quune action dexeacutecuter un programme ou un

systegraveme dans le but de deacutetecter ses deacutefauts Agrave leacutepoque cette deacutefinition a eacuteteacute probablement la

meilleure disponible Elle refleacutetait les pratiques de cette peacuteriode ou le test apparaicirct seulement

agrave la fin du cycle de deacuteveloppement visant principalement la deacutetection des erreurs Puis en

1988 la deacutefinition de test logiciel a changeacute en faveur de leacutevaluation de la qualiteacute du logiciel

plutocirct quun simple processus pour reacuteveacuteler les erreurs Hetzel (1988) a deacutefinit le test comme

une activiteacute dont son but est deacutevaluer et valider les fonctionnaliteacutes du logiciel Reacutecemment

le test est perccedilu comme une activiteacute exeacutecuteacutee pour eacutevaluer et ameacuteliorer la qualiteacute du logiciel

en identi fiant ses deacutefauts et ses problegravemes (Swebok 2004) Par cette deacutefinition Swebok

ajoute lameacutelioration de la qualiteacute du logiciel agrave leacutevaluation de la qualiteacute et agrave la recherche des

deacutefauts Cette meacutethode connue actuellement sous le tenne de laquo test preacuteventifraquo (Craig ct

Jaskiel 2002 Swebok 2004 Perry 2000) Selon Swebok (2004) le test devrait encadrer

lensemble du deacuteveloppement et de la maintenance Cl ecirctre en soi une partie importante de la

construction du produit logiciel

La philosophie de test preacuteventif dicte que le test pourrait ameacuteliorer la qualiteacute du logiciel sil

apparaicirct assez tocirct dans le cycle de deacuteveloppement ]1 sagit de la creacuteation de cas de tests pour

valider les exigences et la conception avant mecircme le codage du logiciel Cela permet de

deacutetecter les faiblesses potentielles et les erreurs dans les premiegraveres phases de deacuteveloppement

et de reacuteduire le coucirct de correction des deacutefauts sachant que plus lerreur est deacutecouverte tocirct

dans le processus moins elle colite cher agrave corriger ct plus lerreur se situe au deacutebut du cycle

de deacuteveloppement plus eUe colite cher agrave corriger ulteacuterieurement dans le cycle (Boehm J981

Pressman J997) Selon Perry (2000) la plupaJ1 des erreurs deacutetecteacutees pendant la phase de test

pourraient ecirctre attribueacutees agrave des erreurs danalyse et de conception Elles repreacutesentent

approximativement tel quillustreacute sur la figure 21 les deux tiers des erreurs failes pendant le

deacuteveloppement du logiciel En conseacutequence la preacuteparation du plan ct des proceacutedures de test

sceacutenariseacute tocirct dans le cycle de deacuteveloppement permettent de fournir des informations utiles

17

aux concepteurs en identifiant les erreurs tocirct dans le projet comme les oublis ou les

incoheacuterences de conception avant que ces erreurs se transforment agrave des deacutefauts dans le code

Figure 21 Le pourcentage des erreurs danalyse et de conception (Adapteacute ct traduit de Perry 2000 pAS)

Erreurs de codage

64

Erreurs danalyse et de conception

Dans les meacutethodes agiles lactiviteacute de test est incorporeacutee dans chaque iteacuteration du processus

de deacuteveloppement et constitue une partie inteacutegrante essentielle de la construction du logiciel

(Boehm et Turner 2004) De ce fait nous croyons que les meacutethodes agiles satisfont aussi les

aspects principaux de la deacutefinition proposeacutee par Swebok (2004)

A part une vue exploratoire non traditionnelle propose le test comme une activiteacute

dinvestigation et dexpeacuterimentation Selon Bach ct Kaner (2004) le test est une investigation

dont Jobjectif est de reacuteveacuteler des informations sur la qualiteacute du produit agrave tester Cette

deacutefinition vise principalement linclusion de TE qui se base sur linvestigation et le

questionnement

24 Les modegraveles de test

Le modegravele en V constitue leacutetat de lart dans le domaine de test du logiciel Cest le modegravele

le plus utiliseacute et traiteacute dans la litteacuterature de test (Craig et Jaskiel 2002 Perry 2000) Cc

modegravele tel quillustreacute agrave la figure 22 divise le processus de test en plusieurs niveaux

effectueacutes conjointement avec jimplantation du logiciel Il commence par le test de petits

morceaux ct avance vers des plus grands refleacutetant diffeacuterents points de vues de test a

diffeacuterents niveaux de deacutetail

18

Figure 22 Modegravele de test en V (Adapteacute et traduit de Pyhajarvi ct aL 2003)

[ Exgence Jr-o---------t~[ AcceplaUon J li( ~

Speacutecifications Systegraveme

~

Conception Inteacutegration

~ ~

Codage Uniteacute~

Speacutecification ----J~ Planification ----J~ Test

Ce modegravele identifie des activiteacutes de test agrave chaque eacutetape du cycle de vie Le test unitaire est au

niveau Je plus bas dans la hieacuterarchie Lobjectif geacuteneacuteral de ce niveau de test est de trouver les

deacutefauts dans la logique dans les donneacutees et dans les algorithmes de chaque module pris

individuellement Apregraves Je test unitaire viennent les tests dinteacutegration ces derniers sont

effectueacutes pour trouver les deacutefauts dinterfaces entre les uniteacutes En remontant dans la

hieacuterarchie le niveau suivant les tests dinteacutegration est le test du systegraveme Ce dernier est le

processus de tester le systegraveme entier afin de veacuterifier le produit par rapport aux speacutecifications

des exigences Finalement le test dacceptation prend place afin de deacuteterminer si le logiciel

reacutepond aux exigences et aux attentes du client

La force de ce modegravele est quil permet de planifier et de preacuteparer les cas de test tregraves tocirct dans

le cycle du deacuteveloppement degraves que labstraction des exigences est connue Ce fait aide dans

la deacutetection des erreurs de conception et de speacutecification Autrement il permettait de deacutetecter

les erreurs avant quils se transforment agrave des deacutefauts dans le code cest ce quest connu

actuellement SOllS le terme de test preacuteventif Cependant celle force ramegravene avec elle une

19

faiblesse importante Cette faiblesse se traduit par la rigiditeacute de modegravele aux changements En

effet souvent la documentation utiliseacutee pour planifier et preacuteparer les cas de tests nest pas

assez mucircrie au deacutebut du projet de deacuteveloppement Par conseacutequent la possibiliteacute que le

logiciel se change ulteacuterieurement dans le cycle de deacuteveloppement est forte probable Ceci

neacutecessite la mise agrave jour de tous les artefacts du test deacutejagrave conccedilus qui est souvent tregraves coucircteux

Selon Bach et al (2002) les revues et les inspections pourraient ecirctre plus efficace dans la

deacutetection des erreurs des exigences et la conception que de concevoir des cas tests qui ne

seront jamais exeacutecuteacutes

Derniegraverement avec lapparition des meacutethodes agiles le modegravele de test en V ne peut plus

suivre cette nouvelle tendance du deacuteveloppement (Pyhajarvi et al 2003) En reacuteaction le test

Agile a fait son apparition Cest une meacutethode de test suivie dans les projets agiles de

deacuteveloppement (Marick 2003) Cet auteur a preacuteciseacute que la communication ct la collaboration

entre les testeurs les deacuteveloppeurs et le client constituent les principes essentiels du test

agile Le rocircle du testeur nest plus pareil agrave celui des modegraveles traditionnels ougrave le testeur

soccupe seulement de la veacuterification et la validation du logiciel deacuteveloppeacute Cela nous amegravene

vers un rocircle plus constructif du logiciel gracircce aux informations et aux feedbacks utiles que le

testeur pourrait fournir aux deacuteveloppeurs au fur ct agrave mesure sur la qualiteacute de lapplication

deacuteveloppeacutee agrave chaque iteacuteration Souvent le testeur utilise le TE pour tester le logiciel et fournir

cc feedbaek (Pettichord 2004)

La communication entre le testeur agile et le client est aussi tregraves importante (Marick 2003)

Souvent le testeur devrait collaborer avec le client pour identifier les sceacutenarios dutilisation

neacutecessaires agrave leacutelaboration des tests dacceptation Cela fournira une revue implicite aux

exigences et aide agrave bien visualiser le logiciel En fait le testeur peut assurer un fecdback tregraves

tocirct sur quelques aspects du logiciel tels que lutilisabiliteacute et dautres fonctionnaliteacutes aux

deacuteveloppeurs

Selon Hcndrickson (2005) le testeur a deux rocircles dans le test Agile testeur et designer Les

pratiques de test agile peuvent ecirctre reacutesumeacutees sur la figure ci-dessous

20

Figure 23 Les pratiques de test Agile (Adapteacute et traduit de Hendrickson 2005)

Dans une seule iteacuteration

Testeur

Tests unitaires Test exploratoire

automatiseacutes Tests dacceptations

automatiseacutes manuel

Reacutepresente des Fournit unRpent~ l exigences speacutecifications feedback

exeacutecutables exeacutecutables addtiOllllcl

Tel quillustreacute agrave la figure 23 le TE constitue une partie inteacutegrante et essentielle de test agile

25 Processus de test sceacutenariseacute

Pour faire la diffeacuterence entre le TS et le TE nous preacutesentons dans cette section un processus

de TS sans speacutecifier une meacutethodologie preacutecise Nous nous inteacuteressons seulement aux aspects

qUI nous permettrons de mener notre eacutetude comparative Nous avons choisi de suivre Je

standard IEEE 829 Selon Copland (2004) cetle norme de documentation est la meilleure

dans le domaine du test qui peut illustrer les aspects principaux de lapproche sceacutenariseacutee Ce

choix a eacuteteacute influenceacute aussi par nos besoins de contraster une vue sceacutenariseacutee disciplineacutee et

formelle avec une autre exploratoire et libre

La norme de documentation IEEE 829 de test du logiciel est une tentative de rassembler les

vues et preacutesenter quelques meilleures ideacutees de la pratique afin de mieux controcircler lactiviteacute

de test La nonne a eacuteteacute reacuteviseacutee et mise agrave jour en 1998 Elle deacutecrit huit documents qui peuvent

ecirctre diviseacutes en trois cateacutegories selon (Copeland 2004) les documents de preacuteparation des

tests produits avant le deacuteveloppement du logiciel les documents dexeacutecution des tests et les

21

documents de compleacutetude des tests Chacune de ces cateacutegories est composeacutee de documents

suivants

bull Documents de preacuteparation de tests

bull Plan de test

bull Speacutecification de conception de tests

bull Speacutecification de cas de tests

bull Speacutecification de proceacutedure de tests

bull Documents dexeacutecution de tests

bull Rapport de transmission darticle de test

bull log (registre) de test

bull Documents de compleacutetude de test

Rapport dincident de test

bull Rappol1 de sommaire de tests

La nonne IEEE 829 (1998) a citeacute quclques avantages de son utilisation

o Lutilisation des documents de tcsts standardiseacutes pourraient faciliter la communication

entre Ies intervenants de projct du deacuteveloppement en fournissant un protocole de

reacutefeacuterence commun

o Le standard IEEE 829 pourrait servIr comme un outil de veacuterification et deacutevaluation

(Check List) au processus de test

o Un ensemble de documents normaliseacutes selon cette norme pourrait eacutegalement fournir une

base pour leacutevaluation des pratiques de documentation de test du logiciel

o Lutilisation des documents selon la norme IEEE 829 permettrait de controcircler le

processus de test Cela reacutesulte de laugmentation de la visibiliteacute dc chaque phase du

processus

22

Figure 24 Scheacutematisation des documents de preacuteparation de tests (Adapteacute et traduit de

Copeland 2004 p189)

Plan de test

Speacuteci1iumlcation

de Conception de Test

1 S peacuteci fica lion

Speacutecification de Proceacutedure

de Cas de Test de Test

~------------~-Rapport de - Exeacutecution des -

transmission -~ _ tests _

darticle de test -------------

bull

Rapport

-~Log de test dincident de test

1 Rapport de~ Se reacutefeumlre agrave Sommaire de - -_ ___ EntreacuteeSortie

test

Dans notre eacutetude nous nous inteacuteresserons seulement aux documents de preacuteparation de tests

du fait quils constituent le principal point de divergence entre le TS et le TE La figure 24

montre les doeuments devraient ecirctre creacuteeacutees avant jexeacutecution de tests Souvent ces documents

sont creacuteeacutes parallegravelement agrave limpleacutementation du logiciel dans les vues preacuteventives de test

(Craig ct Jaskiel 2002) Cest lune des forces de TS qui pourrait sintroduire tregraves tocirct dans le

cycle de vie du logiciel et preacutevenir les erreurs et les ambiguiumlteacutes pendant la phase de

speacutecification des exigences et la conception avant quils se transforment agrave des deacutefauts dans le

code

Notons que les documents du test sont eacutegalement sujets agrave une validation Cela peut ecirctre

reacutealiseacute par une reacutevision formelle agrave ccs documents Agrave cet effet Jutilisation de la norme pouna

faciliter eacutenormeacutement la mise en place de cette validation (Craig et Jaskiel 2002) Cependant

23

selon Bach et al (2002) la norme pourrait nuire agrave la qualiteacute de test effectueacute Du fait que les

testeurs consacrent le temps limiteacute du test agrave la creacuteation dune documentation lourde et non

neacutecessaire au 1ieu de linvestir dans le test du logiciel

Selon (Swebok 2004 Pyhajarvi et al 2003 Craig et Jaskiel 2002 Perry 2000) le

processus de test comporte les eacutetapes suivantes la planification lanalyse et la conception de

tests lexeacutecution el leacutevaluation de tests Nous aHons aborder dans les sections qui suivent

chacune de ces eacutetapes en mettant laccent sur les documents creacuteeacutes et les eacuteleacutements

fondamentaux speacutecifieacutes dans ces documents

251 La planification

La planification de lactiviteacute de test peut commencer au moment de la formulation des

besoins se deacutevelopper et se raffiner pendant la phase de conception du logiciel Ce processus

de planification donne naissance a un plan de lesl qui deacutecrit les items (composants) et les

caracteacuteristiques de qualiteacute (fonctionnaliteacute performance utilisabiliteacute etc) qui devraient ecirctre

testeacutes ainsi que les responsabiliteacutes les livrables et les besoins environnementaux requis et

leacutecheacuteancier de projet de test Sachant que ce plan de test peut ecirctre creacutee au niveau de projet

(Master Test Plan) ou au niveau secondaire (unitaire inteacutegration systegraveme acceptation etc)

Cela deacutepend de la complexiteacute de logiciel et de lorganisation de projet Il faut noter que celle

planification est une activiteacute continue seffectue tout au long du cycle de deacuteveloppement

Alors les reacutesultats de lactiviteacute de test sont utiliseacutes pour mesurer les risques el modifier le

plan si neacutecessaire

Le patron du plan de test de la norme IEEE 829 deacutefinit 16 clauses deacutecrites ci-dessous la

description deacutetailleacutee de chaque clause est preacutesenteacutee dans lannexe B

1 Identificateur du plan de test

2 Introduction

3 Items de test

4 Caracteacuteristiques agrave tester

5 Caracteacuteristiques qui ne devraient pas ecirctre testeacutees

6 Approche de test

24

7 Critegravere de passageeacutechec

8 Critegravere de suspension et conditions de reprise

9 Livrables du test

10 Tacircches du test

Il Besoins environnementaux

12 Responsabiliteacutes

13 Besoins en personnel et formation

14 Ceacutedule

15 Risques et contingences

16 Acceptations

Le patron du plan de test preacutesenteacute ci dessus foumit un croquis ou une structure de base du

plan de test quil peut ecirctre adapteacute selon les besoins de chaque organisation Pratiquement la

plupart des plans proposeacutes dans la litteacuterature divisent la clause risque et contingence en deux

clauses seacutepareacutees la premiegravere deacutecrit les risques lieacutes au logiciel et la deuxiegraveme les risques lieacutes

au projet de test et ses contingences (Craig et Jaskiel 2002) En effet la rapiditeacute suivie dans

le deacuteveloppement et limpossibiliteacute de tester le logiciel exhaustivement ont pousseacute les

intervenants dans le domaine du test agrave utiliser les risques du logiciel pour focaliser la strateacutegie

et identifier la prioriteacute des items de test 11 sagit de faire une analyse de risques au deacutebut de

projet de test en se basant sur les speacutecifications dexigences (Craig Jaskiel 2002) Elle

permet aussi de deacuteterminer les zones agrave risques et les parties potentielles qui auraient tendance

agrave avoir plus derreurs et qui devraient ecirctre testeacutees rigoureusement Selon ces mecircmes auteurs

les reacutesultats de cette analyse doivent ecirctre revus occasionnellement pendant le projet de test

du fait que les speacutecifications les ressources la porteacutee de test et dautres facteurs dans le projet

peuvent se changer Dailleurs le risque des composants qui ont subi des changements

devient naturellement plus grand agrave chaque version Cette analyse de risques pourrait servir

aussi dans la mise en place de contingences convenables lorsquun eacuteveacutenement inattendu

survient et empecircche jexeacutecution normale du plan de test

252 Analyse et conception

La conception de tests est la premiegravere eacutetape de deacuteveloppement de tests Le processus

25

danalyse et de conception de tests se consiste de trois eacutetapes agrave savoir concevoir les tests en

identifiant les conditions de tests speacutecifier les cas de tests et speacutecifier les proceacutedures de tests

Alors pendant lanalyse la documentation de base disponible dans cette eacutetape tels que les

documents de speacutecification des exigences et de conception doivent ecirctre analyseacutes

soigneusement pour deacuteterminer les items ou les articles gui devraient ecirctre testeacutes Une

condition de test est deacutefinie comme un article ou un eacuteveacutenement qui peut ecirctre veacuterifieacute par un ou

plusieurs cas de tests tel que une fonction ou caracteacuteristique de qualiteacute

Pendant la speacutecification de cas de tests les donneacutees de tests sont deacuteveloppeacutees et deacutecrites en

deacutetail en utilisant une ou plusieurs techniques de conception de tests (Beizer 1995 Craig

Jaskiel 2002) Le choix dune technique deacutepend de la nature du systegraveme agrave tester les objectifs

viseacutes et le risque global de lexeacutecution (Craig Jaskiel 2002) Cette phase se conclut par la

production de trois livrables Speacutecification de Conception de Test Speacutecification de Cas de

Tes et Speacutecification de Proceacutedure de Test Elle se conclut aussi par leacutelaboration de la

matrice de traccedilabiliteacute qui trace les exigences vers les cas de tests (Craig Jaskiel 2002)

Tableau 21 La matrice de traccedilabiliteacute

Cas de test 1 Cas de test 2 Cas de test 3 Cas de test 4

Exigence J X X X X

Exigence 2 X Exigence 3 X X X

Exigence 4 X X

Totale 2 4 3 1

La matrice de traccedilabiliteacute permet de tracer les cas de tests sur les exigences Cela fournit un

moyen pour identifier les exigences qui ne sont pas bien testeacutees Autrement cest un outil

pour mesurer la couvel1ure de tests (sera eacutevoqueacute en deacutetail dans le chapitre VU)

Cette matrice permettait aussi danalyser limpact de changements sur les exigences et donne

une ideacutee du volume de travail neacutecessaire pour mettre agrave jour les cas de tests deacutejagrave conccedilus (Bach

et aL 2002)

26

2521 Speacutecification de Conception de test

Speacutecification de Conception de Test est un document speacutecifiant les conditions de tests

(eacuteleacutements de couverture) pour un article de test lapproche deacutetailleacutee du test et lidentification

des cas de tests de haut niveau associeacutes (IEEE 829 1998) Il compolie les eacuteleacutements suivants

J Identificateur de Speacutecification de Conception de Test (un nom unique pour distinguer le

document parmi tous les autres)

2 Caracteacuteristiques agrave tester (identifie es items et les caracteacuteristiques objets de celte

Speacutecification de Conception de test

3 Raffinements de lapproche (identifie les deacutetails de la technique de test et de lapproche

proposeacutee dans le plan de test)

4 Identification de tests (fournit un identificateur unique et une courte description des cas

de tests associeacutes agrave celte Speacutecification de Conception de test)

S Critegravere de succegraveseacutechec de test (critegravere utiliseacute pour deacuteterminer si une caracteacuteristiques

passe ougrave eacutechoue Je test)

En fait le document de Speacutecification de Conception de Test est unc miniature de plan de test

Son rocircle cst de regrouper les cas dc tests semblables destineacutes agrave tester une ou plusieurs

caracteacuteristiques du logiciel Ici quillustreacute sur la figure 2S

Figure 25 Speacutecification de Cas de Test

PIgtln de lest]

Speacutecilicirceation SpeacutecifiCgtltion peacutecifieation de Conception de Conception de Conception

de test de test de test ~ T

Cns de lesl 01 Cas de lest 02

1 i

27

Par la suite les speacutecifications de chaque cas de test speacutecifieacute dans le document Speacutecification de

Conception de Test devraient ecirctre deacutetermineacutees

2522 Speacutecification de Cas de Test

Le but de Speacutecification de Cas de Test est didentifier les deacutetails de chaque cas de test citeacute

dans la Speacutecification de Conception de Test Le patron IEEE 829 de Speacutecification de Cas de

Test deacutecrit les eacuteleacutements suivants

1 Identificateur de Cas de Test (un nom unique qui distingue ce cas de test parmi tous

les autres)

2 Items de test (items et caracteacuteristiques objets du cas de test)

3 Speacutecification des entreacutees (speacutecifie les entreacutees requises par ce cas de test)

4 Speacutecification des sorties (speacutecifie les reacutesullats preacutevus de lexeacutecution de cas de test)

5 Besoins environnementaux (mateacuteriel speacutecial ou logiciel neacutecessaire pour exeacutecuter ce

cas de test)

6 Exigences proceacutedurClles speacuteciales (identifie nimporte quelle proceacutedure speacuteciale

neacutecessaire pour insta11er lenv ironnement de test)

7 Deacutependances inter-cas (cite les cas de test qui doivent ecirctre exeacutecuteacutes avant ce cas de

test)

Comme nous venons de le voir les reacutesullats attendus devraient faire partie de Speacutecification

de Cas de Test Ces reacutesultats constituent loracle de test dans le TS

Selon Craig et Jaskiel (2002) japproche IEEE 829 requiert une documentation complegravete de

chaque cas de test cest la raison pour laquelle elle est utiliseacutee dans les systegravemes agrave grand

risque Selon ces mecircmes auteurs le patron ne constitue pas un bon choix pour tester les

systegravemes dynamiques et instables En effet la norme de documentation IEEE 829 demande

un effort important dans la creacuteation des cas de tests et quelques changements introduits sur le

logiciel peuvent rcndre ces cas dc tests invalides

Par contre ce patron constitue un bon choix dans les organisations dynamiques qUI se

caracteacuterisenl par le changement freacutequent de leur personnel ou qui ont du personnel

inexpeacuterimenteacute

28

Par la suite les cas de test conccedilus se mettent dans un ordre exeacutecutable dans le troisiegraveme

document de standard de documentation lEEE 829 de phase de conception la Speacutecification

de Proceacutedure de test Ces proceacutedures de tests sont deacuteveloppeacutees agrave pal1ir des documents de

Speacutecification de Conception de Test et Speacutecification de Cas de Test Le document de

Speacutecification de Proceacutedure de test deacutecrit comment le testeur junior devra exeacutecuter

physiquement le test Une Speacutecification de Proceacutedure de Test pourrait inclure plus quun seul

cas de test

2523 Speacutecification de Proceacutedure de Test

La Speacutecijicatian de Proceacutedure de Test est un document speacutecifiant la seacutequence dactions pour

lexeacutecution dun test Ce document connu aussi sous le terme script de tests ou script de tests

manuels (JEEE 829) La norme deacutefinit dix eacutetapes qui peuvent ecirctre utiliseacutees dans lexeacutecution

de tests qui sont deacutecrites ci- dessous

1 Objet de la proceacutedure

2 Exigences speacuteciales

3 Eacutetapes de la proceacutedure

bull Log comment enregistrer les reacutesultats

bull Set Up comment preacuteparer l exeacutecut ion de la proceacutedure

bull Stcm comment deacutebuter lexeacutecution de la proceacutedure

bull Proceed actions de la proceacutedure

Measure comment les mesures seront effectueacutees

bull Shut Down comment suspendre la proceacutedure de test

bull Restart comment redeacutemarrer la proceacutedure de test

bull Stop comment effectuer un arrecirct ordonneacute de lexeacutecution

bull Wrap Up comment restaurer lenvironnement

bull Contingencies comment traiter les anomalies durant lexeacutecution

Nous pouvons constater de la description ci-dessus que le script de la proceacutedure deacutecrit en

deacutetail les eacutetapes dexeacutecution de tesl ct ne laisse rien agrave la volonteacute du testeur qui exeacutecute le test

Cest lune dcs critiques proposeacutes par les membres dc COS contre le TS Selon eux ce script

transforme le testeur en robot exeacutecutant les tacircches sans aucune reacuteflexion critique

29

253 Exeacutecution et eacutevaluation

Lexeacutecution des tests conccedilus se fait selon le planning deacutecrit dans le plan de test Pendant

lexeacutecution des tests le testeur junior enregistre les reacutesultats de lexeacutecution dans les

documents proposeacutes par IEEE 829 Registre de test Rapport dincident de test Les deacutefauts

sont enregistreacutes dans un systegraveme de suivi des bogues Agrave la fin de lactiviteacute de test le

document de standard IEEE 829 Rapport de synthegravese de Test syntheacutetise les activiteacutes et les

reacutesultats de test de la version testeacutee du logiciel

26 Conclusion

Nous avons donneacute dans ce chapitre un aperccedilu global sur la plupart des aspects touchant au TS

en mettant laccent sur les principales eacutetapes du processus de TS Il apparaicirct que le processus

sceacutenariseacute est visible planifieacute incluant plusieurs meacutetriques pouvant faciliter la mesure de

lefficaciteacute de lactiviteacute de test Mais dans la pratique le processus de test du logiciel ne se

passe pas toujours de la mecircme faccedilon quc dans la theacuteorie speacutecifiquement le test des systegravemes

dynamiques et changeants Sajoute agrave ce problegraveme le fail que les testeurs ninterviennent quagrave

la fin de la chaicircne de deacuteveloppement dans les modegraveles traditionnels Par conseacutequent lactiviteacute

de test seffectuera souvent sous des pressions du temps de coucirct ct le besoin de livrer le

logiciel Agrave cet effet les compagnies de deacuteveloppement de logiciels ont commenceacute agrave chercher

des meacutethodes pouvant mieux sadapter avec ces reacutealiteacutes Le TE constitue une de ces

meacutethodes il fera Je sujet de prochain chapitre

CHAPITRE III

TEST EXPLORATOIRE VUE DENSEMBLE

Ce chapitre propose une vue densemble du test exploratoire en preacutesentant briegravevement les

aspects fondamentaux de cette approche Nous commenccedilons par la deacutefinition de test

exploratoire (TE) puis laccent sera mis sur lapproche de test laquoSession Based Test

Managementraquo (SBTM) et ses meacutecanismes principaux Enfin quelques techniques ct styles

dexploration seront deacutecrits et nous terminerons par une conclusion

31 Deacutefinitions

Au deacutebut des anneacutees 90 les membres de Context Oriven School (CDS) ont commenceacute agrave

utiliser le terme laquoexploratoireraquo pour deacutecrire cette nouvelle pratique de test Cette

terminologie a eacuteteacute publieacutee dabord par Kaner (1988)

laquo () At some point youll stop formoly planning and documenting new tests until the next test cycle You can keep testing Run new tests as you think of them without spending much time preparing or explaining the tests Trust your instincts ln this example you quick~y reached the switch point from formol ta inarmai testing becallse the program crashed sa saon SOll7ething moy be fllndamenta~v wrong l(so the progral71 wil be redesigned Creoting new test series nm is risky They may hecome obsolete with the next version of the prngram Rother thon gomhling away the planning time tlY some exploratOlY tests whatever cames to mind raquo dapreacutes (Kaner 1988)

Comme nous pouvons le constater lauteur a deacutefinit le TE comme la conception et

lexeacutecution de tests agrave temps reacuteel degraves quune nouvelle ideacutee de test seacutemerge sans perdre du

temps dans la planification et la preacuteparation de tests formels qui pourront devenir obsolegravetes agrave

la prochaine version vue linstabiliteacute du systegraveme

31

Agrave loccasion du 7egraveme atelier de Los Altos sur le test du logiciel les praticiens ct les

chercheurs participants ont tous collaboreacute pour deacutefinir le TE Ils ont accentueacute certaines des

caracteacuteristiques communes de leurs vues et se sont mis daccord sur les caracteacuteristiques de

TE citeacutees ci dessous (Kaner Tinkham 2003a)

bull Interactif

bull Combinaison de la cognition et lexeacutecution

bull Creacuteatif

bull Megravene agrave des reacutesultats rapides

bull Diminue larchivage des documents de test

En 2002 dans le premier livre qui preacutesente les ideacutees et les principes de la penseacutee laquotest piloteacute

par le contexteraquo CDS Bach et al(2002) ont deacutefini le terme exploration comme une

interrogation deacutetermineacutee cest agrave dire une navigation avec une mission geacuteneacuterale sans itineacuteraire

sceacutenariseacute

laquoBy exploration we mean purposejiil wandering navigaling Ihrough a space wilh a general mission bul wilhoU a pre-seripIed roule Exploralion involves conlinuols learning and experimenling ()gtgt dapregraves (Bach ct al 2002)

Ces mecircmes auteurs ont preacutesenteacute le TE comme une technique de test ougrave le testeur apprend le

produit logiciel son marcheacute ses risques et ses deacutefauts anteacuterieurs tout au long de lactiviteacute de

test pour concevoir des nouveaux tests plus puissants gracircce agrave leacutevolution et agrave la maturiteacute de

ses connaissances (Bach et al 2002)

Kaner et Tinkham (2003a) ont deacutefini le TE comme nimporte quelle activiteacute de test dans la

mesure ougrave le testeur controcircle activement la conception des tests Pendant que ces tests

sexeacutecutent il utilise linformation reacutesultante pour concevoir de nouveaux tests Par cette

proposition les auteurs tendent agrave geacuteneacuteraliser la deacutefinition au test sceacutenariseacute (TS) qui pourrait

ecirctre exeacutecuteacute dans certaines situations dune faccedilon exploratoire comme nous allons le voir

dans les lignes qui suivent

Cependant la deacutefinition la plus freacutequente dans la litteacuterature est celle donneacutee par Bach (2003)

32

11 deacutefinit le TE comme lapprentissage la conception et lexeacutecution simultaneacutee des tests

Le TE a eacuteteacute reconnu par le guide Swebok (2004) comme une technique valide de test

Cependant il relie lefficaciteacute de TE agrave la connaissance de lingeacutenieur logiciel ou le testeur

Dapregraves les deacutefinitions ci-dessus nous pouvons deacuteduire les proprieacuteteacutes maicirctresses de TE

bull Lapprentissage lexploration la conception et lexeacutecution des tests se font

simultaneacutement Autrement dit les tests ne sont pas deacutefinis agrave lavance comme les cas de

tests seeacutenariseacutes

bull Lactiviteacute de test est guideacutee agrave chaque moment par les reacutesultats des tests anteacuterieurs dans

une boucle interactive dappreacutehension du logiciel sous test

Le TE nexige pas la disponibiliteacute des exigences du logiciel du fait quil se fonde sur

lexploration et lapprentissage pendant le test

bull Centreacutee autour de la deacutetection des deacutefauts cest-agrave-dire orienteacute vers le reacutesultat plutocirct que

la preacuteparation la documentation ct larchivage des cas de tests

Nous pouvons constater de ces proprieacuteteacutes quil y une diffeacuterence claire entre le TE et le TS La

reacutealiteacute des pratiques de test deacutemontre que cette diffeacuterence est inaperccedilue du fait que mecircme

une activiteacute de TS pourrait ecirctre exeacutecuteacutee dune faccedilon exploratoire Un exemple clair de telle

situation apparaicirct quand le testeur deacutevie de ses proceacutedures de tests et utilise lexploration

pour explorer un deacutefaut pendant lexeacutecution de ses tests sceacutenariseacutes (Kaner Tinkham 2003a)

Nous pouvons donc conclure que nimporte quelle activiteacute de test logiciel reacutealiseacutee par un ecirctre

humain pourrait ecirctre exploraoire agrave un certain degreacute Selon Bach (2003) nimporte quel effort

de test tombe quelque part sur un continuum (figure 31) dont un des pocircles repreacutesente le TS

ougrave le testeur suit exactement les proceacutedures de tests sceacutenariseacutes dans chaque deacutetail et lautre

pocircle repreacutesente le TE le plus libre (Freestyle Exploratory Testing) ougrave les ideacutees de test

eacutemergent au moment de leur exeacutecution

33

Figure 31 Continuum repeacuterant lactiviteacute de test (Adapteacute et traduit de Bach 2007)

Test Test

sceacutenariseacute Scripts vagues Fragments de Chartes Rocircles

exploratoire libre

cas de tests 1 1

La figure 31 situe plusieurs variantes de test entre les deux paradigmes le TE et le TS

Chacune de ces variantes accentue un niveau de formalisme de deacutetail de documentation et

de controcircle par rapport au TE libre Elle pourrait prendre la forme des rocircles ou des

responsabiliteacutes pour chaque membre de Jeacutequipe de test sur une partie du logiciel Elle

pourrait prendre aussi la forme des chal1es qui sont plus preacutecises que les rocircles Ces chartes

identifient la dureacutee de Ja mission avec une liste preacutecise des items agrave tester Les deux derniers

types sont les deux modegraveles de TE les plus proches de TS Tout dabord les fragments de cas

de test qui poulTaient speacutecifier les mecircmes eacuteleacutements que Speacutecification de Cas de Tes dans la

norme IEEE 829 sans speacutecifier toutefois les deacutetails fins comme le eas de test sceacutenariseacute

Quant aux scripts vagues ils sont plus preacutecis que les fragments de cas de test et similaires

aux proceacutedures Ils contiennent les eacutetapes agrave suivre pour accomplir la mission de tesl mais

sont moins deacutetailleacutees que celles-ci ct neacutecessitent de lexploration pour les accomplir Avant

de fermer celle parenthegravese notons que certaines organisations ont uti liseacute les patrons JEEE

829 speacutecialement les speacutecificalions des cas de tests pour inteacutegrer le TE dans leurs pratiques

de test avant lintroduction du concept de laquoSession Based Test Managemenl raquo (Amland et

Vaga 2002)

34

32 Processus de test exploratoire

Le processus de TE est un processus tridimensionnel Tel quillustreacute sur le tableau 31 ces

dimensions sont produit qualiteacute et techniques (Bach 2003) Selon lauteur un testeur

exploratoire teste un produit logiciel eacutevalue sa qualiteacute en utilisant diverses techniques

Chaque case dans la grille ci-dessous repreacutesente un aspect du proceSSllS de TE Le testeur

exploratoire peut choisir nimporte quel point de deacutepart et suivre nimporte quel chemin dans

la grille jusquagrave la fin de la session de test il condition que les neuf tacircches soient couvertes

pendant le cycle de test et gue chacune des trois activiteacutes principales apprentissage

conception de tests et exeacutecution de tests donnent un reacutesultat tangible

Tableau 31 Grille des tacircches de test exploratoire (Adapteacute ct traduit dAmland 2002a)

Grille des Apprentissage Conception de Exeacutecution de tests tacircches tests

Produit Deacutecouvrir les eacuteleacutements du Deacutecider quoi tester Observer le (couverture) produit comportement du

nrnrlilil

Qualiteacute Deacutecouvrir comment le produit Penser aux Evaluer le (Oracle) devrait fonctionner problegravemes de comportement

qualiteacute possibles contre les preacutevisions

Techniques Deacutecouvrir les techniques de Choisir et appliquer Configurer et conception des tests qui les techniques de exercer le produit peuvent ecirctre utiliseacutees conception de tests

bull Les notes de Les tests Les problegravemes

tests trouveacutes

Selon Bach (200 J) le TE peut ecirctre pratiqueacute selon un plan preacutevu qui nest pas neacutecessairement

rigoureux Du fait quun plan rigoureux exige la certitude et implique la perfection Cellcs-ci

ne pourraient pas ecirctre atteintes dans une activiteacute de TE qui se fonde sur lexploration ct

lapprentissage du logiciel pour identifier cc qui doit ecirctre testeacute Cependant Bach signale

35

quun bon TE est une activiteacute planifieacutee et la preacuteparation de quelques notes sur la strateacutegie agrave

suivre et les eacuteleacutements du logiciel agrave aborder dans le test pourraient ecirctre tregraves utiles

En ce qui concerne les types de TE deux types ont eacuteteacute traiteacutes dans la litteacuterature le premier

est le test exploratoire libre (Freestyle Exploratory Testing) Cest un test qui se fait sur des

intervalles limiteacutes de temps quon appelle sessions chacune munie dune charte La charte

deacutecrit la mission de test et parfois identifie quelques tactiques et techniques de test pouvant

ecirctre utiliseacutees pour exeacutecuter cette mission La cha11e pourrait ecirctre choisie par le testeur ou

assigneacutee par le responsable du test Les reacutesultats officiels de ce type sont constitueacutes seulement

des bogues deacutetecteacutes pendant la session de test (Bach 2003) Le deuxiegraveme type de TE est le

test exploratoire geacutereacute par session (Session Based Test Management SBTM) Cest une

approche structureacutee de TE introduite par Jonathan Bach (2000) pour controcircler le TE libre

Dans ce type de TE les reacutesultats officiels sont constitueacutes des bogues deacutetecteacutes dans la session

de test et un rapport de session qui fait lobjet dune eacutevaluation par Je responsable de test Les

meacutecanismes et les meacutetriques de ce type de TE vont ecirctre eacutevoqueacutes en deacutetail dans la section qui

suit

33 Test exploratoire geacutereacute par session (SBTM)

Lapparition du TE dans sa version originale cest-agrave-dire tel que preacutesenteacute au deacutebut un

processus libre et informel a susciteacute beaucoup de critiques de la part des praticiens et des

professionnels Ces critiques eacutetaient centreacutees sur le manque de controcircle et de mesure qui sont

importants et cruciaux dans Jindustrie de test de logiciel En effet le fait que le TE ne soit

pas sceacutenariseacute ni reacutepeacutetitif et qu j] deacutepend fortement de la creacuteativiteacute du testeur a rendu difficile

le controcircle et le suivi de la progression de projet de test Compte tenu de ces faiblesses les

intervenants dans le domaine de test ont trouveacute difficile dessayer ou dintroduire le TE tel

que preacutesenteacute la premiegravere fois comme une meacutethodologie de tes

Pour paJJier ces problegravemes Jonathan Bach (2000) a proposeacute une nouvelle approche de TE

nommeacute Test geacutereacute par session (Session Based Test Management (SBTM) Le but de

lapproche est de rendre Je TE plus responsable (Accountable) ct dintroduire la mesure et le

controcircle neacutecessaires pour la gestion de projet de test Lideacutee principale de la meacutethode SBTM

est de planifier et diviser la mission geacuteneacuterale de test en plusieurs sessions Une session est un

36

intervalle de temps ininterrompu qUI pourrait durer de 60 agrave 120 minutes (BachJ

2000)Chaque session est identifieacutee par une charte qui deacutecrit la mission de test agrave remplir

Nous pouvons dire que cest un plan de haut niveau son rocircle est de speacutecifier les tacircches de test

agrave remplir ainsi que quelques tactiques et techniques pour les exeacutecuter Notons que la

granulariteacute de deacutetails de chaque charte varie selon limportance de celle-ci en termes de

risque et de la difficulteacute de la mission

Selon Jonathan Bach (2000) chaque session devrait ecirctre diviseacutee cn trois eacutetapes qUI

comportent autant de meacutetriques pour controcircler la porteacutee de travail du testeur Ces meacutetriques

sont

bull Preacuteparation de test le pourcentage du temps de la session consacreacute agrave linstallation

de lenvironnement de test (configurer mateacuteriels de test lire quelques manuels etc)

bull Conception et exeacutecution de tests le pourcentage du temps de la session passeacute dans

lexploration et le test

investigation et rapport de bogues Je pourcentage du temps de la session passeacute dans

la recherche et linvestigation lors de lapparition dun comportement inattendu du

logiciel Plus le temps passeacute sur le rapport des bogues

Le testeur devrait rapporter aussi lestimation du temps passeacute sur la chartc par rapport au

temps passeacute sur laquo lopportuniteacute raquo Lopportuniteacute cest le test effectueacute par le testcur qui nest

pas inclus dans la charte de session puisque le rocircle de lapproche SBTM scion Jonathan

Bach (2000) est dintroduire le controcircle et la mesure sur le TE libre tout en gardant ses

aspects essentiels que soient limprovisation lexploration et la creacuteativiteacute

De plus le rapport de session devrait rapporter les bogues les problegravemes et Ics notes Les

problegravemes sont les questions et les obstacles relieacutes au processus du test Quant aux notes

elles preacutesentent des ideacutees et des pistes qui peuvent amener agrave la creacuteation de nouveaux chartes

de test Le rapport de chaque session fait alors lobjet dune eacutevaluation pendant le deacutebriefing

avec le responsable du test

37

Figure 32 Cadre dapplication de SBTM (Inspireacute de James et Wood 2003)

Identification des chartes de

test

~ __ ________J___ _ __ ~

1 ------ 1 Estimation de Deacutefinition de 1 leffort de test ~ la session ou 1 1

neacutecessaire Ajustement

Planification continue 1

1____shy _shy -i-_shy - _-- ___j

Non La charte compleacuteteacutee

oui

Tel quillustreacute agrave la figure 32 au deacutebut de Jactiviteacute du test le responsable du test identifie les

chartes de tests et leffon neacutecessaire pour accomplir chacune delles Apregraves Jexeacutecution de

chacune de ces chartes le responsable rencontre le testeur pour eacutevaluer son travail Suite agrave ce

deacutebriefing Ic responsable deacutecidera si lexeacutecution de cbarte est compleacuteteacutee ou si la session

devrait ecirctre ajusteacutee et prolongeacutee pour compleacuteter le test de charte Le responsable du test

pourrait aussi ajouter de nouvelles chal1es pour explorer les notes rapporteacutees par le testeur

De ce fait le processus didentification de chanes est un processus de planification continue

(Wood ct James 2003) se change reacuteguliegraverement pendant lactiviteacute de test au fur et agrave mesure

que des nouvelles infonnations apparaissent pendant Jexeacutecution des chanes Les reacutesultats de

sessions de tests sont la plupart du temps rassembleacutes dans une base de donneacutees Ainsi le

pourcentage de sessions compleacuteteacutees les bogues rapporteacutes et le rendement des testeurs

38

pourraient ecirctre retraceacutees par les responsables du test Les renseignements sur la progression et

le statut de lactiviteacute de test pourraient ecirctre disponibles agrave chaque moment de projet En effet

les mesures collecteacutees pendant Je test et le deacutebriefing permettent destimer la productiviteacute ou

le rendement de chaque membre de leacutequipe de test pendant le projet de test en cours Cela

avec le nombre de sessions compleacuteteacutees pourrait aider dans lestimation de quantiteacute du travail

restante avant la fin du cyc le de test

Une expeacuterience dutilisation de cette approche a eacuteteacute preacutesenteacutee par (Lyndsay et van Eeden

2003) Les auteurs ont proposeacute des meacutethodes pour controcircler la porteacutee de test et eacutevaluer et

mesurer la couverture de test Les reacutesultats de cette expeacuterience seront abordeacutes en deacutetail dans

le chapitre IV

34 Les styIes ct les techniques dexploration

Depuis lapparition de TE plusieurs praticiens et chercheurs se penchaient sur leacutelaboration

des techniques et des modegraveles dexploration (Bach et Jonathan Bach 2006 Bach et Kaner

2004 Amland 2002b) Dans cette perspective Amland (2002b) ont proposeacute quelques styles

et techniques pour effectuer le TE lis incluent entre autres

bull Les intuitions sont les ideacutees que le testeur pourrait geacuteneacuterer en se basant sur ses

preacutedictions ses compeacutetences et son expertise

bull Les modegraveles il sagit de certains diagrammes et modegraveles qui peuvent aider le testeur

dans lappreacutehension du logiciel et la conception de tests Ils incluent entre autres

o Diagramme darchitecture consiste agrave construire ou concevoir un diagramme

darchitecture du logiciel sous test incluant ses interfaces son flux de donneacutees et

ainsi de suite En pratique ce travail se fait la plupart du temps pendant des reacuteunions

de groupe cntre les testeurs et les programmeurs Souvent lidentification de chartes

de tests et les responsabiliteacutes se fait agrave cette eacutetape ougrave chaque testeur deacutetermine sa

mission convenablement aux parties du logiciel comprises

39

o Digrammes deacutetats consiste agrave creacuteer un diagramme repreacutesentant jes modes

opeacuterationnelles les actions et les entreacutees possibles du logiciel Selon Amland (2002b)

ce digramme est un outil utile pour exposer les contradictions du logiciel

o Modegraveles de deacutefaillances consiste agrave utiliser un catalogue de bogues typiques pour

concevoir les cas de tests Le testeur exploratoire peut utiliser ses expeacuteriences

anteacuterieures pour construire ce catalogue ou utiliser en un de la litteacuterature (Kaner et

aL 1999)

bull Exemples il sagit de certains exemples dutilisation du systegraveme qui peuvent indiquer

les anomalies ct les deacutefauts existants Ils incluent entre autres

o Les cas dutilisations il sagit de deacuteterminer les utilisateurs du systegraveme et les tacircches

fonctionnelles pour chacun dentre eux ensuite on creacutee des tests qui reflegravetent leurs

utilisations

o Opeacutera savon il sagit de geacuteneacuterer des sceacutenarios dutilisations du systegraveme sous test en

exageacuterant dans quelques-unes de ses aspects par exemple en utilisant des valeurs

extrecircmes (limites) pour le mecircme sceacutenario

bull Les interfeacuterences il sagit de certaines actions qui peuvent nuire agrave Jexeacutecution normale

du systegraveme comme des arrecircts subits la concurrence avec dautres systegravemes etc Ces

interreacuterences peuvent reacuteveacuteler des deacutefauts dans le logiciel

bull Gestion derreurs il sagit de veacuterifier que Je 10gicieJ gegravere bien les erreurs dutilisation

autrement dit de veacuterifier que les messages derreurs se deacuteclenchent au bon moment et

SOllS les bonnes conditions

Il faut rappeler que le questionnement constitue le cœur de TE Il constitue la base de

nimporte quelle tcchnique ou style dexploration La qualiteacute du TE effectueacute deacutepend de la

qualiteacute des questions geacuteneacutereacutees agrave propos du produit sous test (Bach 2003 Kaner Tinkham

40

2003b Kaner Amland 2002b) Dans le but de faciliter la tacircche du testeur exploratoire dans

leacutelaboration des questions et des strateacutegies efficaces quelques praticiens et chercheurs ont

proposeacute quelques modegraveles comme le modegravele danalyse proposeacute par Bach (1996) qui est

illustreacute agrave la figure 33 et les modegraveles dattaques du logiciel proposeacutes par Whittaker (2003)

Figure 33 Heuristic Test Strategy Model (Adapteacute et traduit de Bach 1996)

Lenvironnement du projet de test

Les critegraveres de Les techniques de Les eacuteleacutements du qualiteacute test logiciel

Qualiteacute perccedilue

Ce modegravele preacutesente quatre secteurs principaux chacun eacutetant un indicateur que le testeur peut

utiliser pour deacuteterminer linformation dont jl a besoin pour concevoir une strateacutegie de test

Lobjectif immeacutediat de ce modegravele est donc de guider la reacuteflexion des testeurs exploratoires

lorsquils creacuteent les tests Ses principaux composants sont

bull Lenvironnement de projet inclut les ressources les contraintes et dautres facteurs

qui peuvent aider ou nuire au processus de conception et dexeacutecution des tests

(client calendrier eacutequipement etc)

bull Les eacuteleacutements du produit sont les aspects visibles ou invisibles du produit comme les

structures de donneacutees les interfaces etc

41

bull Les critegraveres Je qualiteacute sont les nonnes et les caracteacuteristiques de qualiteacute que le logiciel

devrait respecter Ces critegraveres permettent au testeur de deacuteterminer les problegravemes dans

le logiciel sous test

bull Les techniques de tests sont les strateacutegies neacutecessaires pour concevoir les tests Le

choix des techniques de test deacutepend de lenvironnement de projet les eacuteleacutements du

produit sous test el les critegraveres de qualiteacute viseacutes dans le projet de test en cours

bull La qualiteacute perccedilue est le reacutesultat preacutevu du test

Lenvironnement de projet les critegraveres de qualiteacute et les eacuteleacutements du produit sont tous

combineacutes avec les techniques de test afin de deacuteterminer la qualiteacute perccedilue du produit Selon

Kaner et Bach (2004) le modegravele aide le testeur exploratoire agrave deacuteterminer ce qui est doit ecirctre

testeacute Ainsi les attributs de qualiteacute les plus importants dans le projet (les types de problegravemes

agrave chercher pendant lactiviteacute de test) les aspects de projet qui pourraient faciliter ou

contrarier lactiviteacute de test en cours La reacuteflexion sc]on ces trois axes pourrait geacuteneacuterer des

ideacutees de test inteacuteressantes qui peuvent ecirctre mises en œuvre en respectant les contraintes et les

ressources du projet

Nous croyons que les secteurs deacutecrits dans cc modegravele danalyse sont semblables et ont les

mecircmes utiliteacutes que les secteurs identifieacutes dans le plan de test IEEE 829 (Annexe B)

Cependant le choix dun style speacutecifique dexploration ou tactique particuliegravere de TE deacutepend

selon Kaner et Tinkham (2003b) de facleurs deacutecrits ci-dessous

bull Les expeacuteriences anteacuterieures

bull Les qualifications

bull La personnaliteacute SUl10ut le modegravele dapprentissage

bull Les connaissances anteacuterieures sur lapplication sous test

Selon ces mecircmes auteurs le facteur le plus pertinent est le modegravele dapprentissage qUi

repreacutesente la faccedilon dont la personne choisit et traite linformation (Kaner Tinkham 2003b)

Cependant cette hypothegravese est theacuteorique et nest pas toujours confirmeacutee par une eacutetude

empIrIque

42

35 Conclusion

Nous avons donneacute dans ce chapitre un aperccedilu global sur la plupart des aspects touchant au

TE en commencent par sa deacutefinition et les concepts principaux du son processus Puis nous

avons preacutesenteacute lapproche SBTM et ses meacutecanismes En terminant nous avons proposeacute

quelques techniques et modegraveles dexploration Tout le mateacuteriel dont nous avons discuteacute dans

ce chapitre a eacuteteacute eacutelaboreacute dans le but daider et encourager les testeurs ct les organisations agrave

adopter le TE Mais comment les entreprises vont adopter cette nouvelle approche et quels

sont les motifs et les raisons qui les ont pousseacutees agrave essltlyer et utiliser le TE en mettant agrave

leacutecart la pratique sceacutenariseacutee habitueJJe Nous allons proposer des reacuteponses agrave toutes ces

questions dans la revue de litteacuterature de quelques travaux et eacutetudes de cas dans le chapitre

qui suit

41

CHAPITRE IV

REVUE DE TRAVAUX RELIEacuteS

Dans ce chapitre nous allons preacutesenter une revue des travaux de recherches acadeacutemiques et

professionnelles traitant du test exploratoire (TE) Dans la premiegravere partie nous deacutecrirons les

reacutesultats de la seu le recherche acadeacutemique existante agrave date Elle met laccent sur les raisons et

les faccedilons dutilisation de TE et recense les beacuteneacutefices ct les impcrfcctions perccedilus par les

praticiens dans lindustrie de test Puis nous proposerons quelques expeacuteriences dutilisations

de TE qui ont fait lobjet de plusieurs confeacuterences internationales Noire but sera de deacutefinir et

de comprendre comment et pourquoi les praticiens adoptent et adaptent le TE dans lindustrie

de test Cela va nous permettre didentifier les facteurs influenccedilant ladoption ct ladaptation

de lapproche dans lindustrie Ces facteurs vont nous aider dans la construct ion de notre

cadre comparatif qui va guider notre analyse comparative entre les deux approches le test

seeacutenariseacute (TS) et le test exploratoire (TE)

Eacutetude de Itkonen et Rautiainen ( 2005)

La croissance remarquable dutilisation de TE dans lindustrie de test logiciel el la promotion

eacutetendue de son efficaciteacute par quelques praticiens ont motiveacute les auteurs I1koncn Cl Rautiaincn

(2005) agrave eacutetudier lapproche afin de deacutevoiler ses beacuteneacutefices annonceacutes Ils ont retenu la question

suivante laquo pourquoi ct comment les compagnies utilisent-elles le TE raquo pour aborder leur

recherche Dans le but de reacutepondre agrave cette question ils ont entrepris trois eacutetudes de cas

descriptives aupregraves de trois entreprises finlandaises Une dentre elles est petite avec environ

10 employeacutes travaillant dans le deacuteveloppement du logiciel ct na quun seul produit sur le

marcheacute au moment de lenquecircte Sa meacutethodologie de test sc fonde sur le TE due agrave

limmaturiteacute de son processus de deacuteveloppement Les deux autres entreprises sont

moyennes avec environ 30 et 40 employeacutes dans le deacuteveloppement du logiciel Ses produits

44

ont eacuteteacute sur le marcheacute pe~dant plusieurs anneacutees Leurs meacutethodes de test incluent les deux

approches de test le TE et le TS

Itkonen et Rautiainen (2005) ont eacutelaboreacute sept interviews theacutematiques semi-slruclureacutees avec

les praticiens effectuant le TE dans les trois entreprises Ils ont intervieweacute successivement un

seul testeur de la plus petite entreprise participante dans leacutetude qui avait utiliseacute le TE

seulement deux fois avant (entrevue Puis quatre testeurs de la deuxiegraveme entreprise ougrave le TE

a eacuteteacute introduit dans la meacutethodologie de test six mois avant les entrevues Enfin deux testeurs

de la plus grande entreprise dans lenquecircte ou le TE avait eacuteteacute utiliseacute et ameacutelioreacute pendant

quatre ans Les auteurs ont utiliseacute des thegravemes et des questions ouvertes et neutres afin de

recueillir les opinions et les expeacuteriences reacuteelles des intervenants en mettant lemphase sur les

raisons et les modes dutilisation du TE dans les trois entreprises eacutetudieacutees En mecircme temps

ils ont recenseacute les imperfections et les beacuteneacutefices du TE tels que perccedilus par les praticiens

Parallegravelement agrave leur eacutetude descriptive ltkonen et Rautiainen (2005) ont recueilli des donneacutees

quantitatives sur le TE afin den mesurer la productiviteacute

411 Les raisons dutilisation du test exploratoire

Les reacutesultats de cette eacutetude ont indiqueacute que Je TE est utiliseacute pour les raisons ugrave savoir

bull La difficulteacute de concevoir des cas de test sceacutenariseacutes deacutetailleacutes ugrave cause de jinterdeacutependance

entre les uniteacutes logiciel

bull Le besoin de tester Je logiciel du point de vue de lutilisateur final

bull Le besoin dexploiter la creacuteativiteacute et lexpeacuterience des testeurs dans la deacutetection des

deacutefauts importants

bull Le besoin de fournir aux deacuteveloppeurs un feedback rapide sur les nouvelles uniteacutes

logicielles

bull La capaciteacute du TE de sadapter aux contraintes des environnements dynamiques de

deacuteveloppement et les situations ougrave les exigences du logiciel manquent

45

412 Les modes dutilisation du test exploratoire

Les auteurs Itkonen et Rautiainen (2005) ont identifieacute en se basant sur les informations

recueillies aupregraves des intervieweacutes cinq modes dutilisation principaux de TE dans les trois

eacutetudes de cas reacutealiseacutees Selon les constations de ItkQnen et Rautiainen (2005) lintuition a eacuteteacute

utiliseacutee comme technique de base dans Je TE Aucune autre strateacutegie ou technique speacutecifique

dexploration na eacuteteacute utiliseacutee parmi celles proposeacutees par (Kaner et Bach 2004) Les auteurs

ont identifieacute les modes dutilisation suivants

Test exploratoire baseacute sur session deux des trois entreprises eacutetudieacutees utilisent le TE geacutereacute

par session connu sous Je terme Session Based Exploratory Testing (SBET) Il consiste agrave

utiliser le principe de la technique SBTM proposeacute dans le chapitre JIl sans impleacutementer les

meacutetriques de gestion proposeacutees par (Jonathan Baeh 2000)

Test fonctionnel dune uniteacute logicielle Il sagit de tester une uniteacute logicielle individuelle

directement apregraves limpleacutementation de celle-ci pour produire un fccdback rapide aux

deacuteveloppeurs tregraves tocirct dans le cycle de vie du logiciel

Test exploratoire fumigatoire (Smoke Exploratory Testing) Cc typc dc TE est utiliseacute par

la plus grande entreprise participante dans leacutetudc Il consiste agrave cxplorcr chaque vcrsion du

systegraveme agrave tester par leacutequipe de test avant le deacutebut de test sceacutenariseacute pour formuler une vue

globale sur la qualiteacute du systegraveme et sassurer que les reacuteparations sont proprement

impleacutementeacutees ct que les fonctions les plus cruciales fonctionnent sans se preacuteoccuper des

petits deacutetails

Test exploratoire de reacutegression deux des trois entreprises eacutetudieacutees utilisent Ic TE dans le

tcst de reacutegression pour veacuterifier que les modifications nont pas causeacute deffets inattendus agrave

dautres parties du logiciel 11 sagit dexplorer le systegravemc dans unc courte session sans

aucune planification Les reacutesultats de cette session sont informcllcmcnt communiqueacutes aux

deacuteveloppcurs En fait la limitation de ressources el du temps ont eacuteleacute les motifs principaux

pour utiliser Je TE dans un test de reacutegression au lieu dutiliser le lcsl de reacutegression habituel

par une reacutepeacutetition seacutelective des cas de tests deacutejagrave conccedilus

46

Test exploratoire libre ce type de test est perccedilu par les intervieweacutes dans la grande

entreprise comme une pratique systeacutematique et naturelle qui devrait se faire pendant

lexeacutecution des cas de test sceacutenariseacutes

413 Les beacuteneacutefices du test exploratoire

En ce qui concerne les beacuteneacutefices perccedilus de TE tous les intervieweacutes ont il lustreacute que la

souplesse et la flexibiliteacute de lapproche leur permettrait de tester en profondeur les uniteacutes

logicielles qui ne pourront pas ecirctre traiteacutees dans les cas de tests sceacutenariseacutes comme les

interdeacutependances entre les anciennes et les nouvelles uniteacutes logicielles (ltkonen ct

Rautiainen 2005) Selon les constatations de ces mecircmes auteurs la productiviteacute en terme de

nombre des deacutefauts deacutetecteacutes et limportance de ces deacutefauts a eacuteteacute perccedilue comme un beacuteneacutefice

Cependant les intervieweacutes ont relieacute la productiviteacute agrave lexpertise des testeurs dans le TE Ils

affirment que le TE ne poulTa pas ecirctre productif si le testeur na pas dcs connaissances

adeacutequates dans le domaine daffaire du logiciel agrave tester Ils ajoutent que la diffeacuterence dans

lattitude pendant le test joue un rocircle crucial dans la productiviteacute perccedilue de TE En effet le

testeur tend plus agrave veacuterifier lexactitude entre les reacutesultats observeacutes ct les reacutesultats preacutevus

identifieacutes dans les cas de test sceacutenariseacutes dans une activiteacute de TS Par contre dans le TE le

testcur aborde le logiciel avec une attitude laquo offensiveraquo Autrement dit il cherche les

deacutefaillances avec de la curiositeacute et un œil critique (ltkonen et Rautiainen 2005) Les

reacutepondants ont affirmeacute aussi que le TE est productif seulement dans les courtes peacuteriodes cie

test en consideacuterant le nombre dheures utiliseacutees et le nombrc de deacutefauts deacutetecteacutes Tandis quagrave

long terme il ne pourrait pas ecirctre productif agrave cause de la difficulteacute destimcr la couverture de

tests pendant lactiviteacute de test Par la suite quelques parties ou caracteacuteristiques du logiciel

peuvent ecirctre livreacutees sans ecirctre testeacutees (ltkonen et Rautiainen 2005)

414 Les lacunes du test exploratoire

Selon les constations de 1lkonen et Rautiainen (2005) la couverture limiteacutec est la plus grande

lacune de TE

Ccci a eacuteteacute mentionneacute par lous les intervieweacutes dans lenquecirctc quils ont entreprise

47

Les reacutesultats ont montreacute que la deacutependance de TE agrave la creacuteativiteacute et agrave lexpeacuterience des testeurs

a eacuteteacute perccedilue aussi comme un deacutesavantage du TE du fait que le TE est sujet aux erreurs

humaines

Malgreacute la profondeur et la rigueur de cette recherche elle est limiteacutee par le nombre et la taille

des entreprises participantes Ceci apparaicirct clairement agrave plusieurs reprises dans la recherche

ougrave les reacutesultats obtenus concernent une seule entreprise parmi les trois participantes Donc

nous ne pouvons pas savoir si les reacutesultats obtenus sont geacuteneacuteraux ou des cas isoleacutes En ce qui

concerne la productiviteacute de lapproche dans la deacutetection de deacutefauts la recherche na pas

proposeacute des preuves fiables En fait les donneacutees quantitatives collecteacutees ne peuvent pas ecirctre

deacutefinitives Agrave cause de labsence des donneacutees quantitativcs du TS qui pourraient constituer

une base de comparaison Leacutetude est quand mecircme un apport utile agrave lenrichissement de la

litteacuterature sur les justifications et les modes dutilisation du TE

42 Eacutetude de Petty (2005)

Petty (2005) preacutesente une expeacuterience dutilisation de lapproche Session Based Exploratory

Testing (SBET) comme une meacutethodologie primaire de test en remplacement dc la meacutethode

sceacutenariseacutee habituelle Cette derniegravere se trouvait incapable de sadapter aux changements

freacutequents des exigences du logiciel Alors lintroduction de la meacutethode SBET a eacuteteacute perccedilue

comme une solution vu les frustrations accumuleacutees de Jutilisation dc TS Ces reacutealiteacutes

reacutesident dans le changement continu des exigences et labsence du temps suffisant de test du

logiciel La meacutethode SBET adopteacute par Petty (2005) est inspireacutee dans unc grande partie de

celle proposeacutee par Jonathan Bach (2000) Cette meacutethodc a permis aux testeurs decirctre agiles

dans le sens ougrave ils ont eacuteteacute capables de sadapter agrave lincertitude et au changement de logiciel et

de tester adeacutequatement le logiciel agrave un coucirct optimal

Selon les constatations de Petty (2005) la chose la plus inteacuteressante dans la meacutethode SBET

est quelle a eacutelimineacute le besoin de retravailler ct de mettre agrave jour les cas dc tests sceacutenariseacutes

apregraves chaque changement du logiciel Ce temps selon lauteur a pu ecirctre invcsti dans le test et

Jameacutelioration de qualiteacute du produit logiciel

48

Petty (2005) a utiliseacute des pairs cest-agrave-dire que deux personnes sassoient agrave seul ordinateur et

exeacutecutent la mecircme mission de test Chacune de ces paires est composeacutee dun testeur et dun

deacuteveloppeur Selon les constatations de lauteur lutilisation de lapproche SBET en pair a

ameacutelioreacute consideacuterablement la qualiteacute de test effectueacute En effet dans une session de test par

pairs un membre de la paire peut se concentrer sur la conception des tests et lautre sur

lenregistrement et la reacutedaction de notes Les rocircles des membres de la paire sont eacutechangeacutes

plusieurs fois pendant la session Cela augmente la creacuteativiteacute et la concentration du membre

qui conccediloit les tests et eacutelimine la distraction qui pourrait ecirctre causeacute par lenregistrement des

notes Aussi la collaboration et le pa11age des connaissances tacites des membres de leacutequipe

pendant la session ont ameacutelioreacute la compreacutehension et lapprentissage du logiciel sous test

Notons que lutilisation de deacuteveloppeurs dans les pairs a permis de corriger les deacutefauts en

temps reacuteel sans avoir besoin denregistrer beaucoup de notes de session ni de les reproduire

ulteacuterieurement

Selon les constations de Petty (2005) le fait que lapproche SBET soit baseacutee sur lexploration

et lapprentissage a pousseacute les testeurs agrave simpliquer plus dans Je processus de conception et

de clarification des exigences pour pouvoir comprendre le produit logiciel et son domaine

daffaire Cela a eu des reacutepercussions positives sur la qualiteacute des tests effectueacutes et sur la

capaciteacute de deacutetecter des deacutefauts ulteacuterieurement pendant le test Les testeurs sont devenus plus

capables de diffeacuterencier entre un deacutefaut et un comportement normal du logiciel Ce concept

est connu sous le terme doracle de test Il sera abordeacute plus en deacutetail dans le chapitre VII

Selon les constatations de Petty (2005) lapproche SBET a eacuteteacute tregraves efficace dans le cas de

leur projet de test Ce projet se caracteacuterisait par le changement Uumleacutequent des exigences qui

sonl souvent communiqueacutees verbalement Par la suite la meacutethode SBET lui a permis de

pouvoir reacutepondre agrave ces changements rapidement Selon les constatations de lauteur le moral

de leacutequipe de test a augmenteacute consideacuterablement pendant le test du logiciel Agrave cause de

leacutelimination du fardeau habituel de la mise agrave jour des cas de tests lors de changement du

logiciel La communication entre les testeurs et les deacuteveloppeurs sest ameacutelioreacutee et

transformeacutee dune relation dadversiteacute agrave une relation de collaboration Cependant lauteur

souligne que la reacuteussite de la meacutethode SBET deacutepend fortement de lexpeltise et les

49

connaissances de domaine daffaires des membres de leacutequipe de test Petty (200S) souligne

aussi que la capaciteacute dapprentissage est plus rapide en TE quen TS Mais selon lauteur

cette capaciteacute deacutepend encore des personnes impliqueacutees

Linnovation de la meacutethode preacutesenteacutee par Petty (200S) est Jutilisation de paires composeacutees

des testeurs et des deacuteveloppeurs Cela permet de corriger les deacutefauts pendant les tcsts sans

avoir le besoin de les reproduire ulteacuterieurement La participation de testeurs dans la phase de

clarification et de deacutefinition dexigences a permis dameacuteliorer la qualiteacute de Joracle de test

Toutefois lauteur na pas preacutesenteacute de donneacutees quantitatives sur la productiviteacute de Japproche

SBET et le degreacute dameacutelioration reacutealiseacute par lintroduction de lapproche dans la

meacutethodologie de test En plus la taille de lentreprise ougrave sest deacuterouleacutee lexpeacuterience est petite

ce qui simplifie eacutenormeacutement la communication et la collaboration entre les testeurs et les

deacuteveloppeurs Par contre dans les grandes entreprises le projet de test est souvent seacutepareacute du

processus de deacuteveloppement (Pyhajarvi et aL 2003) Par conseacutequent nous ne pouvons pas

savoir si la faccedilon dadoption de lapproche SBET proposeacutee par Petty (200S) pourrait

sappliquer dans les grandes entreprises Cependant cette eacutetude est un apport utile agrave

lenrichissement de la litteacuterature sur les modes dadoption du TE surtout dans les petites

entreprises de deacuteveloppement du logiciel

43 Eacutetude de Lyndsay et van Eeden (2003)

Les auteurs Lyndsay et van Eeden (2003) deacutecrivent leur expeacuterience reacuteussie dans la mise en

oeuvre de la technique Session Based Exploratory Testing (SBET) Cette mise en oeuvre a

pris place dans une petite entreprise anglaise en sinspirant des travaux de Jonathan Bach

(2000) qui sont deacutejagrave abordeacutes dans le chapitre lll Lobjectif principal de limpleacutementation de

lapproche SBET eacutetait dintroduire le controcircle et la mesure sur jactiviteacute de lest ad-hoc

existant dans lentreprise (test exploratoire libre selon Bach (2003) parce que les testeurs

enregistrent les deacutefauts deacutetecteacutes dans le Bug Tracking System) Le choix de la technique

SBET eacutetait pour reacutepondre agrave un mandat dameacutelioration de la qualiteacute dune petite application

Web deacutejagrave testeacute en utilisant le test ad hoc tout en restant dans la limite des ressources

existantes Alors le manque du temps et de personnel ont pousseacute les auteurs agrave utiliser

lapproche SBET au lieu dutiliser un TS que les ressources disponibles ne le pcrmctlcnt pas

50

La meacutethode proposeacutee par Lyndsay et van Eeden (2003) se fonde sur les quatre eacuteleacutements cleacutes

citeacutes ci-dessous

Controcircle de la porteacutee du test Pour geacuterer la porteacutee de test les auteurs ont introduit le

concept de point de test Le terme point de test sous-entend une partie ou plusieurs concepts

du logiciel sous test neacutecessitant lexploration et la conception de plusieurs cas de test pour

remplir la mission de test de ce point Lobjectif de lintroduction de ce concept est davoir le

controcircle sur la porteacutee de test pendant le test de chaque version du logicieL Autrement dit ecirctre

capable de deacuteterminer ce qui doit ecirctre testeacute dans chaque version En effet labsence dune

liste de test deacutetermineacutee dans le processus ad hoc existant et labsence des exigences dans

lensemble de projet du deacuteveloppement a rendu difficile lidentification du volume de test

neacutecessaire de chaque version ou apregraves chaque changement En effet avant lintroduction de

lapproche SBET la porteacutee de test a eacuteteacute guideacutee par les deacutefauts trouveacutes et par les preacutedictions ct

les intuitions de testeurs sur les secteurs du logiciel devant ecirctre testeacutes Donc une liste de point

de test va permettre de seacutelectionner les parties devant ecirctre testeacutees de chaque version Ainsi

une liste de points de test va permettre deacutevaluer le statut et la progression de projet de test

simplifier la communication agrave linteacuterieur et agrave lexteacuterieur de leacutequipe de test deacuteviter la

duplication du travail agrave linteacuterieur de leacutequipe de test dans le sens ou une partie poulTait ecirctre

lesteacutee par plusieurs testeurs (Lyndsay et van Eeden 2003)

Controcircle du travail de leacutequipe de test les auteurs ont proposeacute le concept de test en session

pour controcircler le travail accompli par chaque testeur La session est un intervalle non

interrompu Dans une session de test le testeur se charge de lexeacutecution dune ou plusieurs

points de test et rapporte les deacutefauts trouveacutes et les questions rencontreacutees pendant lexploration

agrave la fin de la session de test Les questions megravenent souvent agrave des nouvelles pistes pour la

conception de dautres points de test Ce rapport de test fera lobjet dune revue et une

discussion avec le responsable de test Ce dernier eacutevalue le travail accompli par le testeur et

le guide vers dautres astuces ou strateacutegies si neacutecessaire (Lyndsay et van Eeden 2003)

Mesure de la couverture de tests selon Lyndsay et van Eeden (2003) la couverture de test

consiste agrave mesurer ce qui a eacuteteacute testeacute comme proportion de ce qui poulTait ecirctre testeacute

51

Selon ces mecircmes auteurs labsence des exigences documenteacutees et de cas de test sceacutenaliseacute a

rendu impossible dutiliser les meacutethodes formelles habituelles de mesure de couverture de

test dans lactiviteacute de test effectueacute par lapproche de test SBET (ces meacutethodes seront

abordeacutees en deacutetail dans le chapitre VII) Face agrave ceci les auteurs ont proposeacute une technique de

mesure de couverture de tests qui sadapte avec les caracteacuteristiques speacuteciales de lapproche

SBET Leur technique fondeacutee sur lestimation et leacutevaluation subjective de laquola testabiliteacuteraquo

sous-entend le pourcentage testeacute ou couvert par les tests de chaque point de test dans la

session de test Apregraves lexeacutecution de la session de test le responsable de test eacutevaluera le

travail accompli par le testeur et en mecircme temps veacuterifiera le pourcentage estimeacute de la

testabiliteacute rapporteacute par le testeur de chaque point de test Si le pourcentage est insuffisant et le

risque associeacute a ce point de test exige un pourcentage supeacuterieur leffort de test neacutecessaire

pour accomplir ce point de test est re-estimeacute (Lyndsay et van Eeden 2003) En calculant la

testabiliteacute de chaque point de test les auteurs ont pu calculer la couverture globale du produit

logiciel sous test agrave nimporte quel moment du processus de test en utilisant la formule

suivante

Couverture de test = la somme de temps de points de test compleacuteteacuteslestimation de la

somme de temps neacutecessaire pour accomplir les points de test restants

Mesure et hieacuterarchisation de risque les auteurs Lyndsay et van Eeden (2003) ont mesureacute

le risque de chaque point de test en terme de la probabiliteacute doccurrence dune deacutefaillance

associeacutee agrave ce point de test et )impact de cette deacutefaillance sur le fonctionnement du logiciel

Cela leur permis de classifier et destimer leffort neacutecessaire pour tester chaque point de test

et de prioriser les tacircches du test Autrement dit les points de test repreacutesentant plus de risque

recevront plus de tests

Selon les auteurs Lyndsay et van Eeden (2003) lintroduction de lapproche a eu des reacutesultats

immeacutediats et des reacutesultats agrave long terme En ce qui concerne les reacutesultats immeacutediats leacutequipe

de test a pu produire une meacutetrique de couverture utile degraves la premiegravere utilisation de

Japproche SBET Ce fait a eu une reacutepercussion positive sur la qualiteacute du produit parce que

les parties agrave grands risques du logiciel ont reccedilu plus dattention et plus de tests Lutilisation

52

de lapproche SBET a permis de controcircler le travail des testeurs apregraves lexeacutecution de chaque

session sans avoir le besoin decirctre sur place pendant le test En ce qui concerne la

productiviteacute les auteurs nont pas pu tirer de conclusions fiables agrave cause de labsence des

mesures quantitatives avant lintroduction de lapproche SBET

Cependant mecircme avec laugmentation du nombre derreurs trouveacutees dans les cinq mois qui

suivent lutilisation de SBET les auteurs Lyndsay et van Eeden (2003) nont pas pu savoir si

cette augmentation due a ljntroduction de lapproche SBET ou laugmentation de la

complexiteacute de lapplication et lajout de nouvelles fonctionnaliteacutes A long terme les auteurs

Lyndsay et van Eeden (2003) ont remarqueacute que le produit est devenu plus stable et que le

nombre de deacutefauts trouveacutes a diminueacute dune faccedilon signi ficative bjen que de nouvelles

fonctionnaliteacutes sajoutent toujours Aussi ils nont pas pu savoir si cette reacuteduction provenait

de Jameacutelioration de la qualiteacute du code ou de lincapaciteacute de lapproche SBET agrave deacutetecter

dautres deacutefauts Toutefois selon Lyndsay et van Eedcn (2003) lintroduction de la technique

a eu une reacutepercussion positive sur tout le projet de deacuteveloppement du fait quelle a inciteacute les

responsables de projet de deacuteveloppement agrave ameacuteliorer la globaliteacute du processus de

deacuteveloppement surtout la documentation Selon ces mecircmes auteurs quelques reacutesul1ats

intangibles ont eacuteteacute perccedilus suite agrave Jintroduction de SBET JI sagit de lameacutelioration de la

visibiliteacute agrave linteacuterieur et lexteacuterieur du processus de tcst

En geacuteneacuteral selon les auteurs Lyndsay et van Eeden (2003) lapproche SBET a eacuteteacute tregraves

efficace dans le cas de leur projet de test Elle a permis dintroduire Je controcircle et la mesure

sur le processus ad hoc existant Ces mecircmes auteurs soulignent que la meacutethode a permis

dencourager la communication entre les membres du test au lieu dutiliser la documentation

pour le faire Ils ajoutent que le deacutebriefing utiliseacute dans lapproche SBET apregraves lexeacutecution de

chaque session de test a permis de former les testeurs et leur apprendre les techniques de

tests Toutefois ils affirment que cetle meacutethode pourrait ecirctre moins efficace dans un

environnement de deacuteveloppement plus sophistiqueacute ]Is soulignent aussi que la qualiteacute de test

effectueacute deacutepend de la creacuteativiteacute et lexpertise des membres de leacutequipe de test

53

La taille et la nature de lapplication qui a eacuteteacute le sujet de cette eacutetude ne permettent pas de

geacuteneacuteraliser les reacutesultats de cette eacutetude La meacutetrique de couverture proposeacutee dans leacutetude est

subjective et deacutepend aussi de lexpertise du testeur Mais les ideacutees et les techniques de

mesures proposeacutees sont inteacuteressantes et initient plusieurs pistes de recherches afin

dameacuteliorer ladoption de lapproche SBET

44 Eacutetude de James et Wood (2003)

Les auteurs Wood et James (2003) deacutecrivent leur expeacuterience dutilisation de lapproche

Session Based Exploratory Testing (SBET) Alors lapproche SBET a eacuteteacute introduite pour

tester un logiciel destineacute agrave ecirctre utiliseacute dans les appareils meacutedicaux Les auteurs ont eu recours

agrave la technique SBET pour deux raisons la premiegravere raison est la moindre cougravet de lapproche

SBET qui leur a permis de lutiliser comme une meacutethode compleacutementaire agrave la meacutethode

sceacutenariseacutee de test Cette derniegravere a un coucirct consideacuterable agrave cause des frais de documentation

des tests Cette documentation doit ecirctre deacutetailleacutee et rigoureuse dans le domaine du test des

logiciels meacutedicaux afin de respecter les normes de la qualiteacute du systegraveme (Quality System

Regulation) La deuxiegraveme raison est que les auteurs ont cu besoin dune meacutethode de test

pouvant introduire linnovation et la creacuteativiteacute dans le test en leur permettant de deacutetecter les

erreurs manqueacutees par lapproche sceacutenariseacutee

Les auteurs ont utiliseacute lapproche SBET comme une meacutethode de test compleacutementaire agrave la

meacutethode sceacutenariseacutee principale Cette derniegravere est baseacutee sur la validation des exigences et la

veacuterification de code du logiciel sous test Le test de validation est centreacute sur la couverture des

exigences et le respect des standards Ccci neacutecessite une traccedilabiliteacute accrue entre les

proceacutedures de tests et les exigences initiales Selon James et Wood (2003) ce type de test ne

met pas lemphase sur la deacutetection des deacutefauts tant que le respect des exigences ct les normes

du domaine de deacuteveloppement du logiciel meacutedical Le test de veacuterification est baseacute sur la

couverture de code Ce type de couverture cherche agrave satisfaire un critegravere de couverture de

code par exemple 80 des blocs de code doivent avoir au moins un test qui les parcourt

Autrement lexeacutecution dun maximum de lignes de code possibles pour eacuteviter quun bogue

reste dans le logiciel agrave cause dune ligne de code non exeacutecuteacutee pendant les tests Selon James

ct Wood (2003) le test de veacuterification ne met pas Jaccent sur la deacutetection de deacutefauts tant gue

la couverture de code par les tests

54

Les faiblesses des deux meacutethodes de test le test de validation et le test de veacuterification ont

motiveacute les auteurs agrave introduire lapproche SBET dans le but de deacutetecter les deacutefauts qui

peuvent ecirctre manqueacutes par ces meacutethodes de test

James et Wood (2003) ont organiseacute le test en sinspirant de la meacutethode proposeacutee par Jonathan

Bach (2000) deacutejagrave preacutesenteacutee dans le chapitre III Au deacutebut ils ont planifieacute les chartes de test

et ont estimeacute leffort neacutecessaire pour rempl ir chacune dentre elles Pendant lexeacutecution de

chaque charte le testeur devrait enregistrer les deacutefauts deacutetecteacutes ct les opportuniteacutes

rencontreacutees Notant quune opportuniteacute sous-entend des nouvelles pistes de test deacutecouvertes

pendant Jexploration qui pourraient donner lieu agrave la creacuteation de nouvelles chartes Agrave la fin

de lexeacutecution de chaque charte les auteurs deacutebriefent le testeur pour eacutevaluer les reacutesultats

rapporteacutes et mettre agrave jour le plan des chartes si neacutecessaire

Selon Wood et James (2003) lapproche SBET est une meacutethode de test tregraves efficace dclns le

domaine de deacuteveloppement des logiciels meacutedicaux du fait quelle pourrait deacutetecter les

deacutefauts pouvant ecirctre manqueacutes par les autres meacutethodes de test Un autre avantage de la

meacutethode SBET signaleacute par ces mecircmes auteurs est la documentation produite pendant les tests

qui est tregraves appreacutecieacutee dans Je domaine de deacuteveloppement du logiciel meacutedical Les auteurs

soulignent que lapproche SBET a encourageacute la creacuteativiteacute cr linllovation de testeurs Cela a

pennis de deacutetecter des deacutefauts impol1ants dans le logiciel agrave moindre coucirct par rapport aux

meacutethodes sceacutenariseacutees traditionnelles tel quillustreacute agrave la figure 4 J

55

Figure 41 Coucirct de documentation versus linnovation dans le test (Adapteacute et traduit de

James et Wood)

r---------- -Qgt 1 1

1 Session Based 1 Qgt

-GS Exploratory ~

1 testino 1~ ------1----------~

= C

C 0 -c

sect 2-~

1l 1l 1

Test de verificatioo

1

1 J r----------

0 c 1 1 -= J -~

Test de -0 1 Validation 1 -(1)

0 1 1I

1 1J

Reacuteduit Moyenne Itleveacute

Coftt typique de documentation

En ce qui concerne la productiviteacute de lapproche SBET les auteurs James et Wood (2003)

soulignent quelle est plus efficace que les deux approches sceacutenariseacutees utiliseacutees le test de

veacuterification et le test de validation en se basant sur les reacutesultats publieacutes par (Joncs TCJones

1998) Ces reacutesultats ont montreacute que le test dutilisabiliteacute est plus efficace que le test de

veacuterification et le test de validation En faisant lanalogie entre Je test dutilisabiliteacute et le

SBET les auteurs ont pu conclure que lapproche SBET est plus cfficace que la meacutethode

sceacutenariseacutee cest agrave dire plus efficace que le test sceacutenariseacute de validation et de veacuterification En

effet selon James et Wood (2003) le test duti]isabiliteacute et Japproche SBET sont semb1abJes

agrave cause de trois raisons la premiegravere est que les deux se fondent sur le manuel dutilisateur la

deuxiegraveme que les deux seffectuent sur des pctitcs peacuteriodes seacutepareacutees connues sous le terme

de laquosession de testraquo et la troisiegraveme que les deux utilisent les talents et la creacuteativiteacute de testeurs

Toute fois James et Wood (2003) ont souligneacute que la qualiteacute de test effectueacute deacutepend des

qualifications et Jexpertise des testeurs qui exeacutecutcnt les tests Selon cs auteurs la meacutethode

SBET ne fournit quun protocole ou une structure dorganisation et de gestion mais ne

garantit pas la qualiteacute de test effectueacute ]Is ont souligneacute aussi que le rocircle de responsable de test

est crucial et infiuence la qualiteacute globale de test effectueacute du fait que ccst lui qui identifie et

56

deacutetermine la liste des eacuteleacutements de test et le contenu des chartes Par conseacutequent la couverture

de test de haut niveau deacutepend des compeacutetences et de lexpertise du responsable du test

Cette eacutetude montre que le TE pourrait ecirctre utiliseacute mecircme dans les domaines de test le plus

critique comme une meacutethode compleacutementaire agrave la meacutethode sceacutenariseacutee Agrave cause de sa valeur

ajouteacutee et son innovation dans la deacutetection des deacutefauts pouvant ecirctre manqueacutes par les

meacutethodes sceacutenariseacutees traditionnelles Cependant leacutetude na pas preacutesenteacute des donneacutees

quantitatives sur la productiviteacute de lapproche SBET et le degreacute dameacutelioration reacutealiseacute de

qualiteacute du logiciel testeacute

45 Eacutetude de Amland et Vaga (2002)

Les auteurs Amland et Vaga (2002) deacutecrivent une eacutetude de cas dutiJisation de TE en tant

quune strateacutegie de test primaire dans une entreprise norveacutegiennc Lintroduction de

japproche eacutetait pour tester un portail Web Linstabiliteacute et le changement freacutequent des

exigences et le manque du temps eacutetant les motifs principaux quc ont pousseacute les auteurs agrave

chercher une approche de test qui peut sadapter avec les contraintes changeantes de leur

projet de test a la place de lapproche sceacutenariseacutee habituelle qui eacutetait incapable de sadapter agrave

ces contraintes

En effet au deacutebut les auteurs ont commenceacute la preacuteparation de plan de test et des cas de test

formels neacutecessaires pour la mise en œuvre dune approche de test sceacutenariseacute Agrave cause de

labsence des exigences du systegraveme les auteurs ont utiliseacute le TE libre pour se renseigner sur

le logiciel planifier et concevoir les cas de tests Cependant les deacuteveloppeurs ou les auteurs

ont eu le mandat de tester le logiciel deacuteveloppeacute ont continueacute dintroduire des changements au

code De ce fait selon Amland et Vaga (2002) lapproche sceacutenariseacutee de test ne pourra pas

ecirctre rentable dans leur cas parce quapregraves chaque changement dans Je logiciel ils devront

retravailler les artefacts de test deacutejagrave conccedilus

Agrave cet effet Amland et Vaga (2002) ont deacutecideacute dutiliser le TE Cependant les auteurs ont

reacutealiseacute que la meacutethode de gestion ct de controcircle de TE a un rocircle deacutecisif dans la reacuteussite de

leur projet de test surtout si tout le temps disponible pour le test est seulement de deux jours

57

Alors Amland et Vaga (2000) ont geacutereacute le TE dune faccedilon proche de la meacutethode proposeacutee par

Jonathan Bach (2000) Ils ont preacutepareacute des directives pour les sept pairs participantes dans le

test dacceptation de portail En fait ces directives ont eacuteteacute eacutelaboreacutees agrave partir de plan de test

formel deacutejagrave conccedilu Ce plan identifie deacutejagrave les items du logiciel agrave tester et les items ne doivent

pas ecirctre testeacutes Ces items ont eacuteteacute utiliseacutes pour controcircler la couverture de tests Avant le deacutebut

de test les testeurs ont suivi une fonnation de deux jours puis un briefing de 20 minutes a eacuteteacute

mis en oeuvre pour annoncer aux testeurs les secteurs fonctionnels principaux quils doivent

tester En plus un controcircle aupregraves de testeurs pendant le deacuteroulement de test a aideacute les

auteurs dans la direction des testeurs en cas de deacuteraillement sur les directives

Selon les constatations de Amland et Vaga (2002) lexpeacuterience dutilisation de TE a eacuteteacute

fructueuse Toutefois ils affirment que la creacuteativiteacute et les connaissances des testeurs ct du

responsable du test chargeacute de la seacutelection de la liste des items agrave test cr sont essentielles dans le

TE et peuvent innuencer la qualiteacute du test

Malgreacute la reacuteussite de cette eacutetude de cas la taille ct la nature de lapplication ne permettent pas

de geacuteneacuteraliser les reacutesultats obtenus ni de tirer des conclusions fiables Toutefois cette

expeacuterience a introduit une situation reacuteelle ou le TE a eacuteteacute impleacutementeacute pour confrontcr les

contraintes changeantes de projet de test Cette eacutetude de cas nous a montreacute que les artefacts

seeacutenariseacutes formels pourront servir dans limpleacutementation de TE sans avoir lobligation

dutiliser les techniques proposeacutees par Jonathan Bach (2000) et Lyndsay et van Eeden (2003)

46 Synthegravese des reacutesultats des eacutetudes proposeacutees

Les eacutetudes que nous avons preacutesenteacutees dans ce chapitre nous ont pelmis de tirer plusieurs

conclusions dapregraves des expeacuteriences reacuteelles dutilisation de TE Ainsi elles nous ont permis

de comprendre comment les praticiens et les professionnels dans Jindustrie de test perccediloivent

le TE comment ils limpleacutementent dans la pratique pourquoi ils lutilisent les difficulteacutes et

les lacunes rencontreacutees lors de lutilisation de TE et finalement deacutelaborer une vue globale et

commune agrave partir de toutes les eacutetudes proposeacutees

58

Nous avons constateacute que les praticiens ne considegraverent que lapproche SBET comme un TE

tandis que le TE libre est consideacutereacute comme un test ad hoc (Lyndsay et van Eeden 2003

Amland et Vaga 2002) Ainsi tous les auteurs dans les eacutetudes de cas que nous avons

preacutesenteacutees adoptent une forme personnaliseacutee de lapproche SBET Autrement dit les auteurs

organisent lactiviteacute de test dans des sessions de test de dureacutee deacutetermineacutee chacune delles

produit des notes qui font lobjet dune eacutevaluation par le responsable de test Nous avons

constateacute aussi que ces eacutetudes ne mentionnent pas les techniques utiliseacutees pendant

lexploration et les tests malgreacute la diversiteacute des techniques proposeacutees par les concepteurs de

TE Kaner et Bach (2004) dont quelques-unes deacutejagrave eacutevoqueacutees dans le chapitre Ill En fait dans

la plupart des eacutetudes les testeurs utilisent leurs intuitions pour deacutetecter les deacutefauts nous

pourrons mecircme dire quil sagit dun test ad hoc planifieacute et structureacute

Toutes les eacutetudes que nous avons preacutesenteacutees dans ce chapitre ont montreacute que les changements

freacutequents du logiciel la pression de temps et la limitation de ressources en tcrme de budget

de test et de personnel sont les raisons principales pour utiliser le TE plus particuliegraverement

Japproche SBET Certaines eacutetudes (Itkonen et Rautiainen 2005 Lyndsay et van Eeden

2003 Amland et Vaga 2002) ont signaleacute Je manque de controcircle de couverture de test comme

une lacune du TE Toutes les eacutetudes (ltkonen et Rautiainen 2005 Petty 2005 Lyndsay et

van Eeden 2003 Wood et James 2003 Amland et Vaga 2002) ont signaleacute que la qualiteacute du

TE effectueacute deacutepend des quai ifications et de la creacuteativiteacute des testeurs De plus deux de ces

eacutetudes ajoutent que la qualiteacute de TE deacutepend aussi des compeacutetences et des qualifications du

responsable de test (Wood ct James 2003 Amland et Vaga 2002) La planification et le

controcircle de lapproche SBET ont eacuteteacute mentionneacutes comme dcs facteurs impol1ants de succegraves de

lactiviteacute de test (Lyndsay et van Eeden 2003 Wood ct James 2003 Amland et Vaga

2002)

En geacuteneacuteral nous avons constateacute que toutes les eacutetudes de cas ont eacuteteacute faites sur des petites

applications et avec des petites eacutequipes de test La collaboration et la communication entre

les membres de leacutequipe de test la concentration sur laccomplissement du travail de test

plutocirct que la documentation et la gestion de processus ont eacuteteacute les eacuteleacutements cleacutes de lapproche

SBET Ceux-ci nous ont pousseacute de faire janalogie enlre le deacuteveloppement du logiciel el le

59

test du logiciel autrement dit lanalogie entre lagiliteacute et la discipline du processus de

deacuteveloppement et linformaliteacute et la discipline de processus de test Nous allons aborder en

deacutetail au cours de notre eacutetude comparative dans le chapitre VII cette analogie que nous avons

lexploiteacutee pour construire notre cadre conceptuel de comparaison qui va nous permettre de

comparer les deux approches de test le TE et le TS

51

CHAPITRE V

LEacuteTUDE EMPIRIQUE

Dans ce chapitre nous preacutesentons les eacutetapes principales de notre eacutetude empIrIque Tout

dabord nous proposerons la motivation de leacutetude et la strateacutegie que nous avons choisie pour

laborder Puis nous preacutesenterons le scheacutema conceptuel de lexpeacuterience Par la suite nous

analyserons les reacutesultats recueillis et nous conclurons

Motivation de leacutetude

Depuis son apparition dans lindustrie du test Je test exploratoire (TE) se fait preacutesenter

comme une approche productive qui pourrait augmenter lefficaciteacute de Jactiviteacute de test en

termes de nombre et dimportance de deacutefauts deacutetecteacutes Selon Bach (2003) le TE pourrait ecirctre

plus productif que le test sceacutenariseacute (TS) Cependant lauteur na pas preacutesenteacute de preuves de

cette reacuteclamation agrave palt quelques anecdotes et expeacuteriences personnelles Un tour rapide sur

les reacutecentes publications de Kaner sur son site l montre que le TE se fait traiter comme une

innovation scientifique qui exploite et optimise la creacuteativiteacute et lexpertise du testeur dans la

deacutetection des deacutefauts importants qui ne pourraient pas ecirctre deacutetecteacutes par le TS Selon Kaner et

Bach (2005) Je TS transforme les testeurs en robots inefficaces Ces arguments nous ont

motiveacutee agrave faire une eacutetude empirique pour eacutevaluer la productiviteacute du TE Tout dabord nous

allons comparer les reacutesultats de TE recueillis de Jexpeacuterience avec les reacutesultats quantitatifs

publieacutes par ltokens et Rautiainen (2005) Puis nous proceacutederons agrave une analyse comparative

empirique enlre le TE et le TS en se basant sur les reacutesultats de notre eacutetude

Cependant dans la mise en ouvre de notre eacutetude empirique nous avons eacuteteacute confronteacutee au

1 wwwtcstingeducationorg

61

problegraveme du contexte expeacuterimental En effet dans un contexte industriel nous pouvons

utiliser comme instrument de lexpeacuterience un logiciel professionnel cest agrave dire un logiciel

deacuteveloppeacute dans Jindustrie de deacuteveloppement du logiciel Ce logiciel pourrait ecirctre testeacute avec

deux groupes un utilise le TS et lautre le TE Les donneacutees pourraient ecirctre recueillies

pendant Jactiviteacute de test et sur le site de production du logiciel testeacute Par la suite lanalyse

des reacutesultats de lexpeacuterience doit ecirctre faite sur deux niveaux le premier est de comparer le

nombre et limportance des deacutefauts deacutetecteacutes avant la livraison du logiciel cest agrave dire agrave la fin

de lactiviteacute de test Le deuxiegraveme est de comparer le nombre et limportance des deacutefauts

deacutetecteacutes apregraves Ja livraison du logiciel cest agrave dire dans le site dutilisation du logiciel testeacute

Cette strateacutegie pennettrait de mesurer la productiviteacute pendant et apregraves lactiviteacute de test Or la

mise en place dune telle expeacuterience neacutecessite lengagement dune entreprise de

deacuteveloppement du logiciel agrave participer agrave lexpeacuterience et agrave divulguer les informations de son

activiteacute de test Malheureusement nous navons pas pu trouver une entreprisc pour se plier agrave

ces contraintes Cela nous a obligeacutee agrave concevoir une nouvelle strateacutegie pour notre expeacuterience

dans le contexte acadeacutemique ougrave nous avons deacutecideacute de la faire

52 La strateacutegie de lexpeacuterience

Dans un contexte acadeacutemique lexpeacuterience pourrait ecirctre entreplise de deux faccedilons

diffeacuterentes la premiegravere consiste agrave faire lexpeacuterience de la mecircme faccedilon que si elle se deacuteroulait

dans le contexte industriel cest agrave dire nous divisons les sujets en deux groupes dont un

exeacutecute le TE et lautre le TS Nous pouvons mecircme aller plus loin et utiliser japproche

SBET pour controcircler la couverture de test et eacuteviter que les deacutefauts deacutetecteacutes soient dupliqueacutes

Quant au TS il poulTait ecirctre exeacutecuteacute de la mecircme faccedilon quen industrie Alors chaque sujet

exeacutecute des cas de tests correspondant agrave une partie du logiciel Finalement nous analysons le

nombre et limportance des deacutefauts rappol1eacutes pour deacuteterminer lapproche la plus efficace

Malheureusement nous navons pas pu utiliser cette strateacutegie pour deux raisons la taille du

programme utiliseacute dans lexpeacuterience et le manque dexpeacuterience des expeacuterimentateurs En

effet nous avons ducirc utiliser un petit programme dans lexpeacuterience afin de simplifier la

mission des sujets pendant Jactiviteacute de TE Cela pour eacutevitcr dobtenir des reacutesultats nuls qui

peuvent reacutesulter de lexeacutecution de TE si nous utilisons un trop grand logiciel

62

La deuxiegraveme raIson du choix de notre strateacutegie est le manque dexpeacuterience chez les

participants Ces sujets sont des eacutetudiants agrave lUQAgraveM Ils possegravedent une expeacuterience des tests

et de ses techniques limiteacutee agrave la couverture de ces matiegraveres dans le programme offert agrave

lUQAgraveM Nous avons cependant choisi les eacutetudiants du cours INF6160 Qualiteacute processus et

produits parce que cest dans ce cours que ces sujets sont abordeacutes le plus profondeacutement Cela

ne nous a quand mecircme pas permis dorganiser lactiviteacute de test de la mecircme faccedilon

professionnelle deacutecrite ci- dessus Lexpeacuterience consiste agrave utiliser les mecircmes sujets pour

exeacutecuter dabord le TE et le TS ensuite afin deacuteviter que les sujets apprennent les cas de tests

sceacutenariseacutes et les reacutepegravetent par la suite dans le TE Agrave cet effet nous avons programmeacute

Jexpeacuterience dans une seacuteance de cours de 2 heures 45 minutes pour exeacutecuter chacune de deux

approches de test Les eacutetudiants ont pris connaissance du deacuteroulement de lexpeacuterience dans

une seacuteance anteacuterieure ougrave le professeur a preacutesenteacute aux eacutetudiants une vue densemble du TE

Le sujet de lexpeacuterience et ses reacutesultats a constitueacute une partie de travail de session de cours

lNF6160 Alors chaque eacutetudiant participant dans lexpeacuterience a ducirc rappol1er ses reacutesultats et

les conclusions quil a pu tirer de Jexpeacuterience concernant les deux approches de test le TE

et le TS dans un rapport de fin de session Ceci a motiveacute les sujets agrave deacutelecter le maximum des

deacutefauts possibles el nous a garanti que les eacutetudiants ont pris Jexpeacuterience au seacuterieux

Nous avons proposeacute aux 56 sujets participants dans lexpeacuterience le programme agrave tester

accompagneacute de quelques modegraveles et techniques dexploration (Annexe C) pour les guider

pendant le TE et eacuteviter dobtenir des reacutesultats nuls Puis nous leur avons proposeacute les cas de

tests sceacutenariseacutes que nous avions preacutepareacute pour lactiviteacute de TS Alors tous les sujets ont

exeacutecuteacute les mecircmes cas de tests

Dans notre plan expeacuterimental les mecircmes sujets ont eacuteteacute utiliseacutes dans les deux traitements Ce

type deacutetude est qualifieacute de plan expeacuterimental agrave facteur unique agrave mesures reacutepeacuteteacutees sur les

mecircmes eacuteleacutements laquo Single Factor Experiments Having Reapted Measures on The Same

Elementsraquo (Winer 197 J p 105) Les reacutesultats ont eacuteteacute exploiteacutes de deux faccedilons di ffeacuterentes

la premiegravere lexploitation des reacutesultats de TE collecteacutes de notre expeacuterience et la deuxiegraveme

lexploitation des reacutesultats des deux activiteacutes de test et la comparaison des reacutesultats collecteacutes

Agrave cet effet nous utilisons dans celte analyse comparative lanalyse de variance ANOVA

63

proposeacute par Winer (1971 p lOS) Celte analyse nous a permet deacutevaluer leffet de

traitement cest agrave dire lapproche de test (T8 TE) sur la performance des sujets Celte faccedilon

de faire nous a permis deacutevaluer la productiviteacute de chacune des deux approches de test Cela a

aussi permis dexplorer la validiteacute de lhypothegravese proposeacutee par Kaner et Bach (2005) qui cite

que les testeurs juniors ne pourraient pas reproduire les cas de tests de la mecircme faccedilon que

lauteur ou le concepteur de ces cas de tests (le testeur senior) Aussi nous a permis

danalyser et de comparer les reacutesultats de TE de notre eacutetude empirique avec les reacutesultats des

travaux de recherches proposeacutes dans la litteacuterature par Itokens et Rautiainen (2005)

53 Le scheacutema de lexpeacuterience

531 Objectifs et hypothegraveses de lexpeacuterience

Comme le soulignent Lait et Rambach (1997) lidentification preacutecise des buts de leacutetude est

cssentielle agrave la mise en œuvre dune eacutetude expeacuterimentale Cette identification permet de

planifier et deacuteterminer les deacutetails de la perspective ou la strateacutegie suivie pour que lexpeacuterience

atteigne ses buts speacutecifieacutes De ce fait les aspects agrave eacutevaluer et les meacutetrigues agrave utiliser devront

ecirctre preacuteciseacutes et bien identifieacutes avant le deacutebut de lexpeacuterience Dans notre cas le but de

lexpeacuterience est de comparer la productiviteacute de TE et le T8 en termes de nombre et

dimportance des deacutefauts deacutetecteacutes Cela nous a permis deacutenoncer les hypothegraveses suivantes

Notre hypothegravese primaire est

Hl - le test exploratoire est plus efficace en terme de nombre de deacutefauts deacutetecteacutes que le test

sceacutenanseacute

Lhypothegravese nulle correspondante agrave celte hypothegravese est

Ho - il ny a pas de diffeacuterence entre le test exploratoire et le test sceacutenariseacute quant au nombre

de deacutefauts deacutetecteacutes

Notre hypothegravese secondaire est

H2 - le test exploratoire permet de deacutetecter des deacutefauts plus importants point de vue graviteacute

que le test sceacutenariseacute

64

532 La conception expeacuterimentale

Dans cette section nous preacutesentons la conception expeacuterimentale que nous avons faite pour

notre eacutetude empirique La conception et lanalyse de lexpeacuterience sont traiteacutees complegravetement

par (Winer 197 J) qui eacuteteacute utiliseacute comme reacutefeacuterence dans plusieurs eacutetudes expeacuterimentales

anteacuterieures (Wood et a1 ]997) Avant dintroduire les deacutetails de la conception choisie nous

deacutefinissons certains termes neacutecessaires agrave la compreacutehension de la conception de notre

expeacuterience

bull Variable indeacutependante est le facteur qui influence les reacutesultats de lexpeacuterience cest agrave

dire le facteur causal La manipulation des valeurs prises par cette variable permet

deacutetudier les effets de ces diffeacuterentes valeurs sur les reacutesultats Dans notre eacutetude la variable

indeacutependante est lapproche de test et ses valeurs possibles sont le TE et le TS

bull Variable deacutependante mesure les effets de la manipulation des variables indeacutependantes

Dans notre expeacuterience elle correspond au nombre et la seacuteveacuteriteacute des deacutefauts deacutetecteacutes

Dans notre expeacuterience nous al10ns eacutetudier leffet de lapproche de test (TE TS) surmiddot la

productiviteacute de lactiviteacute de test en utilisant un eacutechantillon composeacute de 56 sujets Chaque

eacuteleacutement de leacutechantillon applique les deux techniques de test sur le mecircme programme agrave

tester Donc nous avons un seul facteur qui peut influencer les reacutesultats de lexpeacuterience qui

est lapproche de test (TE TS) Selon (Winer J971) les contraintes de notre eacutetude empirique

correspondent agrave la conception proposeacutee par lauteur sous lexpression laquo expeacuterience agrave facteur

unique a mesures reacutepeacuteteacutees sur les mecircmes eacuteleacutementsraquo (Single Factor Experiments Having

Repeated Measures on the Same Elements)

533 Lcs instruments de leacutexpeacuterience

Les instruments de lexpeacuterience sont constitueacutes dun seul programme dans les deux activiteacutes

de test le TE el le TS JI sagit dun prognllnme de gestion des messages deacuteveloppeacute avec le

langage de programmation Jav3 Nous avons choisi le programme pour que sa taille et sa

complexiteacute facilitentmiddot lexeacutecution des deux techniques de test aux sujets (les eacutetudiants de cours

(NF 6160)

65

534 Le traitement expeacuterimental

En ce qui concerne le TS les sujets ont reccedilu en entreacutee le programme et les cas de tests que

nous leur avons conccedilus en utilisant un test fonctionnel (boicircte noire) Les sOlties sont les

deacutefauts deacutetecteacutes

Figure 51 Le traitement de test sceacutenariseacute

Les cas de tests

Les deacutefautsExeacutecution des cas deLe programme deacutetecteacutestests

Tel quillustreacute sur la figure 51 les sujets ont reccedilu les cas de test ct les ont exeacutecuteacutes dans une

session de 45 minutes Ils ont eacuteteacute informeacutes de ne pas produire de cas de tests additionnels

pendant lexeacutecution des cas de tests pour eacuteviter dintroduire le TE dans le TS Alors pendant

lexeacutecution des cas de test les sujets comparent les reacutesultats de sOl1ies observeacutes avec les

reacutesultats deacutecrits dans le script de cas de test Si les deux reacutesultats ne correspondent pas le

sujet doit enregistrer ct deacutecrire le comportement observeacute pendant lexeacutecution de ce cas de

test pour que nous puissions sassurer quil sagit vraiment dun deacutefaut et eacuteviter une

mauvaise interpreacutetation du comportement du programme

En ce qui concerne le TE nous Javons programmeacute dans une session de 45 minutes Les

sujets dans cette session de test exploratoire ont utiliseacute quelques modegraveles et techniques

dexploration que nous Jeur avons preacutepareacutes en avance (Annexe C) en se basant sur les

techniques proposeacutees par Amland (2002) afin de faciliter leur mission et les guider dans le

test

66

Figure 52 Le traitement de test exploratoire

Le programme

~ pprentissage concpetion et exeacutecu tion ----~ Les deacutefauts deacutetecteacutes

des tests ~ -----~----

Tel quillustreacute sur la figure 52 les sujets ont reccedilu le programme en entreacutee Leur mission eacutetait

dapprendre le programme concevoir et exeacutecuter les tests et rapportent Jes deacutefauts deacutetecteacutes

Le reacutesultat de lexeacutecution de TE est une liste des deacutefauts deacutetecteacutes (Annexe D) Pendant

Jexeacutecution de TE les sujets ont classifieacute les deacutefauts deacutetecteacutes selon leur graviteacute en suivant une

Jiste de classification de deacutefauts que nous leur avons fournie avant le deacutebut de lactiviteacute de

TE Cette liste classifie la graviteacute des deacutefaillances en trois niveaux

o fatale lapplication est inopeacuterable complegravetement (Crash)

o Moyenne lapplication fonctionne malS cel1aines fonctions sont inopeacuterables ou

certains reacutesultats sont erroneacutes

o Mineure limpact est rmneur sur Jutilisation du systegraveme comme certains formats

sont erroneacutes bien que les reacutesultats soient corrects ou encore le deacutelai de reacuteponse est

supeacuterieur de ce gui atlendu dune telle application

Apregraves lexpeacuterience nous avons re-classifieacute les deacutefauts rapporteacutes par les expeacuterimentateurs pour

eacuteviter des erreurs qui peuvent se reacutesulter sur une mltluvaise classification

67

54 Analyse des reacutesultats de lexpeacuterience

541 Analyse des resulats de test exploratoire

Avant de proceacuteder agrave une analyse comparative des reacutesultats de TE et TS nous analysons tout

dabord des reacutesultats de test exploratoire en termes de nombre et limportance des deacutefauts

deacutetecteacutes et nous les avons compareacutes avec les reacutesultats rapporteacutes dans la rccherche dltokens et

Rautiainen (2005)

5411 La productiviteacute de TE selon le nombre de deacutefauts deacutetecteacutes

Lanalyse et le traitement des donneacutees de TE recueillis pendant leacutetude empirique nous ont

permis de deacutevelopper une ideacutee estimative de la productiviteacute de TE en tcrme de nombre de

deacutefauts deacutetecteacutes (figure 53)

Figure 53 Les reacutesultats de test exploratoire

12

10

Nombre de

sujets

o 4 7 10 13 16

Nombre de deacutefauts

Les reacutesultats preacutesenteacutes agrave la figure 53 montrent que plus que la moitie (66lt) des sujets ont

reacuteussi agrave deacutetecter entre 6 agrave 9 deacutefauts La moyenne est de 95 deacutefauts par sujet Cette moyenne

est tregraves proche de celle proposeacutee par leacutetude de Itokens et Rautiainen (2005) Selon les

donneacutees quantitatives collecteacutees par ces auteurs dans la petite cntreprise dont son contexte de

deacuteveloppement est immature (plus proche de notre contextc de test) la moyenne reacutealiseacutee est

de 87 deacutefauts dans une session de 60 minutes

68

5412 La productiviteacute selon limportance de deacutefauts

Lanalyse et le traitement des donneacutees de TE recueillis pendant leacutetude empirique nous ont

permis davoir aussi une ideacutee sur limportance de deacutefauts qui pouvant ecirctre deacutetecteacutes

(figure64)

Figure 54 Importance de deacutefauts deacutetecteacutes avec le test exploratoire

10

lZ3 Fatale Grave D Mineure

Nous pouvons constater agrave partir des reacutesultats preacutesenteacutes sur la figure 54 que le pourcentage

des deacutefauts graves deacutetecteacute par les sujets avec le TE est plus que la moitieacute de tous les deacutefauts

deacutetecteacutes Tandis que seulement J0 des deacutefauts deacutetecteacutes sont fatales Les auteurs Jtokens et

Rautiainen (2005) ont rapporteacute un pourcentage de 15 des deacutefauts fatals deacutetecteacutes dans une

session de 60 minutes Cest un pourcentage tregraves proche du pourcentage reacutealiseacute dans notre

eacutetude empirique si nous prenons en consideacuteration la diffeacuterence dans les programmes utiliseacutes

dans leur eacutetude de cas et notre expeacuterience

La figure 54 montre que 70 des deacutefauts deacutetecteacutes pendant lexpeacuterience avec le TE sont des

deacutefauts importants cest agrave dire sont des deacutefauts fatals ou graves qui pounont empecirccher le

fonctionnement normal du programme sous test Par contre 50 des deacutefauts deacutetecteacutes avec le

TS sont des deacutefauts mineurs cest agrave dire des deacutefauts qui ne pourront pas empecirccher le

programme de fonctionner Ainsi la moitieacute des deacutefauts deacutetecteacutes avec le TS sont des deacutefauts

69

importants dont 45 des deacutefauts sont des deacutefauts graves et seulement 5 des deacutefauts sont

fatals De ce fait nous pouvons conclure que le TE permet de deacutetecter des deacutefauts plus

importants que le TS Eacutevidement les reacutesultats de TS deacutependent des connaissances et des

compeacutetences du concepteur des cas de test (lauteur de ce travail de recherche) Agrave cet effet

un autre concepteur peut aboutir agrave des reacutesultats diffeacuterents

Pendant lexpeacuterience nous avons constateacute que la boucle dapprentissage et les feedbacks

instantaneacutes durant Jactiviteacute de test constituent les raisons principales des reacutesultats

performants du TE En effet les sujets ont commenceacute lapprentissage ct la conception des cas

de test deacutes quils ont reccedilu le programme agrave tester Au fur et agrave mesure quils avancent dans leur

mission de TE ils conccediloivent des tests plus productifs et plus performants qui leur

permettent de deacutetecter des deacutefauts plus importants Cela gracircce aux feedbacks deacuteriveacutes des

tests exeacutecuteacutes ulteacuterieurement pendant lactiviteacute de TE et les connaissances accumuleacutees depuis

le deacutebut de la mission de TE

Nous croyons aussi que la diversiteacute des compeacutetences et les qualifications des sujets

participants dans lexpeacuterience a contribueacute aussi aux reacutesultats performants en TE En fait la

participation de plusieurs compeacutetences ou personnes dans le test donne des reacutesultats meilleurs

que lorsque la conception des cas de test est faite par une ou deux personnes seulement Nous

pouvons conclure de cette discussion que le TE permet de deacutetecter des deacutefauts plus

importants point de vue seacuteveacuteriteacute que le TS Autrement que notre hypothegravese secondaire H2

ne peut pas ecirctre rejeteacutee

Cependant nous avons constateacute que quelques sujets dans lexpeacuterience ont pu deacutetecter des

deacutefauts plus importants que ceux deacutetecteacutes avec le TS Nous croyons que limportance des

deacutefauts trouveacutes avec le TE deacutepend de la creacuteativiteacute et les qualifications de testeur Agrave cet effet

nous avons eacutetudieacute dans notre eacutetude empirique linfluence des connaissances en

programmation en Java comme un facteur repreacutesentant lexpertise ct les qualifications de

sujet sur les reacutesultats de TE effectueacute

En effet nous avons choisi ce facteur parce que nous croyons que le niveau de connaissance

70

en java repreacutesente bien la familiariteacute de leacutetudiant avec la programmation et les techniques de

deacutebogage donc implicitement son expertise et ses qualifications neacutecessaires pour exeacutecuter sa

mission pendant le TE (figure55)

Figure 55 Linfluence de lexpertise sur le test exploratoire

fi) -lt1)

14

u lt1) 12

-lt1) 0 10 fi) l

~ 8 lt1) 0

lt1) 6 0

lt1) c 4 c lt1) 2 0

~ 0

Jamais vu Introduction Intermeacutediaire Avanceacute

Connaissance en Java

Les reacutesultats preacutesenteacutes agrave la figure 55 montrent que la moyenne de deacutefauts deacutetecteacutes est plus

eacuteleveacutee pour un niveau de connaissance eacuteleveacute en Java La faible diminution pour le niveau

intermeacutediaire pourrait ecirctre expliqueacutee par la difficulteacute de situer le niveau de connaissance en

Java Notons que la Jiberteacute de TE a eacuteteacute signaleacutee par plusieurs sujets comme un avantage du

TE qui leur permet dapprofondir et dameacuteliorer leurs tests en temps reacuteel

542 Analyse des reacutesultats de TE et TS

Cette section aborde les reacutesultats rapporteacutes de lexpeacuterience de deux approches de test le TS

ct le TE Notre ideacutee est danalyser et de comparer la performance des sujets dans les deux

meacutethodes de test Autrement dit eacutevaluer la productiviteacute de TE par rapport au TS en

comparant le nombre de deacutefauts deacutetecteacutes par chaque sujet en utilisant le TE et le TS Le

traitement des reacutesultats recueillis de lexpeacuterience nous a donneacute le graphe 56

71

Figure 56 Reacutesultats des sujets aux TE et TS

Les sujets

-TE --TS

Nous pouvons constater de la figure 56 que le TE est plus productif que Je TS Cependant la

limitation de contexte de lexpeacuterience reacutesidant dans la taille du programme de jexpeacuterience et

le manque dexpel1ise des expeacuterimentateurs ne permet pas de tirer des conclusions fiables et

de geacuteneacuteraliser les reacutesultats obtenus

5421 Analyse de variance ANOVA

La figure 56 montre que les sujets ont eacuteteacute plus performants et productifs en TE quen TS

Dans eette section nous allons prouver statiquement ces reacutesultats en utilisant lanalyse de

variance ANOY A

Lanalyse de variance ANOYA laquo ANalysis Of VArianceraquo est une meacutethode statistique

permettant de comparer la moyenne de plusieurs populations Elle permet de savoir si une ou

plusieurs variables deacutependantes sont en relation avec une ou plusieurs variables dites

indeacutependantes (Winer ]97 J)

Dans un plan dexpeacuterience agrave mesures reacutepeacuteteacutees un mecircme sujet est mesureacute sous chacun des

niveaux dun traitement expeacuterimental Comme dans notre eacutetude ougrave chaque sujet est mesureacute

deux fois sous le TE puis le TS Dans ce type de plan leffet de lapproche de test

72

exploratoire sur le sujet k est compareacute avec la reacuteponse de mecircme sujet dans le TS Dans ce

plan chaque sujet devient son propre controcircle agrave travers les deux traitements expeacuterimentaux

(les deux approches de test dans notre cas)

Figure 57 Repreacutesentation scheacutematique de lanalyse ANOVA (Adapteacute et traduit de

Winer 1971)

Variation totale dl=kn-l

Varaition intershy Variation intrashyindividus individus

dl=n-I dl=n(k-I)

Variation intershyVariation reacutesiduelle

traitement dl=(n-I)(k-I)

dl~k-l

dl degreacute de liberteacute

La deacutecomposition de la variance selon (Winer 1971)

o Variation totale = Variation inter-individus + Variation intra-individus

o Somme carreacutes totale de la deacuteviation (SC Totale) = Somme carreacutes inter-individus +

Somme calTeacutes intra-individus

o Variation intra-individus = Variation inter-traitement + Variation reacutesiduelle cest agrave

dire

Somme carreacutes intra individus = Somme carreacutes inter-traitements + Somme

reacutesiduelle des carreacutes

Dans notre cas nous reacutesumons les calculs de lanalyse de variance ANOVA agrave mesures

73

reacutepeacuteteacutees sur les donneacutees collecteacutees de notre eacutetude empirique dans le tableau ci dessous

Tableau 51 ANOVA des donneacutees collecteacutees de lexpeacuterience

La source de variation Somme des carreacutees SC dl Carreacute moyen Test-F

Inter-individus 84145 55

Intra-individus 837 56

Inter-traitement 37296 1 37296 458

Reacutesiduelle 46404 55 814

La valeur critique pour un Test F avec (157) degreacutes de liberteacute cst 712 Or dapregraves le calcul

nous avons trouveacute que le test F = 458 Puisque cette valeur est supeacuterieur de 712 nous

rejetons lhypothegravese nulle HO et nous conservons lhypothegravese H 10rdapregraves la repreacutesentation

graphique des reacutesultats de Jexpeacuterience figure 66 nous pouvons constater que le TE est plus

productif en terme de nombre des deacutefauts deacutetecteacutes que le TS Par la suite nous concluons que

1hypothegravese Hl est valide ct que le TE est plus productif que le TS

55 Conclusion

Lanalyse statistique des reacutesultats de leacutetude empirique nous a permis de conclure que la

performance des sujets dans Jexeacutecution de TE est supeacuterieure que leur performance dans

lexeacutecution de TS Par la suite nous avons conclu que le TE est plus productif en terme de

nombre des deacutefauts deacutetecteacutes que le TS Ainsi nous avons conclu que le TE pourraient

deacutetecter des deacutefauts plus importants point de vue graviteacute que le test sceacutenariseacute

61

CHAPITRE VI

CADRE CONCEPTUEL DE COMPARAISON

Dans la revue de litteacuterature nous avons compileacute quelques eacutetudes de cas et expeacuteriences

dutilisations du TE dans lindustrie de test logiciel Nous avons preacutesenteacute un aperccedilu des

raisons que ont motiveacute les praticiens agrave utiliser le TE les faccedilons dont ils ont adopteacute et geacutereacute le

TE et les facteurs qui ont influenceacute ses reacutesultats dans la pratique Cela nous emmegravene dans ce

travail de recherche agrave eacutetudier plus profondeacutement et dune faccedilon geacuteneacuterale ces facteurs dans le

cadre dune eacutetude comparative des deux approches de test le TE et le TS Dans ce chapitre

nous preacutesenterons le contexte de notre eacutetude comparative Puis nous proposerons notre cadre

conceptuel de comparaison Ce cadre va guider notre analyse comparative de TE et TS NOlis

le deacutevelopperons en se basant sur la litteacuterature et les eacutetudes de cas des praticiens et

chercheurs dans lindustrie de test Agrave cet effet les recherches theacuteoriques ct empiriques

anteacuterieures preacutesenteacutees dans la revue de la litteacuterature seront consideacutereacutees

Mise en contexte de leacutetude comparative

Avant de preacutesenter le cadre comparatif de cette analyse nous proposons le contexte geacuteneacuteral

de notre analyse comparative et les choix que nous avons ducirc faire pour rendre possible une

comparaison et une discussion coheacuterente Tout dabord nous choisissons le type de test qui

va repreacutesenter chacune des deux approches dans cette eacutetude comparative En effet eacutetant

donneacute que les deux approches peuvent ecirctre repreacutesenteacutees sur un continuum (Figure 21) la

diffeacuterentiation entre le TE et le TS est difficile et imperceptible sans la speacutecification de type

choisi dc chacun dentre eux De ce fait nous avons choisi de repreacutesenter le TS par un

processus de test baliseacute dans les patrons de standard de documentation IEEE 829 que nous

avons proposeacute dans le chapitre Il Ce choix est motiveacute par notre besoin de normaliser

lanalyse et la comparaison Ainsi nous pourrons comparcr un processus f0l1ement planifieacute ct

75

disciplineacute de test avec un autre processus semi-planifieacute et libre (SBET) Quant au TE nous

avons choisi de le repreacutesenter par lapproche Session Based Exploratory Testing (SBET)

Cette forme de TE dapregraves la revue de la litteacuterature que nous avons preacutesenteacute dans le chapitre

IV est la plus adopteacutee dans lindustrie de test du logiciel comme une meacutethode primaire de test

(ltkonen et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003 Wood et James

2003) tandis que le TE libre est toujours consideacutereacute comme un test ad hoc (Lyndsay van

Eeden 2003) 11 faut noter que mecircme avec le choix de lapproche SBET nous restons dans la

limite de notre comparaison de TE et TS puisque le TE libre constitue Je cœur de lapproche

SBET La seule diffeacuterence entre les deux types est les notes produites agrave la fin de la session

dans le SBET Or ce sont ces notes qui ont favoriseacute son utilisation dans Jindustrie mecircme lagrave

ougrave les tests sont le plus documenteacutes et formels tel le domaine du logiciel meacutedical (James et

Wood 2003)

Lanalyse comparative des deux approches le TE et le TS va nous permettre de ressortir les

contextes favorables pour utiliser le TE agrave la place de la meacutethode sceacutenariseacutec habituelle de test

(TS) En fait on peut dire quun contexte est lensemble des facteurs speacutecifiques de projet de

test du logiciel Par exemple dire que le logiciel agrave tester est petit repreacutesente un facteur de

contexte deacutetermineacute selon le facteur laquo Caracteacuteristiques du logiciel agrave tester raquo

Notre comparaIson est restreinte au type de test boicircte nOIre du fait que Je TE est une

technique de test boicircte noire (Craig et Jaskiel 2002 Kaner et al 2002) Dans ce type de test

on ne sinteacuteresse pas agrave laspect impleacutementation du code mais uniquement au comportement

du logiciel

Nous voulons signaler aussi que dans notre analyse comparative nous ne consideacuterons que

les modegraveles traditionnels de deacuteveloppement On a vu les modegraveles agiles de deacuteveloppement

constituent un cas reacuteel ougrave Je TE et le TS automatiseacute sont utiliseacutes ensemble pour tester le

logiciel (section 24) Or dans notre eacutetude nous voulons identifier les contextes ougrave le TE

pourrait ecirctre utiliseacute comme une meacutethode primaire de test agrave la place de TS Agrave cet effet les

modegraveles agi les ne seront pas consideacutereacutes dans cette eacutetude

76

Dans ce chapitre et les chapitres suivants nous utilisons labreacuteviation laquo TE raquo pour deacutesigner

lapproche SBET afin dalleacuteger le texte

62 Cadre conceptuel de comparaison

La comparaison entre le TS et le TE est peu abordeacutee dans la litteacuterature Les travaux qui ont

traiteacute le sujet eacutetaient plus axeacutes sur la proposition et la promotion des avantages de TE par

rapport au TS (Kaner 2006 Bach 2003) Pour cela nous nous sommes fixeacute comme objectif

dans ce travail de recherche de comparer dune faccedilon neutre les deux approches en mettant

laccent sur les apports et les contextes ougrave le TE pourrait remplacer le TS Nous tentons par le

biais de cette eacutetude comparative dexplorer ces contextes en se basant sur nos deacuteductions

personnelles tireacutes de la base theacuteorique de test du logiciel et la revue de litteacuterature des travaux

de praticiens dans Jindustrie de test (Chapitre IV) et sur leacutetude empirique preacutesenteacutee au

chapitre preacuteceacutedent

Tout dabord afin que notre analyse eomparative soit meneacutee agrave bien nous preacutesenterons notre

cadre conceptuel de comparaison Ce cadre doit permettre de guider et focaliser notre analyse

comparative entre le TE et le TS Il regroupe les critegraveres autour desquels la discussion et

lanalyse seront centreacutees Lidentification des facteurs de comparaison a eacuteteacute deacuteveloppeacutee dune

part en se basant sur les reacutesultats des expeacuteriences dutilisation du TE par les chercheurs et les

praticiens preacutesenteacutes dans la litteacuterature Nous nous sommes aussi inspireacutes des facteurs

proposeacutes par Boehm et Turner (2004)

Le cadre proposeacute par Boehm et Turner (2004) a pour objectif la comparaison des approches

agiles et les approches disciplineacutees de deacuteveloppement du logiciel Or notre comparaison

pourrai1 ecirctre vue aussi comme la comparaison entre deux meacutethodes de test disciplineacute et agile

ougrave le TS repreacutesente la meacutethode disciplineacutee et le TE la meacutethode laquoagileraquo On entend par agile

le fait que le TE se caracteacuterise par les deux caracteacuteristiques essentielles de lagiliteacute identifieacutee

dans (Boehm Turner 2004) La premiegravere eacutetant sa capaciteacute de reacutepondre ou de sadapter

rapidement aux changements du logiciel agrave tester (ltkonen ct Rautiainen 2005 Petty 2005

Lyndsay et van Eedcn 2003 Amland et Vaga 2002) La deuxiegraveme est la leacutegegravereteacute de la

documentation utiliseacutee ct produite pendal1t le TE

77

Le cadre proposeacute par Boehm et Turner (2004) est axeacute sur quatre dimensions agrave savoIr

Caracteacuteristiques dutilisations caracteacuteristiques de gestion caracteacuteristiques techniques et

caracteacuteristiques du personnel Or une meacutethode de test du logiciel doit ecirctre adapteacutee agrave un

contexte particulier (Craig et Jaskiel 2002 Perry 2000) Ce contexte se reacutesulte de

linteraction de plusieurs facteurs relieacutes aux objectifs principaux de lactiviteacute de test les

ressources financiegraveres techniques humaines et organisationnelles existantes Agrave cet effet le

cadre de comparaison de deux meacutethodes de test se composait de mecircmes dimensions citeacutees

par Boehm et Turner (2004) Notre cadre de comparaison va regrouper les axes de

comparaisons suivantes caracteacuteristiques d uti lisations caracteacuteristiques de gestion

caracteacuteristiques techniques et caracteacuteristiques de personnels Cependant il nous revient de

deacuteterminer les facteurs de comparaison associeacutes agrave chaque dimension De plus nous ajoutons

une cinquiegraveme dimension traitant la productiviteacute dc lactiviteacute de test puisque la veacuterification

dc la productiviteacute de TE est lun des objectifs principaux de ce travail de recherche Alors

notre cadre conceptuel de comparaison se constitue des dimensions et facteurs suivants

preacutesenteacutes dans les sections ci-dessous

621 Les caracteacuteristiques dutilisation

Selon Turner et Boehm (2004) les caracteacuteristiques dutilisations repreacutesentent les aspects et les

types de projets approprieacutes pour chaque approche du deacuteveloppement Ils ont identifieacute sous

cette dimension les facteurs suivants les objectifs principaux dutilisation de chaque

approche du deacuteveloppement la taille de projet du deacuteveloppement en termes de nombre de

personnes participants dans le projet la complexiteacute le volume du logiciel et le type

denvironnement daffaire ougrave se deacuteveloppe le projet Dans notre cas les caracteacuteristiques

dutilisation regroupent les facteurs suivants

bull Les raisons dutilisation ou les motivations pour utiliser chacune de deux approches de

tesl le TE ct le TS

bull Les caracteacuteristiques du logiciel agrave tester en termes de la taille de la complexiteacute et de la

crit ical iteacute

bull Le type denvironnement daffaire ougrave se produit le projet de test

78

bull Les ressources financiegraveres

bull Le temps disponible pour remplir lactiviteacute de test

622 Les caracteacuteristiques de gestion

Selon les auteurs Boehm el Turner (2004) les caracteacuteristiques de gestion deacutecrivent les faccedilons

de geacuterer Je projet du deacuteveJoppement dans Ies deux meacutethodes du deacuteveloppement agiles et

disciplineacutees Ils ont identifieacute sous cette dimension les facteurs suivants La planification et le

controcircle de projet de deacuteveloppement la relation avec Je client et la communication dans le

projet du deacuteveloppement Dans notre cas de recherche cette dimension de comparaison

regroupe les mecircmes facleurs discuteacutes par Boehm et Turner mais dans Je cadre de projel de

test Il sagit de la planification de tesl le controcircle et le suivi de la progression de test la

communication dans le projet de test el Ja relation avec le client

623 Les caracteacuteristiques techniques

Selon Boehm et Turner (2004) les caracteacuteristiqucs techniques deacutecrivent comment chacune de

deux meacutethodes du deacuteveloppement agile et disciplineacute abordent les eacutetapes essentielles du cycle

de deacuteveloppement du logiciel la speacutecification des exigences Je deacuteveloppement el le test

Dans notre cas cette dimension deacutecrit comment les deux approches de test le TE et le TS

abordent les eacutetapes essentielles de lactiviteacute de test Selon (Pyhajarvi el al 2003 Swebok

2004 Craig et Jaskiel 2002 Perry 2000) ces activiteacutes sont la planification de tests la

conception de tests lexeacutecution de tests Toutefois les activiteacutes de test deacutecoulent selon

(Bolton et aL 2005) de trois facteurs loracle de test les risques du logiciel agrave lester et la

couverture du test Ces eacuteleacutements seront donc discuteacutes sous cette rubrique

624 Les caracteacuteristiqucs du pClSonnel

Les auteurs Boehm et Turner (2004) abordent sous cette dimension les caracteacuteristiques du

personnel impliqueacute dans les projets de deacuteveloppement qui pouvaient favoriser JutiJisation de

chacune de deux approches de deacuteveloppement agile et disciplineacute Ils ont identifieacute les facteurs

suivants les caracteacuteristiques du client les caracteacuteristiques des deacuteveloppeurs et la culture de

lorganisation ougrave se deacuteroule le projet de deacuteveloppement Dans notre analyse comparative de

79

TE el le TS cette dimension ugravee comparaIson regroupe les facleurs suivants les

caracteacuteristiques des testeurs et la culture de lorganisation ougrave se deacuteroule le projet de test

625 La productiviteacute

Nous avons ajouteacute cette dimension agrave notre cadre vu limportance de cet aspect dans notre

travail de recherche Ce critegravere constitue le centre de cc travail de rechercbe agrave cause de la

productiviteacute du TE annonceacutee dans la litteacuterature surtout par les praticiens du CDS (Bach

2003 Kaner 2006) Les facteurs dc cette dimension sont le nombre de deacutefauts deacutetecteacutes et

limporlance de deacutefauts deacutetecteacutes par chacunc des dcux approches de test le TE et le TS Ces

facteurs de comparaison vont ecirctre traiteacutes dc dcux faccedilons theacuteoriquc cn se basant sur la

1itteacuterature et empirique ou expeacuterimenta le en se basant sur les reacute su hats dc notre eacutetude

cmplfJque

En reacutesumeacute notre cadre comparatif sc compose dcs dimensions et des facteurs de

comparaison illustreacutes sur la figurc 6)

80

Figure 61 Le cadre conceptuel de comparaison

1 Les raisons dutilisation 1 1

1 Les caracteacuteristiques du ~ 1 logiciel 1Les caracteacuteristiques

dutilisation 1 Le type denvironement daffaire1 1

1 Les ressources finacieacuteres 1 1

=-1 Le temps de test disponible 1

1 La planification ~ 1 1

1 Le controcircle et le suivi de progression de test1 1Les caracteacuteristiques

de gestion 1 La communication dans le 1 ~ 1 projet de test

1 La relation avec le client 1 1

1 Les activiteacutes de test 1 1

Les caracteacuteristiques

1 1

Les risques du logiciel 1

techniques 1 La couverture de test 1 1

1 ~ 1 Loracle de test

1

1 Les caracteacuteristiques du testeur1 1Les caracteacuteristiques

du personnel -J La c1uture de lorganisation 1

1 Le nombre de deacutefauts ~ 1 deacutetecteacutes 1

La productiviteacute 1 Limportance de deacutefauts

~ 1 deacutetecteacutes 1

81

63 Conclusion

Au cours de ce chapitre nous avons preacutesenteacute un cadre conceptuel de comparaison Nous

avons identifieacute et deacutefini dans ce cadre cinq dimensions principales de comparaison les

caracteacuteristiques dutilisation les caracteacuteristiques de gestion les caracteacuteristiques techniques

les caracteacuteristiques du personnel la productiviteacute Chacune de ces dimensions se deacutecompose

en plusieurs facteurs Ces facteurs vont nous servir dans notre analyse comparative du TE ct

du TS qui sera abordeacutee dans le chapitre qui suit

CHAPITRE VII

ANALYSE COMPARATIVE DU TEST EXPLORATOIRE ET DU TEST SCEacuteNARISEacute

Dans ce chapitre nous allons poursuIvre notre discussion plus en deacutetails sur les factcurs

influenccedilant ladoption et ladaptation de test exploratoire (TE) dans le cadre dune analyse

comparative des deux approches de test le test exploratoire (TE) et le test sceacutenariseacute (TS)

Nous COmparons les deux approches en se basant sur les facteurs deacutevaluation de notre cadre

conceptuel de comparaison que nous avons deacuteveloppeacute dans Je chapitre preacuteceacutedent Lobjectif

de ce preacutesent chapitre est didentifier les contextes de test ougrave le TE pourrait ecirctre utiliseacute en

remplaccedilant la meacutethode habituelle sceacutenariseacutee de test En terminant nous proposons un guide

de seacutelection de lapproche de test Ce guide reacutecapitule les reacutesultats de notre analyse

comparative et tente de baliser une deacutemarche danalyse pouvant ecirctre inteacutegreacutee agrave la reacuteflexion

strateacutegique des entreprises lors de choix de lapproche de test

71 Comparaison selon les caracteacuteristiques dutilisation

Dans cette section nous allons discuter les caracteacuteristiques dutilisation speacutecifiques pour

chacune des deux approches de test le TE et le TS Tout dabord nous aborderons les raisons

dutilisation de chacune des deux approches de test Puis nous discutons linfluence des

caracteacuteristiques du logiciel agrave tester sur le choix de lapproche de test Ces caracteacuteristiques

regroupent la taille du logiciel sa complexiteacute et sa criticiteacute Ensuite nous discuterons

linfluence de type denvironnement daffaire sur le choix de lapproche de test Finalement

nous aborderons linfluence des facteurs le temps de test disponible et les ressources

financiegraveres sur le choix de Japproche de test

711 Les raisons dutilisation

La raison principale de lutilisation du TE comme une approche primaire de test eacutetait pour

83

saccommoder agrave Jinstabiliteacute du logiciel deacuteveloppeacute etou labsence des exigences du logiciel

(Itkonen et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003 Amland et Vaga

2002) Ces eacutetudes ont montreacute que le TE sadapte agrave de telles situations Cette adaptation

se~plique par la possibiliteacute dutiliser le TE sans avoir besoin dutiliser les exigences du

logiciel En effet le TE nexige pas lexistence dexigences formelles du fait que les chal1es

de tests (le contenu de la mission de chaque session de test) pourraient ecirctre identifieacutees en

utilisant nimporte quelle source dinformation existante mises agrave part les exigences du

logiciel Les auteurs Kaner et Bach (2004) ont deacutecrit plusieurs reacutefeacuterences peuvent servir

pendant lidentification des chartes Souvent le manuel dutilisateur est utiliseacute pour identifier

ces chartes Ces chartes identifient seulement les grandes lignes de la mission de test agrave

accomplir Par conseacutequent lintroduction des changements sur le logiciel sous test ne

pourrait introduire que des mises agrave jour minimes au pire des cas comme lajout de nouvelles

chal1es correspondant aux nouvelles fonctionnaliteacutes ajouteacutees au logiciel

Parmi les principes de leacutecole CDS on retrouve que les projets se deacuteroulent souvent dune

maniegravere impreacutevisible Ceci implique que lapproche de test devrait sadapter agrave cette

impreacutevisibiliteacute A cet effet nous pouvons constater que lobjectif principal du TE est de

sadapter agrave Jimpreacutevisibiliteacute de projet de test du fait quil est baseacute sur les principes de CDS

La recherche meneacutee par les auteurs Itkonen et Rautiainen (2005) a deacutevoileacute dautres raisons

d uti lisation du TE agrave savoir premiegraverement la possibiliteacute de tester le systegraveme du point de vue

de lutilisateur autrement dit tester la combinaison de plusieurs sceacutenarios dutilisation du

logiciel Deuxiegravemement la difficulteacute de concevoir des cas de tests sceacutenariseacutes deacutetailleacutes agrave cause

de linterdeacutependance entre plusieurs uniteacutes logicielles Troisiegravemement la possibiliteacute

dexploiter la creacuteativiteacute et lexpertise des testeurs dans la deacutetection des deacutefauts imponants

Finalement la limitation du temps de test et les ressources financiegraveres disponibles

Par contre les raisons dutilisation de TS ne pourraient pas ecirctre deacutenombreacutees dans une liste

deacutetermineacutee de raisons dutilisation Du fait que le TS constitue toujours la meacutethode

habituelle et naturelle de test dans plusieurs entreprises Cependant nous avons constateacute

dapregraves notre revue de litteacuterature que Je TS ne saccommode pas facilement aux changements

84

du logiciel En effet nimporte quel changement dans le logiciel neacutecessite la mise agrave jour de

tous les artefacts de test deacutejagrave conccedilus toucheacutes par ce changement Leffort neacutecessaire pour

mettre agrave jour ces artefacts augmente proportionnellement avec laugmentation de niveau de

deacutetail de ces artefacts Lutilisation de standard de documentation IEEE 829 dans le TS

neacutecessite aussi un eff0l1 significatif pour mettre agrave jour les artefacts de test deacutejagrave conccedilus (Craig

et Jaskiel 2002 Petty 2005) Notant que le volume de modifications neacutecessaire accroicirct

propol1ionnellement avec le volume de changements introduit sur le logiciel Or avec la

culture rapide du deacuteveloppement du logiciel actuelle les praticiens tendent souvent agrave

commencer le deacuteveloppement du logiciel le plus tocirct possible avant que les exigences soient

stables et mucircries afin de reacuteduire le temps de mise en marcheacute Par la suite la probabiliteacute

dintroduire des changements ulteacuterieurs sur le logiciel est fort possible parfois assez

nombreux

Agrave cet effet nous pouvons constatcr que la stabiliteacute de projet du deacuteveloppement pourrait ecirctre

lune des raisons essentielles pour utiliser le TS Notant que mecircme le TE pourrait ecirctre utiliseacute

dans ce type de projet Dans une telle situation dautres facteurs pourront influencer le choix

de lapproche convenable dc tcst agrave saVOir ladoption de lorganisation du modegravele

dameacutelioration de processus logicicl comme le CMMI (Capability Maturity Model

Integration) Dans ce genre dc processus la documentation ct la mesure constituent des

eacuteleacutements fondamentaux Par conseacutequent Je TS constitue le choix ideacuteal dans ce type de projet

de deacuteveloppement Le domaine daffaire de quelques types de projet du deacuteveloppement exige

lutilisation de TS Autrement la neacutecessiteacute dune documentation deacutetailleacutee de Jactiviteacute de test

exige lutilisation de TS comme les projets de test dapplications critiques par exemple Par

la suite le besoin de documentation de processus de test pourrait ecirctrc lune des raisons pour

utiliser le TS

Nous concluons de cettc discussion que Je TE est plus approprieacute dans les projets dc

deacuteveloppement instables gracircce agrave sa grande capaciteacute dadaptation agrave limpreacutevisibiliteacute de projet

dc test Tandis que Je TS est plus approprieacute dans les projets dc deacuteveloppement stables et qui

ont besoin de documenter et mesurer lactiviteacute de test

85

712 Les caracteacuteristiques du logiciel

7121 La taille du logiciel

Il apparaicirct que le TE est plus approprieacute dans les petits et moyens projets de test Cest agrave dire

le test des petites et moyennes applications Cela sexplique par leffort neacutecessaire pour la

gestion et le controcircle de TE En effet la gestion de TE neacutecessite que le responsable de test

deacutebriefe chaque testeur apregraves lexeacutecution de chaque session de test afin d eacuteva luer et

dapprouver les reacutesultats de la session Or ceci ne semblait pas ecirctre facile dans une grande

eacutequipe Nous avons constateacute ceci agrave travers les travaux de la litteacuterature que nous avons

preacutesenteacute dans le chapitre IV Alors tous les logiciels qui ont eacuteteacute lobjet des eacutetudes de cas

eacutetaient des petites applications deacuteveloppeacutees par des petites ou moyennes entreprises (ltkonen

et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003 Amland et Vaga 2002)

Selon Lyndsay et van Eeden (2003) la collaboration et le partage ues connaissances entre les

membres de leacutequipe de test peuvent ameacuteliorer la qualiteacute de TE effectueacute Cependant nous

croyons que la collaboration est plus facile entre les membres dune petite eacutequipe de test

quentre les membres dune grande eacutequipe

Par contre le TS est plus approprieacute dans les grands projets de test associeacutes agrave des grands

projets du deacuteveloppement En effet dans ces projets le projet de test constitue souvent un

sous projet organiseacute et geacutereacute seacutepareacutement du projet de deacuteveloppement du logieiel (Pyhajarvi et

al 2003) Agrave cet effet la planification et la documentation sont les moyens de gestion et de

communication agrave linteacuterieur et agrave lexteacuterieur de projet de test Sajoute agrave ceci le fait que les

grands projets puissent seacutetaler sur plusieurs mois Par la suite la meacutemorisation et

lenregistrement des cas de test sont neacutecessaires afin de maintenir et tester lapplication dans

les phases ulteacuterieures du deacuteveloppement dune faccedilon rentable (Beizer 1990)

Nous concluons que le TE est plus approprieacute dans les petits et moyens projets de test cest-agraveshy

dire le test des petits et moyens logiciels Tandis que le TS est plus approprieacute dans les grands

projets de test cest-agrave-dire pour les grands logiciels

86

7122 La complexiteacute du logiciel

La complexiteacute du logiciel fait reacutefeacuterence agrave la difficulteacute de compreacutehension et dappreacutehension du

logiciel Autrement dit la compreacutehension du logiciel nest pas agrave la porteacutee de tous les testeurs

dans le projet Par exemple un logiciel qui impleacutemente une nouvelle technologie Alors le

TE ne semblait pas le meilleur choix dans cette situation puisque lapprentissage et

lappreacutehension du logiciel neacutecessaires pour remplir lactiviteacute de TE ne pourront pas ecirctre agrave la

porteacutee de tous les testeurs dans le projet de test Le TS pourrait ecirctre la meilleure strateacutegie

dans ce cas de test du fait que les cas de tests pourraient ecirctre conccedilus par des experts dans la

technologie impleacutementeacutee et exeacutecuteacutes par des testeurs novices

Il faut noter que parfois les logiciels complexes se deacuteveloppent en collaboration entre

plusieurs compagnies (Kaner et al 1999) Dans une telle situation le TS repreacutesente le bon

choix surtout sil est documenteacute par le standard de la documentation IEEE 829 La

documentation de lactiviteacute de test permet de veacuterifier et dinspecter formellement la qualiteacute

de test effectueacute au niveau de chaque entreprise participante dans le deacuteveloppement du

logicieL Le standard IEEE 829 peut introduire un protocole commun de communication entre

les entreprises paJ1icipantes dans le projet du deacuteveloppement (IEEE829 1998)

Nous concluons que le TS est plus approprieacute dans les projets de test de logiciel complexe

Tandis que lutilisation de TE dans tels projets deacutepend des compeacutetences ct de leXpeJ1ise des

testeurs impliqueacutes dans le projet

7123 La criticaliteacute du logiciel

En ce qui concerne le test des logiciels critiques seulement le TS pourrait ecirctre utiliseacute En

effet pour les logiciels critiques comme les logiciels temps reacuteel ou embarqueacutes seulement les

meacutethodes seeacutenariseacutees peuvent ecirctre utiliseacutees Lun des eacuteleacutements essentiels de ces meacutethodes de

tests est la documentation deacutetailleacutee de lactiviteacute de test Cette documentation fera lobjet de

plusieurs eacutevaluations et inspections afin de sassurer de la qualiteacute de lactiviteacute de test

effectueacutee Dans certaines situations la documentation ct lactiviteacute de test devront suivre des

normes et des standards speacutecifiques dans quelques domaines daffaires Nous avons constateacute

87

ce fait agrave travers leacutetude ugravee cas ugravee James et Wood (2003) preacutesenteacute dans le chapitre IV Les

deux auteurs ont utiliseacute le TE comme une meacutethode compleacutementaire agrave Japproche sceacutenariseacutee

habituelle Cette derniegravere devait suivre les normes de qualiteacute du systegraveme (Quality System

Regulation) dans le domaine de construction dappareils meacutedicaux

Il faut rappeler que mecircme Bach et al (2002) ont signaleacute que les pnnclpes et les leccedilons

preacutesenteacutes dans (Bach et al 2002) de leacutecole de penseacutee Context Driven School (CDS)

concernent les logiciels commerciaux seulement Agrave cet effet nous croyons que le TE

sapplique lui aussi agrave ce type de logiciels du fait quil est baseacute sur les mecircmes principes de

leacutecole

Nous concluons de cette discussion que seule le TS pourrait ecirctre utiliseacute dans le test des

logiciels cri tiques

713 Le type denvironnement daffaire

Le type denvironnement daffaire pourrait influencer le choix de lapproche de test entre le

TE et le TS Dapregraves notre revue de litteacuterature nous avons constateacute que le TE sadapte

faci lement aux changements du logiciel agrave tester Par la suite nous pouvons constateacute que le

TE est plus approprieacute dans les environnements dynamiques Le dynamisme fait reacutefeacuterence au

dynamisme de la technologie utiliseacutee dans le deacuteveloppement du logiciel ouet de la volatiliteacute

des besoins du client Agrave linverse le TS ne sadapte pas facilement aux environnements

dynamiques De fait que la maintenance des artefacts de test neacutecessite du temps et des

ressources financiegraveres consideacuterables qui ne sont pas souvent disponibles dans la pratique du

test surtout dans les petites ct moyennes entreprises Dailleurs nous avons constateacute cela agrave

travers notre revue de litteacuterature La deacutecouverte et lutilisation de TE ont eacuteteacute motiveacutees dans la

plupart des eacutetudes de cas que nous avons preacutesenteacutees par lincapaciteacute de TS agrave reacutepondre aux

besoins des praticiens dans la limite du temps ct des ressources disponibles (Petty 2005

Amland et Vaga 2002)

Le TS sadapte tregraves bien aux environnements stables Dans ces environnements les artefacts

de test peuvent ecirctre speacutecifieacutes tocirct dans le processus du deacuteveloppement dans la limite des

88

ressources disponibles et aucun coucirct suppleacutementaire de changement nest neacutecessaire Le TS

est plus approprieacute aussi dans dautres types denvironnements daffaires comme les logiciels

eacutevolutifs et les logiciels deacuteveloppeacutes sous contrat Dans ce type denvironnements le plan de

test et les cas de tests uevraient ecirctre Jivreacutes avec le logiciel Parfois le client deacutetermine et

neacutegocie la structure le format et le niveau de deacutetail de ces artefacts dans le contrat Il pourrait

exiger lutiliseacuteltion de la norme de documentation IEEE 829 dans quelques situations (Kaner

et al 1999)

Les logiciels deacuteveloppeacutes dans quelques domaines dindustrie exigent Jutilisation de TS agrave

cause de la neacutecessiteacute dune documentation deacutetailleacutee de processus de test Souvent cest le cas

dans le test des logiciels qui peuvent causer des pertes importantes en cas de deacutefaillance du

logiciel dans le site de production Alors la documentation de test pourrait constituer un outil

de deacutefense dans les causes judiciaires (Kaner et al 1999)

Nous pouvons conclure de cette analyse que le TE est plus approprieacute dans les

environnements dynamiques Par contre le TS est plus approprieacute dans les environnements

stables eacutevolutifs ou sous contrat et ceux qui neacutecessitent la documentation deacutetailleacutee du

processus de test

714 Les ressources financiegraveres

Nous avons constateacute dapregraves notre revue de lilteacuterature que les ressources financiegraveres

disponibles dans Je projet de test jouent un rocircle important et crucial dans le choix de

lapproche de test (ltkonen et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003

Amland Vaga 2002)

Le TS neacutecessite des ressources financiegraveres importantes La preacuteparation la conception des cas

de tests et la documentation du processus de test occasionnent des frais significatifs En effeL

leffort neacuteccssaire en nombre de personnesjours pendant le processus de test est plus grand

en TS quen TE Ce fait empecircche lutilisation de TS quand le budget de test est serreacute

(Lyndsay van Eeden 2003) Contrairement le TE ne neacutecessite pas une documentation

rigoureuse pendant le processus de test agrave pm1 un investissement minime dans le processus

didentification des cbaI1es de tests La moindre coucirct dc TE a eacuteteacute signaleacute par les praticiens qui

89

ont utiliseacute lapproche dans lindustrie de test (Petty 2005 Lyndsay Van Eeden 2003 James

Wood 3003)

Cependant la diffeacuterence dans les coucircts entre le TE et le TS apparaicirct clairement lors de

lintroduction des changements sur le produit sous test Alors la maintenance des artefacts de

tests sceacutenariseacutes a un coucirct suppleacutementaire qui augmente en fonction du volume de

changements introduits Par contre le changement du logiciel dans une activiteacute de TE ne

pourrait geacuteneacuterer que quelques changements sur les chartes existantes tel que lajout des

nouvelles chartes Par la suite le TE ne geacutenegravere pas des coucircts suppleacutementaires importants

comme le TS En fait le coucirct moindre de TE eacutetait le principal motif de la deacutecouverte et de

lutilisation de cette approche par les professionnels et les praticiens dans lindustrie de test

(Petty 2005 Amland Vaga 2002)

Nous concluons de cette discussion que le TE est plus approprieacute dans les projets de test agrave

ressources financiegraveres limiteacutees Tandis que le TS est plus approprieacute dans les projets de test

qui ont des ressources financiegraveres importantes pour suppol1er ses frais

715 Le temps de test disponible

Le temps disponible pour accomplir lactiviteacute de test est lun des facteurs essentiels pouvant

influencer le choix de lapproche de test (ltkonen et Rautiainen 2005 Petty 2005 Lyndsay

et van Eeden 2003 Amland Vaga 2002) Le TS neacutecessite du temps consideacuterable pour la

planification et la conception des cas de tests avant Je deacutebut de Jexeacutecution physique des tests

Toutefois avec la tendance preacuteventive actuelle de test du logiciel la planification et la

conception de cas de tests sceacutenariseacutes peuvent commencer degraves le deacutebut de projet du

deacuteveloppement parallegravelement avec limpleacutementation du logiciel Agrave cet effet il y a toujours

suffisamment de temps pour planifier et preacuteparer les cas de tests sceacutenariseacutes Le problegraveme de

temps se pose lors de Jintroduction de changements sur le logiciel ulteacuterieurement dans le

cycle du deacuteveloppement cest-agrave-dire le changement de la conception du logiciel apregraves

leacutelaboration des cas de tests associeacutes agrave celle-ci Dans ce cas le temps neacutecessaire pour mettre

agrave jour les artefacts de test deacutejagrave conccedilus ct le temps disponible pour tester le logiciel pourrait

avoir une incidence sur le deacuteroulement normal de Jactiviteacute de lest qui peul changer

90

subtilement vers un test ad hoc ou dans la meilleure des cas au TE En effet la preacuteparation

des cas de tests tocirct dans le processus nest pas toujours fructueuse parce que les exigences ne

sont pas toujours stables au deacutebut du projet de deacuteveloppement Par la suite la planification et

la preacuteparation des cas de tests en se basant sur ces speacutecifications changent souvent et geacutenegraverent

des modifications et des mises agrave jour eacutenormes Aussi lemplacement des testeurs agrave la fin de

la chaicircne du deacuteveloppement cest-agrave-dire sur Je chemin critique de livraison du logiciel

sajoute au problegraveme que nous venons de citer Alors les testeurs accumulent les retards faits

au deacutebut de la chaicircne du deacuteveloppement et se retrouvaient souvent dans des situations

difficiles ougrave ils doivent faire de compromis entre le temps disponible pour le test la qualiteacute

attendue du logiciel et le budget Dans de telles situations souvent les praticiens renoncent

aux cas de tests sceacutenariseacutes et sen remettent au TE (Petty 2005 Bach et al 2002) Le TE leur

permet dinvestir le temps disponiblc dans le test du logiciel au lieu de mettre agrave jour les cas

de tests sceacutenariseacutes Selon Bach et al (2002) la preacuteparation des cas de tests pendant la phase

de conception du logiciel est une perte du temps du fait que ces cas de tests pourraient ecirctre

deacutesuets ulteacuterieuremcnt dans le cyclc du deacuteveloppement

Par contre le TE nc neacutecessite pas beaucoup du temps pour la preacuteparation de cha11es de test ]]

suffi t que le responsable de test preacutepare les chartes de tests en se basant sur nimporte quelle

source dinformation disponible (Kaner et Bach 2004) Nous pouvons dire quc cest

eacutequivalent agrave la preacuteparation dun plan de test selon le patron IEEE 829 puisque lobjectif dans

les deux cas est didentifier ce qui doit ecirctre testeacute les responsabiliteacutes lestimation de leffort

neacutecessaire pour remplir chaque mission dans le processus de tcst Notons quavant

lintroduction de la technique Session Based Exploratory Testing (SBET) Amland et Vaga

(2002) ont utiliseacute un plan de test sceacutenariseacute pour identifier les chartes des sessions de tests

exploratoires

Nous concluons de cette discussion que le TE est plus approprieacute dans les projets de test ougrave il

ya peu de temps pour le tcst surtout si les ressources financiegraveres ne permettent pas dajouter

de personnel ou de fairc dautres contingences Tandis que le TS est plus approprieacute dans les

projets de test ougrave il ya suffisamment de temps pour la preacuteparation ct la planification de test

91

72 Comparaison selon les caracteacuteristiques de gestion

Dans cette section nous abordons les eacuteleacutements principaux de gestion de lactiviteacute de test dans

les deux approches de test le TS et le TE Il sagit de la planification de test le controcircle et le

suivi de la progression de test la communication dans le projet de test et la relation avec le

client

721 La planification

Selon Joffice queacutebeacutecois de la langue franccedilaise la planification est un ensemble de deacutecisions

ayant pour but deacutetablir un ordre dapplication ugravees actions avant leur exeacutecution Dans cette

section nous allons discuter comment Ics deux approches abordent la planification en se

basant sur eelle deacutefinition

En ce qui concerne le TS lactiviteacute de test est piloteacutee par le plan de test eacutelaboreacute au deacutebut du

projet de test Ce plan situe les activiteacutes de test dans la strateacutegie globale de livraison du

logiciel La preacuteparation de plan dc test pcut commencer au moment de la formulation des

besoins et se deacuteveloppcr et se raffiner pendant la phase de conception du logiciel Cela

sinclut dans le cadre de test preacuteventif Ce type de test dicte que la planification de TS peut

preacutevenir les erreurs dans la phase de conception avant que celles ci se transforment agrave des

deacutefauts dans le code (Craig et Jaskiel 2002 Perry 2002 Swebok 2004) Alors du processus

de planification reacutesulte le plan de test Ce plan deacutecrit les items et les caracteacuteristiques

(fonctionnaliteacute performance utilisabiliteacute etc) qui devraient ecirctre testeacutes les caracteacuteristiques

qui ne devraient pas ecirctre testeacutees les responsabiliteacutes les livrables les besoins

environnementaux et leacutecheacuteancier du projct de test Par la suite tous les deacutetails des tests sont

identifieacutes et rigoureusement planifieacutes avant le deacutebut de leur exeacutecution En fait le plan de test

dans une activiteacute de TS vise deux objectifs essentiels le premier la planification de lactiviteacute

de test Je deuxiegraveme leacutetablissement des canaux de communications entre les intervenants agrave

linteacuterieur et lexteacuterieur du projet de test Selon (IEEE 829 1998) lutilisation de standard

IEEE 829 pourrait ameacuteliorer la qualiteacute de ces canaux de communication

Le TE introduit lui aussi la planification mais avec un rocircle et une signification diffeacuterents Au

deacutebut de lactiviteacute de test le responsable de test identifie une liste des items agrave tester Ces

92

itcms constituent les chartes de tests (deacutejagrave eacutevoqueacute dans le chapitre III) Cependant il ne sagit

pas dune identification complegravete de toutes les chal1es avant le deacutebut de lexeacutecution de test

mais dune planification preacuteliminaire agrave quelques chartes de test en se basant sur les

informations disponibles au deacutebut du projet de test Ce plan sameacuteliore pendant le

deacuteroulement du projet de test gracircce aux notes reacutesu hant de Jexeacutecution de chartes de test

Autrement dautres chartes de test sajoutent au fur et agrave mesure que les chartcs preacuteliminaires

sexeacutecutent En effet pendant lexeacutecution de charte de test le testeur peut explorer nimpone

quel panie du logiciel et rapporter ses constations el ses observations dans les notes de

session ce que Jonathan Bach (2000) appelle laquoOpportuniteacuteraquo Ces notes font lobjet dune

eacutevaluation avec le responsable de test Suite agrave cette eacutevaluation le responsable de test pourrait

ajouter des nouvelles chartes correspondant et mettre agrave jour le plan de chartes Selon James

et Wood (2003) la planification de TE est une planification continue (Figure32) Dans la

mecircme perspective Copeland (2003) classifie la planification de TE comme une planification

adaptative qui se change agrave chaque moment agrave la venue de nouvelles informations pendant le

processus de test alors que la planification sceacutenariseacutec est une pIani fication classique qui

identifie toutes les actions et les deacutetails de test avant lexeacutecution de ces actions

Nous pouvons constater que la planification dans une activiteacute de TE constitue un moyen de

controcircle et dencadrement de processus En fait il nc sagit pas dune planification telle

quelle est deacutefinie par le dictionnaire ougrave toutes les actions devraient ecirctre speacutecifieacutees avant leur

exeacutecution Mais cest une planification introduite par Jonathan Bach (2000) pour geacuterer

lactiviteacute de test et introduire le controcirclc ct la mesure sur le TE libre Donc il sagit dune

planification qui vise lexeacutecution de la mission de test du logiciel plutocirct que la documentation

ct larchivage en texte Nous pouvons constater aussi que la planification de TS est plus

cenaine et rigoureuse que la planification de TE En effet la planification de TS tend agrave

preacuteciser tous les deacutetails fins du processus de test avant le deacutebut de Icur exeacutecution tandis que

le TE tend agrave preacuteciser Jessentiel du processus de test et compte sur Jexploration des testeurs

pendant lexeacutecution des sessions de test pour raffiner et ameacuteJiorcr le plan initial

Nous concluons de cette discussion que Ic TS est plus approprieacute dans les projcts de test qui

neacutecessitent une planification cel1aine et rigoureuse de lactiviteacute de test Par exemple les

93

situations ougrave la plate-forme de test est disponible seulement par intermittence Comme un

projet client serveur ougrave les serveurs configureacutes devraient ecirctre partageacutes par lactiviteacute de test et

le deacuteveloppement La logistique dune telle situation peut exiger lutilisation de TS qui

pourrait fournir une planification rigoureuse de lactiviteacute de test pour profiter au maximum du

temps limiteacute pour les tests (Bach 2003) Par contre le TE est plus approprieacute dans Ics projets

de test flexibles

722 Le controcircle et le suivi de progression de test

Lobjectif de controcircle et du suivi du test est de foumir un retour et une visibiliteacute sur les

activiteacutes de test Les informations agrave suivre peuvent ecirctre recueillies manuellement ou

automatiquement et peuvent ecirctre utiliseacutees pour eacutevaluer les critegraveres de sonies comme la

couvenure de test Des mesures peuvent aussi ecirctre utiliseacutees pour eacutevaluer lavancement par

rapport au ca lendrier et au budget planifieacutes

Selon Craig et JaskieJ (2002) le controcircle et le suivi du test sont panni les problegravemes auxquels

le responsable devrait faire face dans un projet de test Alors le responsable devrait trouver

une meacutethode pour retracer ou suivre le deacuteroulement de lactiviteacute de test Par la suitc il devrait

ecirctre capable de faire un rapport sur le statut des tests agrave nimporte que 1 moment tant que le

produit est toujours sous test ]1 devrait aussi pouvoir reacutepondre aux questions typiqucs qui se

posent reacuteguliegraverement pendant les tests

bull Comment se deacuteroulent les tests

bull Quel est le pourcentage des tests accomplis

bull Qucl est le pourcentage des tests reacuteussis

Le TS se precircte tregraves bien agrave la mesure Un nombre total de cas de tests peut ecirctre calculeacute et une

meacutetrique de test peut ecirctrc creacuteeacutee mesurant par exemple Je pourcentage des cas de tests qui ont

eacuteteacute exeacutecuteacutes Des meacutethodes speacutecifiques proposeacutees dans la 1illeacuterature permellent de mesurer la

progression de lactiviteacute de TS et de preacutevoir la date de livraison du logiciel en se basant sur le

nombre de cas de tests restants avant la compleacutetude de lactiviteacute de test (Kan 2001 Craig et

Jaskiel 2002)

94

Quant au TE les mesures collecteacutecs pendant le test et le deacutebriefing permettent destimer la

productiviteacute ou le rendement de chaque membre de leacutequipe de test pendant le projct de test

en cours Cela avec le nombre de sessions compleacuteteacutees pourrait aider dans lestimation de la

quantiteacute du travail restant avant la fin du cycle de test (Jonathan Bach 2000) Notons que le

sujet du controcircle de la progression nest pas toujours bien abordeacute dans la litteacuteraturc agrave part ce

meacutecanisme proposeacute par Jonathan Bach (2000) Toutefois ce meacutecanisme aide sculcmcnt dans

leacutelaboration dune estimation de la quantiteacute du travail restant avant la fin du cycle dc test Il

ne sagit que dune estimation la preacutevision se basant sur cette estimation eacutetant incertaine

Nous pouvons conclure de cette discussion que le controcircle et le suivi de la progression de test

dans le TS est mesurable alors quil nest quun estimeacute En conseacutequence nous concluons que

le TS est plus approprieacute dans les projets de tests qui ont un eacutecheacuteancier fixe alors que le TE

est approprieacute dans les projets de test qui ont un eacutecheacuteancier flexible et toleacuterant au retard qui

pourrait reacutesulter dune mauvaise estimation

723 La communication dans le projet de test

Le TE mise fOl1ement sur les connaissances tacites et sur les compeacutetenccs interpersonnelles

Comme nous avons deacutejagrave vu dans la revue de litteacuterature le TE est baseacute sur les connaissances

tacites du testeur et son expertise (Itkonen et Rautiainen 2005 Petty 2005 Lyndsay ct van

Eeden 2003 Wood et James 2003) Les compeacutetences interpersonnelles jouent aussi un rocircle

important dans la qualiteacute du travail (Lyndsay et van Eeden 2003) la communication eacutetant

essentielle dans le TE Nous avons constateacute dapregraves notre revue de litteacuterature que la

communication et leacutechange des connaissances interviennent de diffeacuterentes faccedilons dans le

TE La premiegravere est Je partage des connaissances entre le testeur et dautres intervenants hors

de leacutequipe de test comme le client En effet le testeur chargeacute de lexeacutecution dune mission

de TE pourrait collecter les informations neacutecessaires sur le logiciel agrave tester agrave paI1ir des

reacuteunions ou des discussions avec diffeacuterents intervenants dans le projet de deacuteveloppemcnt du

logiciel agrave tester afin de comprendre et dapprcndre le logiciel el ses caracteacuteristiques

fonctionnelles (Kaner et Bach 2004)

La deuxiegraveme forme dc communication est entre testeurs et responsablc du test Ce dcmier

devrait deacutebriefer chaquc testeur apregraves Jexeacutecution dc chacune des chartes dc test pour eacutevaluer

95

le travail accompli Alors pendant le deacutebriefing le responsable pourrait eacutechanger ses

connaissances avec le testeur pour le guider (Jonathan Bach 2004 Lyndsay et van Eeden

2003) La communication pourrait aussi prendre la forme dune collaboration entre les

testeurs La communication entre les membres de leacutequipe de test pourrait ameacuteliorer la

qualiteacute de TE effectueacute En effet de bons canaux de communication permettent deacutechanger les

expeacuteriences et les connaissances dans leacutequipe de faccedilon agrave ce que les membres plus

expeacuterimenteacutes aident et encadrent les membres moins expeacuterimenteacutes (Lyndsay et van Eeden

2003)

La troisiegraveme forme deacutechanges des connaissances peut apparaicirctre pendant la session de test

entre deux personnes qui se chargent de lexeacutecution de la mecircme mission de test deacutefinie sous

le terme de laquotest par pairesraquo Nous avons noteacute cela agrave travers les eacutetudes de cas que nous avons

proposeacute dans la revue de litteacuterature parfois entre deux testeurs (Amand et Vaga 2002) ou

entre un testeur et un deacuteveloppeur (Petty 2005)

Le TS au contraire se mise beaucoup sur les connaissances explicitement documenteacutees La

communication entre les praticiens dans le projet de test est centreacutee autour dcs livrables bien

deacutetermineacutes En effet souvent les testeurs chargeacutes de la conception (testeurs seniors)

communiquent avec les testeurs chargeacutes de lexeacutecution des tests (testeurs juniors) par les

proceacutedures de test Ces derniers communiquent reacuteciproquement par les rapports dincidents

En ce qui concerne la communication entre les testeurs et les deacuteveloppeurs dans la plupart

des cas la communication se fait agrave travers laquole Bug Traeking System raquo le systegraveme qui

enregistre les deacutefauts deacutetecteacutes Nous notons que dans quelques situations il regravegne une

relation difficile entre les deacuteveloppeurs et les testeurs (Bach et al 2002) du fait que les

deacuteveloppeurs sentent que les testeurs deacutetruisent leur travail et se sentent responsables des

deacutefaillances deacutetecteacutees

Nous pouvons conclure que la gesti on de TE se fonde sur la communication entre les

intervenants dans le projet de test mecircme la qualiteacute des tests effectueacutes deacutepend de la qualiteacute de

communication entre le responsable des tests et les testeurs tandis que la gestion dans le TS

se fonde sur la documentation

96

En conseacutequence il semble que les contextes supportant la communication informelle sont

plus approprieacutes et favorables au TE

724 La relation avec le client

Selon Kaner et Bach (2004) la conversation avec le client pourrait ecirctre une source

dinformation importante pour la compreacutehension et lappreacutehension du logiciel dans une

activiteacute de TE Agrave cet effet une bonne relation avec le client est essentielle dans le TE Par

contre celte relation nest pas neacutecessaire dans une activiteacute de TS du fait que les cas de test

sont conccedilus agrave partir des exigences du systegraveme Cependant il est faux de dirc que celte

relation entre le testeur et le client nest pas souhaiteacutee dans le TS Selon Craig et Jaskiel

(2002) le client peut jouer un rocircle important dans lactiviteacute de TS par la participation dans les

reacuteunions didentification de la liste des risques du logiciel Ceci pourrait optimiser et orienter

lactiviteacute de test vers les risques importants du logiciel

Nous concluons de celte discussion quune bonne relation avec le client est essenticllc dans le

TE et pourrait ameacuteliorer la compreacutehension du logiciel Par contre elle est souhaiteacutee ct non

obligatoire dans le TS

73 Comparaison selon les caracteacuteristiques techniques

Nous allons discuter dans cette section des caracteacuteristiques techniques de deux approches de

test le TE et le TS Ces caracteacuteristiques portent sur le processus de test les activiteacutes de test

les artefacts creacutees et les eacuteleacutements neacutecessaires pour le bon deacuteroulement de test Nous allons

cssayer de deacuteceler comment les deux approches de test le TE et le TS abordent chaquc eacutetapc

de lactiviteacute de test Selon (Swebok 2004 Pyhajarvi ct aL 2003 Craig et Jaskicl 2002

Perry 2000) les activiteacutes de test comportent les eacutetapes suivantes la planification la

conception dc tests et lexeacutecution de tests Toutefois ces activiteacutes sont influenceacutees selon

(Bolton 2005) par trois facteurs agrave savoir les risqucs du logiciel Joracle de tcst ct la

couverture de test tel quillustreacute sur la figure 71

97

Figure 71 Les eacuteleacutements essentiels du test du logiciel (Bolton Kaner et Bach 2005)

Les risques du logiciel

Les activiteacutes de test 1 La couvertu~ Ee d~ t~)

731 Les activiteacutes de test

En ce qui concerne le TS les cas de test sont conccedilus au deacutebut de lactiviteacute de test

principalement agrave partir des exigences du logiciel Chaque cas de tcst devrait ecirctre sous le

controcircle de la gestion de configuration du logiciel et inclure les reacutesultats preacutevus dc chaque

test (Swebok 2004 Perry 2000 Hetzel 1988) La conception ct la planification pourraient

commencer en parallegravele avcc le projet de deacuteveloppement

Tel quillustreacute agrave la figure 72 la preacuteparation de plan de test et des cas de test se font par le

testeur souvent un testeur senior en utilisant les entreacutees speacutecifiques de projet de test en

cours Alors ces entreacutees peuvent inclure les exigences du logiciel les standards ct les normes

agrave respecter qui varient selon le domaine de test Dans certaines situations le test peut ecirctre

guideacute par divers objectifs comme les risques du logiciel ou les cas dutilisations pour

identifier les prioriteacutes de test et focaliser sa strateacutegie (Swebok 2004) Quant aux tcchniques

de tesl elles sont choisies selon la nature du logiciel sous test lefficaciteacute et la preacutecision

souhaiteacutees (Craig el Jaskiel 2003 Biezer J990)

Sajoutenl agrave ces entreacutees citeacutees ci dessus les compeacutetences et les quaI ifications du testeur

senior chargeacute de la conception de tests ses connaissances comme les connaissances du

98

domaine du logiciel agrave tester ses expeacuteriences anteacuterieures ses connaissances techniques et ses

qualiteacutes personnelles Linteraction de toutes les entreacutees permet didentifier le plan et les cas

de test Le pourcentage de cOLlvel1ure de test atteint pourrait ecirctre mesureacute agrave cc niveau du

processus de test agrave laide de a matrice de traccedilabiliteacute figure 2

Figure 72 Les activiteacutes de test sceacutenariseacute (Adapteacute et traduit de Bach 2006)

Les entreacutees Les connaissances du domaine Les sorties Les expeacuteriences anteacuterieures Les connaissances techniques Les qualiteacutes personnelles

Les Les cas Le plan

risques dutilisations de test

Les Les standards Les cas de

exigences tests

Les techniques de La couverture Seacuteparation dans le temps

tests et fou dans lespace

Les entreacutees Les sorties

Rapports

Les cas de dincidents tests

Systegraveme sous test

99

Les cas de tests sont souvent exeacutecuteacutes ulteacuterieurement par des testeurs juniors quand le

logiciel devient disponible pour le test Ces testeurs se chargent de Jexeacutecution des proceacutedures

de test Ces derniegraveres deacutecrivent tous les deacutetails fins neacutecessaires agrave lexeacutecution des tests

incluant les reacutesultats preacutevus comme nous lavons deacutejagrave proposeacute dans le chapitre II Il suffit

que les testeurs comparent les reacutesultats preacutevus et les reacutesultats observeacutes En cas dapparition

dune deacutefaillance le testeur rapporte les reacutesultats dans le rapport dincident preacutevu agrave cet effet

selon la norme IEEE 829

Figure 73 Les activiteacutes de test exploratoire (Adapteacute et traduit de Bach 2006)

Les entreacutees Les connaissances du domaine Les sorties Les expeacuteriences anleacuterieures Les connaissances techniques Les qualiteacutes personnelles La charte de

session

Rapport de session Nimporte quelle

documentation existante o Les Deacutefauts

les exigences le manuel

dutilisateur E-mail o Les notes

Les techniques de o Ips nrnhlpmls

test

Systegraveme sous test

Par contre tel quillustreacute agrave la figure 73 les cas de tests de TE sont conccedilus pendant le test En

effet le testeur reccediloit en entreacutee la charte de la session de test qui identifie les grandes lignes

de sa mission de test Il doit sinformer sur le logiciel en utilisant nimporte quelle source

dinformation existante dans le projet de test en cours comme Je manuel dutilisateur des

discussions avec le client et les deacuteveloppeurs et dautres Par la suite il doit identifier les

techniques convenables de test Parfois ces techniques de test peuvent ecirctre mentionneacutees dans

la charte de test selon la complexiteacute ct le risque ditems agrave tester traiteacutes dans la charte Alors

100

pendant lexeacutecution de sa mission le testeur apprend explore conccediloit et exeacutecute les tests

(Bach 2003) Chaque cas de test beacuteneacuteficie de (information obtenue de tests anteacuterieurs et la

maturiteacute des connaissances accumuleacutees agrave chaque moment de lactiviteacute de test (Bach et aL

2002) Les reacutesultats de la session de test sont rapporteacutes dans le rapport de la session Ce

rapport fera lobjet dun deacutebriefing avec le responsable de test afin de valider le travail

effectueacute par le testeur

Nous concluons de cette discussion que le TS est plus approprieacute dans les projets de test

favorisant la reacutepeacutetitiviteacute et lauditabiliteacute de tests Par contre le TE est plus approprieacute dans les

projets de test favorisant la creacuteativiteacute et ladaptabiliteacute agrave chaque moment de processus de test

732 Les risques du logiciel

Selon le dictionnaire de loffice queacutebeacutecois de la langue franccedilaise le risque informatique est la

probabiliteacute plus au moins grande de voir une menace informatique se transformer en

eacuteveacutenement reacuteel entraicircnant une perte II se mesure agrave la fois par la probabiliteacute doccurrence

dune menace et par limpact de sa reacutealisation Dans la litteacuterature de test du logiciel le risque

du logiciel se deacutefinit comme la probabiliteacute doccurrence et limpact de la reacutealisation dune

deacutefaillance dans le logiciel (Craig et ]askiel 2002 Lyndsay et van Eeden 2003)

Limpossibiliteacute de test complet du logiciel (Pressman 1997 Kaner 1997 Hetzel 1988) et

les cycles de deacuteveloppement de plus en plus courts ont pousseacute les intervemmts dans le

domaine de test du logiciel agrave chercher des techniques leur permettant dexploiter le temps

consacreacute au test dune faccedilon optimale telle que lanalyse de risque du logiciel Selon

Swcbok (2004) les diffeacuterentes eacutetapes de tests pourraient ecirctre guideacutees par les risques associeacutes

au logiciel pour identifier sa prioriteacute et focaliser sa strateacutegie Ces risques sont identifieacutes par le

biais dune analyse qui pourrait ecirctre faite pendant la phase de preacuteparation de lactiviteacute de test

Cette analyse permet de deacuteterminer les eacuteleacutements du logiciel les plus susceptibles de contenir

le plus de deacutefauts Les reacutesultats de cette activiteacute sont utiliseacutes pendant le planning pour

deacuteterminer la strateacutegie de test les prioriteacutes et la profondeur de test neacutecessaire (Craig et

]askiel 2002 Lyndsay et van Ecdcn 2003 Perry 2000)

Le standard de documentation IEEE 829 a identifieacute une section dans le patron de plan de test

101

pour les risqucs ct contingences En fait cette section nidentifie que les risques pouvant

empecirccher le deacuteroulement normal de plan de test Dans la pratique de test les entreprises

divisent celle clause de plan de test a deux clauses une traite les risques pouvant empecirccher

lexeacutecution normale de plan de test ainsi les contingences convenables pour les surmonter

lautre traitc et identifie les risques du logiciel (Craig et Jaskiel 2002) et cite les proceacutedures agrave

entreprendre dans le test pour minimiser ses probabiliteacutes docculTence et ses impacts en cas

de reacutealisation

Dans une activiteacute de TS lanalyse de risques associeacutes au logiciel se fait agrave partir de documents

des exigenccs et de conception du logiciel Le livrable de cette phase est une matrice de

risque montrant le degreacute de risque acceptable pour chaque fonction ou secteur du logiciel et

sa criticiteacute aux affaires (Craig et Jaskiel 2002) Par la suite lapproche de test et leffort de

test neacutecessaire de chaque eacuteleacutement de cette matrice pourront ecirctre fixeacutes et documcnteacutes selon le

degreacute de risque calculeacute Ainsi les cas de test conccedilus pourront ecirctre revus et inspecteacutes par

plusieurs intervenants dans le projet de test autant de fois que neacutecessaire pour sassurer de la

profondeur et la couverture de tests des zones risqueacutees du logiciel

Selon (Bach 2003 Kaner et Tinkham 2003) le TE pourrait ecirctrc guideacute par une liste de

risques Lc responsable de test identifie cette 1iste en se basant sur nimporte quclle reacutefeacuterence

ou source dinformation existant dans Je projet de test (Jonathan Bach 2004 Lyndsay et van

Eeden 2003) Suite agrave cette identification les chartes com~spondant aux eacuteleacutements de cette

liste seront plus deacutetai lIeacutees que les autres chartes et pourront mecircme deacutecrire les techniques agrave

utiliser pcndant le tcst (Jonathan Bach 2004) Cependant le degreacute au bas niveau pour lequel

chaque eacuteleacutement de la liste est testeacute ne pourrait pas ecirctre assureacute mecircme avec les notes de session

et le deacutebriefing avec le responsable Par conseacutequent le TE pOl1e le risque que certaines parties

de grands risques ne soient pas testeacutecs correctement

Nous concluons de cette discussion que lauditabiliteacute de TS assure que les risques du logiciel

soient bien testeacutes par conseacutequent le TS pourrait ecirctre plus approprieacute dans les projets de test

preacutescntent un niveau eacuteleveacute de risque Tandis que le TE ne garantit pas que les secteurs agrave

risque soicnt bicn couvel1s

102

733 La couverture de test

La couverture de test est la mesure de ce qui a eacuteteacute testeacute proportionnellement agrave ce qui pourrait

ecirctre testeacute (Kaner 1996) Cest le degreacute exprimeacute en pourcentage selon lequel un eacuteleacutement de

couverture (les exigences lignes de code branches etc) a eacuteteacute exeacutecuteacute lors dune suite de

tests Cest une meacutetrique importante dans lactiviteacute de test logiciel Sa pertinence reacuteside dans

Je fait quil permet deacutevaluer la qualiteacute des tests effectueacutes et de savoir si le logiciel a subi

assez de tests (Swebok 2004) Pratiquement la mesure de la couverture des exigences et de

la couverture du code sont les deux formes de mesures de couverture les plus utiliseacutees et

discuteacutees dans la litteacuterature et les plus supporteacutees par les outils dans le domaine de test du

logiciel

La matrice de traccedilabiliteacute (Figure 21) constitue la premiegravere forme de mesure de couverture en

type de test boicircte noire En effet cette matrice montre agrave quel degreacute chaque exigence ou

caracteacuteristique du logiciel (la fiabiliteacute lutilisabiliteacute etc) a eacuteteacute testeacutee en illustrant le nombre

de cas de tests qui la couvre (Craig et Jaskiel 2002 Bach et al 2002) Puis des inspections et

des revues formelles des cas de tests permettent deacutevaluer la qualiteacute des cas de tests conccedilus et

de sassurer que les secteurs identifieacutes pendant lanalyse de risque du logiciel sont bien

couverts par Ics tests (Craig ct Jaskiel 2002)

La deuxiegraveme forme est la mesure de eouvcI1ure de code Cest une meacutethode danalyse qui

deacutetermine quelles parties du programme ont eacuteteacute exeacutecuteacutees (couvertes) par une suite de tests et

quelles parties ne lont pas eacuteteacute par exemple la couverture des lignes de code des deacutecisions

ou des conditions Dans Je type de test de type boicircte noire la couverture de lignes de code

sutilise souvent en utilisant un logiciel outil appeleacute laquomoniteur de testraquo Ce moniteur mesure

ou calcule le pourcentage de lignes de code exeacutecuteacute lors de lexeacutecution des cas de tests

sceacutenariseacutes (Kaner et al 1999 Marick 1997) Alors si le pourcentage mesureacute est insuffisant

des cas de tests peuvent ecirctre ajouteacutes afin datteindre le pourcentage viseacute

Bach (2003) a mentionneacute que les chartes de tests peuvent ecirctre identifieacutees selon une liste ou

matrice de couverture cest-agrave-dire une liste des eacuteleacutements du logiciel agrave recouvrir dans le test

Cependant la couverture de bas niveau ne pouvait pas ecirctre mesureacutee du fait que les meacutethodes

103

traditionnelles que nous venons de citer dans le TS ne pourraient pas ecirctre utiliseacutees dans le TE

En conseacutequence la couverture du test nest pas claire ni mesurable dans le TE Les auteurs

Itkonen et Rautiainen (2005) ont mentionneacute que ce manque de mesure de couverture est la

plus grande lacune du TE Lindsay et van Eeden (2003) ont proposeacute une technique pour

mesurer la couverture de test que nous avons deacutecrite dans la revue de litteacuterature Quoique la

technique soit innovatrice son succegraves deacutepend aussi de Jexpeltise de testeur et de sa capaciteacute

de faire un bon jugement sur Je pourcentage couvert par les tests pendant la session de test

Dun autre point de vue la mesure de couverture est tregraves utile pour la prise de deacutecision de

larrecirct de test En effet une des choses les plus difficiles dans le test de logiciel est de savoir

quand le logiciel est suffisamment testeacute et precirct agrave ecirctre livreacute Eacutevidemment le logiciel est bien

testeacute quand tous les bogues sont trouveacutes Cependant impossible de savoir sils sont tous

trouveacutes Ce problegraveme a eacuteteacute reconnu par Dijstra en 1972 par sa citation ceacutelegravebre qui deacuteclare que

laquole test du programme peut ecirctre utiliseacute pour montrer la preacutesence des bogues mais jamais

pour montrer leur absenceraquo De ce fait le recours aux critegraveres permettant la prise de deacutecision

de larrecirct de tests reste neacutecessaire Selon Copeland (2004) les critegraveres les plus utiliseacutes dans

la pratique sont le budget le calendrier de test et la couverture de tests En conseacutequence la

couverture fournit un appui utile pour la prise de deacutecision de larrecirct de tests (Swebok 2004)

Toutefois les praticiens dans lindustrie de test qui ont utiliseacute le TE comme une

meacutethodologie primaire de test et les auteurs fondateurs de lapproche (Bach et al 2002)

nont pas preacutesenteacute les meacutecanismes et les techniques quils ont utiliseacutes pour prendre la

deacutecision darrecircter le test

Nous concluons de cette discussion que la mesure de couverture de test ne peut pas ecirctre

mesureacutee dans le TE Par conseacutequent le TE nest pas approprieacute dans les projets de test qui

neacutecessitent que la couverture de test soit mesureacutee

734 Loracle de test

Selon Hoffman (1999) le test du logiciel est la comparaison du comportement du logiciel

avec le comportement attendu de celui-ci Ce compol1cmcnt attendu est connu sous Je terme

laquoOrac leraquo

104

Nous allons aborder dans cette section les faccedilons deacutelaboration de loracle de test dans le les

deux approches de test le TS et le TE

Selon Swebok (2004) un oracle de test est nimporte quel agent humain ou meacutecanique qui

statue si un programme sest comporteacute correctement dans un test donneacute et produit en

conseacutequence un verdict de passage ou eacutechec de test Selon Biezer (1990) un oracle de test est

nimporte quel programme processus ou ensemble de donneacutees qui speacutecifient les reacutesultats

preacutevus

Dans une approche sceacutenariseacutee leacutevaluation de comportement du logiciel sous test est deacutejagrave

intrinsegraveque aux cas des tests qui mentionnent les reacutesultats preacutevus Ccs reacutesultats servent

comme un oracle et guident le testeur pendant le test Cet oracle de test est de type

entreacuteesortie (Biezer 1990) cest-agrave-dire le testeur devrait exeacutecuter le logiciel en utilisant les

entreacutees speacutecifieacutees dans Je cas de test puis comparer les reacutesultats observeacutes aux sorties

speacutecifieacutees dans le cas de tesl Sils sont semblables le logiciel passe le test sinon il eacutechoue le

test

Selon Bach (1999) loracle de test est une strateacutegie eacutelaboreacutee au moment du test pour

deacuteterminer si un comportement observeacute du logiciel est correct ou non Alors nous pouvons

constater de cette deacutefinition que Joracle de test dans Je TE sc construit en temps reacutee) pendant

le tesl Le testeur formule une ideacutee sur le comportement normal et correct du logiciel en se

basant sur ses intuitions et anticipations ses compeacutetences et sa compreacutehension du logiciel agrave

tester

Afin de faciliter et guider la reacuteflexion de testeur exploratoire pendant la session de test Bach

et Kaner (2005) ont proposeacute une liste des heuristiques Ces demiegraveres pourraient aider le

testeur agrave construire Joracle de test en se basant sur la veacuterification de la coheacuterence selon

plusieurs dimensions Chacune de ces dimensions exploite un aspect particulier de contexte

de projet de test pour savoir si le comportement observeacute apregraves lexeacutecution dun test donneacute est

normal ou non par la suite prendre une deacutecision dc passage ou deacutechec dc tesl

105

Cette liste inclut

bull Coheacuterence du logiciel le comportement de chaque fonction est coheacuterent avec le

comportement de dautres fonctions comparables du logiciel ou avec le pattern

fonctionnel

bull Coheacuterence par rapport aux logiciels comparables le comportement de chaque

fonction du logiciel est coheacuterent avec le comportement dautres fonctions de logiciels

comparables

Coheacuterence avec lhistorique le comportement actuel du logicicl est coheacuterent avec

son comportement anteacuterieur

bull Coheacuterence avec limage de lorganisation le comportement du logiciel est coheacuterent

avec limage que lorganisation voulait projeter

bull Coheacuterence avec les exigences le comportement est coheacutercnt avec la documentation

existante et ce qui est annonceacute sur le produit

bull Coheacuterence avec les speacutecifications et les reacutegulations le comportement cst coheacuterent

avcc les exigences et les normes qui devaient ecirctre respecteacutees dans le projet de test

Coheacuterence avec les attentes de Jutilisatcur le cOmpoJ1ement est coheacuterent avec ce que

lutilisateur attend du logiciel

bull Coheacuterence avec Jobjectif du produit le comportemcnt cst coheacuterent avec le but

apparent et la fonction globale du produit

Dans la mecircme perspective Whittaker (2003) a proposeacute un modegravele intituleacute laquo Fault Modelraquo

pour guider le testeur dans Jeacutelaboration de loracle de test Lideacutee principale de ce modegravele est

que le logiciel a quatre capaciteacutes principales acccptcr les entreacutees enregistrer les donneacutees

traiter les donneacutees entreacutees et enregistreacutees ct produire des sorties Donc si le logiciel ne fait

pas lune de ces eacutetapes correctement pendant lexeacutecution dun cas de test il eacutechoue le test Ce

modegravele fait paJ1ie dcs techniques citeacutees et rccommandeacutees par Bach et Kaner (2004) Ces

106

meacutecanismes sajoutent agrave dautres qui visent la simplification de la mission de testeur pendant

la session de test ainsi que lameacutelioration des reacutesultats de TE Mais une question qui se pose

est-ce que nimporte quel testeur pourrait ecirctre capable dutil iser toutes ces techniques Il

semblerait que ces tcchniques neacutecessitent un testeur compeacutetent et expeacuterimenteacute

Dun autre point de vue selon Kaner (2004) la speacutecification des reacutesultats preacutevus de chaque

test dans le TS pourrait avoir des conseacutequences neacutegatives sur lefficaciteacute de lactiviteacute de test

Selon cet auteur le logiciel ou le systegraveme informatique pourrait eacutechoucr de plusieurs faccedilons

impreacutevues Par conseacutequent loracle entreacuteesortie de TS pourrait desservir au lieu de servir

dans le test parce quil peut empecirccher la deacutetection des deacutefauts non preacutevus dans le cas de test

Nous concluons de cette discussion que le TS permet davoir le mecircme oracle de test chaque

fois que les cas de test sont exeacutecuteacutes li permet aussi de veacuterifier le logiciel formcllement par

rapport ses speacutecifications Par contre loracle de TE est variable et permet dc comparer le

logiciel contre les preacutevisions du testeur

74 Comparaison selon les caraeacuteteacuteristiques du personnel

Dans cette section nous allons discuter de linflucncc des caracteacuteristiqucs du personncl sur le

choix de lapproche de test Les caracteacuteristiqucs du personncl rcgroupcnt deux factcurs les

caracteacuteristiques du testeur et la culture de lorganisation ougrave se deacuteroulc Ic projet de test

74J Les carateacuteristiques du testeur

En geacuteneacuteral tel quillustreacute sur les figures 72 et 73 les deux approches le TE et le TS

neacutecessitent des qualifications et des compeacutetences pour que le test soit efficace et attcigne ses

objectifs La diffeacuterence reacuteside dans le niveau dapplication de ces compeacutetences En effet dans

une activiteacute de TS nimporte quel testeur peut exeacutecuter les proceacutedures de tests Ces

proceacutedures sont deacutecomposeacutees en eacutetapes claires et faciles agrave suivre comme nous lavons deacutejagrave

eacutevoqueacute dans le chapitre Il Par conseacutequent lexeacutecution des tests sceacutenariseacutes nexige pas des

testeurs tregraves expeacuterimenteacutes et fortement habiles et mecircme un testeur qui vient juste de

commencer sa carriegravere en test logiciel pourrait faire face (Craig Jaskiel 2002)

Par contre la conception des cas de tests exige la compeacutetence Donc cest agrave ce niveau que

107

les qualifications et lexpertise sont neacutecessaircs Parcc quil y a un deacutelai entre la creacuteation des

cas de tests et leur exeacutecution diffeacuterents testeurs peuvent concevoir et exeacutecuter les cas de

tests De ce fait les tests peuvent ecirctre conccedilus par des testeurs compeacutetents ou mecircme par un

seul testeur expert ct ecirctre deacuteleacutegueacutes agrave plusieurs moins expeacuterimenteacutes Bref il ny a aucun

besoin davoir seulement des tesleurs experts dans une eacutequipe de test sceacutenariseacute

Par contre le TE neacutecessite des compeacutetences et de qualifications importantes pour la

conception et lexeacutecution des tests (Itkonen et Rautiainen 2005 Petty 2005 Swebok 2004

Lyndsay et van Eeden 2003 James et Wood 2003 Amland et Vaga 2002) Selon Kaner

(2004) nimporte quelle activiteacute de test neacutecessite la creacuteativiteacute et les compeacutetences pour ecirctre

efficace incluant le TS Selon ce mecircme auteur les cas de tests sceacutenariseacutes peuvent limiter la

creacuteativiteacute de testeur et la transformer en un robot exeacutecutant les tacircches demandeacutees sans aucune

reacuteflexion critique surtout si le rendement du testeur est eacutevalueacute par le nombrc de cas de test

exeacutecuteacutes et par les erreurs deacutetecteacutees Dans une telle si tuation le testeur se concentre sur

lexeacutecution des proceacutedures de test et eacutevite la deacuteviation ellimprovisation

Dans le but de montrer les effets neacutegatifs de TS sur la creacuteativiteacute du testeur Kaner et son

eacutequipe (Kaner et Bach 2005) ont eacutelaboreacute plusieurs expeacuteriences et recherches dans les

laboratoires de Florida Institut sur des souris dont les deacutemonstrations sont disponibles dans

(Kaner et Bach 2005) Ces recherches ont prouveacute que les proceacutedures de test pourraient

empecirccher le testeur de voir dautres problegravemes non speacutecifieacutes dans les proceacutedures mais qui

peuvent apparaicirctre pendant lexeacutecution agrave cause du fait que le testeur se concentre seulement

sur les reacutesultats identifieacutes dans les proceacutedures de tests Cela est connu en psychologie sous le

terme anglophone laquoInattentional Blindnessraquo (Mack et Rock 2000) Selon Kaner (2004) le TE

aide le testeur agrave apprendre de nouvelles meacutethodes ct strateacutegies de test en lui permettant

dameacuteliorer sa capaciteacute danalyse et de reacuteflexion critique Selon les constations de Petty

(2005) la possibiliteacute dapprentissage dans le TE est plus grande que celle en TS

Nous concluons que le TE est approprieacute dans les projets de test ayant des testeurs compeacutetents

et experts Tandis que le TS est plus approprieacute dans les projets de test que ont un nombre

limiteacute de testeurs expelis et plusieurs non expeacuterimenteacutes

108

742 La culture de lorganisation

La culture de lorganisation pourrait fortement influencer le choix de lapproche de test

Selon Craig et laskiel (2002) un processus de TS ne pourrait pas ecirctre mis en place sil

nexistait pas un proccssus de deacuteveloppement formel et bien structureacute qui supporte le projet

de test Souvent les entreprises qui utilisent les bonnes pratiques et les meacutethodes disciplineacutees

de deacuteveloppement favorisent plus lutilisation de TS qui convient plus avec leur

meacutethodologie de deacuteveloppement Tandis que les entreprises qui possegravedent des processus

immatures ou chaotiques de deacuteveloppement ne pourraient pas utiliser le TS Ces entreprises

favorisent souvent des meacutethodes de test informelles comme le TE (Lyndsay van Eeden

2003 ltkonen et Rautiainen 2005)

Nous concluons gue le TS est plus approprieacute dans les projets de test des entreprises favorisant

la discipline Tandis gue le TE est plus approprieacute dans les entreprises qui ont des processus de

deacuteveloppement immatures et qui sappuient sur les compeacutetences et la creacuteativiteacute du personnel

pour mener les activiteacutes de deacuteveloppement ct eacuteviter le chaos

75 Comparaison selon la productiviteacute

Dans cette section nous allons comparer les deux approches de test le TS et le TE selon le

facteur de laquola productiviteacute raquo Nous discutons la productiviteacute en termes du nombre de deacutefauts

deacutetecteacutes et de limportance de deacutefauts deacutetecteacutes

Depuis son apparition dans Je domaine du test le TE sest fait promouvoir comme une

meacutethode efficace Selon Bach (2003) le TE pourrait ecirctre plus productif que le TS Cependant

il ny a aucune preuve jusquagrave maintenant dans la litteacuterature prouvant cette productiviteacute agrave part

quelques anecdotes et expeacuteriences veacutecues des praticiens

Theacuteoriquement lefficaciteacute pourrait ecirctre perccedilue autrement gue baseacutee seulement sur la base du

compte des deacutefauts trouveacutes Selon Copeland (2004) le TS est plus avantageux que Je TE du

fait quil pourrait sintroduire tocirct dans le cycle du deacuteveloppement du logiciel En effet dans

les vues preacuteventives actuelles le TS peut commencer des le deacutebut de projet du

deacuteveloppement Par la suite il pourrait deacutelecter les erreurs dans la conception et les exigences

avant que ces derniegraveres ne se transforment en des deacute1agraveuts dans le logiciel Par contre le TE

109

ne pourrait sintroduire quapregraves le codage du logiciel De ce point de vue nous pouvons

conclure que le TS est plus efficace que le TE vu sa capaciteacute de preacutevenir les deacutefauts Dun

autre point de vue selon (Copland 2004 Kaner 2003) les cas de tests sceacutenariseacutes deviennent

laquofatigueacutesraquo cest-agrave-dire incapables de deacutetecter de nouveaux deacutefauts dans les cycles ulteacuterieurs

de test Par conseacutequent le TE pourrait ecirctre plus efficace dans cette situation

Les auteurs Itkonen Rautiainen (2005) ont tenteacute de collecter des donneacutees quantitatives

pouvant leur donner une ideacutee de la productiviteacute de TE Malheureusement les donneacutees

collecteacutees neacutetaient pas fiables Sajoute agrave ce fait labsence des reacutesultats de TS pouvant servir

comme une reacutefeacuterence de comparaison Dans les autres eacutetudes de cas que nous avons

proposeacutees dans la revue de litteacuterature les praticiens ont tous rappol1eacute que leur expeacuterience

dans Jutilisation de TE comme une approche primaire de test a eacuteteacute fmetueuse et reacuteussie

Cependant ils nont pas preacutesenteacute des donneacutees quantitatives sur lefficaciteacute reacutealiseacutee et les

reacutesultats obtenus

Quant agrave notre expeacuterience qui sest deacuterouleacutee dans les laboratoires informatiques de lUQAgraveM

nous navons pas pu tirer des conclusions fiables et geacuteneacuteraliseacutees agrave cause des limites du

contexte de lexpeacuterience Cette limite est causeacutee par la taille du programme utiliseacute dans

lexpeacuterience choisi pour faciliter la tacircche des sujets et eacuteviter les reacutesultats nuls Le contexte ne

nous a pas permis daborder lactiviteacute de test dune faccedilon professionnelle Le manque

dexpeacuterience des sujets dans le domaine de test du logiciel sajoute aussi aux limitations de

contexte Ces limitations ont influenceacute les reacutesultats de lexpeacuterience Cela est appam

clairement dans les reacutesultais de TS obtenus Quoique nous ayons proposeacute aux sujets les

mecircmes sceacutenarios de cas de test nous avons constateacute que les sujets ont interpreacuteteacute les reacutesultats

observeacutes diffeacuteremment ct ils ont eu de la difficulteacute agrave classifier les deacutefagraveuts deacutetecteacutes

correctement Nous avons dailleurs duuml les reclasser apregraves lexpeacuterience

Les reacutesultats recueillis de cette eacutetude empirique nous a permis de conclure que le TE est plus

productif en terme de nombre des deacutefauts deacutetecteacutes que le TS Ainsi nous avons conclu que Je

TE pourraient deacutetecter des deacutefauts plus importants point de vue graviteacute que le test sceacutenariseacute

110

76 Discussion et synthegravese

Dans ce chapitre nous avons compareacute les deux approches de test Je TE et le TS selon les

facteurs du cadre de comparaison que nous avions eacutelaboreacute Dans cette section nous allons

reacutecapituler les reacutesultats et conclure Le tableau ci-bas reacutecapitule les reacutesultats de notre analyse

comparative Il inclut les facteurs principaux qui doivent ecirctre pris en compte pendant la

seacutelection de lapproche de test pour eacuteviter de proposer une solution inadeacutequate

En fait ce tableau constitue un guide de seacutelection de lapproche de test parmi les deux

discuteacutes dans ce travail de recherche agrave savoir le TE ct le TS Alors ce guide identifie

comment chaque facteur de contexte de test sapplique agrave chacune des deux approches de test

En analysant chaque facteur dun contexte de test pm1iculier suivant ce guide (Tableau 71)

nous pouvons savoir si le contexte est favorable pour utiliser le TE agrave la place de la meacutethode

traditionnelle sceacutenariseacutee Ce guide tente de baliser une deacutemarche danalyse pouvant ecirctre

inteacutegreacutee agrave la reacuteflexion strateacutegique des entreprises pendant la seacutelection de [approche de test

Ainsi il pourrait aider agrave comprendre les apports et les besoins de TE ce qui va permettre

dassimiler et adopter lapproche

JJ1

Tableau 71 Le guide de seacutelection de lapproche de test

Facteurs Test sceacutenariseacute Test exploratoire

1 Caracteacuteristiques dutilisation

Les raisons La stabiliteacute de projet de Linstabiliteacute de projet de dutilisation deacuteveJoppement le besoin de deacuteveloppement labsence des

documenter et mesurer lactiviteacute eXlgences de test

Les caracteacuteristiques du logiciel

La taille du logiciel Les grands logiciels Les logiciels petits et moyens La complexiteacute du Plus approprieacute Deacutepend des compeacutetences logiciel existant dans le projet de test La criticiteacute du logiciel Exigeacute Ne devrait pas ecirctre utiliseacute

Le type Stable eacutevolutif sous contrat et Dynamique denvironnement nimporte quel environnement daffaire qui neacutecessite une documentation

deacutetailleacutee des tests Les ressources Ressources importantes Ressources raisonnables ou financiegraveres limiteacutees Le temps de test Temps consideacuterable requis Peu de temps requis disponible

2 Caracteacuteristiques de gestion

La planification Rigoureuse classique et cel1aine Adaptative continue non rigoureuse

Le controcircle et le suivi Mesurable Estimeacute de progression de test La relation avec le Souhaiteacutee Essentielle peut ameacuteliorer la client qualiteacute du test La communication Souhaiteacutee Essentielle la qualiteacute de test dans le projet de test effectueacute deacutepend de la qualiteacute de

communication existante dans le projet de test

3 Caracteacuteristiques techniques

Les activiteacutes de test Reacutepeacutetitives audi tables Creacuteatives adaptatives

Loracle de test Fixe deacuteriveacute agrave partir des Variable deacuteriveacute agrave partir des exigences du logiciel et les preacutevisions du testeur standards

Les risques du logiciel La couverture de tous les risques La couverture de tous les risques est assureacutee nest pas assureacutee

112

Facteurs Test sceacutenariseacute Test exploratoire

3 Caracteacuteristiques techniques

La couverture de test Mesureacutee Nest pas assureacutee ni mesureacutee

4 Caracteacuteristiques du personnel

Les caracteacuteristiques Testeurs compeacutetents et experts Nombre limiteacute dexperts et du testeur plusieurs non expeacuterimenteacutes La culture de Disciplineacutee Immature lorganisation

5 Productiviteacute

Le nombre des Moins productive que le TE Plus productive que le TS deacutefauts deacutetecteacutes Limportance des Moins importants que ceux qui Importants et critiques sil est deacutefauts deacutetecteacutes pourraient ecirctre deacutetecteacutes avec le exeacutecuteacute par des personnes

TE compeacutetentes

Or les facteurs identifieacutes nont pas tous le mecircme poids ni la mecircme importance dans le

contexte de test Nous avons constateacute dapregraves notre analyse comparative que la couve11urc de

test est le facteur le plus important dans le contexte de test Du fait que les autres facteurs

sont inter-relieacutes dune maniegravere ou dune autre avec la couverture du tes Aussi nous avons

constateacute que les qualifications et les compeacutetences existantes dans les projets de test pourraient

influencer le choix de lapproche de tes Alors dans les projets de test ougrave les qualifications

personnelles sont insuffisantes il apparaicirct difficile dutiliser le TE Nous pouvons conclure

que le TE pourrait remplacer Je TS dans nimporte quel projet de test ougrave le controcircle de la

couverture ne constitue pas une exigence et ougrave les compeacutetences ct les quaJificati~ns du

personnel aident agrave utiliser le TE

Pourtant il est difficile de cerner un contexte ougrave une seule approche de test palmi le TS et le

TE conviendrai Agrave cet effet nous croyons quune approche hybride peut convenir mieux ougrave

certaines parties du logiciel pourraient ecirctre testeacutees en utilisant le TS et dautres en utiJisantle

TE Ainsi la meacutethodologie de test pourrait beacuteneacuteficier des avantages de chacune des deux

approches

113

77 Conclusion

Au cours de ce chapitre nous avons compareacute et analyseacute les deux approches de test selon le

cadre comparatif de comparaison que nous avons eacutelaboreacute dans le chapitre preacuteceacutedent Nous

sommes revenues sur les reacutesultats de leacutetude empirique que nous avons meneacutee dans le cadre

de ce travail de recherche afin deacutevaluer empiriquement la productiviteacute de test exploratoire

en termes du nombre et de limportance de deacutefauts deacutetecteacutes Lanalyse comparative selon les

facteurs du cadre de comparaison nous a permis de ressortir les contextes favorables pour

utiliser le TE comme une meacutethodologie primaire de test agrave la place de la meacutethode sceacutenariseacutee

habituelle En terminant nous avons eacutelaboreacute un guide de seacutelection de lapproche dc test Ce

guide reacutecapitule les reacutesultats de lanalyse comparative et tente de baliser une deacutemarche

danalyse pouvant ecirctre inteacutegreacute agrave la reacuteflexion strateacutegique des entreprises pendant la seacutelection

de lapproche de test

CHAPITRE VIII

ANALYSE DES REacuteSULATS

Cc chapitre preacutesente une analyse des reacutesultats de lanalyse comparative preacutesenteacutee au chapitre

preacuteceacutedent et les reacutesultats de leacutetude empirique preacutesenteacutee dans le chapitre V Ce chapitre fait

aussi ressortir la contribution de leacutetude et les pistes potentielles de recherche

8] Analyse des reacutesultats theacuteoriques

Lanalyse comparative du TE et du TS que nous avons effectueacutee dans le chapitre preacuteceacutedent

nous a permis didentifier les facteurs de contexte pouvant influencer le choix de lapproche

de test Nous avons identifieacute comment chaque facteur sapplique dans le cadre de chacune

des deux approches Agrave cet effet nimporte quel contexte de test pourrait ecirctre analyseacute selon les

facteurs identifieacutes dans le guide de seacutelection de lapproche de test (tableau 71) Cela permet

de savoir a priori lapproche la plus approprieacutee aux besoins du contexte de test

Selon Copeland (2004) le TS pourrait ecirctre utiliseacute nimporte ougrave lobjectiviteacute la reacutepeacutetitiviteacute et

lauditabiliteacute sont neacutecessaires (Section 22) Bach (2003) a mentionneacute que le TE pourrait ecirctre

plus productif que le TS dans certaines situations Or ces situations nont pas eacuteteacute identifieacutees

dans aucune eacutetude Dans notre recherche nous avons eacutetudieacute ces situations dans Je cadre

dune analyse comparative theacuteorique et empirique entre le TE et le TS selon un cadre de

comparaison (figure5l) que nous avons deacuteveloppeacute afin de guider notre analyse comparative

des deux approches Par le biais de celle analyse comparative nous avons pu eacutetudier

identifier et analyser les contextes qui favorisant ladaptation et [utilisation de TE comme

une meacutethodologie indeacutependante de test Notre eacutetude a mis en eacutevidence que dautres facteurs

que ceux identifieacute par Copland (2004) pourraient favoriser lutilisation de TS Toutefois

] 15

nous avons constateacute que la couverture du test ct les qualifications et lexpertise des

personnels preacutesents dans le contcxte de test sont les deux facteurs les plus importants

La premiegravere contribution dc cette recherche est de preacutesenter un guide de seacutelection de

lapproche de test qui reacutecapitule tous les facteurs du contexte de test et comment ils

sappliquent dans le cadre du TS et du TE Ce guide pourrait ecirctre inclus dans la reacuteflexion

strateacutegique des entreprises pour seacutelectionner lapproche le mieux approprieacutee agrave nimporte quel

contexte de test li constituc aussi un outil denseignement de TE qui peut aider les eacutetudiants

agrave mieux comprendre et agrave mieux diffeacuterencier les contextes favorables pour utiliser chacune des

deux approches

82 Analyse des reacutesultats empiriques

Leacutevaluation empirique de la productiviteacute de TE na pas eacuteteacute bien abordeacutee dans les travaux de

recherches Bach (2003) a proposeacute les reacutesultats de ces expeacuteriences veacutecues comme preuves de

la productiviteacute du TE Les auteurs Jtkonen et Rautiainen (2005) ont collecteacute des donneacutees

quantitatives de TE de deux petites entreprises qui utilisent le TE comme une meacutethode

primaire de test Toutcfois ccs donneacutees ne sont pas fiables ni repreacutesentatives agrave cause de

labsence de donneacutees quantitatives de TS dans les deux cas qui pourraient ecirctre consideacutereacutees

comme reacutefeacuterence afin de prouver la productiviteacute de TE Labsence des eacutetudes empiriques

dans la litteacuterature nous a obligeacute agrave consideacuterer les reacutesultats dJtkonen et Rautiainen (2005) dans

notre eacutetude comparative

Loriginaliteacute de notre eacutetude empirique reacuteside dans la conception innovatrice que nous avons

choisie pour Jeffectuer Cette conception nous a permis deacutevaluer plusieurs aspects

o La productiviteacute de TE cn terme du nombre et de limportance des deacutefauts deacutetecteacutes

pendant lcxpeacuterience puis la comparaison des reacutesultats de lexpeacuterience avec les reacutesultats

rapporteacutes par les auteurs ltkonen et Rautiainen (2005)

o Lcffct dc la technique dc tcst (TE TS) sur la perfUumllmance des sujets pendant lactiviteacute

de test De cette faccedilon nous avons pu eacutevaluer la capaciteacute des sujets dexeacutecuter et de

116

reproduire les cas de tests dc la mecircme faccedilon preacutevue par le concepteur (lauteur ltle ce

travail) Cela nous a pennis dexplorer Jhypothegravese de Kaner et Bach (2005) qui cite que

le testeur dans le TS ne pourrait pas reproduire les cas de test de la mecircme faccedilon que leur

conceptcur Nous avons aussi pu explorer la deuxiegraveme hypothegravese de Kaner et Bach qui

cite que le TS empecircche le testeur dapercevoir dautres deacutefauts que ceux qui sont

documenteacutes dans le cas de test Ce pheacutenomegravene est connu dans le domaine de psychologie

sous le terme anglophone laquoInattentional Blindnessraquo (Mack et Rock 2000)

Lanalyse des reacutesultats recueillis de lexpeacuterience a montreacute que la moyenne des deacutefauts

deacutetecteacutes est de 95 dans une session de 45 minutes Cette moyenne est proche de eelle

proposeacutee par la reeherche des auteurs Itkonen et Rautiainen (2005) soit 87 dans une session

de 60 minutes

En ce qui concerne limportance des deacutefauts deacutetccteacutes par le TE nous avons conclu que plus

que la moitieacute des deacutefauts deacutetecteacutes ont eacuteteacute des deacutefauts graves tandis que les deacutefauts fatals ont

constitueacute 10 de total des deacutefauts deacutetccteacutes Les auteurs ltokens et Rautiainen (2005) ont

rapporteacute un pourcentage dc 15 des deacutefauts fatales deacutetecteacutes dans une session de 60 minutes

Ce pourcentage est proche de pourcentage que nous avons obtenu dans notre eacutetude

empirique si nous prenons en consideacuteration la diffeacuterence dans les programmes utiliseacutes Nous

avons aussi eacutetudieacute dans notre eacutetude empirique JinOuence de lexpertise de testeur sur les

reacutesultats de TE Agrave cet effet nous avons eacutetudieacute la relation entre le niveau de connaissance en

Java et Je nombre des deacutefauts deacutetecteacutes Notons que le niveau de connaissance en Java

repreacutesente dans notre eacutetudc empirique lcxpe11isc ct les qualifications de lexpeacuterimentateur

Alors les reacutesultats ont montreacute que la moyenne de deacutefauts deacutetecteacutes croicirct en fonction de niveau

de connaissance en Java

En ee qui concerne la productiviteacute du TE par rapport au TS nous avons conclu que le TE est

plus productif que le TS du fait que la performancc des sujets dans le TE a eacuteteacute supeacuterieure de

celle reacutealiseacutee dans le TS Par la suite nous avons conclu que le TE a un effet positif sur le

rendement des sujets en comparaison avec le TS Ces reacutesultats appuient les hypothegraveses de

117

Kancr ct Bach (2005) Toutcfois la limitation de contexte de leacutetude empirique a affaibli la

validiteacute externe des reacutesultats De ce fait ces reacutesultats ne pourront pas ecirctre geacuteneacuteraliseacutes

Les reacutesultats quantitatifs de cette eacutetude empirique all1S1 que sa conception constituent la

deuxiegraveme contribution de notre travail de recherche Nous pensions que les conclusions tireacutees

de cette eacutetude sont susceptibles de sappliquer dans des reacuteplications futures et les chercheurs

inteacuteresseacutes par leacutevaluation de la productiviteacute de TE empiriquement pourront reacuteutiliser notre

eacutetude empirique eomme eacutebauche pour leurs eacutetudes

83 Pistes potentielles de recherche

Le but de ee travail eacutetait deacutevaluer empiriquement la productiviteacute de TE et dexplorer les

contextes qui favorisent son utilisation agrave la place de la meacutethode sceacutenariseacutee habituelle Suite a

cette recherche plusieurs avenues meacuteriteraient decirctre approfondies

o Enrichir le guide de seacutelection de lapproche de test

Nous avons consideacutereacute dans le deacuteveloppement du guide de seacutelection de lapproche de test les

facteurs qui ont influenceacute les reacutesultats de lutiJisation de TE dans lindustrie Or avec la

croissance de ladoption et de ladaptation du TE par les entreprises dautres facteurs

pourront apparaicirctre Lessai de ce guide dans Jindustrie pourrait engendrer aussi des

feedbacks et des apports utiles Agrave cet effet il serait inteacuteressant de veacuterifier si dautres facteurs

peuvent sappliquer et venir enrichir le guide

o Reacuteplication de leacutetude empirique dans un contexte industriel

Le contexte acadeacutemique ou sest deacuterouleacute Jeacutetude empIrIque a influenceacute neacutegativement la

validiteacute externe de lexpeacuterience et a constitueacute sa limite majeure Pour deacutepasser cette limite il

serait inteacuteressant de reprendre leacutetude dans un contexte industriel en utilisant plusieurs projets

de test Ainsi leacutevaluation de la productiviteacute pourrait ecirctre faite sur deux eacutetapes pendant

lactiviteacute de test et apregraves lactiviteacute de test cest agrave dire dans Je site de production de chacun des

logiciels qui faisaient Jobjet de cette eacutetude

118

o Explorer Jinfluence de lexpertise et les connaissances du domaine sur la qualiteacute de

TE

Il serait inteacuteressant deacutetudier linfluence de lexpertise et les connaissances du domaine sur la

qualiteacute de TE effectueacute en termes du nombre des deacutefauts deacutetecteacutes et de limportance de ces

deacutefauts dans un contexte industriel en utilisant le nombre danneacutees dexpeacuterience dans le

domaine du test comme une meacutetrique de lexpertise

84 Conclusion

Au eours de ce chapitre nous avons effectueacute L1ne analyse et preacutesenteacute une discussion des

reacutesultats de notre recherche dans laquelle nous avons situeacute ses contributions au niveau

theacuteorique et empirique Par la suite nous avons preacutesenteacute des pistes de recherche futures dans

lesquelles nous avons identifieacute dautres probleacutematiques qui peuvent ecirctre utiles en vue

dinitier des travaux futurs de recherches

CONCLUSION

Nous avons eacutetudieacute dans ce travail deux approches de test du logiciel le test exploratoire (TE)

et le test sceacutenariseacute (TS) La partie theacuteoriquc de cc travail a eu comme but lexploration des

contextes du test ougrave le TE pourrait remplacer le TS et ecirctre utiliseacute comme une meacutethodologie

primaire du test La partie empirique a eu pour objectif leacutevaluation de la productiviteacute de TE

annonceacutee dans la litteacuterature

Apregraves la deacutefinition du sujet de recherche nous avons preacutesenteacute une vue densemble de TS et

de TE successivement Par la suite nous avons preacutesenteacute une revue de litteacuterature de quelques

eacutetudes de cas et expeacuteriences dutilisation de TE dans lindustrie du test Cest ainsi que nous

avons identifieacute les facteurs influenccedilant ladoption et ladaptation de TE dans la pratique du

test Par la suite nous avons preacutesenteacute les reacutesultats de leacutetude empirique que nous avons

meneacutec dans les laboratoires de lUQAgraveM Puis nous avons eacutelaboreacute un cadre conceptuel de

comparaison dans lequel nous avons identifieacute les dimensions principales de notre analyse

comparative de TE et TS Ce cadre pourra servir dans dautres eacutetudes compmatives des

approches du test

Lanalyse comparative reacutealiseacutee a permis de ressortir les facteurs contextuels favorables pour

utiliser chacune des deux approches du test Entre autres nous avons montreacute que le TE nest

pas approprieacute dans les projets de test neacutecessitant que la couverture de test soit mesureacutee

Aussi nous avons montreacute quc la deacutependance de TE agrave lexpertise et les qualifications du

testeur rend difficile son utilisation dans les contextes ougrave les qualifications ct les compeacutetences

du personnel sont insuffisantes Agrave cet effet Nous avons conclu que le TE pourrait remplacer

le TS dans nimporte quel projct de test ougrave le controcircle de la couverture ne constitue pas une

exigence etougrave les compeacutetences et les qualifications du personnel permettcnt dutiliser le TE

Notre eacutetude empirique a montreacute la productiviteacute de TE en tennes de nombre et Jimportance

des deacutefauts deacutetecteacutes Toutefois nous ne pouvons pas geacuteneacuteraliser les reacutesultats obtenus dans

120

cette eacutetude agrave cause de la limitation du contexte ou sest deacuterouleacute notre expeacuterience Agrave cet effet

nous reportons cette question agrave des travaux futurs de recherches de preacutefeacuterence dans des

contextes industriels

Au niveau pratique ce travail de recherche sinscrit dans un courant de preacuteoccupation des

entreprises qui ont agrave la recherche des meacutethodes du test plus efficaces qui pounaient sadapter

avec la culture rapide actuelle de deacuteveloppement du logiciel Il est agrave noter que cette eacutetude

constitue une ouverture sur le deacuteveloppement dun guide visant Jadaptation de TE dans

lindustrie du test Nous espeacuterons que le guide de seacutelection de Japproche de test aide les

entreprises et les praticiens agrave mieux choisir leur approche de test selon leur contexte du test

Nos objectifs personnels eacutetaient dexplorer les apports de TE et deacutevaluer sa productiviteacute

fortement mise de lavant par les praticiens de CDS Lanalyse comparative de TE ct le TS

nous a pousseacutee agrave approfondir nos connaissances dans Je domaine du test logiciel pour que

nous puissions identifier les apports et les lacunes de chacune des deux approches Ce travail

nous a permis de deacutecouvrir limportance de lactiviteacute du test dans le processus de

deacuteveloppement logiciel Cela nous a montreacute les diffeacuterents cocircteacutes de test du logiciel ses deacutefis

son cocircteacute quasi artistique matheacutematique et critique Bref nous avons trouveacute un autre domaine

dinteacuterecirct outre que la programmation et le deacuteveloppement

ANNEXE A

CADRE DE BASILI ADAPTEacute Agrave LA RECHERCHE EXPLORATOIRE

Les tableaux preacutesenteacutes dans celle annexe reacutecapitulent les phases du projet de recherche selon

le cadre de Basili agrave la recherche exploratoire adapteacute par Abran et al (J 999)

1 Deacutefinition Motivation Porteacutee Objectif Utilisateurs

J Explorer les Comparaison theacuteorique Reacutepondre agrave la question - Les chercheurs et apports de TE et empirique de TE et principale de recherche les praticiens

TS selon un proceacutedeacute Est-ce que le TE pourrait inteacuteresseacutes al eacutetude 2 Explorer de tesl boicircte noire remplacer Je test du TE lampleur de la sceacutenariseacute Si oui dans quel divergence enlre contexle - Les entreprises les deux vues deacutesirant mettre en

oeuvre ces 3Eacutevaluer la approches de test productiviteacute dc TE

4Eacutelaborer un guide de seacutelection de lapproche de test

122

2 Planification du projet Les eacutetapes Les intrants Les livrables

1 Proposer dun modegravele du La norme IEEE 829 - Un cadre conceptuel de processus de TS comparaison des approches

de test 2Eacutelaborer un cadre de comparaIson - Les reacutesultats quantitatifs de

leacutetude empirique 3 Faire leacutetude comparative empirique de TE et TS - Un guide deacutevaluation des

facteurs de contexte de projet 4 Faire leacutetude comparative de test pour le choix dune de TE et TS en se basant sur approche de test le cadre eacutelaboreacute et les reacutesultats empirique

5 Analyser et discuter des reacutesultats

3 Ooeacuteration Analyse des documents Feedback des Modegraveles proposeacutes

praticiens

1 Identifier les facteurs qui ont Cadre conceptuel de comparaison des influenceacute ladoption et ladaptation approches de test qui inclut les cinq de TE dans lindustrie dimensions agrave savoir

2 Analyser leacutetude comparative de 1 Les caracteacuteristiques dutilisations Boehm et Turner

2 Les caracteacuteristiques du logiciel agrave 3 Eacutetudier et analyser les tester connaissances theacuteoriques de test du logiciel 3 Les caracteacuteristiques de gestion

4 Eacutetudier et analyser les apports et 4 Les caracteacuteristiques du personnel les meacutecanismes de TE

5 La productiviteacute

Proposition dun guide de seacutelection de lapproche de test

]23

4 Interpreacutetation

Contexte dinterpreacutetation Extrapolation des reacutesultats Travaux futurs

) La comparaison theacuteorique - Les reacutesultats de Jeacutetude empirique sont - Reacuteplication de et empirique des deux limiteacutes Ils deacutependent du contexte leacutetude empirique et approches de test le TE et acadeacutemique ougrave sest deacuterouleacutee comparative de TE le TS a eacuteteacute reacutealiseacutee lexpeacuterience et TS dans un

environnement 2 Lanalyse comparative de - Lanalyse comparative entre le TE et le industriel TE et TS selon les facteurs TS est associeacutee au cadre de comparaison de notre cadre conceptuel de eacutelaboreacute dans ce travail de recherche et les - Leacutetude de comparaison a permis reacutesultats de leacutetude empirique Agrave cet linfluence des didentifier les contextes effet celte analyse est limiteacutee et en partie connaissances du favorables pour utiliser le subjective Elle deacutepend des domaine et TE agrave la place de TS connaissances et de Jexpeacuterience de lexpeliise de testeur

auteure dans le domaine de test du sur les reacutesu Ilats de 3 Lanalyse comparative a logiciel TE permis deacutelaborer un guide de seacutelection de lapproche - Lameacutelioration du de test guide de seacutelection de

lapproche de test 4 Cette recherche pourrait eacutelaboreacute dans ce contribuer agrave mieux travail de recherche comprendre le TE Elle facilite Jadoption de TE au sein des entreprises qui oeuvrent dans le domaine du deacuteveloppement

ANNEXEB

PLAN DE TEST IEEE829 (ADAPTEacute ET TRADUIT DE IEEE 8291998)

1 Identificateur de plan de test

bull Identificateur unique de document qui pourrait le distinguer des autres documents

2 Introduction

bull lintroduction pourrait inclure les paragraphes suivants

Description du logiciel sous test ce paragraphe donne un aperccedilu du logiciel

ses opeacuterations maintenance histoire son code ct toute autre information

pertinente

Une liste de reacutefeacuterences agrave dautres documents utiles pour la compreacutehension du

plan de test Selon la norme IEEE 829 les reacutefeacuterences aux documents

suivants sils existent doivent ecirctre mentionneacutees

o Autorisation du projet

o Plan du projet de deacuteveloppement

o Plan dassurance qualiteacute

o Plan de gestion de configuration

o Politique pertinente de la compagnie et du client

o Normes pertinentes de la compagnie du client ou de lindustrie

3 Items de test

bull Identifie les items agrave tester incluant leur versionniveau de reacutevision

125

4 Caracteacuteristiques agrave tester

bull Identifie les caracteacuteristiques agrave tester telles que fonctionnaliteacute performance seacutecuriteacute

portabiliteacute etc

5 Caracteacuteristiques qui ne doivent pas ecirctre testeacutees

bull Identifie les caracteacuteristiques qui nc vont pas ecirctre testeacutees ainsi les raisons de ce fait

6 Approche

bull Propose la strateacutegie globale de test afin dassurer gue tous les items et leurs

caracteacuteristiques seraient testeacutes adeacutequatement

7 Critegravere de passageeacutechec

Deacutefinit le critegravere de passage et deacutechec de test de chaque item

8 Critegravere de suspension et conditions de reprise

bull Deacutefinit les circonstances dans lesquelles le test pourrait ecirctre arrecircteacute ct les conditions

pour quil reprenne (deacutefauts critiques gui neacutecessitent la re-conception cnvironnement

de test incomplet etc)

9 Livrable du test

bull Identifie les documents de test ainsi que les autres livrables devant ecirctre produits au

cours du projet de test (ex speacutecifications de conception de test speacutecifications de cas

de test speacutecifications de proceacutedure de test registre de test rapport dincident de

tcst rappol1 de synthegravese de test matrice de traccedilabiliteacute etc)

10 Tacircche de test Identifie les tacircches de test et linterdeacutependance entre clics ainsi que la

dureacutee et les rcssources requises pour les accomplir

126

II Besoins environnementaux

bull Speacutecifie lenvironnement requis pour accomplir lactiviteacute de test incluant mateacuteriel

logiciel outils etc

12 Responsa biliteacutes

Identifie la responsabiliteacute ct la tacircche de chaque membre de [eacutequipe de test

13 Besoins en personnel et en formation

bull Les personnes et les qualifications neacutecessaires pour reacutealiser le plan

14 Calendrier

bull Speacutecifie les eacutetapes importantes dans le plan de projet de deacuteveloppement ainsi que les

items qui devraient ecirctre transmis agrave chaque eacutetape

15 Risques ct contingences

bull Identifie les risques qui peuvent empecirccher le suivi du plan et les mesures agrave prendre

pour les surmonter

16 Approbation

ANNEXE C

SOIREacuteE DE TESTS

Document remis aux participant(e)s

Lobjcctif premIer de cet exercIce est daugmenter votre niveau dexpeacuterience dans

Jexeacutecution de tests preacutepareacutes par dautres et dans le domaine des tcsts exploratoires Pour ce

faire vous uti liserez dabord jusquagrave 2000 lapproche des tests exploratoires agrave laide des

directives donneacutees dans la section suivante Dans la deuxiegraveme partie de la sOireacutee vous

exeacutecuterez des tests sceacutenariseacutes qui vous seront remis agrave 2000

Dans les dcux cas vous prendrez en note sur les formulaires ci-joints (voir Annexe D) les

deacutefauts que vous constaterez Par la suite vous compleacuteterez les rapports demandeacutes en

reacutepondant aux questions proposeacutees Toutes ces informations serviront de base agrave un travail de

maicirctrise sur les diffeacuterences entre le TE et le test sceacutenariseacute

Quelques directives et informations pour exeacutecuter le TE

Deacutefinition du programme

IJ sagit dun gestionnaire simple de messages Chaque message contient les informations

suivantes eacutemelleur destinataire sujet du message texte du message et une information

suppleacutementaire qui indique si le message a eacuteteacute lu ou non eacutelimineacute ou non Pour chaque

message le logiciel allribue un numeacutero automatiquement supeacuterieur agrave 100 Le programme

utilisc un tablcau de taille 10 pour geacuterer les messages Le programme doit afficher un

message un message derreur si on tente de geacuteneacuterer plus de 10 messages

Les directives agrave utiliser

Nous proposons cer1aines techniques qui peuvent vous aider dans vos tests exploratoires

128

Vous pouvez choisir une ou plusieurs de ces techniques Vous necirctes pas obligeacutes de les

appliquer strictement et vous avez toujours la possibiliteacute dintroduire vos propres techniques

Cependant rappelez-vous que le but de lexercice est de deacutecouvrir le plus possible de bogues

importants de faccedilon agrave ameacuteliorer la qualiteacute du logiciel

o Exeacutecution du programme en utilisant des donneacutees valides (parmi les choix afficheacutes

dans le menu principal) pour avoir une ideacutee sur ses fonctions et ses caracleacuteristiques

principales

o Suivez votre intuition et explorez le programme si vous avez une ideacutee sur les types

derreurs quil peut inclure

o Essayez de geacuteneacuterer des questions sur la capaciteacute du programme daccomplir certaines

fonctions que vous sont apparu essentielles mais toujours dans le cadre de la

description ci-dessus Essayez ensuite de transformer chaque queslion en un jeu

dessai (cas de test)

o Geacuteneacuterez diffeacuterents sceacutenarios dutilisation de logiciel Ensuite essayez dexplorer les

aspects de vos sceacutenarios par exemple utilisez diffeacuterentes valeurs dentreacutee surtout

les valeurs extrecircmes (limites) pour le mecircme sceacutenario

o Veacuterifiez les messages derreurs du programme autrement dit veacuterifiez sils se

deacuteclenchent au bon moment et sous les bonnes conditions

o Choisissez une variable puis essayez de tracer son flux dans le programme Les

meacutethodes quellcs lutilisent ainsi que ses interactions avec dautres variables

Ensuite utilisez ces informations pour interfeacuterer avec la variable

o Choisissez une tacircche parmi les fonctionnaliteacutes du programme et essayez de deacutecrire

eacutetape par eacutetape comment elle est accomplie et manipuleacutee dans le logiciel puis essayez

dimproviser et de concevoir des techniques pour la tester (par exemple en utilisant

des valeurs dentreacutees qui peuvent pousser la fonction dans dautres chemins)

o Utilisez un diagramme deacutetats pour deacutecrire les diffeacuterentes actions et transitions que

129

lapplication peut prendre pour toutes les entreacutees possibles Essayez ensuite de

trouver les contradictions dans Je modegravele

La proceacutedure

bull Le travail doit ecirctre fait individuellement et aucun contact avec un(e) autre eacutetudiant(e)

nest permis durant toute lactiviteacute de test

bull Notez Jheure de deacutebut et de fin de vos tests exploratoire

bull Durant votre activiteacute de test agrave chaque fois que vous trouvez un bogue inscrivez les

informations demandeacutees dans la liste que vous a eacuteteacute remise Vous devez deacutecrire en

deacutetail lerreur Vous devez deacutecrire briegravevement comment vous avez reacutealiseacute quil sagit

dune eueur par exemple labsence dun menu ou changement dans la valeur de

sortie preacutevue etc Vous devez aussi classer lerreur selon sa graviteacute Ces

informations sont aussi donneacutees avec Je fonnulaire dinscription des deacutefectuositeacutes

ANNEXE D

RAPPORT DE LA SESSION DE TEST

Nom de leacutetudiant(e)

bull Comment eacutevaluez-vous vos connaissances en Java

Niveau Jamais vu Introduction Intermeacutediaire Avanceacute Expeacuterimenteacute

Estimation

bull Classification

On classifie la seacuteveacuteriteacute des erreurs en trois niveaux

o Fatale (F) Japplication est inopeacuterable complegravetement (Crash)

o Grave (G) lapplication fonctionne mais certaines fonctions sont inopeacuterables ou certains reacutesultats sont erroneacutes

o Mineure (M) limpact est mineur sur Jutilisation du systegraveme ex certains formats sont erroneacutes bien que les reacutesultats soient corrects ou encore les deacutelais sont supeacuterieurs agrave ce quon attend dune telle application

Noubliez pas de prendre des notes sur les techniques dexploration que vous utilisez

Description de lerreur Classification

REacuteFEacuteRENCES

Abran Alain Lucie Laframboise et Pierre Bourque 1999 laquo A Risk Assessment Method and Grid for Software Engineering Measurement Programsraquo Montreacuteal Universiteacute du Queacutebec agrave Montreacuteal

Amland Stale et Jarle Vaga 2002 laquo Managing High Speed Web Testing raquo In Software Quality and Software Testing in Internet Times sous la dir de Meyerhoff Dirk Begona Laibarra Rob Van Der Pouw Kraan et Alan Wallet P 23-30 Berlin Springcr

Amland Stale 2002a laquoExploralory Testing Planning Execution and Documentationraquo Version (120) wwwtestingeducationorg

Amland Stale 2002b laquoExploratory Testing Stylesraquo Version (120) wwwtestingeducationorg

Bach James 2007 laquoRapid Software Testing raquo Version (132) wwvvsatisficccom

Bach James et Jonathan Bach 2006 laquoExploratory Testing Dynamics raquo Version 16

Bach James 2003 laquoExploratory Testing Explained raquoVersion (13)

Bach James Bret Pettichord ct Cem Kaner 2002 Lessons Learned in Sofiware Testing New York Johon Wiley amp Sons

Bach James 2001 laquoExploratory Testing and Planning Mythraquo (StickymindsCom) 19 mars

Bach James 1999 laquoGeneral Functionality and Stability Test Procedureraquo wwwsatisficecom

Bach James J996 laquoHeuristic Test Strategy Moderaquo wwwsntisficccom

Bach Jonathan 2000 laquo Session Bascd Test Management raquo SofilVare Testing and Quality Engineering novembre

Basili Victor Richard Selby ct David Hutchens J986 laquoExperimentation in Software Engineeringraquo IEEE Transactions on software engineering vol J 2 no 7 p 733-743

J32

Beedle Mike et al 200 J laquoManifesto for Agi le Software Developmentraquo Consulteacute janvier 2007 httpagilemanifcstoorg

Black Rex 1999 Managing the Testing Process Redmond (Wachington) Microsoft Press

Beizer Boris 1995 Black Box Testing Techniques for Functional Testing of Software and Systems New York Johon Wiley amp Sons

Beizer Boris 1990 Software Testing Techniques 2 eeacuted New York Van Nostrand Reinhold

Boehm Barry W et Richard Turner 2004 Baancing Agility and Discipline Boston Addison-Wesley

Boehm Barry W 198 1Software Engineering Economics Upper Sadd le River (NJ) Prentice-Hall

Bolton Michael James Bach et Cem Kaner 2005 laquo Rapid Testing ExpJained raquo International Quality Conference 200SToronto octobre

Copeland Lee 2004 A Practitioners Guide 10 Software Tesl Design Boston Artcch HOllse Publ ishers

Craig Rick et Stefan Jaskiel 2002 Systematic Sojiware Tesling Boston Artech Housc Publishers

Hendriekson Elizabeth 2005 laquo Agile Testing raquo Video de Googlc wwwgooglecom

Hetzel William C1988 The Campete Guide la Sojiware Tesling 2 C eacuted New York Johon WiJeyamp Sons

Hoffman Douglas 1999 laquoHeuristie Test Oraclesraquo Sofiware Testing and Quairy Engineering marsavril wwwsoftwnrequalitymcthodscomPapersSTOE20Heuristicpdf

ltkonen Juha et Kristian Rautiainen 2005 laquo Exploratory Testing A Multiple Case Studyraquo Empirica Software Engineering 2005 1l1lernationa Symposium novembre

1EEE829 1998 Standardfor Soflware Test Documentotion New York IEEE press

lEEE729 1983 laquolEEE Computer Society 1EEE Standard Glossary of Software Engineering TerminoJogyraquo

133

JEEE610 1990 laquoIEEE Standard Glossary of Software Engineering TerminologyraquoJEEE STD6102

James David et Bill Wood 2003 laquoApplying Session Based Testing to Medical Softwareraquo Medical Deviceamp Dignostic lndustry mai

Jones TCapers 1998 Estimating Software Costs New York McGraw-Hill pSS4

Kan Parrish et Manlove 2001 laquoIn-process Metrics for Software Testingraquo IBM Systems Journa vol 40 no 01

Kaner Cern 2006 laquoExploratory Testing after 23 Yearsraquo Conference of the Association for Software Testing Indianapolis (US) wwwTestingeducationcom

Kaner Cern et James Bach 2005 laquo Scripting An Jndustry Worst Practice raquo Back Box Testing Course wwwTestingeducationcom

Kaner Cern 2004 laquoThe Ongoing Revolution in Software Teslingraquo Software Test amp Performance Conference (Baltimore MD 7-9 deacutecembre 2004) wwwTcstingeducationcom

Kaner Cern et James Bach 2004 laquoThe Nature of Exploratory Teslingraquo Software Tesling Day University Tampere Finland consulteacute le 15012007

Kaner Cern 2003 laquoWhat is a Good Test Case raquo STarEast Conference May 2003 httpwwwkanercompdfsGoodTestpdf

Kaner Cern et Andy Tinkham 2003a laquoExploring Exploratory Testingraquo STarEast Conference on Software Testing Analysis and Review (Orlando FL May 12-16 2003)

Kaner Cern et Andy Tinkham 2003b laquoLearning Style and Exploratory Testingraquo Pacifie Northwest Software Quality Conference (Portland OR October 13- J 52003)

Kaner Cern Jack Falk ct Hung Quoc Nguyen 1999 Testing Computer Sojiware 2 e eacuted New York John Wiley and Sons

Kaner Cern 1997 laquo The lmpossibiity of Complete teting raquo Low of Sofiware Quairy Coumn Software QA vol 04 no 04 hltpvwwkancrcompdfslimposspdf

Kaner Cem1996 laquoSoftware Negligence and Testing Coverageraquo Sofiware QA quartery vol 02 no 03 p 18 httpwwwkanercomcovcragchtm

Kaner Cern 1988 Testing Computer Sojiware 1 erceacutedi New York McGraw-Hill

Kohl Jonathan 2005 laquoExploratory Tesling on Agile Teamsraquo InformitCom 18 Novembre httpwwwinformitcomartielcs

134

Lindsay James et Neil Van Eeden 2003 laquoAd ventures in Session Based Testingraquo Version 12 hltplwwwworkroom-productionscomlpapcrsAiSBTv 12pdf

Lott Christopher et Rombach Dieter J997 laquo Repeatable software engineering experiments for comparing defect detection techniquesraquo Empirical Software Engineering vol 0 l no 03 p241-277

Mack Arien et Irvin Rock 2000 laquoInaltentional Blindnessraquo Cambridge (MA) Bradford BooksMIT press

Marick Brian 2003 laquo Agile Methods and Agile Testing raquoSoftware Testing and Quality Engineering vol 03 no 05

Myers Glenford J 1979 The Art ofSoftware Testing 1 ere eacutedi New York Johon Wiley

Osterweil Leon 1996 laquoStrategie directions in software quality raquo ACM Computing SUIveys vol 04 no 04

Perry William E 2000 Effective Methodsfor Software Testing 2 C eacutedi Johon WiJey and Sons

Petty Kenn 2005 laquoReflections on the Use of Session Based Exploratory Testing as the Primary Test Methodology for Software in an Agile Environmentraquo lndianapolis Workshops on Software Testing hltpwwwiwst2007comlimagcsRefleelions on the use of SessionshyBased Exploratory Tcsting in an_ Agile _Environmcntdoc

Pettichord Brel 2002 laquoAgile testing What is it Can it work raquo Consulteacute Janvier 2007 wwwPeltichordcom

Pressman Roger 1997 Software Engineering A Practitioner s Approach 4 Ceacutedi New York MeGraw-Hill

Pyhajarvi Maarct KJistian Rautiainen ct Juha ltkonen 2003 laquolncreasing understanding of the modern testing perspective in software product development projects raquo IEEE Computer Society Proceedings of the Hawaii International Conference on System Sciences

Royce Wiston J 970 laquoManaginw the Development of Large Software Systems Concepts and Techniquesraquo Reprinted in 9 International Conference in Software Engineering Los1

Alamitos (CA) IEEE Computer Society Press p 328-338

SWEBOK 2004 laquo Guide to the Software Engineering Body of Knowledge raquo IEEE Computer Society Version 2004 httpwWvswcbokorg

13S

Thompson Neil 2003 laquoBest Practices and Context-Driven Building a Bridgeraquo International Conference on Software Testing Analysis and Review StarEast FJorida StickyMinds Magazine

Whittaker James A 2003 How to Break softwaremiddot A Practica Guide to Testing Boston Addison Wisely

Winer Ben James 1971 Statistica Principes in Experimental Design 2 e eacutedi New York McGraw Hill

Wood Murray Marc Roper Andrew Brooks et James Miller 1997 laquo Comparing and Combining Software Defect Detection Techniques A Replicated Empirical Study raquo ACM SIGSOFT Proceeding on the Foundations of Software Engineering NdegS Zurich SUISSE (22091997) vol 22 no 6 New York Springer-Verlag (ACM Press)

VI

713 Le type denvironnement daffaire 87

7IA Les ressources financiegraveres 88

715 Le temps de test disponible 89

72 COMPARAISON SELON LES CARACTEacuteRIST1QUES DE GESTION 91

721 La planification 91

722 Le controcircle et le suivi de progression de test 93

723 La communication dans le projet de test 94

72A La relation avec le client 96

73 COMPARAISON SELON lES CARACTEacuteRISTIQUES TeCHNIQUES 96

731 Les activiteacutes de test 97

732 Les risques du logiciel 100

733 La couverture de test 102

734 Loracle de test 103

74 COMPARAISON SELON LES CARACTEacuteRISTIQUES DU PeRSONNEL 106

7AI Les carateacuteristiques du testeur 106

75 COMPARAISON SELON lA PRODUCTIVITEacute 108

77 CONClUSiON 113

CHAPITRE VIII 114

ANALYSE DES REacuteSULATS 114

81 ANALYSE DES RESULTATS THEORIQUeS 114

82 ANALYSE DES REacuteSULTATS EMPIRIQUES 115

83 PISTES POTENTIELLES DE RECHERCHE 117

8A CONCLUSION ] 18

CONCLUSION 119

ANNEXE A 121

CADRE DE BASILI ADAPTEacute Agrave LA RECHERCHE EXPLORA TUumlIRE 121

ANNEXE B 124

vu

PLAN DE TEST IEEE829 124

ANNEXE C 127

SOIREacuteE DE TESTS 127

ANNEXE D 130

RAPPORT DE LA SESSION DE TEST 130

REacuteFEacuteRENCES ~ 131

YJJI

LISTE DES TABLEAUX

Tableau 11 Cadre de Basili adapteacute agrave la recherche exploratoil-e 7

Tableau 21 La matrice de traccedilabiliteacute 25

Tableau 31 Grille des tacircches de test exploratoire 34

Tableau 51 ANOVA des donneacutees collecteacutees de lexpeacuterience 73

Tableau 71 Le guide de seacutelection de lapproche de test III

IX

LISTE DES FIGURES

Figure 21 Le pourcentage des erreurs danalyse et de conception 17

Figure 22 Modegravele de test en V 18

Figure 23 Les pratiques de test Agile 20

Figure 24 Scheacutematisation des documents de preacuteparation de tests 22

Figure 25 Speacutecification de Cas de Test 26

Figure 31 Continuum repeacuterant lactiviteacute de test 33

Figure 32 Cadre dapplication de SBTM 37

Figure 33 Heuristic Test Strategy Model 40

Figure 41 Coucirct de documentation versus linnovation dans le test 55

Figure 52 Le traitement de test exploratoire 66

Figure 53 Les reacutesultats de test exploratoire 67

Figure 54 Importance de deacutefauts deacutetecteacutes avec le test exploratoire 68

Figure 55 LinOuence de lexpertise su r le test exploratoire 70

Figure 56 Reacutesultats des sujets aux TE ct TS 71

Figure 57 Repreacutesentation scheacutematique de lanalyse ANOVA 72

Figure 61 Le cadre conceptuel de comparaison 80

Figure 71 Les eacuteleacutements essentiels du test du logiciel 97

Figure 72 Les activiteacutes de test sceacutenariseacute 98

Figure 73 Les activiteacutes de test exploratoire 99

x

LISTE DES ABREacuteVIATIONS

COS Context Driven School

Institute ofElectrical and Electronics IEEE

Enginecrs

SBET Session Based Exploratory Testing

SBTM Session Based Test Management

SWEBOK Software Engineering Body ofKnowledge

UQAgraveM Universiteacute du Queacutebec Agrave Monlreacuteal

TE Test exploratoire

TS Test sceacutenariseacute

Xl

REacuteSUMEacute

Le test exploratoire (TE) est deacutefini comme lapprentissage la conception et jexeacutecution simultaneacutes des tests tout agrave fait lopposeacute du test sceacutenariseacute (TS) preacutedeacutefini Lapplicabiliteacute de cette nouvelle approche ne cesse pas daugmenter dans lindustrie du test de logiciel Malgreacute cette expansion et le succegraves de quelques entreprises qui souvrent dans le domaine de deacuteveloppement du logiciel dans ses expeacuteriences dadoption et dutilisation de TE les contextes et les facteurs favorables pour ladoption de lapproche dans une meacutethodologie de test ne sont pas toujours bien eacutetablis Labsence des preuves claires de sa productiviteacute annonceacutee par quelques praticiens dans la litteacuterature sajoute agrave la probleacutematique Ce travail est une eacutetude exploratoire visant deux objectifs Premiegraverement eacutetudier et analyser les contextes favorisant lutilisation de TE comme une meacutethodologie primaire de test agrave la place des tests sceacutenariseacutes en eacutelaborant une analyse comparative entre le TE et le TS Deuxiegravemement eacutevaluer sa productiviteacute dans une eacutetude empirique par rapport au TS Nous avons eacutelaboreacute un cadre conceptuel de comparaison dans lequel nous avons identifieacute cinq dimcnsions o Les caracteacuteristiques dutilisation les raisons de lutilisation les caracteacuteristiques du

logiciel le type denvironnement daffaires les ressources financiegraveres et le temps disponible pour les tests

o Les caracteacuteristiques de gestion la planifIcation le controcircle ct le suivi des tcsts la communication dans le projet de test ct la relation avec le client

o Les caracteacuteristiques techniques les activiteacutes de test joracle de test les nsques du logiciel ct la couverture de test

o Les caracteacuteristiques du personnel les caracteacuteristiques des testeurs la culture de lorganisation

o La productiviteacute le nombrc de deacutefagraveuts deacutetecteacutes limportance de deacutefauts deacutetecteacutes

Cc cadre a eacuteteacute utiliseacute comme base dans Janalyse comparative du TE et du TS Dans cette analyse nous avons compareacute une approche disciplineacutee de TS guideacute par les patrons de documentation IEEE 829 ct une approche librc scmi planifieacutee de TE rcpreacutesenteacutec par lapproche Session Based Exploratory Testing (SI3ET) Dans cette comparaison la productiviteacute a eacuteteacute eacutevalueacutee par le biais dunc eacutetudc cmpirique que nous avons mise en œuvre dans les laboratoires informatiques de LUQAgraveM Malgreacute les limites du contexte de cette eacutetude empirique nous avons pu deacutegager quelques conclusions utiles Les reacutesultats permettent de montrer que certains facteurs de contexte du projet de test peuvent empecirccher lutilisation de TE comme une meacutethode principale de test Nous avons conclu que labsence de controcircle de couverture de test restreint en plus le type des projets ougrave le TE pourrait ecirctre utiliseacute Aussi lexpertise ct les qualifications neacutecessaires pour exeacutecuter le TE pourraient cmpecirccher son utilisation dans les projets de tests ougrave ces qualifications sont manquantes Les reacutesultats de jeacutetude empirique ont supporteacute lhypothegravese relative agrave limportance des deacutefauts deacutetecteacutes Dautres recherches quantitatives sur la productiviteacute de TE sont neacutecessaires dont ce travail pourra servir comme point de deacutepart

Mots-cleacutes

Test Test seeacutenariseacute Test exploratoire Session Based Exploratory Test (SBET)

INTRODUCTION

La croissance rapide de jutilisation des systegravemes infonnatiseacutes dans tous les domaines donne

une importance cruciale au problegraveme des anomalies informatiques De nos jours les

ordinateurs aident les humains dans la plupart des aspects de notre vie quotidienne et les

applications informatiques sont rendues plus puissantes et complexes Agrave cet effet

limportance de produire du logiciel de grande qualiteacute et robuste est devenue primordiale

(Osterweil 1996) Or la forte demande de produits logiciels de qualiteacute fait que les

organisations sont en quecircte continuelle de moyens pouvant leur permettre de produire de la

qualiteacute dans les temps ct dans le cadre du budget Un des moyens est Je test du logiciel

Dans les modegraveles traditionnels de deacuteveloppcment le test est un processus important II

soutient Jassurance qualiteacute en fournissant dcs informations sur la qualiteacute du logiciel

deacuteveloppeacute ou modi fieacute Lactiviteacute de test dans ces modegraveles est extrecircmement laborieuse et

demande des ressources importantes allant de 50 agrave 60 du eoucirct de deacuteveloppement (Perry

2000) Cependant la concurrencc sans ccsse croissante oblige les entreprises agrave sadapter aux

changements du marcheacute dans des cycles de deacuteveloppement plus courts Tester un logiciel

dans telles conditions nest plus une tacircche facile seffectue souvent sous la pression de temps

ct de budget Cela force lindustrie informatique agrave chercher de nouvelles meacutethodes efficaces

de test pour eacutepargner temps el argcnt et en produisant des logiciels de qualiteacute

Une nouvelle pratique dc test qui a fait son apparition a la fin des anneacutees 80 avait remis en

eause la vision traditionnelle des tests Cette pratique se deacutefinit comme lapprentissage la

conception ct lexeacutecution simultaneacutee des tests Cette derniegravere est tout agrave fait lopposeacute de la

meacutethode habituelle et sceacutenariseacutee de test neacutecessitant la speacutecification des cas de tests deacutetailleacutes

et des reacutesultats preacutevus avant jcxeacutecution de tests

2

Au deacutebut cette nouvelle pratique a eacuteteacute confondue avec le test ad hoc qui est trop souvent le

synonyme dun processus improviseacute intuitif pour chercher les deacutefauts du logiciel (Bach

2003) En 1990 un groupe dexperts en tests connu sous le nom anglophone Context Driven

School (CDS) laquo Test piloteacute par le contexteraquo a adopteacute le terme anglophone Exploratory

Testing laquo test exploratoireraquo pour deacutecrire et nommer cc type de test qui est deacutecrit dabord par

Kaner ( 1988)

Depuis son apparition le test exploratoire (TE) a eacuteteacute preacutesenteacute comme une innovation dans

lindustrie du test Une innovation pouvant garantir un niveau defficaciteacute de lactiviteacute de test

qui ne pourrait pas ecirctre reacutealiseacute par le test sceacutenariseacute seul (TS) (Bach 2003 Kaner et Tinkham

2003a) Cependant quelques praticiens ne le voient pas de la mecircme faccedilon et considegraverent le

TE comme un test ad hoc deacuteguiseacute ou enveloppeacute sous le terme scientifique laquo explorationraquo

(Black 1999) Bach (2003) ne nie pas le fait que le TE est une pratique habituelle utiliseacutee

souvent inconsciemment par nimporte quel testeur qui utilise sa creacuteativiteacute pendant lactiviteacute

de test Linnovation de lapproche selon lui est dameacuteliorer la faccedilon avec laquelle ce testeur

effectue ses tests en se basant sur des techniques ct des modegraveles scientifiques dexplorations

Agrave cet efrct les praticiens ct les chercheurs se sont pencheacutes sur lameacutelioration de ces

techniques dans le but de faire du TE une discipline apprise comme nimporte quelle activiteacute

intellectuelle Enfin avec la tendance actuelle des meacutethodes agiles le TE a pu trouver sa

place dans Jindustrie du test (Bach 2003) Les laquo agilistesraquo ont adopteacute le TE compte tenu de

sa grande capaciteacute dadaptation avec les pratiques agiles (Kohl 2005)

Les grandes organisations de deacuteveloppement du logiciel ont commenceacute agrave consideacuterer le TE

comme une approche valide de test Microsoft a utiliseacute un type structureacute et documenteacute de TE

impleacutementeacute par Bach (1999) pour tester et certifier une application pour la compatibiliteacute et la

stabiliteacute avec Windows 2000 Dautres entreprises sajoutent continuellement parce quelles

cherchent des meacutethodes plus rentables de test Toutefois chacune delles adopte lapproche

dune faccedilon personnaliseacutee avec les contraintes de son contexte

Malgreacute le succegraves obtenu par quelques entreprises dans limplantation de TE les contextes

favorables pour uti liser et impleacutementer lapproche ne sont pas encore bien eacutetablis dans la

3

litteacuterature Nous nous sommes fixeacute comme objectif dans ce travail de recherche agrave explorer

ces contextes en analysant les eacutetudes de cas et les expeacuteriences professionnelles publieacutees

reacutecemment Nous avons proceacutedeacute agrave une analyse comparative entre les deux approches de test

le TS et TE pour faire ressortir les facteurs favorables pour utiliser chacune delles

Nous avons proceacutedeacute aussi agrave une eacutetude empirique dc la productiviteacute de TE annonceacutee dans la

litteacuterature surtout par les deux concepteurs de lapproche (Bach 2003 Bach et Kaner

2004) Nous avons eacutevalueacute la productiviteacute de lapproche en termes du nombre et de

limportance des deacutefauts quelle peut deacutetecter Malhcureuscment les limites de contexte ougrave

sest deacuterouleacute notre eacutetude empirique ne nous a pas permis de tirer des conclusions fiables et

geacuteneacuteraliseacutees sur cette productiviteacute Cependant nous avons pu deacutegager quelques indications

utiles

Dans la reacutealisation de ce travail de recherche nous avons ducirc confronter le problegraveme de la

peacutenurie des travaux de recherches ct de la litteacuterature qui traite Je sujct de TE Malgreacute que

cette approche ait eacuteteacute introduitc dans le domaine de test logiciel il y a plus dc vingt ans elle

na pu que reacutecemment attirer linteacuterecirct des chercheurs autres que les membres de CDS

(ltkonen ct Rautiainen 200S)Labsence des connaissances agrave ce sujet nous a obligeacutee agrave avoir

recours agrave notre jugement dans cette analyse comparative cn sappuyant sur notre

compreacutehension de tous les eacuteleacutements relieacutes agrave lactiviteacute de test Notre approche a eacuteteacute de

sappuyer sur la litteacuterature ainsi que sur divers concepts theacuteoriques

Dans le cadre de cette recherchc nous proceacutedons par une eacutetude cxploratoire pUisque les

connaissances dans le domaine que nous traitons dans cc travail de recherche ne sont pas

encore bien eacutetablies

Ce meacutemoire est composeacute de huit chapitres Dans le chapitre l nous deacutefinirons notre sujet de

recherche la probleacutematiquc la motivation la porteacutee lobjectif les utilisateurs ct les limites

du projet selon la meacutethode de (Abran ct al J 999) que nous avons adopteacutee pour la mise en

œuvre de cc travail de recherche Dans le chapitre Il nous preacutesenterons une vue densemble

de TS afin didentifier ses eacuteleacutemcnts fondamentaux ct de comprendre ses points de diffeacuterence

4

avec le TE Dans le chapitre Ill nous preacutesenterons une vue densemble de TE Puis dans le

chapitre IV nous proposerons une revue de litteacuterature de quelques eacutetudes de cas et

expeacuteriences dutilisation de TE dans lindustrie de test Le chapitre suivant deacutecrit leacutetude

empirique que nous avons meneacutee en laboratoire Nous preacutesenterons dans le chapitre VI le

cadre conceptuel de comparaison que nous avons deacuteveloppeacute dans le cadre de notre recherche

Le chapitre VlI preacutesentera notre analyse comparative de TE et TS Nous preacutesenterons des

suggestions et les contextes favorables pour utiliser le TE comme unc meacutethodologie primaire

de test Le dernier chapitre porte essentiellement sur les reacutesultats danalyse linterpreacutetation

de ces reacutesultats et les perspectives futures de recherche Enfin nous terminerons notre rapport

avec une conclusion

11

CHAPITRE 1

DEacuteFINITION DU SUJET DE RECHERCHE

Eacutenonceacute de la probleacutematique

Lapparition de test exploratoire (TE) dans le domaine du test du logiciel a susciteacute beaucoup

de controverse quant agrave sa validiteacute et agrave son efficaciteacute Pour certains praticiens le test

exploratoire est toujours le test ad hoc deacuteguiseacute sous le terme scientifique laquoexplorationraquo

(Black 1999) Selon Black (1999) Ic TE ne diffegravere pas de la technique laquo Error Guessing raquo

proposeacutee par Myers (l97) qui a toute fois preacuteciseacute quil ne sagit pas dune technique de test

mais seulement de lintuition Selon Bach (2003) le TE est une approche valide de test tout

comme le test sceacutenariseacute (TS) et il pourrait ecirctre dans certaines situations plus productif que le

TS La diffeacuterence sur la reconnaissance ct la valeur de TE qui est le chef dœuvre ct

linvention de la penseacutee Context Oriven School (CDS) a lanceacute un deacutebat entre les intervenants

preacuteconisant les principes de cette eacutecole de penseacutee ct les adheacuterents de la discipline

La philosophie de la penseacutee CDS est deacutetablir une relation consciente explicable et

autocritique entre le processus de test et le contexte de test Autrement dit le testeur devrait

ajuster ses solutions convenablement au problegraveme courant et ecirctre capable de controcircler son

processus de test ct dapporter des changements au moment voulu pendant le processus En

2001 les trois membres fondateurs de CDS Kaner Bach et Pettichord ont formuleacute les sept

principes cleacutes de leur discipline ct ils les ont publieacutes dans le premier livre portant sur les

pratiques et les ideacutees de ce groupe (Bach et al 2002) Il sagit des principes deacutecrits cishy

dessous (traduit de Bach et al 2002 p 261)

bull La valeur de nimporte quelle pratique deacutepend de son contexte

bull li ya de bonnes pratiques dans un contexte mais il ny a aucune mei Ileure pratique

6

bull Des personnes qui collaborent entre elles sont les parties les plus importantes de

nimporte quel contexte de projet de test

bull Les projets se deacuteroulent souvent dune maniegravere impreacutevisible

bull Le produit est une solution agrave un problegraveme Si le problegraveme nest pas reacutesolu le produit ne

pourra pas fonctionner

bull Un bon test logiciel est un processus intellectuel comportant plusieurs deacutefis

bull Seulement par les compeacutetences qui sexercent dune faccedilon coopeacuterative dans tout le

projet nous sommes capables de prendre les bonnes deacutecisions au bon moment pour

tester efficacement le produit

Par contre la discipline met laccent sur des principes diffeacuterents de ceux citeacutes ci-dessus

Entre autres la normalisation la documentation et le formalisme du processus constituent les

eacuteleacutements clefs du processus de test (Thompson 2003) Alors il ressort des principes de deux

eacutecoles que le CDS accentue le rocircle de la personne ses qualifications et la collaboration entre

les intervenants dans le projet de test tandis que la discipline accentue le rocircle du processus

sa gestion et sa mesure dans le projet de test En dautres telmes Ic test devrait ecirctre

preacutedictible enchacircsseacute dans un cadre de travail planifieacute et documenteacute dont la norme de

documentation IEEE 829 pourrait constituer une partie inteacutegrante (Swebok 2004)

Les deacutefenseurs des deux approches de test le TS et le TE ont lanceacute un deacutebat qui oppose le

formel contre jinformel les proceacutedures contre la liberteacute luniformiteacute contre la creacuteativiteacute et le

controcircle contre lefficaciteacute Les auteurs ct les praticiens de CDS annoncent quc le TE est une

approche productive qui pourrait constituer une meacutethode principale ct indeacutependante de test

(Bach 2003 Kaner 2006) Toutefois ces mecircmes praticiens nont pas identifieacute les contextes

favorables dutilisation de TE

De plus ils nont pas proposeacute des preuves concregravetes de sa productiviteacute largement annonceacutee

dans la litteacuterature agrave part quelques anecdotes et expeacuteriences veacutecues eacutelaboreacutees dans dcs

contextes personnels (Bach 2003)

7

12 Meacutethode de recherche

Dans le cadre de cette recherche exploratoire la deacutemarche meacutethodologique suivie est baseacutee

sur le cadre de Basili (Abran et al 1999) adapteacute aux eacutetudes de cas de type exploratoire Ce

travail est inclus sous le thegraveme de recherche exploratoire compte tenu du fait que les

problegravemes souleveacutes sont peu abordeacutes dans la litteacuterature Nous essayons de clarifier la base de

connaissances sur le TE et de trouver des pistes futures de recherche

Le cadre proposeacute est composeacute de quatre eacutetapes principales la deacutefinition la planification

lopeacuteration et linterpreacutetation Chaque phase deacutecrit les activiteacutes etou les livrables agrave

entreprendre afin datteindre les objectives de celle recherche Un modegravele de ce cadre est

preacutesenteacute dans le tableau 11 La deacutefinition du projet est preacutesenteacutee dans la scction qui suit La

structure suivie dans ce travail de recherche est proposeacutee dans lannexe A

Tableau 11 Cadre de Basili adapteacute agrave la recherche exploratoire (Abran ct al 1999)

1 Deacutelinition

Motivation Objet Objectif Utilisateurs

2 Planification

Etapes du projet Inlrants Livrables du projet

3 Opeacuteration

Analyse des documents Fcedback des praticiens Modegravele proposeacute

4 1nlerpreacutetation

Contexte Extrapolalion Travaux futurs

13 Deacutefinition du projet

La deacutefinition de la recherche agrave partir du cadre a permis deacutetablir la motivation la porteacutee les

obj ectifs de recherche les utilisateurs des reacutesultats de celle recherche et la planification du

projet de recherche

8

131 La motivation

La motivation principale de ce travail de recherche est dexplorer les apports du TE Il sagit

aussi dexplorer lampleur de la divergence entre les deux eacutecoles de penseacutees ]a discipline et

le CDS par le biais dune eacutetude comparative approfondie des meacutecanismes et des techniques

utiliseacutes dans le TS et dans le TE La productiviteacute du TE est fortement annonceacutee par quelques

praticiens ce qui nous a aussi motiveacutee agrave entreprendre une eacutetude empirique pour eacutevaluer la

validiteacute de ces annonces Nous voulons par cette recherche contribuer agrave ameacuteliorer le

processus de choix de lapproche convenable de test en deacuteveloppant un guide deacutevaluation

des facteurs de contexte de projet de test Ce guide va permettre de clarifier les contextes

favorables pour utiliser le TE comme une meacutethodologie primaire de test

132 La porteacutee

Cette eacutetude traite le test dynamique du logiciel selon lin proceacutedeacute boicircte noire Elle porte sur la

comparaison de deux approches de test le TE ct TS

133 Lobjectif

Lobjectif de notre eacutetude est de preacutesenter un ensemble de faits theacuteoriques et expeacuterimentaux

qui peuvent justifier une reacuteponse agrave notre question de recherche principale

bull Est-ce que le test exploratoire pourrait remplacer le test sceacutenoriseacute Si oui dans quels

contextes

Pour reacutepondre agrave la question principale de la recherche nous essayons dabord de trouver des

reacuteponses aux questions secondaires suivantes

1 Quels sont les facteurs de contexte de test qui influencent le choix de Japproche de

test

2 Parmi ces facteurs quels sont les facteurs de contexte de test favorables pour utiliser

leTE

Pour reacutepondre agrave toutes ccs questions nous avons effectueacute une analyse comparative de TE par

rappol1 au TS cn utilisant un cadre conceptuel de comparaison deacuteveloppeacute dans le cadre de ce

9

travail de recherche Ce cadre inclut des critegraveres ou des facteurs de comparaison formuleacutes agrave

partir des reacutesultats des eacutetudes de cas de TE proposeacutees dans la litteacuterature ct en sinspirant du

cadre de comparaison proposeacute par Tumer et Boehm (2004) Cette analyse comparative va

permettre de souligner les contextes favorables agrave chacune des deux approches de test Par la

suite nous avons conclu sur les contextes ougrave le TE peut remplacer le TS

Dans le cadre de cette eacutetude comparative nous avons proceacutedeacute agrave une eacutetude empirique de la

productiviteacute de TE Agrave cet effet nous avons reacutealiseacute une expeacuterience dans les laboratoires

informatiques de lUQAgraveM Lobjectif principal de cette expeacuterience eacutetait de veacuterifier la

productiviteacute de TE en telmes de nombre et dimpo11ance de deacutefauts qui pourraient ecirctre

deacutetecteacutes en utilisant cette meacutethode de test De plus cette eacutetude empirique a porteacute sur la

comparaison de la productiviteacute de TE par rapport au TS autrement dit lanalyse de leffet de

la technique de test (TE TS) sur la productiviteacute de lactiviteacute de test en utilisant un

eacutechantillon composeacute de 56 sujets (les eacutetudiants de cours INF6160 session de lautomne

2005) Chaque eacuteleacutement de leacutechantillon a appliqueacute les deux techniques de test sur un

programme choisi Dans notre plan expeacuterimental les mecircmes sujets sont utiliseacutes dans les deux

traitements Cc type deacutetude est qualifieacute de plan expeacuterimental agrave un seul facteur agrave mesures

reacutepeacuteteacutees laquoSingle Factor Experiments Having Reapted Measures on The Same Elementsraquo

Nous avons exploiteacute et analyseacute les reacutesultats de deux faccedilons diffeacuterentes la premiegravere

lexploitation des reacutesultats de TE collecteacutes de notre expeacuterience que nous comparons avec les

reacutesultats quantitatifs proposeacutes dans la litteacuterature La deuxiegraveme la comparaison des reacutesultats

collecteacutes des deux approches Nous avons proceacutedeacute agrave lanalyse de variance ANOVA proposeacute

par Wincr (197 J p 105)

En geacuteneacuteral notre eacutetude vise la clarification des connaissances concernant le TE et sinteacuteresse

tout particuliegraveremcnt agrave leacutevaluation de sa contribution dans le domaine du test logiciel Nous

voulons preacutesenter les faits et les arguments existant dans la litteacuterature accompagneacutes de nos

deacuteductions personnelles

134 Description des utilisateurs des reacutesultats de la recherche

Ce travail de recherche revecirct de linteacuterecirct pour plusieurs types dintervenants les chercheurs

10

en terme de contribution agrave louverture de nouvelles pistes de recherche pour les praticiens et

les entreprises en terme de productiviteacute et rentabiliteacute de jactiviteacute de test et gains financiers et

les enseignants en terme didentification des nouvelles matiegraveres pour le cours dc test du

logiciel

1341 Les chercheurs

Les reacutesultats de ce projet de recherche pourront ecirctre utiliseacutes par les chercheurs inteacuteresseacutes par

leacutetude de TE Comme domaine de recherche les contextes favorables pour utiliser le TE

nont pas eacuteteacute eacutetudieacutes Ainsi la productiviteacute du TE en termes du nombre et de limportance

des deacutefauts qui pourront ecirctre deacutetecteacutes a eacuteteacute peu eacutetudieacutee empiriquement Dougrave limportance

des pistes et des solutions proposeacutees dans ce travail de recherche Lcs reacutesu hats theacuteoriques et

empiriques de cette eacutetude pourront ecirctre reacuteutiliseacutes dans dautres reacutepeacutetitions empiriques et

travaux futurs afin denrichir les connaissances existantes sur le TE

1342 Les entreprises

Au nivcau pratique cette recherche sinscrit dans un courant de preacuteoccupation des praticiens

et des entreprises dans le domaine de test du logicicl qui voudraicnt adopter et adapter le TE

clans leurs meacutethodologies de test En effet les patriciens et les entreprises veilleront avec plus

dimportance sur la rentabiliteacute de lactiviteacute de test en reacuteduisant la dureacutee du cycle de test et en

diminuant les efforts consacreacutes aux tests Le guide de seacutelection de lapproche de test reacutesultant

de lanalyse comparative entre le TE et le TS vise lidentification des contextes favorabIes

pour utiliser chacune des deux approches de tcst afin datleindre la rentabiliteacute et la

productiviteacute voulues et de reacutepondre aux besoins des praticiens et les entreprises

1343 Les enseignants

Ce travail est destineacute aux enseignants par lidentification des nouvelles matiegravercs pour le

cours de test du logiciel Habituellement la matiegravere de ce cours traite seulement le TS du fait

quelle est la meacutethode habituelle de test dans lindustrie Or la croissance continue de

ladoption de TE justifie linclusion de celui-ci dans les cours de tests pour preacuteparcr les

eacutetudiants agrave reacutepondrc aux besoins de Jindustrie Lutilisation du guide de seacutelection eacutelaboreacute

II

dans le cadre de ce travail serait beacuteneacutefique pour aider les eacutetudiants agrave identifier et agrave

diffeacuterencier les contextes qui favorisent lutilisation de chacune des deux approches de test

135 Les limites du projet

Une limite importante du projet vient de la limitation de contexte de notre eacutetude empirique

Labsence dun contexte industriel ou nous pouvons effectuer notre eacutetude empirique nous a

pousseacutee de faire cette eacutetude dans un contexte acadeacutemique en utilisant des eacutetudiants comme

des sujets de lexpeacuterience et un petit programme comme instrument de lexpeacuterience au lieu

dutiliser un grand logiciel Ceci a influenceacute les reacutesui tats de lexpeacuterience

lA Planification du projet

Dans le but datteindre notre objectif principal nous avons identifieacute les phases suivantes

1 Nous proposons un modegravele de processus de TS en mettant laccent sur les livrables

de chaque eacutetape et la documentation eacutelaboreacutee Notre modegravele suit le standard de

documentation lEEE829 (1998) pour pouvoir contraster les deux penseacutees discuteacutees

dans ce travail agrave savoir la discipline et le CDS chacune est repreacutesenteacutee par sa

pralique successivement le TS et Je TE

2 Nous proposons lapproche Session Based Test Managcmenl (SBTM) qUI va

repreacutesenter le TE dans lanalyse comparative de TE et le TS

3 Nous eacutetudions les eacutetudes de cas et les expeacuteriences dutilisations de TE dans

lindustrie de test Nous deacuteduirons les facteurs qui ont influenceacute Jutilisation ct

ladoption de TE dans la pratique de test

4 Nous reacutealisons notre eacutetude empirique dans les laboratoires informatiques de lUQAgraveM

et nous traitons les donneacutees collecteacutees pendant cette expeacuterience

5 Deacuteveloppement de notre cadre conceptuel de comparaison qui va guider lanalyse

comparative de TE et le TS

12

6 Nous proceacutedons agrave une analyse comparative des deux approches de test le TS et le TE

selon le cadre de comparaison eacutelaboreacute et les reacutesultats de leacutetude empirique

7 Nous discutons les reacutesultats de lanalyse comparative Puis nous concluons les

contextes favorables pour utiliser le TE comme une meacutethodologie primaire de test

Nous terminons par leacutelaboration dun guide de seacutelection de lapproche dc test

Le chapitre 1preacutesente leacutetape 2 laquoPlanificationraquo de cadre de Basili Leacutetape 3 laquoOpeacuterationraquo de

ce cadre sera abordeacutee dans les chapitres Il 111 IV V VI et VII Leacutetape 4 laquoInterpreacutetationraquo

sera abordeacutee dans le chapitre VIII

CHAPITRE II

TEST SCEacuteNARISEacute VUE DENSEMBLE

Ce chapitre preacutesente les eacuteleacutements neacutecessaires agrave la compreacutehension du test sceacutenariseacute (TS) Dans

la premiegravere partie nous deacutefinissons le rs et nous preacutesenterons un bref historique du test du

logiciel Nous faisons ensuite un survol rapide de quelques modegraveles de test Par la suite nous

proposerons un modegravele du processus de TS baliseacute dans les patrons de la norme IEEE 829 et

nous terminons par une conclusion

2] Concepts de base et terminologie

211 Terminologie

Dans cette section nous proposons quelques deacutefinitions et certains termes et concepts

fondamcntaux du test logiciel Premiegraverement nous deacutefinissons les termes erreur deacutefaut et

deacutefaillance Ces termes sutilisent parfois dune faccedilon interchangeable pour deacutecrirc un

mauvais fonctionnement dans le logiciel Swebok (2004) a identifieacute une fautc ou deacutefaut

(Defeu FauI) comme la cause dun mauvais fonctionnement dans le logiciel ct leffet nonshy

deacutesireacute obscrveacute comme deacutefaillance (Faiure) Autrement dit les tests reacutevegravelent lcs deacutefaillances

causeacutees par un deacutefaut qui peut etou doit ecirctre enleveacute En fait Swebok a adopteacute les deacutefinitions

proposeacutees par IEEE agrave ces termes

bull Erreur (Error) Action humeacuteline produisant un reacutesultat incorrect (IEEE 729)

bull Deacutefaut (Defect Bug FanU) une imperfection dans un composanl ou un systegraveme qui

peUl conduirc agrave ce gu un composant ou un systegraveme nexeacutecute pas les fonctions requises

(IEEE 729)

Deacutefaillance (Failure) Fin de la capaciteacute du systegraveme ou du composant agrave effectuer la

fonction rcquise ou agrave Jcffectucr dans les limites speacutecifieacutecs (IEEE 729)

14

212 Cas de test

Cest un ensemble de valeurs dentreacutee de preacute-conditions dexeacutecution de reacutesultats attendus et

de post-conditions dexeacutecution deacuteveloppeacutes pour un objectif particulier tel quexeacutecuter un

chemin pm1iculier dun programme ou veacuterifier Je respect dune exigence speacutecifique (IEEE

610) La norme IEEE829 (1998) a deacutefini un cas de test comme un document indiquant les

entreacutees les reacutesultats preacutevus et les conditions dexeacutecution pour un article de test

Selon Kaner (2003) un cas de test est une question eacutelaboreacutee pour obtenir une information sur

le programme sous test Cette information se reacutevegravele par lexeacutecution du test relieacute agrave cette

question Cet auteur a citeacute deux conseacutequences indirectes de sa deacutefinition la premiegraverc est que

le cas de test devrait ecirctre capable de fournir une information utile au moment de lexeacutecution

Dc ce fait selon lauteur un cas de test eonccedilu au deacutebut de lactiviteacute de test ne pourra pas

reacuteveacuteler une information ulteacuterieurement dans le projet de test quand le logieiel deviendra plus

stable Cest lun des deacutesavantages du TS citeacute par Copeland (2004) La deuxiegraveme implication

que le cas de test ne devrait pas neacutecessairement deacutetecter un deacutefaut mais il suffit quil

fournisse unc information qui souvent megravene agrave la deacutetection dun deacutefaut scion lauteur

Leacutelaboration de ccttc deacutefinition nest pas arbitraire mais proposeacutee pour inclure le cas speacutecial

de cas de tcst cxploratoire (TE) et ee pour deux raisons la premiegravere est que les eas de tests

exploratoires se fondent sur leacutelaboration des questions agrave propos du logieiel sous test (Kaner

ct Tinkham 2003a) La deuxiegraveme est quun cas de test exploratoire ne devrait pas

obligatoiremcnt deacutetecter un deacutefaut mais il suffit quil reacutevegravele une information Cette

information pourrait ecirctre utiliseacutee pour concevoir un autre cas de test qui pouuait mener agrave la

deacutetcction dun deacutefaut (Kancr et Tinkham 2003a)

22 Test sceacutenariseacute (Scripted Tcsting)

Cest un test manuel qui sc fait typiquement par un testeur junior en suivant les eacutetapes et les

proceacutedures conccedilus par un testeur senior (Bach et aL 2002)Ces mecircmes auteurs ont souligneacute

plus tard dans plusieurs reprises que le test sceacutenariseacute pourrait ecirctre automatiseacute (Kaner 2006)

15

Selon Copland (2004) le test sceacutenariseacute est nimporte quelle activiteacute de test manuelle ou

automatiseacutee baseacutee sur la conception et Jenregistrement des scripts deacutetailleacutes de tests avant

lexeacutecution

Dans un TS la planification et la conception des tests se font avant leur exeacutecution Les cas et

les sceacutenarios de test typiquement mais pas neacutecessairement sont deacutefinis tocirct dans le cycle du

deacuteveloppement du logiciel selon le modegravele du cycle de vie utiliseacute On les preacutepare en se

basant habituellement sur le document des speacutecifications des exigences du logiciel dans un

proceacutedeacute de test boicircte noire sans accegraves au code ou sur la logique interne du programme dans

un proceacutedeacute boicircte blanche avec accegraves au code ou une combinaison des deux Les cas de tests

sont alors exeacutecuteacutes par un autre testeur que celui qui les a conccedilus quand le logiciel devient

disponible pour les tests

Historiquement le test sceacutenariseacute a eacutemergeacute en tanl quune phase dans le premier modegravele de

deacuteveloppement en cascade (Royce 1970) Dans ce modegravele le deacuteveloppement est deacutecomposeacute

en plusieurs eacutetapes seacutequentielles dont chacune possegravede des critegraveres dentreacutee et de sortie

preacutecis et des livrables bien deacutetermineacutes Alors le test est lune de ces eacutetapes son rocircle est

deacutevaluer si les exigences sont bien comprises et speacutecifieacutees (Validation) et que la conception

est correctement implanteacutee par le code (Veacuterification) Reacutecemment le TS a franchi des

nouvelles dimensions que ccllcs connues dans Ics anneacutees 70 Alors nimporte quelle

meacutethodologie de deacuteveloppement mecircme les plus agiles peuvent Jutiliser nimporte ougrave la

reacutepeacutetitiviteacute lobjectiviteacute et lauditabiliteacute sont neacutecessaires ct importantes dans le processus de

test du logiciel (CopeJand 2004)

Selon Copeland (2004) la reacutepeacutetitiviteacute signifie que les lests ou les proceacutedures de tests sont

suffisamment deacutetailleacutees pour quils puissent ecirctre exeacutecuteacutes par quelquun autre que leur auteur

original En cc qui concerne lobjectiviteacute elle signifie que la creacuteation de tests ne deacutepend pas

seulement de la creacuteativiteacute et la compeacutetence de son concepteur mais quils sont baseacutes sur des

prineipes de conception bien deacutetermineacutes deacuteriveacutes agrave partir des exigences du logiciel les cas

dutilisations ct les standards agrave respecter dans le projet de test Quant agrave lauditabiliteacute ellc

signifie la traccedilabiliteacute bidirectionnelle entre les speacutecifications dexigences et les cas de tests

16

Cette traccedilabiliteacute permet de mesurer formellement la couvel1ure de test qui sera abordeacutee dans

les sections qui suivent

23 Bregraveve histoire des tests

Myers (1979) a identifieacute le test logiciel en tant quune action dexeacutecuter un programme ou un

systegraveme dans le but de deacutetecter ses deacutefauts Agrave leacutepoque cette deacutefinition a eacuteteacute probablement la

meilleure disponible Elle refleacutetait les pratiques de cette peacuteriode ou le test apparaicirct seulement

agrave la fin du cycle de deacuteveloppement visant principalement la deacutetection des erreurs Puis en

1988 la deacutefinition de test logiciel a changeacute en faveur de leacutevaluation de la qualiteacute du logiciel

plutocirct quun simple processus pour reacuteveacuteler les erreurs Hetzel (1988) a deacutefinit le test comme

une activiteacute dont son but est deacutevaluer et valider les fonctionnaliteacutes du logiciel Reacutecemment

le test est perccedilu comme une activiteacute exeacutecuteacutee pour eacutevaluer et ameacuteliorer la qualiteacute du logiciel

en identi fiant ses deacutefauts et ses problegravemes (Swebok 2004) Par cette deacutefinition Swebok

ajoute lameacutelioration de la qualiteacute du logiciel agrave leacutevaluation de la qualiteacute et agrave la recherche des

deacutefauts Cette meacutethode connue actuellement sous le tenne de laquo test preacuteventifraquo (Craig ct

Jaskiel 2002 Swebok 2004 Perry 2000) Selon Swebok (2004) le test devrait encadrer

lensemble du deacuteveloppement et de la maintenance Cl ecirctre en soi une partie importante de la

construction du produit logiciel

La philosophie de test preacuteventif dicte que le test pourrait ameacuteliorer la qualiteacute du logiciel sil

apparaicirct assez tocirct dans le cycle de deacuteveloppement ]1 sagit de la creacuteation de cas de tests pour

valider les exigences et la conception avant mecircme le codage du logiciel Cela permet de

deacutetecter les faiblesses potentielles et les erreurs dans les premiegraveres phases de deacuteveloppement

et de reacuteduire le coucirct de correction des deacutefauts sachant que plus lerreur est deacutecouverte tocirct

dans le processus moins elle colite cher agrave corriger ct plus lerreur se situe au deacutebut du cycle

de deacuteveloppement plus eUe colite cher agrave corriger ulteacuterieurement dans le cycle (Boehm J981

Pressman J997) Selon Perry (2000) la plupaJ1 des erreurs deacutetecteacutees pendant la phase de test

pourraient ecirctre attribueacutees agrave des erreurs danalyse et de conception Elles repreacutesentent

approximativement tel quillustreacute sur la figure 21 les deux tiers des erreurs failes pendant le

deacuteveloppement du logiciel En conseacutequence la preacuteparation du plan ct des proceacutedures de test

sceacutenariseacute tocirct dans le cycle de deacuteveloppement permettent de fournir des informations utiles

17

aux concepteurs en identifiant les erreurs tocirct dans le projet comme les oublis ou les

incoheacuterences de conception avant que ces erreurs se transforment agrave des deacutefauts dans le code

Figure 21 Le pourcentage des erreurs danalyse et de conception (Adapteacute ct traduit de Perry 2000 pAS)

Erreurs de codage

64

Erreurs danalyse et de conception

Dans les meacutethodes agiles lactiviteacute de test est incorporeacutee dans chaque iteacuteration du processus

de deacuteveloppement et constitue une partie inteacutegrante essentielle de la construction du logiciel

(Boehm et Turner 2004) De ce fait nous croyons que les meacutethodes agiles satisfont aussi les

aspects principaux de la deacutefinition proposeacutee par Swebok (2004)

A part une vue exploratoire non traditionnelle propose le test comme une activiteacute

dinvestigation et dexpeacuterimentation Selon Bach ct Kaner (2004) le test est une investigation

dont Jobjectif est de reacuteveacuteler des informations sur la qualiteacute du produit agrave tester Cette

deacutefinition vise principalement linclusion de TE qui se base sur linvestigation et le

questionnement

24 Les modegraveles de test

Le modegravele en V constitue leacutetat de lart dans le domaine de test du logiciel Cest le modegravele

le plus utiliseacute et traiteacute dans la litteacuterature de test (Craig et Jaskiel 2002 Perry 2000) Cc

modegravele tel quillustreacute agrave la figure 22 divise le processus de test en plusieurs niveaux

effectueacutes conjointement avec jimplantation du logiciel Il commence par le test de petits

morceaux ct avance vers des plus grands refleacutetant diffeacuterents points de vues de test a

diffeacuterents niveaux de deacutetail

18

Figure 22 Modegravele de test en V (Adapteacute et traduit de Pyhajarvi ct aL 2003)

[ Exgence Jr-o---------t~[ AcceplaUon J li( ~

Speacutecifications Systegraveme

~

Conception Inteacutegration

~ ~

Codage Uniteacute~

Speacutecification ----J~ Planification ----J~ Test

Ce modegravele identifie des activiteacutes de test agrave chaque eacutetape du cycle de vie Le test unitaire est au

niveau Je plus bas dans la hieacuterarchie Lobjectif geacuteneacuteral de ce niveau de test est de trouver les

deacutefauts dans la logique dans les donneacutees et dans les algorithmes de chaque module pris

individuellement Apregraves Je test unitaire viennent les tests dinteacutegration ces derniers sont

effectueacutes pour trouver les deacutefauts dinterfaces entre les uniteacutes En remontant dans la

hieacuterarchie le niveau suivant les tests dinteacutegration est le test du systegraveme Ce dernier est le

processus de tester le systegraveme entier afin de veacuterifier le produit par rapport aux speacutecifications

des exigences Finalement le test dacceptation prend place afin de deacuteterminer si le logiciel

reacutepond aux exigences et aux attentes du client

La force de ce modegravele est quil permet de planifier et de preacuteparer les cas de test tregraves tocirct dans

le cycle du deacuteveloppement degraves que labstraction des exigences est connue Ce fait aide dans

la deacutetection des erreurs de conception et de speacutecification Autrement il permettait de deacutetecter

les erreurs avant quils se transforment agrave des deacutefauts dans le code cest ce quest connu

actuellement SOllS le terme de test preacuteventif Cependant celle force ramegravene avec elle une

19

faiblesse importante Cette faiblesse se traduit par la rigiditeacute de modegravele aux changements En

effet souvent la documentation utiliseacutee pour planifier et preacuteparer les cas de tests nest pas

assez mucircrie au deacutebut du projet de deacuteveloppement Par conseacutequent la possibiliteacute que le

logiciel se change ulteacuterieurement dans le cycle de deacuteveloppement est forte probable Ceci

neacutecessite la mise agrave jour de tous les artefacts du test deacutejagrave conccedilus qui est souvent tregraves coucircteux

Selon Bach et al (2002) les revues et les inspections pourraient ecirctre plus efficace dans la

deacutetection des erreurs des exigences et la conception que de concevoir des cas tests qui ne

seront jamais exeacutecuteacutes

Derniegraverement avec lapparition des meacutethodes agiles le modegravele de test en V ne peut plus

suivre cette nouvelle tendance du deacuteveloppement (Pyhajarvi et al 2003) En reacuteaction le test

Agile a fait son apparition Cest une meacutethode de test suivie dans les projets agiles de

deacuteveloppement (Marick 2003) Cet auteur a preacuteciseacute que la communication ct la collaboration

entre les testeurs les deacuteveloppeurs et le client constituent les principes essentiels du test

agile Le rocircle du testeur nest plus pareil agrave celui des modegraveles traditionnels ougrave le testeur

soccupe seulement de la veacuterification et la validation du logiciel deacuteveloppeacute Cela nous amegravene

vers un rocircle plus constructif du logiciel gracircce aux informations et aux feedbacks utiles que le

testeur pourrait fournir aux deacuteveloppeurs au fur ct agrave mesure sur la qualiteacute de lapplication

deacuteveloppeacutee agrave chaque iteacuteration Souvent le testeur utilise le TE pour tester le logiciel et fournir

cc feedbaek (Pettichord 2004)

La communication entre le testeur agile et le client est aussi tregraves importante (Marick 2003)

Souvent le testeur devrait collaborer avec le client pour identifier les sceacutenarios dutilisation

neacutecessaires agrave leacutelaboration des tests dacceptation Cela fournira une revue implicite aux

exigences et aide agrave bien visualiser le logiciel En fait le testeur peut assurer un fecdback tregraves

tocirct sur quelques aspects du logiciel tels que lutilisabiliteacute et dautres fonctionnaliteacutes aux

deacuteveloppeurs

Selon Hcndrickson (2005) le testeur a deux rocircles dans le test Agile testeur et designer Les

pratiques de test agile peuvent ecirctre reacutesumeacutees sur la figure ci-dessous

20

Figure 23 Les pratiques de test Agile (Adapteacute et traduit de Hendrickson 2005)

Dans une seule iteacuteration

Testeur

Tests unitaires Test exploratoire

automatiseacutes Tests dacceptations

automatiseacutes manuel

Reacutepresente des Fournit unRpent~ l exigences speacutecifications feedback

exeacutecutables exeacutecutables addtiOllllcl

Tel quillustreacute agrave la figure 23 le TE constitue une partie inteacutegrante et essentielle de test agile

25 Processus de test sceacutenariseacute

Pour faire la diffeacuterence entre le TS et le TE nous preacutesentons dans cette section un processus

de TS sans speacutecifier une meacutethodologie preacutecise Nous nous inteacuteressons seulement aux aspects

qUI nous permettrons de mener notre eacutetude comparative Nous avons choisi de suivre Je

standard IEEE 829 Selon Copland (2004) cetle norme de documentation est la meilleure

dans le domaine du test qui peut illustrer les aspects principaux de lapproche sceacutenariseacutee Ce

choix a eacuteteacute influenceacute aussi par nos besoins de contraster une vue sceacutenariseacutee disciplineacutee et

formelle avec une autre exploratoire et libre

La norme de documentation IEEE 829 de test du logiciel est une tentative de rassembler les

vues et preacutesenter quelques meilleures ideacutees de la pratique afin de mieux controcircler lactiviteacute

de test La nonne a eacuteteacute reacuteviseacutee et mise agrave jour en 1998 Elle deacutecrit huit documents qui peuvent

ecirctre diviseacutes en trois cateacutegories selon (Copeland 2004) les documents de preacuteparation des

tests produits avant le deacuteveloppement du logiciel les documents dexeacutecution des tests et les

21

documents de compleacutetude des tests Chacune de ces cateacutegories est composeacutee de documents

suivants

bull Documents de preacuteparation de tests

bull Plan de test

bull Speacutecification de conception de tests

bull Speacutecification de cas de tests

bull Speacutecification de proceacutedure de tests

bull Documents dexeacutecution de tests

bull Rapport de transmission darticle de test

bull log (registre) de test

bull Documents de compleacutetude de test

Rapport dincident de test

bull Rappol1 de sommaire de tests

La nonne IEEE 829 (1998) a citeacute quclques avantages de son utilisation

o Lutilisation des documents de tcsts standardiseacutes pourraient faciliter la communication

entre Ies intervenants de projct du deacuteveloppement en fournissant un protocole de

reacutefeacuterence commun

o Le standard IEEE 829 pourrait servIr comme un outil de veacuterification et deacutevaluation

(Check List) au processus de test

o Un ensemble de documents normaliseacutes selon cette norme pourrait eacutegalement fournir une

base pour leacutevaluation des pratiques de documentation de test du logiciel

o Lutilisation des documents selon la norme IEEE 829 permettrait de controcircler le

processus de test Cela reacutesulte de laugmentation de la visibiliteacute dc chaque phase du

processus

22

Figure 24 Scheacutematisation des documents de preacuteparation de tests (Adapteacute et traduit de

Copeland 2004 p189)

Plan de test

Speacuteci1iumlcation

de Conception de Test

1 S peacuteci fica lion

Speacutecification de Proceacutedure

de Cas de Test de Test

~------------~-Rapport de - Exeacutecution des -

transmission -~ _ tests _

darticle de test -------------

bull

Rapport

-~Log de test dincident de test

1 Rapport de~ Se reacutefeumlre agrave Sommaire de - -_ ___ EntreacuteeSortie

test

Dans notre eacutetude nous nous inteacuteresserons seulement aux documents de preacuteparation de tests

du fait quils constituent le principal point de divergence entre le TS et le TE La figure 24

montre les doeuments devraient ecirctre creacuteeacutees avant jexeacutecution de tests Souvent ces documents

sont creacuteeacutes parallegravelement agrave limpleacutementation du logiciel dans les vues preacuteventives de test

(Craig ct Jaskiel 2002) Cest lune des forces de TS qui pourrait sintroduire tregraves tocirct dans le

cycle de vie du logiciel et preacutevenir les erreurs et les ambiguiumlteacutes pendant la phase de

speacutecification des exigences et la conception avant quils se transforment agrave des deacutefauts dans le

code

Notons que les documents du test sont eacutegalement sujets agrave une validation Cela peut ecirctre

reacutealiseacute par une reacutevision formelle agrave ccs documents Agrave cet effet Jutilisation de la norme pouna

faciliter eacutenormeacutement la mise en place de cette validation (Craig et Jaskiel 2002) Cependant

23

selon Bach et al (2002) la norme pourrait nuire agrave la qualiteacute de test effectueacute Du fait que les

testeurs consacrent le temps limiteacute du test agrave la creacuteation dune documentation lourde et non

neacutecessaire au 1ieu de linvestir dans le test du logiciel

Selon (Swebok 2004 Pyhajarvi et al 2003 Craig et Jaskiel 2002 Perry 2000) le

processus de test comporte les eacutetapes suivantes la planification lanalyse et la conception de

tests lexeacutecution el leacutevaluation de tests Nous aHons aborder dans les sections qui suivent

chacune de ces eacutetapes en mettant laccent sur les documents creacuteeacutes et les eacuteleacutements

fondamentaux speacutecifieacutes dans ces documents

251 La planification

La planification de lactiviteacute de test peut commencer au moment de la formulation des

besoins se deacutevelopper et se raffiner pendant la phase de conception du logiciel Ce processus

de planification donne naissance a un plan de lesl qui deacutecrit les items (composants) et les

caracteacuteristiques de qualiteacute (fonctionnaliteacute performance utilisabiliteacute etc) qui devraient ecirctre

testeacutes ainsi que les responsabiliteacutes les livrables et les besoins environnementaux requis et

leacutecheacuteancier de projet de test Sachant que ce plan de test peut ecirctre creacutee au niveau de projet

(Master Test Plan) ou au niveau secondaire (unitaire inteacutegration systegraveme acceptation etc)

Cela deacutepend de la complexiteacute de logiciel et de lorganisation de projet Il faut noter que celle

planification est une activiteacute continue seffectue tout au long du cycle de deacuteveloppement

Alors les reacutesultats de lactiviteacute de test sont utiliseacutes pour mesurer les risques el modifier le

plan si neacutecessaire

Le patron du plan de test de la norme IEEE 829 deacutefinit 16 clauses deacutecrites ci-dessous la

description deacutetailleacutee de chaque clause est preacutesenteacutee dans lannexe B

1 Identificateur du plan de test

2 Introduction

3 Items de test

4 Caracteacuteristiques agrave tester

5 Caracteacuteristiques qui ne devraient pas ecirctre testeacutees

6 Approche de test

24

7 Critegravere de passageeacutechec

8 Critegravere de suspension et conditions de reprise

9 Livrables du test

10 Tacircches du test

Il Besoins environnementaux

12 Responsabiliteacutes

13 Besoins en personnel et formation

14 Ceacutedule

15 Risques et contingences

16 Acceptations

Le patron du plan de test preacutesenteacute ci dessus foumit un croquis ou une structure de base du

plan de test quil peut ecirctre adapteacute selon les besoins de chaque organisation Pratiquement la

plupart des plans proposeacutes dans la litteacuterature divisent la clause risque et contingence en deux

clauses seacutepareacutees la premiegravere deacutecrit les risques lieacutes au logiciel et la deuxiegraveme les risques lieacutes

au projet de test et ses contingences (Craig et Jaskiel 2002) En effet la rapiditeacute suivie dans

le deacuteveloppement et limpossibiliteacute de tester le logiciel exhaustivement ont pousseacute les

intervenants dans le domaine du test agrave utiliser les risques du logiciel pour focaliser la strateacutegie

et identifier la prioriteacute des items de test 11 sagit de faire une analyse de risques au deacutebut de

projet de test en se basant sur les speacutecifications dexigences (Craig Jaskiel 2002) Elle

permet aussi de deacuteterminer les zones agrave risques et les parties potentielles qui auraient tendance

agrave avoir plus derreurs et qui devraient ecirctre testeacutees rigoureusement Selon ces mecircmes auteurs

les reacutesultats de cette analyse doivent ecirctre revus occasionnellement pendant le projet de test

du fait que les speacutecifications les ressources la porteacutee de test et dautres facteurs dans le projet

peuvent se changer Dailleurs le risque des composants qui ont subi des changements

devient naturellement plus grand agrave chaque version Cette analyse de risques pourrait servir

aussi dans la mise en place de contingences convenables lorsquun eacuteveacutenement inattendu

survient et empecircche jexeacutecution normale du plan de test

252 Analyse et conception

La conception de tests est la premiegravere eacutetape de deacuteveloppement de tests Le processus

25

danalyse et de conception de tests se consiste de trois eacutetapes agrave savoir concevoir les tests en

identifiant les conditions de tests speacutecifier les cas de tests et speacutecifier les proceacutedures de tests

Alors pendant lanalyse la documentation de base disponible dans cette eacutetape tels que les

documents de speacutecification des exigences et de conception doivent ecirctre analyseacutes

soigneusement pour deacuteterminer les items ou les articles gui devraient ecirctre testeacutes Une

condition de test est deacutefinie comme un article ou un eacuteveacutenement qui peut ecirctre veacuterifieacute par un ou

plusieurs cas de tests tel que une fonction ou caracteacuteristique de qualiteacute

Pendant la speacutecification de cas de tests les donneacutees de tests sont deacuteveloppeacutees et deacutecrites en

deacutetail en utilisant une ou plusieurs techniques de conception de tests (Beizer 1995 Craig

Jaskiel 2002) Le choix dune technique deacutepend de la nature du systegraveme agrave tester les objectifs

viseacutes et le risque global de lexeacutecution (Craig Jaskiel 2002) Cette phase se conclut par la

production de trois livrables Speacutecification de Conception de Test Speacutecification de Cas de

Tes et Speacutecification de Proceacutedure de Test Elle se conclut aussi par leacutelaboration de la

matrice de traccedilabiliteacute qui trace les exigences vers les cas de tests (Craig Jaskiel 2002)

Tableau 21 La matrice de traccedilabiliteacute

Cas de test 1 Cas de test 2 Cas de test 3 Cas de test 4

Exigence J X X X X

Exigence 2 X Exigence 3 X X X

Exigence 4 X X

Totale 2 4 3 1

La matrice de traccedilabiliteacute permet de tracer les cas de tests sur les exigences Cela fournit un

moyen pour identifier les exigences qui ne sont pas bien testeacutees Autrement cest un outil

pour mesurer la couvel1ure de tests (sera eacutevoqueacute en deacutetail dans le chapitre VU)

Cette matrice permettait aussi danalyser limpact de changements sur les exigences et donne

une ideacutee du volume de travail neacutecessaire pour mettre agrave jour les cas de tests deacutejagrave conccedilus (Bach

et aL 2002)

26

2521 Speacutecification de Conception de test

Speacutecification de Conception de Test est un document speacutecifiant les conditions de tests

(eacuteleacutements de couverture) pour un article de test lapproche deacutetailleacutee du test et lidentification

des cas de tests de haut niveau associeacutes (IEEE 829 1998) Il compolie les eacuteleacutements suivants

J Identificateur de Speacutecification de Conception de Test (un nom unique pour distinguer le

document parmi tous les autres)

2 Caracteacuteristiques agrave tester (identifie es items et les caracteacuteristiques objets de celte

Speacutecification de Conception de test

3 Raffinements de lapproche (identifie les deacutetails de la technique de test et de lapproche

proposeacutee dans le plan de test)

4 Identification de tests (fournit un identificateur unique et une courte description des cas

de tests associeacutes agrave celte Speacutecification de Conception de test)

S Critegravere de succegraveseacutechec de test (critegravere utiliseacute pour deacuteterminer si une caracteacuteristiques

passe ougrave eacutechoue Je test)

En fait le document de Speacutecification de Conception de Test est unc miniature de plan de test

Son rocircle cst de regrouper les cas dc tests semblables destineacutes agrave tester une ou plusieurs

caracteacuteristiques du logiciel Ici quillustreacute sur la figure 2S

Figure 25 Speacutecification de Cas de Test

PIgtln de lest]

Speacutecilicirceation SpeacutecifiCgtltion peacutecifieation de Conception de Conception de Conception

de test de test de test ~ T

Cns de lesl 01 Cas de lest 02

1 i

27

Par la suite les speacutecifications de chaque cas de test speacutecifieacute dans le document Speacutecification de

Conception de Test devraient ecirctre deacutetermineacutees

2522 Speacutecification de Cas de Test

Le but de Speacutecification de Cas de Test est didentifier les deacutetails de chaque cas de test citeacute

dans la Speacutecification de Conception de Test Le patron IEEE 829 de Speacutecification de Cas de

Test deacutecrit les eacuteleacutements suivants

1 Identificateur de Cas de Test (un nom unique qui distingue ce cas de test parmi tous

les autres)

2 Items de test (items et caracteacuteristiques objets du cas de test)

3 Speacutecification des entreacutees (speacutecifie les entreacutees requises par ce cas de test)

4 Speacutecification des sorties (speacutecifie les reacutesullats preacutevus de lexeacutecution de cas de test)

5 Besoins environnementaux (mateacuteriel speacutecial ou logiciel neacutecessaire pour exeacutecuter ce

cas de test)

6 Exigences proceacutedurClles speacuteciales (identifie nimporte quelle proceacutedure speacuteciale

neacutecessaire pour insta11er lenv ironnement de test)

7 Deacutependances inter-cas (cite les cas de test qui doivent ecirctre exeacutecuteacutes avant ce cas de

test)

Comme nous venons de le voir les reacutesullats attendus devraient faire partie de Speacutecification

de Cas de Test Ces reacutesultats constituent loracle de test dans le TS

Selon Craig et Jaskiel (2002) japproche IEEE 829 requiert une documentation complegravete de

chaque cas de test cest la raison pour laquelle elle est utiliseacutee dans les systegravemes agrave grand

risque Selon ces mecircmes auteurs le patron ne constitue pas un bon choix pour tester les

systegravemes dynamiques et instables En effet la norme de documentation IEEE 829 demande

un effort important dans la creacuteation des cas de tests et quelques changements introduits sur le

logiciel peuvent rcndre ces cas dc tests invalides

Par contre ce patron constitue un bon choix dans les organisations dynamiques qUI se

caracteacuterisenl par le changement freacutequent de leur personnel ou qui ont du personnel

inexpeacuterimenteacute

28

Par la suite les cas de test conccedilus se mettent dans un ordre exeacutecutable dans le troisiegraveme

document de standard de documentation lEEE 829 de phase de conception la Speacutecification

de Proceacutedure de test Ces proceacutedures de tests sont deacuteveloppeacutees agrave pal1ir des documents de

Speacutecification de Conception de Test et Speacutecification de Cas de Test Le document de

Speacutecification de Proceacutedure de test deacutecrit comment le testeur junior devra exeacutecuter

physiquement le test Une Speacutecification de Proceacutedure de Test pourrait inclure plus quun seul

cas de test

2523 Speacutecification de Proceacutedure de Test

La Speacutecijicatian de Proceacutedure de Test est un document speacutecifiant la seacutequence dactions pour

lexeacutecution dun test Ce document connu aussi sous le terme script de tests ou script de tests

manuels (JEEE 829) La norme deacutefinit dix eacutetapes qui peuvent ecirctre utiliseacutees dans lexeacutecution

de tests qui sont deacutecrites ci- dessous

1 Objet de la proceacutedure

2 Exigences speacuteciales

3 Eacutetapes de la proceacutedure

bull Log comment enregistrer les reacutesultats

bull Set Up comment preacuteparer l exeacutecut ion de la proceacutedure

bull Stcm comment deacutebuter lexeacutecution de la proceacutedure

bull Proceed actions de la proceacutedure

Measure comment les mesures seront effectueacutees

bull Shut Down comment suspendre la proceacutedure de test

bull Restart comment redeacutemarrer la proceacutedure de test

bull Stop comment effectuer un arrecirct ordonneacute de lexeacutecution

bull Wrap Up comment restaurer lenvironnement

bull Contingencies comment traiter les anomalies durant lexeacutecution

Nous pouvons constater de la description ci-dessus que le script de la proceacutedure deacutecrit en

deacutetail les eacutetapes dexeacutecution de tesl ct ne laisse rien agrave la volonteacute du testeur qui exeacutecute le test

Cest lune dcs critiques proposeacutes par les membres dc COS contre le TS Selon eux ce script

transforme le testeur en robot exeacutecutant les tacircches sans aucune reacuteflexion critique

29

253 Exeacutecution et eacutevaluation

Lexeacutecution des tests conccedilus se fait selon le planning deacutecrit dans le plan de test Pendant

lexeacutecution des tests le testeur junior enregistre les reacutesultats de lexeacutecution dans les

documents proposeacutes par IEEE 829 Registre de test Rapport dincident de test Les deacutefauts

sont enregistreacutes dans un systegraveme de suivi des bogues Agrave la fin de lactiviteacute de test le

document de standard IEEE 829 Rapport de synthegravese de Test syntheacutetise les activiteacutes et les

reacutesultats de test de la version testeacutee du logiciel

26 Conclusion

Nous avons donneacute dans ce chapitre un aperccedilu global sur la plupart des aspects touchant au TS

en mettant laccent sur les principales eacutetapes du processus de TS Il apparaicirct que le processus

sceacutenariseacute est visible planifieacute incluant plusieurs meacutetriques pouvant faciliter la mesure de

lefficaciteacute de lactiviteacute de test Mais dans la pratique le processus de test du logiciel ne se

passe pas toujours de la mecircme faccedilon quc dans la theacuteorie speacutecifiquement le test des systegravemes

dynamiques et changeants Sajoute agrave ce problegraveme le fail que les testeurs ninterviennent quagrave

la fin de la chaicircne de deacuteveloppement dans les modegraveles traditionnels Par conseacutequent lactiviteacute

de test seffectuera souvent sous des pressions du temps de coucirct ct le besoin de livrer le

logiciel Agrave cet effet les compagnies de deacuteveloppement de logiciels ont commenceacute agrave chercher

des meacutethodes pouvant mieux sadapter avec ces reacutealiteacutes Le TE constitue une de ces

meacutethodes il fera Je sujet de prochain chapitre

CHAPITRE III

TEST EXPLORATOIRE VUE DENSEMBLE

Ce chapitre propose une vue densemble du test exploratoire en preacutesentant briegravevement les

aspects fondamentaux de cette approche Nous commenccedilons par la deacutefinition de test

exploratoire (TE) puis laccent sera mis sur lapproche de test laquoSession Based Test

Managementraquo (SBTM) et ses meacutecanismes principaux Enfin quelques techniques ct styles

dexploration seront deacutecrits et nous terminerons par une conclusion

31 Deacutefinitions

Au deacutebut des anneacutees 90 les membres de Context Oriven School (CDS) ont commenceacute agrave

utiliser le terme laquoexploratoireraquo pour deacutecrire cette nouvelle pratique de test Cette

terminologie a eacuteteacute publieacutee dabord par Kaner (1988)

laquo () At some point youll stop formoly planning and documenting new tests until the next test cycle You can keep testing Run new tests as you think of them without spending much time preparing or explaining the tests Trust your instincts ln this example you quick~y reached the switch point from formol ta inarmai testing becallse the program crashed sa saon SOll7ething moy be fllndamenta~v wrong l(so the progral71 wil be redesigned Creoting new test series nm is risky They may hecome obsolete with the next version of the prngram Rother thon gomhling away the planning time tlY some exploratOlY tests whatever cames to mind raquo dapreacutes (Kaner 1988)

Comme nous pouvons le constater lauteur a deacutefinit le TE comme la conception et

lexeacutecution de tests agrave temps reacuteel degraves quune nouvelle ideacutee de test seacutemerge sans perdre du

temps dans la planification et la preacuteparation de tests formels qui pourront devenir obsolegravetes agrave

la prochaine version vue linstabiliteacute du systegraveme

31

Agrave loccasion du 7egraveme atelier de Los Altos sur le test du logiciel les praticiens ct les

chercheurs participants ont tous collaboreacute pour deacutefinir le TE Ils ont accentueacute certaines des

caracteacuteristiques communes de leurs vues et se sont mis daccord sur les caracteacuteristiques de

TE citeacutees ci dessous (Kaner Tinkham 2003a)

bull Interactif

bull Combinaison de la cognition et lexeacutecution

bull Creacuteatif

bull Megravene agrave des reacutesultats rapides

bull Diminue larchivage des documents de test

En 2002 dans le premier livre qui preacutesente les ideacutees et les principes de la penseacutee laquotest piloteacute

par le contexteraquo CDS Bach et al(2002) ont deacutefini le terme exploration comme une

interrogation deacutetermineacutee cest agrave dire une navigation avec une mission geacuteneacuterale sans itineacuteraire

sceacutenariseacute

laquoBy exploration we mean purposejiil wandering navigaling Ihrough a space wilh a general mission bul wilhoU a pre-seripIed roule Exploralion involves conlinuols learning and experimenling ()gtgt dapregraves (Bach ct al 2002)

Ces mecircmes auteurs ont preacutesenteacute le TE comme une technique de test ougrave le testeur apprend le

produit logiciel son marcheacute ses risques et ses deacutefauts anteacuterieurs tout au long de lactiviteacute de

test pour concevoir des nouveaux tests plus puissants gracircce agrave leacutevolution et agrave la maturiteacute de

ses connaissances (Bach et al 2002)

Kaner et Tinkham (2003a) ont deacutefini le TE comme nimporte quelle activiteacute de test dans la

mesure ougrave le testeur controcircle activement la conception des tests Pendant que ces tests

sexeacutecutent il utilise linformation reacutesultante pour concevoir de nouveaux tests Par cette

proposition les auteurs tendent agrave geacuteneacuteraliser la deacutefinition au test sceacutenariseacute (TS) qui pourrait

ecirctre exeacutecuteacute dans certaines situations dune faccedilon exploratoire comme nous allons le voir

dans les lignes qui suivent

Cependant la deacutefinition la plus freacutequente dans la litteacuterature est celle donneacutee par Bach (2003)

32

11 deacutefinit le TE comme lapprentissage la conception et lexeacutecution simultaneacutee des tests

Le TE a eacuteteacute reconnu par le guide Swebok (2004) comme une technique valide de test

Cependant il relie lefficaciteacute de TE agrave la connaissance de lingeacutenieur logiciel ou le testeur

Dapregraves les deacutefinitions ci-dessus nous pouvons deacuteduire les proprieacuteteacutes maicirctresses de TE

bull Lapprentissage lexploration la conception et lexeacutecution des tests se font

simultaneacutement Autrement dit les tests ne sont pas deacutefinis agrave lavance comme les cas de

tests seeacutenariseacutes

bull Lactiviteacute de test est guideacutee agrave chaque moment par les reacutesultats des tests anteacuterieurs dans

une boucle interactive dappreacutehension du logiciel sous test

Le TE nexige pas la disponibiliteacute des exigences du logiciel du fait quil se fonde sur

lexploration et lapprentissage pendant le test

bull Centreacutee autour de la deacutetection des deacutefauts cest-agrave-dire orienteacute vers le reacutesultat plutocirct que

la preacuteparation la documentation ct larchivage des cas de tests

Nous pouvons constater de ces proprieacuteteacutes quil y une diffeacuterence claire entre le TE et le TS La

reacutealiteacute des pratiques de test deacutemontre que cette diffeacuterence est inaperccedilue du fait que mecircme

une activiteacute de TS pourrait ecirctre exeacutecuteacutee dune faccedilon exploratoire Un exemple clair de telle

situation apparaicirct quand le testeur deacutevie de ses proceacutedures de tests et utilise lexploration

pour explorer un deacutefaut pendant lexeacutecution de ses tests sceacutenariseacutes (Kaner Tinkham 2003a)

Nous pouvons donc conclure que nimporte quelle activiteacute de test logiciel reacutealiseacutee par un ecirctre

humain pourrait ecirctre exploraoire agrave un certain degreacute Selon Bach (2003) nimporte quel effort

de test tombe quelque part sur un continuum (figure 31) dont un des pocircles repreacutesente le TS

ougrave le testeur suit exactement les proceacutedures de tests sceacutenariseacutes dans chaque deacutetail et lautre

pocircle repreacutesente le TE le plus libre (Freestyle Exploratory Testing) ougrave les ideacutees de test

eacutemergent au moment de leur exeacutecution

33

Figure 31 Continuum repeacuterant lactiviteacute de test (Adapteacute et traduit de Bach 2007)

Test Test

sceacutenariseacute Scripts vagues Fragments de Chartes Rocircles

exploratoire libre

cas de tests 1 1

La figure 31 situe plusieurs variantes de test entre les deux paradigmes le TE et le TS

Chacune de ces variantes accentue un niveau de formalisme de deacutetail de documentation et

de controcircle par rapport au TE libre Elle pourrait prendre la forme des rocircles ou des

responsabiliteacutes pour chaque membre de Jeacutequipe de test sur une partie du logiciel Elle

pourrait prendre aussi la forme des chal1es qui sont plus preacutecises que les rocircles Ces chartes

identifient la dureacutee de Ja mission avec une liste preacutecise des items agrave tester Les deux derniers

types sont les deux modegraveles de TE les plus proches de TS Tout dabord les fragments de cas

de test qui poulTaient speacutecifier les mecircmes eacuteleacutements que Speacutecification de Cas de Tes dans la

norme IEEE 829 sans speacutecifier toutefois les deacutetails fins comme le eas de test sceacutenariseacute

Quant aux scripts vagues ils sont plus preacutecis que les fragments de cas de test et similaires

aux proceacutedures Ils contiennent les eacutetapes agrave suivre pour accomplir la mission de tesl mais

sont moins deacutetailleacutees que celles-ci ct neacutecessitent de lexploration pour les accomplir Avant

de fermer celle parenthegravese notons que certaines organisations ont uti liseacute les patrons JEEE

829 speacutecialement les speacutecificalions des cas de tests pour inteacutegrer le TE dans leurs pratiques

de test avant lintroduction du concept de laquoSession Based Test Managemenl raquo (Amland et

Vaga 2002)

34

32 Processus de test exploratoire

Le processus de TE est un processus tridimensionnel Tel quillustreacute sur le tableau 31 ces

dimensions sont produit qualiteacute et techniques (Bach 2003) Selon lauteur un testeur

exploratoire teste un produit logiciel eacutevalue sa qualiteacute en utilisant diverses techniques

Chaque case dans la grille ci-dessous repreacutesente un aspect du proceSSllS de TE Le testeur

exploratoire peut choisir nimporte quel point de deacutepart et suivre nimporte quel chemin dans

la grille jusquagrave la fin de la session de test il condition que les neuf tacircches soient couvertes

pendant le cycle de test et gue chacune des trois activiteacutes principales apprentissage

conception de tests et exeacutecution de tests donnent un reacutesultat tangible

Tableau 31 Grille des tacircches de test exploratoire (Adapteacute ct traduit dAmland 2002a)

Grille des Apprentissage Conception de Exeacutecution de tests tacircches tests

Produit Deacutecouvrir les eacuteleacutements du Deacutecider quoi tester Observer le (couverture) produit comportement du

nrnrlilil

Qualiteacute Deacutecouvrir comment le produit Penser aux Evaluer le (Oracle) devrait fonctionner problegravemes de comportement

qualiteacute possibles contre les preacutevisions

Techniques Deacutecouvrir les techniques de Choisir et appliquer Configurer et conception des tests qui les techniques de exercer le produit peuvent ecirctre utiliseacutees conception de tests

bull Les notes de Les tests Les problegravemes

tests trouveacutes

Selon Bach (200 J) le TE peut ecirctre pratiqueacute selon un plan preacutevu qui nest pas neacutecessairement

rigoureux Du fait quun plan rigoureux exige la certitude et implique la perfection Cellcs-ci

ne pourraient pas ecirctre atteintes dans une activiteacute de TE qui se fonde sur lexploration ct

lapprentissage du logiciel pour identifier cc qui doit ecirctre testeacute Cependant Bach signale

35

quun bon TE est une activiteacute planifieacutee et la preacuteparation de quelques notes sur la strateacutegie agrave

suivre et les eacuteleacutements du logiciel agrave aborder dans le test pourraient ecirctre tregraves utiles

En ce qui concerne les types de TE deux types ont eacuteteacute traiteacutes dans la litteacuterature le premier

est le test exploratoire libre (Freestyle Exploratory Testing) Cest un test qui se fait sur des

intervalles limiteacutes de temps quon appelle sessions chacune munie dune charte La charte

deacutecrit la mission de test et parfois identifie quelques tactiques et techniques de test pouvant

ecirctre utiliseacutees pour exeacutecuter cette mission La cha11e pourrait ecirctre choisie par le testeur ou

assigneacutee par le responsable du test Les reacutesultats officiels de ce type sont constitueacutes seulement

des bogues deacutetecteacutes pendant la session de test (Bach 2003) Le deuxiegraveme type de TE est le

test exploratoire geacutereacute par session (Session Based Test Management SBTM) Cest une

approche structureacutee de TE introduite par Jonathan Bach (2000) pour controcircler le TE libre

Dans ce type de TE les reacutesultats officiels sont constitueacutes des bogues deacutetecteacutes dans la session

de test et un rapport de session qui fait lobjet dune eacutevaluation par Je responsable de test Les

meacutecanismes et les meacutetriques de ce type de TE vont ecirctre eacutevoqueacutes en deacutetail dans la section qui

suit

33 Test exploratoire geacutereacute par session (SBTM)

Lapparition du TE dans sa version originale cest-agrave-dire tel que preacutesenteacute au deacutebut un

processus libre et informel a susciteacute beaucoup de critiques de la part des praticiens et des

professionnels Ces critiques eacutetaient centreacutees sur le manque de controcircle et de mesure qui sont

importants et cruciaux dans Jindustrie de test de logiciel En effet le fait que le TE ne soit

pas sceacutenariseacute ni reacutepeacutetitif et qu j] deacutepend fortement de la creacuteativiteacute du testeur a rendu difficile

le controcircle et le suivi de la progression de projet de test Compte tenu de ces faiblesses les

intervenants dans le domaine de test ont trouveacute difficile dessayer ou dintroduire le TE tel

que preacutesenteacute la premiegravere fois comme une meacutethodologie de tes

Pour paJJier ces problegravemes Jonathan Bach (2000) a proposeacute une nouvelle approche de TE

nommeacute Test geacutereacute par session (Session Based Test Management (SBTM) Le but de

lapproche est de rendre Je TE plus responsable (Accountable) ct dintroduire la mesure et le

controcircle neacutecessaires pour la gestion de projet de test Lideacutee principale de la meacutethode SBTM

est de planifier et diviser la mission geacuteneacuterale de test en plusieurs sessions Une session est un

36

intervalle de temps ininterrompu qUI pourrait durer de 60 agrave 120 minutes (BachJ

2000)Chaque session est identifieacutee par une charte qui deacutecrit la mission de test agrave remplir

Nous pouvons dire que cest un plan de haut niveau son rocircle est de speacutecifier les tacircches de test

agrave remplir ainsi que quelques tactiques et techniques pour les exeacutecuter Notons que la

granulariteacute de deacutetails de chaque charte varie selon limportance de celle-ci en termes de

risque et de la difficulteacute de la mission

Selon Jonathan Bach (2000) chaque session devrait ecirctre diviseacutee cn trois eacutetapes qUI

comportent autant de meacutetriques pour controcircler la porteacutee de travail du testeur Ces meacutetriques

sont

bull Preacuteparation de test le pourcentage du temps de la session consacreacute agrave linstallation

de lenvironnement de test (configurer mateacuteriels de test lire quelques manuels etc)

bull Conception et exeacutecution de tests le pourcentage du temps de la session passeacute dans

lexploration et le test

investigation et rapport de bogues Je pourcentage du temps de la session passeacute dans

la recherche et linvestigation lors de lapparition dun comportement inattendu du

logiciel Plus le temps passeacute sur le rapport des bogues

Le testeur devrait rapporter aussi lestimation du temps passeacute sur la chartc par rapport au

temps passeacute sur laquo lopportuniteacute raquo Lopportuniteacute cest le test effectueacute par le testcur qui nest

pas inclus dans la charte de session puisque le rocircle de lapproche SBTM scion Jonathan

Bach (2000) est dintroduire le controcircle et la mesure sur le TE libre tout en gardant ses

aspects essentiels que soient limprovisation lexploration et la creacuteativiteacute

De plus le rapport de session devrait rapporter les bogues les problegravemes et Ics notes Les

problegravemes sont les questions et les obstacles relieacutes au processus du test Quant aux notes

elles preacutesentent des ideacutees et des pistes qui peuvent amener agrave la creacuteation de nouveaux chartes

de test Le rapport de chaque session fait alors lobjet dune eacutevaluation pendant le deacutebriefing

avec le responsable du test

37

Figure 32 Cadre dapplication de SBTM (Inspireacute de James et Wood 2003)

Identification des chartes de

test

~ __ ________J___ _ __ ~

1 ------ 1 Estimation de Deacutefinition de 1 leffort de test ~ la session ou 1 1

neacutecessaire Ajustement

Planification continue 1

1____shy _shy -i-_shy - _-- ___j

Non La charte compleacuteteacutee

oui

Tel quillustreacute agrave la figure 32 au deacutebut de Jactiviteacute du test le responsable du test identifie les

chartes de tests et leffon neacutecessaire pour accomplir chacune delles Apregraves Jexeacutecution de

chacune de ces chartes le responsable rencontre le testeur pour eacutevaluer son travail Suite agrave ce

deacutebriefing Ic responsable deacutecidera si lexeacutecution de cbarte est compleacuteteacutee ou si la session

devrait ecirctre ajusteacutee et prolongeacutee pour compleacuteter le test de charte Le responsable du test

pourrait aussi ajouter de nouvelles chal1es pour explorer les notes rapporteacutees par le testeur

De ce fait le processus didentification de chanes est un processus de planification continue

(Wood ct James 2003) se change reacuteguliegraverement pendant lactiviteacute de test au fur et agrave mesure

que des nouvelles infonnations apparaissent pendant Jexeacutecution des chanes Les reacutesultats de

sessions de tests sont la plupart du temps rassembleacutes dans une base de donneacutees Ainsi le

pourcentage de sessions compleacuteteacutees les bogues rapporteacutes et le rendement des testeurs

38

pourraient ecirctre retraceacutees par les responsables du test Les renseignements sur la progression et

le statut de lactiviteacute de test pourraient ecirctre disponibles agrave chaque moment de projet En effet

les mesures collecteacutees pendant Je test et le deacutebriefing permettent destimer la productiviteacute ou

le rendement de chaque membre de leacutequipe de test pendant le projet de test en cours Cela

avec le nombre de sessions compleacuteteacutees pourrait aider dans lestimation de quantiteacute du travail

restante avant la fin du cyc le de test

Une expeacuterience dutilisation de cette approche a eacuteteacute preacutesenteacutee par (Lyndsay et van Eeden

2003) Les auteurs ont proposeacute des meacutethodes pour controcircler la porteacutee de test et eacutevaluer et

mesurer la couverture de test Les reacutesultats de cette expeacuterience seront abordeacutes en deacutetail dans

le chapitre IV

34 Les styIes ct les techniques dexploration

Depuis lapparition de TE plusieurs praticiens et chercheurs se penchaient sur leacutelaboration

des techniques et des modegraveles dexploration (Bach et Jonathan Bach 2006 Bach et Kaner

2004 Amland 2002b) Dans cette perspective Amland (2002b) ont proposeacute quelques styles

et techniques pour effectuer le TE lis incluent entre autres

bull Les intuitions sont les ideacutees que le testeur pourrait geacuteneacuterer en se basant sur ses

preacutedictions ses compeacutetences et son expertise

bull Les modegraveles il sagit de certains diagrammes et modegraveles qui peuvent aider le testeur

dans lappreacutehension du logiciel et la conception de tests Ils incluent entre autres

o Diagramme darchitecture consiste agrave construire ou concevoir un diagramme

darchitecture du logiciel sous test incluant ses interfaces son flux de donneacutees et

ainsi de suite En pratique ce travail se fait la plupart du temps pendant des reacuteunions

de groupe cntre les testeurs et les programmeurs Souvent lidentification de chartes

de tests et les responsabiliteacutes se fait agrave cette eacutetape ougrave chaque testeur deacutetermine sa

mission convenablement aux parties du logiciel comprises

39

o Digrammes deacutetats consiste agrave creacuteer un diagramme repreacutesentant jes modes

opeacuterationnelles les actions et les entreacutees possibles du logiciel Selon Amland (2002b)

ce digramme est un outil utile pour exposer les contradictions du logiciel

o Modegraveles de deacutefaillances consiste agrave utiliser un catalogue de bogues typiques pour

concevoir les cas de tests Le testeur exploratoire peut utiliser ses expeacuteriences

anteacuterieures pour construire ce catalogue ou utiliser en un de la litteacuterature (Kaner et

aL 1999)

bull Exemples il sagit de certains exemples dutilisation du systegraveme qui peuvent indiquer

les anomalies ct les deacutefauts existants Ils incluent entre autres

o Les cas dutilisations il sagit de deacuteterminer les utilisateurs du systegraveme et les tacircches

fonctionnelles pour chacun dentre eux ensuite on creacutee des tests qui reflegravetent leurs

utilisations

o Opeacutera savon il sagit de geacuteneacuterer des sceacutenarios dutilisations du systegraveme sous test en

exageacuterant dans quelques-unes de ses aspects par exemple en utilisant des valeurs

extrecircmes (limites) pour le mecircme sceacutenario

bull Les interfeacuterences il sagit de certaines actions qui peuvent nuire agrave Jexeacutecution normale

du systegraveme comme des arrecircts subits la concurrence avec dautres systegravemes etc Ces

interreacuterences peuvent reacuteveacuteler des deacutefauts dans le logiciel

bull Gestion derreurs il sagit de veacuterifier que Je 10gicieJ gegravere bien les erreurs dutilisation

autrement dit de veacuterifier que les messages derreurs se deacuteclenchent au bon moment et

SOllS les bonnes conditions

Il faut rappeler que le questionnement constitue le cœur de TE Il constitue la base de

nimporte quelle tcchnique ou style dexploration La qualiteacute du TE effectueacute deacutepend de la

qualiteacute des questions geacuteneacutereacutees agrave propos du produit sous test (Bach 2003 Kaner Tinkham

40

2003b Kaner Amland 2002b) Dans le but de faciliter la tacircche du testeur exploratoire dans

leacutelaboration des questions et des strateacutegies efficaces quelques praticiens et chercheurs ont

proposeacute quelques modegraveles comme le modegravele danalyse proposeacute par Bach (1996) qui est

illustreacute agrave la figure 33 et les modegraveles dattaques du logiciel proposeacutes par Whittaker (2003)

Figure 33 Heuristic Test Strategy Model (Adapteacute et traduit de Bach 1996)

Lenvironnement du projet de test

Les critegraveres de Les techniques de Les eacuteleacutements du qualiteacute test logiciel

Qualiteacute perccedilue

Ce modegravele preacutesente quatre secteurs principaux chacun eacutetant un indicateur que le testeur peut

utiliser pour deacuteterminer linformation dont jl a besoin pour concevoir une strateacutegie de test

Lobjectif immeacutediat de ce modegravele est donc de guider la reacuteflexion des testeurs exploratoires

lorsquils creacuteent les tests Ses principaux composants sont

bull Lenvironnement de projet inclut les ressources les contraintes et dautres facteurs

qui peuvent aider ou nuire au processus de conception et dexeacutecution des tests

(client calendrier eacutequipement etc)

bull Les eacuteleacutements du produit sont les aspects visibles ou invisibles du produit comme les

structures de donneacutees les interfaces etc

41

bull Les critegraveres Je qualiteacute sont les nonnes et les caracteacuteristiques de qualiteacute que le logiciel

devrait respecter Ces critegraveres permettent au testeur de deacuteterminer les problegravemes dans

le logiciel sous test

bull Les techniques de tests sont les strateacutegies neacutecessaires pour concevoir les tests Le

choix des techniques de test deacutepend de lenvironnement de projet les eacuteleacutements du

produit sous test el les critegraveres de qualiteacute viseacutes dans le projet de test en cours

bull La qualiteacute perccedilue est le reacutesultat preacutevu du test

Lenvironnement de projet les critegraveres de qualiteacute et les eacuteleacutements du produit sont tous

combineacutes avec les techniques de test afin de deacuteterminer la qualiteacute perccedilue du produit Selon

Kaner et Bach (2004) le modegravele aide le testeur exploratoire agrave deacuteterminer ce qui est doit ecirctre

testeacute Ainsi les attributs de qualiteacute les plus importants dans le projet (les types de problegravemes

agrave chercher pendant lactiviteacute de test) les aspects de projet qui pourraient faciliter ou

contrarier lactiviteacute de test en cours La reacuteflexion sc]on ces trois axes pourrait geacuteneacuterer des

ideacutees de test inteacuteressantes qui peuvent ecirctre mises en œuvre en respectant les contraintes et les

ressources du projet

Nous croyons que les secteurs deacutecrits dans cc modegravele danalyse sont semblables et ont les

mecircmes utiliteacutes que les secteurs identifieacutes dans le plan de test IEEE 829 (Annexe B)

Cependant le choix dun style speacutecifique dexploration ou tactique particuliegravere de TE deacutepend

selon Kaner et Tinkham (2003b) de facleurs deacutecrits ci-dessous

bull Les expeacuteriences anteacuterieures

bull Les qualifications

bull La personnaliteacute SUl10ut le modegravele dapprentissage

bull Les connaissances anteacuterieures sur lapplication sous test

Selon ces mecircmes auteurs le facteur le plus pertinent est le modegravele dapprentissage qUi

repreacutesente la faccedilon dont la personne choisit et traite linformation (Kaner Tinkham 2003b)

Cependant cette hypothegravese est theacuteorique et nest pas toujours confirmeacutee par une eacutetude

empIrIque

42

35 Conclusion

Nous avons donneacute dans ce chapitre un aperccedilu global sur la plupart des aspects touchant au

TE en commencent par sa deacutefinition et les concepts principaux du son processus Puis nous

avons preacutesenteacute lapproche SBTM et ses meacutecanismes En terminant nous avons proposeacute

quelques techniques et modegraveles dexploration Tout le mateacuteriel dont nous avons discuteacute dans

ce chapitre a eacuteteacute eacutelaboreacute dans le but daider et encourager les testeurs ct les organisations agrave

adopter le TE Mais comment les entreprises vont adopter cette nouvelle approche et quels

sont les motifs et les raisons qui les ont pousseacutees agrave essltlyer et utiliser le TE en mettant agrave

leacutecart la pratique sceacutenariseacutee habitueJJe Nous allons proposer des reacuteponses agrave toutes ces

questions dans la revue de litteacuterature de quelques travaux et eacutetudes de cas dans le chapitre

qui suit

41

CHAPITRE IV

REVUE DE TRAVAUX RELIEacuteS

Dans ce chapitre nous allons preacutesenter une revue des travaux de recherches acadeacutemiques et

professionnelles traitant du test exploratoire (TE) Dans la premiegravere partie nous deacutecrirons les

reacutesultats de la seu le recherche acadeacutemique existante agrave date Elle met laccent sur les raisons et

les faccedilons dutilisation de TE et recense les beacuteneacutefices ct les impcrfcctions perccedilus par les

praticiens dans lindustrie de test Puis nous proposerons quelques expeacuteriences dutilisations

de TE qui ont fait lobjet de plusieurs confeacuterences internationales Noire but sera de deacutefinir et

de comprendre comment et pourquoi les praticiens adoptent et adaptent le TE dans lindustrie

de test Cela va nous permettre didentifier les facteurs influenccedilant ladoption ct ladaptation

de lapproche dans lindustrie Ces facteurs vont nous aider dans la construct ion de notre

cadre comparatif qui va guider notre analyse comparative entre les deux approches le test

seeacutenariseacute (TS) et le test exploratoire (TE)

Eacutetude de Itkonen et Rautiainen ( 2005)

La croissance remarquable dutilisation de TE dans lindustrie de test logiciel el la promotion

eacutetendue de son efficaciteacute par quelques praticiens ont motiveacute les auteurs I1koncn Cl Rautiaincn

(2005) agrave eacutetudier lapproche afin de deacutevoiler ses beacuteneacutefices annonceacutes Ils ont retenu la question

suivante laquo pourquoi ct comment les compagnies utilisent-elles le TE raquo pour aborder leur

recherche Dans le but de reacutepondre agrave cette question ils ont entrepris trois eacutetudes de cas

descriptives aupregraves de trois entreprises finlandaises Une dentre elles est petite avec environ

10 employeacutes travaillant dans le deacuteveloppement du logiciel ct na quun seul produit sur le

marcheacute au moment de lenquecircte Sa meacutethodologie de test sc fonde sur le TE due agrave

limmaturiteacute de son processus de deacuteveloppement Les deux autres entreprises sont

moyennes avec environ 30 et 40 employeacutes dans le deacuteveloppement du logiciel Ses produits

44

ont eacuteteacute sur le marcheacute pe~dant plusieurs anneacutees Leurs meacutethodes de test incluent les deux

approches de test le TE et le TS

Itkonen et Rautiainen (2005) ont eacutelaboreacute sept interviews theacutematiques semi-slruclureacutees avec

les praticiens effectuant le TE dans les trois entreprises Ils ont intervieweacute successivement un

seul testeur de la plus petite entreprise participante dans leacutetude qui avait utiliseacute le TE

seulement deux fois avant (entrevue Puis quatre testeurs de la deuxiegraveme entreprise ougrave le TE

a eacuteteacute introduit dans la meacutethodologie de test six mois avant les entrevues Enfin deux testeurs

de la plus grande entreprise dans lenquecircte ou le TE avait eacuteteacute utiliseacute et ameacutelioreacute pendant

quatre ans Les auteurs ont utiliseacute des thegravemes et des questions ouvertes et neutres afin de

recueillir les opinions et les expeacuteriences reacuteelles des intervenants en mettant lemphase sur les

raisons et les modes dutilisation du TE dans les trois entreprises eacutetudieacutees En mecircme temps

ils ont recenseacute les imperfections et les beacuteneacutefices du TE tels que perccedilus par les praticiens

Parallegravelement agrave leur eacutetude descriptive ltkonen et Rautiainen (2005) ont recueilli des donneacutees

quantitatives sur le TE afin den mesurer la productiviteacute

411 Les raisons dutilisation du test exploratoire

Les reacutesultats de cette eacutetude ont indiqueacute que Je TE est utiliseacute pour les raisons ugrave savoir

bull La difficulteacute de concevoir des cas de test sceacutenariseacutes deacutetailleacutes ugrave cause de jinterdeacutependance

entre les uniteacutes logiciel

bull Le besoin de tester Je logiciel du point de vue de lutilisateur final

bull Le besoin dexploiter la creacuteativiteacute et lexpeacuterience des testeurs dans la deacutetection des

deacutefauts importants

bull Le besoin de fournir aux deacuteveloppeurs un feedback rapide sur les nouvelles uniteacutes

logicielles

bull La capaciteacute du TE de sadapter aux contraintes des environnements dynamiques de

deacuteveloppement et les situations ougrave les exigences du logiciel manquent

45

412 Les modes dutilisation du test exploratoire

Les auteurs Itkonen et Rautiainen (2005) ont identifieacute en se basant sur les informations

recueillies aupregraves des intervieweacutes cinq modes dutilisation principaux de TE dans les trois

eacutetudes de cas reacutealiseacutees Selon les constations de ItkQnen et Rautiainen (2005) lintuition a eacuteteacute

utiliseacutee comme technique de base dans Je TE Aucune autre strateacutegie ou technique speacutecifique

dexploration na eacuteteacute utiliseacutee parmi celles proposeacutees par (Kaner et Bach 2004) Les auteurs

ont identifieacute les modes dutilisation suivants

Test exploratoire baseacute sur session deux des trois entreprises eacutetudieacutees utilisent le TE geacutereacute

par session connu sous Je terme Session Based Exploratory Testing (SBET) Il consiste agrave

utiliser le principe de la technique SBTM proposeacute dans le chapitre JIl sans impleacutementer les

meacutetriques de gestion proposeacutees par (Jonathan Baeh 2000)

Test fonctionnel dune uniteacute logicielle Il sagit de tester une uniteacute logicielle individuelle

directement apregraves limpleacutementation de celle-ci pour produire un fccdback rapide aux

deacuteveloppeurs tregraves tocirct dans le cycle de vie du logiciel

Test exploratoire fumigatoire (Smoke Exploratory Testing) Cc typc dc TE est utiliseacute par

la plus grande entreprise participante dans leacutetudc Il consiste agrave cxplorcr chaque vcrsion du

systegraveme agrave tester par leacutequipe de test avant le deacutebut de test sceacutenariseacute pour formuler une vue

globale sur la qualiteacute du systegraveme et sassurer que les reacuteparations sont proprement

impleacutementeacutees ct que les fonctions les plus cruciales fonctionnent sans se preacuteoccuper des

petits deacutetails

Test exploratoire de reacutegression deux des trois entreprises eacutetudieacutees utilisent Ic TE dans le

tcst de reacutegression pour veacuterifier que les modifications nont pas causeacute deffets inattendus agrave

dautres parties du logiciel 11 sagit dexplorer le systegravemc dans unc courte session sans

aucune planification Les reacutesultats de cette session sont informcllcmcnt communiqueacutes aux

deacuteveloppcurs En fait la limitation de ressources el du temps ont eacuteleacute les motifs principaux

pour utiliser Je TE dans un test de reacutegression au lieu dutiliser le lcsl de reacutegression habituel

par une reacutepeacutetition seacutelective des cas de tests deacutejagrave conccedilus

46

Test exploratoire libre ce type de test est perccedilu par les intervieweacutes dans la grande

entreprise comme une pratique systeacutematique et naturelle qui devrait se faire pendant

lexeacutecution des cas de test sceacutenariseacutes

413 Les beacuteneacutefices du test exploratoire

En ce qui concerne les beacuteneacutefices perccedilus de TE tous les intervieweacutes ont il lustreacute que la

souplesse et la flexibiliteacute de lapproche leur permettrait de tester en profondeur les uniteacutes

logicielles qui ne pourront pas ecirctre traiteacutees dans les cas de tests sceacutenariseacutes comme les

interdeacutependances entre les anciennes et les nouvelles uniteacutes logicielles (ltkonen ct

Rautiainen 2005) Selon les constatations de ces mecircmes auteurs la productiviteacute en terme de

nombre des deacutefauts deacutetecteacutes et limportance de ces deacutefauts a eacuteteacute perccedilue comme un beacuteneacutefice

Cependant les intervieweacutes ont relieacute la productiviteacute agrave lexpertise des testeurs dans le TE Ils

affirment que le TE ne poulTa pas ecirctre productif si le testeur na pas dcs connaissances

adeacutequates dans le domaine daffaire du logiciel agrave tester Ils ajoutent que la diffeacuterence dans

lattitude pendant le test joue un rocircle crucial dans la productiviteacute perccedilue de TE En effet le

testeur tend plus agrave veacuterifier lexactitude entre les reacutesultats observeacutes ct les reacutesultats preacutevus

identifieacutes dans les cas de test sceacutenariseacutes dans une activiteacute de TS Par contre dans le TE le

testcur aborde le logiciel avec une attitude laquo offensiveraquo Autrement dit il cherche les

deacutefaillances avec de la curiositeacute et un œil critique (ltkonen et Rautiainen 2005) Les

reacutepondants ont affirmeacute aussi que le TE est productif seulement dans les courtes peacuteriodes cie

test en consideacuterant le nombre dheures utiliseacutees et le nombrc de deacutefauts deacutetecteacutes Tandis quagrave

long terme il ne pourrait pas ecirctre productif agrave cause de la difficulteacute destimcr la couverture de

tests pendant lactiviteacute de test Par la suite quelques parties ou caracteacuteristiques du logiciel

peuvent ecirctre livreacutees sans ecirctre testeacutees (ltkonen et Rautiainen 2005)

414 Les lacunes du test exploratoire

Selon les constations de 1lkonen et Rautiainen (2005) la couverture limiteacutec est la plus grande

lacune de TE

Ccci a eacuteteacute mentionneacute par lous les intervieweacutes dans lenquecirctc quils ont entreprise

47

Les reacutesultats ont montreacute que la deacutependance de TE agrave la creacuteativiteacute et agrave lexpeacuterience des testeurs

a eacuteteacute perccedilue aussi comme un deacutesavantage du TE du fait que le TE est sujet aux erreurs

humaines

Malgreacute la profondeur et la rigueur de cette recherche elle est limiteacutee par le nombre et la taille

des entreprises participantes Ceci apparaicirct clairement agrave plusieurs reprises dans la recherche

ougrave les reacutesultats obtenus concernent une seule entreprise parmi les trois participantes Donc

nous ne pouvons pas savoir si les reacutesultats obtenus sont geacuteneacuteraux ou des cas isoleacutes En ce qui

concerne la productiviteacute de lapproche dans la deacutetection de deacutefauts la recherche na pas

proposeacute des preuves fiables En fait les donneacutees quantitatives collecteacutees ne peuvent pas ecirctre

deacutefinitives Agrave cause de labsence des donneacutees quantitativcs du TS qui pourraient constituer

une base de comparaison Leacutetude est quand mecircme un apport utile agrave lenrichissement de la

litteacuterature sur les justifications et les modes dutilisation du TE

42 Eacutetude de Petty (2005)

Petty (2005) preacutesente une expeacuterience dutilisation de lapproche Session Based Exploratory

Testing (SBET) comme une meacutethodologie primaire de test en remplacement dc la meacutethode

sceacutenariseacutee habituelle Cette derniegravere se trouvait incapable de sadapter aux changements

freacutequents des exigences du logiciel Alors lintroduction de la meacutethode SBET a eacuteteacute perccedilue

comme une solution vu les frustrations accumuleacutees de Jutilisation dc TS Ces reacutealiteacutes

reacutesident dans le changement continu des exigences et labsence du temps suffisant de test du

logiciel La meacutethode SBET adopteacute par Petty (2005) est inspireacutee dans unc grande partie de

celle proposeacutee par Jonathan Bach (2000) Cette meacutethodc a permis aux testeurs decirctre agiles

dans le sens ougrave ils ont eacuteteacute capables de sadapter agrave lincertitude et au changement de logiciel et

de tester adeacutequatement le logiciel agrave un coucirct optimal

Selon les constatations de Petty (2005) la chose la plus inteacuteressante dans la meacutethode SBET

est quelle a eacutelimineacute le besoin de retravailler ct de mettre agrave jour les cas dc tests sceacutenariseacutes

apregraves chaque changement du logiciel Ce temps selon lauteur a pu ecirctre invcsti dans le test et

Jameacutelioration de qualiteacute du produit logiciel

48

Petty (2005) a utiliseacute des pairs cest-agrave-dire que deux personnes sassoient agrave seul ordinateur et

exeacutecutent la mecircme mission de test Chacune de ces paires est composeacutee dun testeur et dun

deacuteveloppeur Selon les constatations de lauteur lutilisation de lapproche SBET en pair a

ameacutelioreacute consideacuterablement la qualiteacute de test effectueacute En effet dans une session de test par

pairs un membre de la paire peut se concentrer sur la conception des tests et lautre sur

lenregistrement et la reacutedaction de notes Les rocircles des membres de la paire sont eacutechangeacutes

plusieurs fois pendant la session Cela augmente la creacuteativiteacute et la concentration du membre

qui conccediloit les tests et eacutelimine la distraction qui pourrait ecirctre causeacute par lenregistrement des

notes Aussi la collaboration et le pa11age des connaissances tacites des membres de leacutequipe

pendant la session ont ameacutelioreacute la compreacutehension et lapprentissage du logiciel sous test

Notons que lutilisation de deacuteveloppeurs dans les pairs a permis de corriger les deacutefauts en

temps reacuteel sans avoir besoin denregistrer beaucoup de notes de session ni de les reproduire

ulteacuterieurement

Selon les constations de Petty (2005) le fait que lapproche SBET soit baseacutee sur lexploration

et lapprentissage a pousseacute les testeurs agrave simpliquer plus dans Je processus de conception et

de clarification des exigences pour pouvoir comprendre le produit logiciel et son domaine

daffaire Cela a eu des reacutepercussions positives sur la qualiteacute des tests effectueacutes et sur la

capaciteacute de deacutetecter des deacutefauts ulteacuterieurement pendant le test Les testeurs sont devenus plus

capables de diffeacuterencier entre un deacutefaut et un comportement normal du logiciel Ce concept

est connu sous le terme doracle de test Il sera abordeacute plus en deacutetail dans le chapitre VII

Selon les constatations de Petty (2005) lapproche SBET a eacuteteacute tregraves efficace dans le cas de

leur projet de test Ce projet se caracteacuterisait par le changement Uumleacutequent des exigences qui

sonl souvent communiqueacutees verbalement Par la suite la meacutethode SBET lui a permis de

pouvoir reacutepondre agrave ces changements rapidement Selon les constatations de lauteur le moral

de leacutequipe de test a augmenteacute consideacuterablement pendant le test du logiciel Agrave cause de

leacutelimination du fardeau habituel de la mise agrave jour des cas de tests lors de changement du

logiciel La communication entre les testeurs et les deacuteveloppeurs sest ameacutelioreacutee et

transformeacutee dune relation dadversiteacute agrave une relation de collaboration Cependant lauteur

souligne que la reacuteussite de la meacutethode SBET deacutepend fortement de lexpeltise et les

49

connaissances de domaine daffaires des membres de leacutequipe de test Petty (200S) souligne

aussi que la capaciteacute dapprentissage est plus rapide en TE quen TS Mais selon lauteur

cette capaciteacute deacutepend encore des personnes impliqueacutees

Linnovation de la meacutethode preacutesenteacutee par Petty (200S) est Jutilisation de paires composeacutees

des testeurs et des deacuteveloppeurs Cela permet de corriger les deacutefauts pendant les tcsts sans

avoir le besoin de les reproduire ulteacuterieurement La participation de testeurs dans la phase de

clarification et de deacutefinition dexigences a permis dameacuteliorer la qualiteacute de Joracle de test

Toutefois lauteur na pas preacutesenteacute de donneacutees quantitatives sur la productiviteacute de Japproche

SBET et le degreacute dameacutelioration reacutealiseacute par lintroduction de lapproche dans la

meacutethodologie de test En plus la taille de lentreprise ougrave sest deacuterouleacutee lexpeacuterience est petite

ce qui simplifie eacutenormeacutement la communication et la collaboration entre les testeurs et les

deacuteveloppeurs Par contre dans les grandes entreprises le projet de test est souvent seacutepareacute du

processus de deacuteveloppement (Pyhajarvi et aL 2003) Par conseacutequent nous ne pouvons pas

savoir si la faccedilon dadoption de lapproche SBET proposeacutee par Petty (200S) pourrait

sappliquer dans les grandes entreprises Cependant cette eacutetude est un apport utile agrave

lenrichissement de la litteacuterature sur les modes dadoption du TE surtout dans les petites

entreprises de deacuteveloppement du logiciel

43 Eacutetude de Lyndsay et van Eeden (2003)

Les auteurs Lyndsay et van Eeden (2003) deacutecrivent leur expeacuterience reacuteussie dans la mise en

oeuvre de la technique Session Based Exploratory Testing (SBET) Cette mise en oeuvre a

pris place dans une petite entreprise anglaise en sinspirant des travaux de Jonathan Bach

(2000) qui sont deacutejagrave abordeacutes dans le chapitre lll Lobjectif principal de limpleacutementation de

lapproche SBET eacutetait dintroduire le controcircle et la mesure sur jactiviteacute de lest ad-hoc

existant dans lentreprise (test exploratoire libre selon Bach (2003) parce que les testeurs

enregistrent les deacutefauts deacutetecteacutes dans le Bug Tracking System) Le choix de la technique

SBET eacutetait pour reacutepondre agrave un mandat dameacutelioration de la qualiteacute dune petite application

Web deacutejagrave testeacute en utilisant le test ad hoc tout en restant dans la limite des ressources

existantes Alors le manque du temps et de personnel ont pousseacute les auteurs agrave utiliser

lapproche SBET au lieu dutiliser un TS que les ressources disponibles ne le pcrmctlcnt pas

50

La meacutethode proposeacutee par Lyndsay et van Eeden (2003) se fonde sur les quatre eacuteleacutements cleacutes

citeacutes ci-dessous

Controcircle de la porteacutee du test Pour geacuterer la porteacutee de test les auteurs ont introduit le

concept de point de test Le terme point de test sous-entend une partie ou plusieurs concepts

du logiciel sous test neacutecessitant lexploration et la conception de plusieurs cas de test pour

remplir la mission de test de ce point Lobjectif de lintroduction de ce concept est davoir le

controcircle sur la porteacutee de test pendant le test de chaque version du logicieL Autrement dit ecirctre

capable de deacuteterminer ce qui doit ecirctre testeacute dans chaque version En effet labsence dune

liste de test deacutetermineacutee dans le processus ad hoc existant et labsence des exigences dans

lensemble de projet du deacuteveloppement a rendu difficile lidentification du volume de test

neacutecessaire de chaque version ou apregraves chaque changement En effet avant lintroduction de

lapproche SBET la porteacutee de test a eacuteteacute guideacutee par les deacutefauts trouveacutes et par les preacutedictions ct

les intuitions de testeurs sur les secteurs du logiciel devant ecirctre testeacutes Donc une liste de point

de test va permettre de seacutelectionner les parties devant ecirctre testeacutees de chaque version Ainsi

une liste de points de test va permettre deacutevaluer le statut et la progression de projet de test

simplifier la communication agrave linteacuterieur et agrave lexteacuterieur de leacutequipe de test deacuteviter la

duplication du travail agrave linteacuterieur de leacutequipe de test dans le sens ou une partie poulTait ecirctre

lesteacutee par plusieurs testeurs (Lyndsay et van Eeden 2003)

Controcircle du travail de leacutequipe de test les auteurs ont proposeacute le concept de test en session

pour controcircler le travail accompli par chaque testeur La session est un intervalle non

interrompu Dans une session de test le testeur se charge de lexeacutecution dune ou plusieurs

points de test et rapporte les deacutefauts trouveacutes et les questions rencontreacutees pendant lexploration

agrave la fin de la session de test Les questions megravenent souvent agrave des nouvelles pistes pour la

conception de dautres points de test Ce rapport de test fera lobjet dune revue et une

discussion avec le responsable de test Ce dernier eacutevalue le travail accompli par le testeur et

le guide vers dautres astuces ou strateacutegies si neacutecessaire (Lyndsay et van Eeden 2003)

Mesure de la couverture de tests selon Lyndsay et van Eeden (2003) la couverture de test

consiste agrave mesurer ce qui a eacuteteacute testeacute comme proportion de ce qui poulTait ecirctre testeacute

51

Selon ces mecircmes auteurs labsence des exigences documenteacutees et de cas de test sceacutenaliseacute a

rendu impossible dutiliser les meacutethodes formelles habituelles de mesure de couverture de

test dans lactiviteacute de test effectueacute par lapproche de test SBET (ces meacutethodes seront

abordeacutees en deacutetail dans le chapitre VII) Face agrave ceci les auteurs ont proposeacute une technique de

mesure de couverture de tests qui sadapte avec les caracteacuteristiques speacuteciales de lapproche

SBET Leur technique fondeacutee sur lestimation et leacutevaluation subjective de laquola testabiliteacuteraquo

sous-entend le pourcentage testeacute ou couvert par les tests de chaque point de test dans la

session de test Apregraves lexeacutecution de la session de test le responsable de test eacutevaluera le

travail accompli par le testeur et en mecircme temps veacuterifiera le pourcentage estimeacute de la

testabiliteacute rapporteacute par le testeur de chaque point de test Si le pourcentage est insuffisant et le

risque associeacute a ce point de test exige un pourcentage supeacuterieur leffort de test neacutecessaire

pour accomplir ce point de test est re-estimeacute (Lyndsay et van Eeden 2003) En calculant la

testabiliteacute de chaque point de test les auteurs ont pu calculer la couverture globale du produit

logiciel sous test agrave nimporte quel moment du processus de test en utilisant la formule

suivante

Couverture de test = la somme de temps de points de test compleacuteteacuteslestimation de la

somme de temps neacutecessaire pour accomplir les points de test restants

Mesure et hieacuterarchisation de risque les auteurs Lyndsay et van Eeden (2003) ont mesureacute

le risque de chaque point de test en terme de la probabiliteacute doccurrence dune deacutefaillance

associeacutee agrave ce point de test et )impact de cette deacutefaillance sur le fonctionnement du logiciel

Cela leur permis de classifier et destimer leffort neacutecessaire pour tester chaque point de test

et de prioriser les tacircches du test Autrement dit les points de test repreacutesentant plus de risque

recevront plus de tests

Selon les auteurs Lyndsay et van Eeden (2003) lintroduction de lapproche a eu des reacutesultats

immeacutediats et des reacutesultats agrave long terme En ce qui concerne les reacutesultats immeacutediats leacutequipe

de test a pu produire une meacutetrique de couverture utile degraves la premiegravere utilisation de

Japproche SBET Ce fait a eu une reacutepercussion positive sur la qualiteacute du produit parce que

les parties agrave grands risques du logiciel ont reccedilu plus dattention et plus de tests Lutilisation

52

de lapproche SBET a permis de controcircler le travail des testeurs apregraves lexeacutecution de chaque

session sans avoir le besoin decirctre sur place pendant le test En ce qui concerne la

productiviteacute les auteurs nont pas pu tirer de conclusions fiables agrave cause de labsence des

mesures quantitatives avant lintroduction de lapproche SBET

Cependant mecircme avec laugmentation du nombre derreurs trouveacutees dans les cinq mois qui

suivent lutilisation de SBET les auteurs Lyndsay et van Eeden (2003) nont pas pu savoir si

cette augmentation due a ljntroduction de lapproche SBET ou laugmentation de la

complexiteacute de lapplication et lajout de nouvelles fonctionnaliteacutes A long terme les auteurs

Lyndsay et van Eeden (2003) ont remarqueacute que le produit est devenu plus stable et que le

nombre de deacutefauts trouveacutes a diminueacute dune faccedilon signi ficative bjen que de nouvelles

fonctionnaliteacutes sajoutent toujours Aussi ils nont pas pu savoir si cette reacuteduction provenait

de Jameacutelioration de la qualiteacute du code ou de lincapaciteacute de lapproche SBET agrave deacutetecter

dautres deacutefauts Toutefois selon Lyndsay et van Eedcn (2003) lintroduction de la technique

a eu une reacutepercussion positive sur tout le projet de deacuteveloppement du fait quelle a inciteacute les

responsables de projet de deacuteveloppement agrave ameacuteliorer la globaliteacute du processus de

deacuteveloppement surtout la documentation Selon ces mecircmes auteurs quelques reacutesul1ats

intangibles ont eacuteteacute perccedilus suite agrave Jintroduction de SBET JI sagit de lameacutelioration de la

visibiliteacute agrave linteacuterieur et lexteacuterieur du processus de tcst

En geacuteneacuteral selon les auteurs Lyndsay et van Eeden (2003) lapproche SBET a eacuteteacute tregraves

efficace dans le cas de leur projet de test Elle a permis dintroduire Je controcircle et la mesure

sur le processus ad hoc existant Ces mecircmes auteurs soulignent que la meacutethode a permis

dencourager la communication entre les membres du test au lieu dutiliser la documentation

pour le faire Ils ajoutent que le deacutebriefing utiliseacute dans lapproche SBET apregraves lexeacutecution de

chaque session de test a permis de former les testeurs et leur apprendre les techniques de

tests Toutefois ils affirment que cetle meacutethode pourrait ecirctre moins efficace dans un

environnement de deacuteveloppement plus sophistiqueacute ]Is soulignent aussi que la qualiteacute de test

effectueacute deacutepend de la creacuteativiteacute et lexpertise des membres de leacutequipe de test

53

La taille et la nature de lapplication qui a eacuteteacute le sujet de cette eacutetude ne permettent pas de

geacuteneacuteraliser les reacutesultats de cette eacutetude La meacutetrique de couverture proposeacutee dans leacutetude est

subjective et deacutepend aussi de lexpertise du testeur Mais les ideacutees et les techniques de

mesures proposeacutees sont inteacuteressantes et initient plusieurs pistes de recherches afin

dameacuteliorer ladoption de lapproche SBET

44 Eacutetude de James et Wood (2003)

Les auteurs Wood et James (2003) deacutecrivent leur expeacuterience dutilisation de lapproche

Session Based Exploratory Testing (SBET) Alors lapproche SBET a eacuteteacute introduite pour

tester un logiciel destineacute agrave ecirctre utiliseacute dans les appareils meacutedicaux Les auteurs ont eu recours

agrave la technique SBET pour deux raisons la premiegravere raison est la moindre cougravet de lapproche

SBET qui leur a permis de lutiliser comme une meacutethode compleacutementaire agrave la meacutethode

sceacutenariseacutee de test Cette derniegravere a un coucirct consideacuterable agrave cause des frais de documentation

des tests Cette documentation doit ecirctre deacutetailleacutee et rigoureuse dans le domaine du test des

logiciels meacutedicaux afin de respecter les normes de la qualiteacute du systegraveme (Quality System

Regulation) La deuxiegraveme raison est que les auteurs ont cu besoin dune meacutethode de test

pouvant introduire linnovation et la creacuteativiteacute dans le test en leur permettant de deacutetecter les

erreurs manqueacutees par lapproche sceacutenariseacutee

Les auteurs ont utiliseacute lapproche SBET comme une meacutethode de test compleacutementaire agrave la

meacutethode sceacutenariseacutee principale Cette derniegravere est baseacutee sur la validation des exigences et la

veacuterification de code du logiciel sous test Le test de validation est centreacute sur la couverture des

exigences et le respect des standards Ccci neacutecessite une traccedilabiliteacute accrue entre les

proceacutedures de tests et les exigences initiales Selon James et Wood (2003) ce type de test ne

met pas lemphase sur la deacutetection des deacutefauts tant que le respect des exigences ct les normes

du domaine de deacuteveloppement du logiciel meacutedical Le test de veacuterification est baseacute sur la

couverture de code Ce type de couverture cherche agrave satisfaire un critegravere de couverture de

code par exemple 80 des blocs de code doivent avoir au moins un test qui les parcourt

Autrement lexeacutecution dun maximum de lignes de code possibles pour eacuteviter quun bogue

reste dans le logiciel agrave cause dune ligne de code non exeacutecuteacutee pendant les tests Selon James

ct Wood (2003) le test de veacuterification ne met pas Jaccent sur la deacutetection de deacutefauts tant gue

la couverture de code par les tests

54

Les faiblesses des deux meacutethodes de test le test de validation et le test de veacuterification ont

motiveacute les auteurs agrave introduire lapproche SBET dans le but de deacutetecter les deacutefauts qui

peuvent ecirctre manqueacutes par ces meacutethodes de test

James et Wood (2003) ont organiseacute le test en sinspirant de la meacutethode proposeacutee par Jonathan

Bach (2000) deacutejagrave preacutesenteacutee dans le chapitre III Au deacutebut ils ont planifieacute les chartes de test

et ont estimeacute leffort neacutecessaire pour rempl ir chacune dentre elles Pendant lexeacutecution de

chaque charte le testeur devrait enregistrer les deacutefauts deacutetecteacutes ct les opportuniteacutes

rencontreacutees Notant quune opportuniteacute sous-entend des nouvelles pistes de test deacutecouvertes

pendant Jexploration qui pourraient donner lieu agrave la creacuteation de nouvelles chartes Agrave la fin

de lexeacutecution de chaque charte les auteurs deacutebriefent le testeur pour eacutevaluer les reacutesultats

rapporteacutes et mettre agrave jour le plan des chartes si neacutecessaire

Selon Wood et James (2003) lapproche SBET est une meacutethode de test tregraves efficace dclns le

domaine de deacuteveloppement des logiciels meacutedicaux du fait quelle pourrait deacutetecter les

deacutefauts pouvant ecirctre manqueacutes par les autres meacutethodes de test Un autre avantage de la

meacutethode SBET signaleacute par ces mecircmes auteurs est la documentation produite pendant les tests

qui est tregraves appreacutecieacutee dans Je domaine de deacuteveloppement du logiciel meacutedical Les auteurs

soulignent que lapproche SBET a encourageacute la creacuteativiteacute cr linllovation de testeurs Cela a

pennis de deacutetecter des deacutefauts impol1ants dans le logiciel agrave moindre coucirct par rapport aux

meacutethodes sceacutenariseacutees traditionnelles tel quillustreacute agrave la figure 4 J

55

Figure 41 Coucirct de documentation versus linnovation dans le test (Adapteacute et traduit de

James et Wood)

r---------- -Qgt 1 1

1 Session Based 1 Qgt

-GS Exploratory ~

1 testino 1~ ------1----------~

= C

C 0 -c

sect 2-~

1l 1l 1

Test de verificatioo

1

1 J r----------

0 c 1 1 -= J -~

Test de -0 1 Validation 1 -(1)

0 1 1I

1 1J

Reacuteduit Moyenne Itleveacute

Coftt typique de documentation

En ce qui concerne la productiviteacute de lapproche SBET les auteurs James et Wood (2003)

soulignent quelle est plus efficace que les deux approches sceacutenariseacutees utiliseacutees le test de

veacuterification et le test de validation en se basant sur les reacutesultats publieacutes par (Joncs TCJones

1998) Ces reacutesultats ont montreacute que le test dutilisabiliteacute est plus efficace que le test de

veacuterification et le test de validation En faisant lanalogie entre Je test dutilisabiliteacute et le

SBET les auteurs ont pu conclure que lapproche SBET est plus cfficace que la meacutethode

sceacutenariseacutee cest agrave dire plus efficace que le test sceacutenariseacute de validation et de veacuterification En

effet selon James et Wood (2003) le test duti]isabiliteacute et Japproche SBET sont semb1abJes

agrave cause de trois raisons la premiegravere est que les deux se fondent sur le manuel dutilisateur la

deuxiegraveme que les deux seffectuent sur des pctitcs peacuteriodes seacutepareacutees connues sous le terme

de laquosession de testraquo et la troisiegraveme que les deux utilisent les talents et la creacuteativiteacute de testeurs

Toute fois James et Wood (2003) ont souligneacute que la qualiteacute de test effectueacute deacutepend des

qualifications et Jexpertise des testeurs qui exeacutecutcnt les tests Selon cs auteurs la meacutethode

SBET ne fournit quun protocole ou une structure dorganisation et de gestion mais ne

garantit pas la qualiteacute de test effectueacute ]Is ont souligneacute aussi que le rocircle de responsable de test

est crucial et infiuence la qualiteacute globale de test effectueacute du fait que ccst lui qui identifie et

56

deacutetermine la liste des eacuteleacutements de test et le contenu des chartes Par conseacutequent la couverture

de test de haut niveau deacutepend des compeacutetences et de lexpertise du responsable du test

Cette eacutetude montre que le TE pourrait ecirctre utiliseacute mecircme dans les domaines de test le plus

critique comme une meacutethode compleacutementaire agrave la meacutethode sceacutenariseacutee Agrave cause de sa valeur

ajouteacutee et son innovation dans la deacutetection des deacutefauts pouvant ecirctre manqueacutes par les

meacutethodes sceacutenariseacutees traditionnelles Cependant leacutetude na pas preacutesenteacute des donneacutees

quantitatives sur la productiviteacute de lapproche SBET et le degreacute dameacutelioration reacutealiseacute de

qualiteacute du logiciel testeacute

45 Eacutetude de Amland et Vaga (2002)

Les auteurs Amland et Vaga (2002) deacutecrivent une eacutetude de cas dutiJisation de TE en tant

quune strateacutegie de test primaire dans une entreprise norveacutegiennc Lintroduction de

japproche eacutetait pour tester un portail Web Linstabiliteacute et le changement freacutequent des

exigences et le manque du temps eacutetant les motifs principaux quc ont pousseacute les auteurs agrave

chercher une approche de test qui peut sadapter avec les contraintes changeantes de leur

projet de test a la place de lapproche sceacutenariseacutee habituelle qui eacutetait incapable de sadapter agrave

ces contraintes

En effet au deacutebut les auteurs ont commenceacute la preacuteparation de plan de test et des cas de test

formels neacutecessaires pour la mise en œuvre dune approche de test sceacutenariseacute Agrave cause de

labsence des exigences du systegraveme les auteurs ont utiliseacute le TE libre pour se renseigner sur

le logiciel planifier et concevoir les cas de tests Cependant les deacuteveloppeurs ou les auteurs

ont eu le mandat de tester le logiciel deacuteveloppeacute ont continueacute dintroduire des changements au

code De ce fait selon Amland et Vaga (2002) lapproche sceacutenariseacutee de test ne pourra pas

ecirctre rentable dans leur cas parce quapregraves chaque changement dans Je logiciel ils devront

retravailler les artefacts de test deacutejagrave conccedilus

Agrave cet effet Amland et Vaga (2002) ont deacutecideacute dutiliser le TE Cependant les auteurs ont

reacutealiseacute que la meacutethode de gestion ct de controcircle de TE a un rocircle deacutecisif dans la reacuteussite de

leur projet de test surtout si tout le temps disponible pour le test est seulement de deux jours

57

Alors Amland et Vaga (2000) ont geacutereacute le TE dune faccedilon proche de la meacutethode proposeacutee par

Jonathan Bach (2000) Ils ont preacutepareacute des directives pour les sept pairs participantes dans le

test dacceptation de portail En fait ces directives ont eacuteteacute eacutelaboreacutees agrave partir de plan de test

formel deacutejagrave conccedilu Ce plan identifie deacutejagrave les items du logiciel agrave tester et les items ne doivent

pas ecirctre testeacutes Ces items ont eacuteteacute utiliseacutes pour controcircler la couverture de tests Avant le deacutebut

de test les testeurs ont suivi une fonnation de deux jours puis un briefing de 20 minutes a eacuteteacute

mis en oeuvre pour annoncer aux testeurs les secteurs fonctionnels principaux quils doivent

tester En plus un controcircle aupregraves de testeurs pendant le deacuteroulement de test a aideacute les

auteurs dans la direction des testeurs en cas de deacuteraillement sur les directives

Selon les constatations de Amland et Vaga (2002) lexpeacuterience dutilisation de TE a eacuteteacute

fructueuse Toutefois ils affirment que la creacuteativiteacute et les connaissances des testeurs ct du

responsable du test chargeacute de la seacutelection de la liste des items agrave test cr sont essentielles dans le

TE et peuvent innuencer la qualiteacute du test

Malgreacute la reacuteussite de cette eacutetude de cas la taille ct la nature de lapplication ne permettent pas

de geacuteneacuteraliser les reacutesultats obtenus ni de tirer des conclusions fiables Toutefois cette

expeacuterience a introduit une situation reacuteelle ou le TE a eacuteteacute impleacutementeacute pour confrontcr les

contraintes changeantes de projet de test Cette eacutetude de cas nous a montreacute que les artefacts

seeacutenariseacutes formels pourront servir dans limpleacutementation de TE sans avoir lobligation

dutiliser les techniques proposeacutees par Jonathan Bach (2000) et Lyndsay et van Eeden (2003)

46 Synthegravese des reacutesultats des eacutetudes proposeacutees

Les eacutetudes que nous avons preacutesenteacutees dans ce chapitre nous ont pelmis de tirer plusieurs

conclusions dapregraves des expeacuteriences reacuteelles dutilisation de TE Ainsi elles nous ont permis

de comprendre comment les praticiens et les professionnels dans Jindustrie de test perccediloivent

le TE comment ils limpleacutementent dans la pratique pourquoi ils lutilisent les difficulteacutes et

les lacunes rencontreacutees lors de lutilisation de TE et finalement deacutelaborer une vue globale et

commune agrave partir de toutes les eacutetudes proposeacutees

58

Nous avons constateacute que les praticiens ne considegraverent que lapproche SBET comme un TE

tandis que le TE libre est consideacutereacute comme un test ad hoc (Lyndsay et van Eeden 2003

Amland et Vaga 2002) Ainsi tous les auteurs dans les eacutetudes de cas que nous avons

preacutesenteacutees adoptent une forme personnaliseacutee de lapproche SBET Autrement dit les auteurs

organisent lactiviteacute de test dans des sessions de test de dureacutee deacutetermineacutee chacune delles

produit des notes qui font lobjet dune eacutevaluation par le responsable de test Nous avons

constateacute aussi que ces eacutetudes ne mentionnent pas les techniques utiliseacutees pendant

lexploration et les tests malgreacute la diversiteacute des techniques proposeacutees par les concepteurs de

TE Kaner et Bach (2004) dont quelques-unes deacutejagrave eacutevoqueacutees dans le chapitre Ill En fait dans

la plupart des eacutetudes les testeurs utilisent leurs intuitions pour deacutetecter les deacutefauts nous

pourrons mecircme dire quil sagit dun test ad hoc planifieacute et structureacute

Toutes les eacutetudes que nous avons preacutesenteacutees dans ce chapitre ont montreacute que les changements

freacutequents du logiciel la pression de temps et la limitation de ressources en tcrme de budget

de test et de personnel sont les raisons principales pour utiliser le TE plus particuliegraverement

Japproche SBET Certaines eacutetudes (Itkonen et Rautiainen 2005 Lyndsay et van Eeden

2003 Amland et Vaga 2002) ont signaleacute Je manque de controcircle de couverture de test comme

une lacune du TE Toutes les eacutetudes (ltkonen et Rautiainen 2005 Petty 2005 Lyndsay et

van Eeden 2003 Wood et James 2003 Amland et Vaga 2002) ont signaleacute que la qualiteacute du

TE effectueacute deacutepend des quai ifications et de la creacuteativiteacute des testeurs De plus deux de ces

eacutetudes ajoutent que la qualiteacute de TE deacutepend aussi des compeacutetences et des qualifications du

responsable de test (Wood ct James 2003 Amland et Vaga 2002) La planification et le

controcircle de lapproche SBET ont eacuteteacute mentionneacutes comme dcs facteurs impol1ants de succegraves de

lactiviteacute de test (Lyndsay et van Eeden 2003 Wood ct James 2003 Amland et Vaga

2002)

En geacuteneacuteral nous avons constateacute que toutes les eacutetudes de cas ont eacuteteacute faites sur des petites

applications et avec des petites eacutequipes de test La collaboration et la communication entre

les membres de leacutequipe de test la concentration sur laccomplissement du travail de test

plutocirct que la documentation et la gestion de processus ont eacuteteacute les eacuteleacutements cleacutes de lapproche

SBET Ceux-ci nous ont pousseacute de faire janalogie enlre le deacuteveloppement du logiciel el le

59

test du logiciel autrement dit lanalogie entre lagiliteacute et la discipline du processus de

deacuteveloppement et linformaliteacute et la discipline de processus de test Nous allons aborder en

deacutetail au cours de notre eacutetude comparative dans le chapitre VII cette analogie que nous avons

lexploiteacutee pour construire notre cadre conceptuel de comparaison qui va nous permettre de

comparer les deux approches de test le TE et le TS

51

CHAPITRE V

LEacuteTUDE EMPIRIQUE

Dans ce chapitre nous preacutesentons les eacutetapes principales de notre eacutetude empIrIque Tout

dabord nous proposerons la motivation de leacutetude et la strateacutegie que nous avons choisie pour

laborder Puis nous preacutesenterons le scheacutema conceptuel de lexpeacuterience Par la suite nous

analyserons les reacutesultats recueillis et nous conclurons

Motivation de leacutetude

Depuis son apparition dans lindustrie du test Je test exploratoire (TE) se fait preacutesenter

comme une approche productive qui pourrait augmenter lefficaciteacute de Jactiviteacute de test en

termes de nombre et dimportance de deacutefauts deacutetecteacutes Selon Bach (2003) le TE pourrait ecirctre

plus productif que le test sceacutenariseacute (TS) Cependant lauteur na pas preacutesenteacute de preuves de

cette reacuteclamation agrave palt quelques anecdotes et expeacuteriences personnelles Un tour rapide sur

les reacutecentes publications de Kaner sur son site l montre que le TE se fait traiter comme une

innovation scientifique qui exploite et optimise la creacuteativiteacute et lexpertise du testeur dans la

deacutetection des deacutefauts importants qui ne pourraient pas ecirctre deacutetecteacutes par le TS Selon Kaner et

Bach (2005) Je TS transforme les testeurs en robots inefficaces Ces arguments nous ont

motiveacutee agrave faire une eacutetude empirique pour eacutevaluer la productiviteacute du TE Tout dabord nous

allons comparer les reacutesultats de TE recueillis de Jexpeacuterience avec les reacutesultats quantitatifs

publieacutes par ltokens et Rautiainen (2005) Puis nous proceacutederons agrave une analyse comparative

empirique enlre le TE et le TS en se basant sur les reacutesultats de notre eacutetude

Cependant dans la mise en ouvre de notre eacutetude empirique nous avons eacuteteacute confronteacutee au

1 wwwtcstingeducationorg

61

problegraveme du contexte expeacuterimental En effet dans un contexte industriel nous pouvons

utiliser comme instrument de lexpeacuterience un logiciel professionnel cest agrave dire un logiciel

deacuteveloppeacute dans Jindustrie de deacuteveloppement du logiciel Ce logiciel pourrait ecirctre testeacute avec

deux groupes un utilise le TS et lautre le TE Les donneacutees pourraient ecirctre recueillies

pendant Jactiviteacute de test et sur le site de production du logiciel testeacute Par la suite lanalyse

des reacutesultats de lexpeacuterience doit ecirctre faite sur deux niveaux le premier est de comparer le

nombre et limportance des deacutefauts deacutetecteacutes avant la livraison du logiciel cest agrave dire agrave la fin

de lactiviteacute de test Le deuxiegraveme est de comparer le nombre et limportance des deacutefauts

deacutetecteacutes apregraves Ja livraison du logiciel cest agrave dire dans le site dutilisation du logiciel testeacute

Cette strateacutegie pennettrait de mesurer la productiviteacute pendant et apregraves lactiviteacute de test Or la

mise en place dune telle expeacuterience neacutecessite lengagement dune entreprise de

deacuteveloppement du logiciel agrave participer agrave lexpeacuterience et agrave divulguer les informations de son

activiteacute de test Malheureusement nous navons pas pu trouver une entreprisc pour se plier agrave

ces contraintes Cela nous a obligeacutee agrave concevoir une nouvelle strateacutegie pour notre expeacuterience

dans le contexte acadeacutemique ougrave nous avons deacutecideacute de la faire

52 La strateacutegie de lexpeacuterience

Dans un contexte acadeacutemique lexpeacuterience pourrait ecirctre entreplise de deux faccedilons

diffeacuterentes la premiegravere consiste agrave faire lexpeacuterience de la mecircme faccedilon que si elle se deacuteroulait

dans le contexte industriel cest agrave dire nous divisons les sujets en deux groupes dont un

exeacutecute le TE et lautre le TS Nous pouvons mecircme aller plus loin et utiliser japproche

SBET pour controcircler la couverture de test et eacuteviter que les deacutefauts deacutetecteacutes soient dupliqueacutes

Quant au TS il poulTait ecirctre exeacutecuteacute de la mecircme faccedilon quen industrie Alors chaque sujet

exeacutecute des cas de tests correspondant agrave une partie du logiciel Finalement nous analysons le

nombre et limportance des deacutefauts rappol1eacutes pour deacuteterminer lapproche la plus efficace

Malheureusement nous navons pas pu utiliser cette strateacutegie pour deux raisons la taille du

programme utiliseacute dans lexpeacuterience et le manque dexpeacuterience des expeacuterimentateurs En

effet nous avons ducirc utiliser un petit programme dans lexpeacuterience afin de simplifier la

mission des sujets pendant Jactiviteacute de TE Cela pour eacutevitcr dobtenir des reacutesultats nuls qui

peuvent reacutesulter de lexeacutecution de TE si nous utilisons un trop grand logiciel

62

La deuxiegraveme raIson du choix de notre strateacutegie est le manque dexpeacuterience chez les

participants Ces sujets sont des eacutetudiants agrave lUQAgraveM Ils possegravedent une expeacuterience des tests

et de ses techniques limiteacutee agrave la couverture de ces matiegraveres dans le programme offert agrave

lUQAgraveM Nous avons cependant choisi les eacutetudiants du cours INF6160 Qualiteacute processus et

produits parce que cest dans ce cours que ces sujets sont abordeacutes le plus profondeacutement Cela

ne nous a quand mecircme pas permis dorganiser lactiviteacute de test de la mecircme faccedilon

professionnelle deacutecrite ci- dessus Lexpeacuterience consiste agrave utiliser les mecircmes sujets pour

exeacutecuter dabord le TE et le TS ensuite afin deacuteviter que les sujets apprennent les cas de tests

sceacutenariseacutes et les reacutepegravetent par la suite dans le TE Agrave cet effet nous avons programmeacute

Jexpeacuterience dans une seacuteance de cours de 2 heures 45 minutes pour exeacutecuter chacune de deux

approches de test Les eacutetudiants ont pris connaissance du deacuteroulement de lexpeacuterience dans

une seacuteance anteacuterieure ougrave le professeur a preacutesenteacute aux eacutetudiants une vue densemble du TE

Le sujet de lexpeacuterience et ses reacutesultats a constitueacute une partie de travail de session de cours

lNF6160 Alors chaque eacutetudiant participant dans lexpeacuterience a ducirc rappol1er ses reacutesultats et

les conclusions quil a pu tirer de Jexpeacuterience concernant les deux approches de test le TE

et le TS dans un rapport de fin de session Ceci a motiveacute les sujets agrave deacutelecter le maximum des

deacutefauts possibles el nous a garanti que les eacutetudiants ont pris Jexpeacuterience au seacuterieux

Nous avons proposeacute aux 56 sujets participants dans lexpeacuterience le programme agrave tester

accompagneacute de quelques modegraveles et techniques dexploration (Annexe C) pour les guider

pendant le TE et eacuteviter dobtenir des reacutesultats nuls Puis nous leur avons proposeacute les cas de

tests sceacutenariseacutes que nous avions preacutepareacute pour lactiviteacute de TS Alors tous les sujets ont

exeacutecuteacute les mecircmes cas de tests

Dans notre plan expeacuterimental les mecircmes sujets ont eacuteteacute utiliseacutes dans les deux traitements Ce

type deacutetude est qualifieacute de plan expeacuterimental agrave facteur unique agrave mesures reacutepeacuteteacutees sur les

mecircmes eacuteleacutements laquo Single Factor Experiments Having Reapted Measures on The Same

Elementsraquo (Winer 197 J p 105) Les reacutesultats ont eacuteteacute exploiteacutes de deux faccedilons di ffeacuterentes

la premiegravere lexploitation des reacutesultats de TE collecteacutes de notre expeacuterience et la deuxiegraveme

lexploitation des reacutesultats des deux activiteacutes de test et la comparaison des reacutesultats collecteacutes

Agrave cet effet nous utilisons dans celte analyse comparative lanalyse de variance ANOVA

63

proposeacute par Winer (1971 p lOS) Celte analyse nous a permet deacutevaluer leffet de

traitement cest agrave dire lapproche de test (T8 TE) sur la performance des sujets Celte faccedilon

de faire nous a permis deacutevaluer la productiviteacute de chacune des deux approches de test Cela a

aussi permis dexplorer la validiteacute de lhypothegravese proposeacutee par Kaner et Bach (2005) qui cite

que les testeurs juniors ne pourraient pas reproduire les cas de tests de la mecircme faccedilon que

lauteur ou le concepteur de ces cas de tests (le testeur senior) Aussi nous a permis

danalyser et de comparer les reacutesultats de TE de notre eacutetude empirique avec les reacutesultats des

travaux de recherches proposeacutes dans la litteacuterature par Itokens et Rautiainen (2005)

53 Le scheacutema de lexpeacuterience

531 Objectifs et hypothegraveses de lexpeacuterience

Comme le soulignent Lait et Rambach (1997) lidentification preacutecise des buts de leacutetude est

cssentielle agrave la mise en œuvre dune eacutetude expeacuterimentale Cette identification permet de

planifier et deacuteterminer les deacutetails de la perspective ou la strateacutegie suivie pour que lexpeacuterience

atteigne ses buts speacutecifieacutes De ce fait les aspects agrave eacutevaluer et les meacutetrigues agrave utiliser devront

ecirctre preacuteciseacutes et bien identifieacutes avant le deacutebut de lexpeacuterience Dans notre cas le but de

lexpeacuterience est de comparer la productiviteacute de TE et le T8 en termes de nombre et

dimportance des deacutefauts deacutetecteacutes Cela nous a permis deacutenoncer les hypothegraveses suivantes

Notre hypothegravese primaire est

Hl - le test exploratoire est plus efficace en terme de nombre de deacutefauts deacutetecteacutes que le test

sceacutenanseacute

Lhypothegravese nulle correspondante agrave celte hypothegravese est

Ho - il ny a pas de diffeacuterence entre le test exploratoire et le test sceacutenariseacute quant au nombre

de deacutefauts deacutetecteacutes

Notre hypothegravese secondaire est

H2 - le test exploratoire permet de deacutetecter des deacutefauts plus importants point de vue graviteacute

que le test sceacutenariseacute

64

532 La conception expeacuterimentale

Dans cette section nous preacutesentons la conception expeacuterimentale que nous avons faite pour

notre eacutetude empirique La conception et lanalyse de lexpeacuterience sont traiteacutees complegravetement

par (Winer 197 J) qui eacuteteacute utiliseacute comme reacutefeacuterence dans plusieurs eacutetudes expeacuterimentales

anteacuterieures (Wood et a1 ]997) Avant dintroduire les deacutetails de la conception choisie nous

deacutefinissons certains termes neacutecessaires agrave la compreacutehension de la conception de notre

expeacuterience

bull Variable indeacutependante est le facteur qui influence les reacutesultats de lexpeacuterience cest agrave

dire le facteur causal La manipulation des valeurs prises par cette variable permet

deacutetudier les effets de ces diffeacuterentes valeurs sur les reacutesultats Dans notre eacutetude la variable

indeacutependante est lapproche de test et ses valeurs possibles sont le TE et le TS

bull Variable deacutependante mesure les effets de la manipulation des variables indeacutependantes

Dans notre expeacuterience elle correspond au nombre et la seacuteveacuteriteacute des deacutefauts deacutetecteacutes

Dans notre expeacuterience nous al10ns eacutetudier leffet de lapproche de test (TE TS) surmiddot la

productiviteacute de lactiviteacute de test en utilisant un eacutechantillon composeacute de 56 sujets Chaque

eacuteleacutement de leacutechantillon applique les deux techniques de test sur le mecircme programme agrave

tester Donc nous avons un seul facteur qui peut influencer les reacutesultats de lexpeacuterience qui

est lapproche de test (TE TS) Selon (Winer J971) les contraintes de notre eacutetude empirique

correspondent agrave la conception proposeacutee par lauteur sous lexpression laquo expeacuterience agrave facteur

unique a mesures reacutepeacuteteacutees sur les mecircmes eacuteleacutementsraquo (Single Factor Experiments Having

Repeated Measures on the Same Elements)

533 Lcs instruments de leacutexpeacuterience

Les instruments de lexpeacuterience sont constitueacutes dun seul programme dans les deux activiteacutes

de test le TE el le TS JI sagit dun prognllnme de gestion des messages deacuteveloppeacute avec le

langage de programmation Jav3 Nous avons choisi le programme pour que sa taille et sa

complexiteacute facilitentmiddot lexeacutecution des deux techniques de test aux sujets (les eacutetudiants de cours

(NF 6160)

65

534 Le traitement expeacuterimental

En ce qui concerne le TS les sujets ont reccedilu en entreacutee le programme et les cas de tests que

nous leur avons conccedilus en utilisant un test fonctionnel (boicircte noire) Les sOlties sont les

deacutefauts deacutetecteacutes

Figure 51 Le traitement de test sceacutenariseacute

Les cas de tests

Les deacutefautsExeacutecution des cas deLe programme deacutetecteacutestests

Tel quillustreacute sur la figure 51 les sujets ont reccedilu les cas de test ct les ont exeacutecuteacutes dans une

session de 45 minutes Ils ont eacuteteacute informeacutes de ne pas produire de cas de tests additionnels

pendant lexeacutecution des cas de tests pour eacuteviter dintroduire le TE dans le TS Alors pendant

lexeacutecution des cas de test les sujets comparent les reacutesultats de sOl1ies observeacutes avec les

reacutesultats deacutecrits dans le script de cas de test Si les deux reacutesultats ne correspondent pas le

sujet doit enregistrer ct deacutecrire le comportement observeacute pendant lexeacutecution de ce cas de

test pour que nous puissions sassurer quil sagit vraiment dun deacutefaut et eacuteviter une

mauvaise interpreacutetation du comportement du programme

En ce qui concerne le TE nous Javons programmeacute dans une session de 45 minutes Les

sujets dans cette session de test exploratoire ont utiliseacute quelques modegraveles et techniques

dexploration que nous Jeur avons preacutepareacutes en avance (Annexe C) en se basant sur les

techniques proposeacutees par Amland (2002) afin de faciliter leur mission et les guider dans le

test

66

Figure 52 Le traitement de test exploratoire

Le programme

~ pprentissage concpetion et exeacutecu tion ----~ Les deacutefauts deacutetecteacutes

des tests ~ -----~----

Tel quillustreacute sur la figure 52 les sujets ont reccedilu le programme en entreacutee Leur mission eacutetait

dapprendre le programme concevoir et exeacutecuter les tests et rapportent Jes deacutefauts deacutetecteacutes

Le reacutesultat de lexeacutecution de TE est une liste des deacutefauts deacutetecteacutes (Annexe D) Pendant

Jexeacutecution de TE les sujets ont classifieacute les deacutefauts deacutetecteacutes selon leur graviteacute en suivant une

Jiste de classification de deacutefauts que nous leur avons fournie avant le deacutebut de lactiviteacute de

TE Cette liste classifie la graviteacute des deacutefaillances en trois niveaux

o fatale lapplication est inopeacuterable complegravetement (Crash)

o Moyenne lapplication fonctionne malS cel1aines fonctions sont inopeacuterables ou

certains reacutesultats sont erroneacutes

o Mineure limpact est rmneur sur Jutilisation du systegraveme comme certains formats

sont erroneacutes bien que les reacutesultats soient corrects ou encore le deacutelai de reacuteponse est

supeacuterieur de ce gui atlendu dune telle application

Apregraves lexpeacuterience nous avons re-classifieacute les deacutefauts rapporteacutes par les expeacuterimentateurs pour

eacuteviter des erreurs qui peuvent se reacutesulter sur une mltluvaise classification

67

54 Analyse des reacutesultats de lexpeacuterience

541 Analyse des resulats de test exploratoire

Avant de proceacuteder agrave une analyse comparative des reacutesultats de TE et TS nous analysons tout

dabord des reacutesultats de test exploratoire en termes de nombre et limportance des deacutefauts

deacutetecteacutes et nous les avons compareacutes avec les reacutesultats rapporteacutes dans la rccherche dltokens et

Rautiainen (2005)

5411 La productiviteacute de TE selon le nombre de deacutefauts deacutetecteacutes

Lanalyse et le traitement des donneacutees de TE recueillis pendant leacutetude empirique nous ont

permis de deacutevelopper une ideacutee estimative de la productiviteacute de TE en tcrme de nombre de

deacutefauts deacutetecteacutes (figure 53)

Figure 53 Les reacutesultats de test exploratoire

12

10

Nombre de

sujets

o 4 7 10 13 16

Nombre de deacutefauts

Les reacutesultats preacutesenteacutes agrave la figure 53 montrent que plus que la moitie (66lt) des sujets ont

reacuteussi agrave deacutetecter entre 6 agrave 9 deacutefauts La moyenne est de 95 deacutefauts par sujet Cette moyenne

est tregraves proche de celle proposeacutee par leacutetude de Itokens et Rautiainen (2005) Selon les

donneacutees quantitatives collecteacutees par ces auteurs dans la petite cntreprise dont son contexte de

deacuteveloppement est immature (plus proche de notre contextc de test) la moyenne reacutealiseacutee est

de 87 deacutefauts dans une session de 60 minutes

68

5412 La productiviteacute selon limportance de deacutefauts

Lanalyse et le traitement des donneacutees de TE recueillis pendant leacutetude empirique nous ont

permis davoir aussi une ideacutee sur limportance de deacutefauts qui pouvant ecirctre deacutetecteacutes

(figure64)

Figure 54 Importance de deacutefauts deacutetecteacutes avec le test exploratoire

10

lZ3 Fatale Grave D Mineure

Nous pouvons constater agrave partir des reacutesultats preacutesenteacutes sur la figure 54 que le pourcentage

des deacutefauts graves deacutetecteacute par les sujets avec le TE est plus que la moitieacute de tous les deacutefauts

deacutetecteacutes Tandis que seulement J0 des deacutefauts deacutetecteacutes sont fatales Les auteurs Jtokens et

Rautiainen (2005) ont rapporteacute un pourcentage de 15 des deacutefauts fatals deacutetecteacutes dans une

session de 60 minutes Cest un pourcentage tregraves proche du pourcentage reacutealiseacute dans notre

eacutetude empirique si nous prenons en consideacuteration la diffeacuterence dans les programmes utiliseacutes

dans leur eacutetude de cas et notre expeacuterience

La figure 54 montre que 70 des deacutefauts deacutetecteacutes pendant lexpeacuterience avec le TE sont des

deacutefauts importants cest agrave dire sont des deacutefauts fatals ou graves qui pounont empecirccher le

fonctionnement normal du programme sous test Par contre 50 des deacutefauts deacutetecteacutes avec le

TS sont des deacutefauts mineurs cest agrave dire des deacutefauts qui ne pourront pas empecirccher le

programme de fonctionner Ainsi la moitieacute des deacutefauts deacutetecteacutes avec le TS sont des deacutefauts

69

importants dont 45 des deacutefauts sont des deacutefauts graves et seulement 5 des deacutefauts sont

fatals De ce fait nous pouvons conclure que le TE permet de deacutetecter des deacutefauts plus

importants que le TS Eacutevidement les reacutesultats de TS deacutependent des connaissances et des

compeacutetences du concepteur des cas de test (lauteur de ce travail de recherche) Agrave cet effet

un autre concepteur peut aboutir agrave des reacutesultats diffeacuterents

Pendant lexpeacuterience nous avons constateacute que la boucle dapprentissage et les feedbacks

instantaneacutes durant Jactiviteacute de test constituent les raisons principales des reacutesultats

performants du TE En effet les sujets ont commenceacute lapprentissage ct la conception des cas

de test deacutes quils ont reccedilu le programme agrave tester Au fur et agrave mesure quils avancent dans leur

mission de TE ils conccediloivent des tests plus productifs et plus performants qui leur

permettent de deacutetecter des deacutefauts plus importants Cela gracircce aux feedbacks deacuteriveacutes des

tests exeacutecuteacutes ulteacuterieurement pendant lactiviteacute de TE et les connaissances accumuleacutees depuis

le deacutebut de la mission de TE

Nous croyons aussi que la diversiteacute des compeacutetences et les qualifications des sujets

participants dans lexpeacuterience a contribueacute aussi aux reacutesultats performants en TE En fait la

participation de plusieurs compeacutetences ou personnes dans le test donne des reacutesultats meilleurs

que lorsque la conception des cas de test est faite par une ou deux personnes seulement Nous

pouvons conclure de cette discussion que le TE permet de deacutetecter des deacutefauts plus

importants point de vue seacuteveacuteriteacute que le TS Autrement que notre hypothegravese secondaire H2

ne peut pas ecirctre rejeteacutee

Cependant nous avons constateacute que quelques sujets dans lexpeacuterience ont pu deacutetecter des

deacutefauts plus importants que ceux deacutetecteacutes avec le TS Nous croyons que limportance des

deacutefauts trouveacutes avec le TE deacutepend de la creacuteativiteacute et les qualifications de testeur Agrave cet effet

nous avons eacutetudieacute dans notre eacutetude empirique linfluence des connaissances en

programmation en Java comme un facteur repreacutesentant lexpertise ct les qualifications de

sujet sur les reacutesultats de TE effectueacute

En effet nous avons choisi ce facteur parce que nous croyons que le niveau de connaissance

70

en java repreacutesente bien la familiariteacute de leacutetudiant avec la programmation et les techniques de

deacutebogage donc implicitement son expertise et ses qualifications neacutecessaires pour exeacutecuter sa

mission pendant le TE (figure55)

Figure 55 Linfluence de lexpertise sur le test exploratoire

fi) -lt1)

14

u lt1) 12

-lt1) 0 10 fi) l

~ 8 lt1) 0

lt1) 6 0

lt1) c 4 c lt1) 2 0

~ 0

Jamais vu Introduction Intermeacutediaire Avanceacute

Connaissance en Java

Les reacutesultats preacutesenteacutes agrave la figure 55 montrent que la moyenne de deacutefauts deacutetecteacutes est plus

eacuteleveacutee pour un niveau de connaissance eacuteleveacute en Java La faible diminution pour le niveau

intermeacutediaire pourrait ecirctre expliqueacutee par la difficulteacute de situer le niveau de connaissance en

Java Notons que la Jiberteacute de TE a eacuteteacute signaleacutee par plusieurs sujets comme un avantage du

TE qui leur permet dapprofondir et dameacuteliorer leurs tests en temps reacuteel

542 Analyse des reacutesultats de TE et TS

Cette section aborde les reacutesultats rapporteacutes de lexpeacuterience de deux approches de test le TS

ct le TE Notre ideacutee est danalyser et de comparer la performance des sujets dans les deux

meacutethodes de test Autrement dit eacutevaluer la productiviteacute de TE par rapport au TS en

comparant le nombre de deacutefauts deacutetecteacutes par chaque sujet en utilisant le TE et le TS Le

traitement des reacutesultats recueillis de lexpeacuterience nous a donneacute le graphe 56

71

Figure 56 Reacutesultats des sujets aux TE et TS

Les sujets

-TE --TS

Nous pouvons constater de la figure 56 que le TE est plus productif que Je TS Cependant la

limitation de contexte de lexpeacuterience reacutesidant dans la taille du programme de jexpeacuterience et

le manque dexpel1ise des expeacuterimentateurs ne permet pas de tirer des conclusions fiables et

de geacuteneacuteraliser les reacutesultats obtenus

5421 Analyse de variance ANOVA

La figure 56 montre que les sujets ont eacuteteacute plus performants et productifs en TE quen TS

Dans eette section nous allons prouver statiquement ces reacutesultats en utilisant lanalyse de

variance ANOY A

Lanalyse de variance ANOYA laquo ANalysis Of VArianceraquo est une meacutethode statistique

permettant de comparer la moyenne de plusieurs populations Elle permet de savoir si une ou

plusieurs variables deacutependantes sont en relation avec une ou plusieurs variables dites

indeacutependantes (Winer ]97 J)

Dans un plan dexpeacuterience agrave mesures reacutepeacuteteacutees un mecircme sujet est mesureacute sous chacun des

niveaux dun traitement expeacuterimental Comme dans notre eacutetude ougrave chaque sujet est mesureacute

deux fois sous le TE puis le TS Dans ce type de plan leffet de lapproche de test

72

exploratoire sur le sujet k est compareacute avec la reacuteponse de mecircme sujet dans le TS Dans ce

plan chaque sujet devient son propre controcircle agrave travers les deux traitements expeacuterimentaux

(les deux approches de test dans notre cas)

Figure 57 Repreacutesentation scheacutematique de lanalyse ANOVA (Adapteacute et traduit de

Winer 1971)

Variation totale dl=kn-l

Varaition intershy Variation intrashyindividus individus

dl=n-I dl=n(k-I)

Variation intershyVariation reacutesiduelle

traitement dl=(n-I)(k-I)

dl~k-l

dl degreacute de liberteacute

La deacutecomposition de la variance selon (Winer 1971)

o Variation totale = Variation inter-individus + Variation intra-individus

o Somme carreacutes totale de la deacuteviation (SC Totale) = Somme carreacutes inter-individus +

Somme calTeacutes intra-individus

o Variation intra-individus = Variation inter-traitement + Variation reacutesiduelle cest agrave

dire

Somme carreacutes intra individus = Somme carreacutes inter-traitements + Somme

reacutesiduelle des carreacutes

Dans notre cas nous reacutesumons les calculs de lanalyse de variance ANOVA agrave mesures

73

reacutepeacuteteacutees sur les donneacutees collecteacutees de notre eacutetude empirique dans le tableau ci dessous

Tableau 51 ANOVA des donneacutees collecteacutees de lexpeacuterience

La source de variation Somme des carreacutees SC dl Carreacute moyen Test-F

Inter-individus 84145 55

Intra-individus 837 56

Inter-traitement 37296 1 37296 458

Reacutesiduelle 46404 55 814

La valeur critique pour un Test F avec (157) degreacutes de liberteacute cst 712 Or dapregraves le calcul

nous avons trouveacute que le test F = 458 Puisque cette valeur est supeacuterieur de 712 nous

rejetons lhypothegravese nulle HO et nous conservons lhypothegravese H 10rdapregraves la repreacutesentation

graphique des reacutesultats de Jexpeacuterience figure 66 nous pouvons constater que le TE est plus

productif en terme de nombre des deacutefauts deacutetecteacutes que le TS Par la suite nous concluons que

1hypothegravese Hl est valide ct que le TE est plus productif que le TS

55 Conclusion

Lanalyse statistique des reacutesultats de leacutetude empirique nous a permis de conclure que la

performance des sujets dans Jexeacutecution de TE est supeacuterieure que leur performance dans

lexeacutecution de TS Par la suite nous avons conclu que le TE est plus productif en terme de

nombre des deacutefauts deacutetecteacutes que le TS Ainsi nous avons conclu que le TE pourraient

deacutetecter des deacutefauts plus importants point de vue graviteacute que le test sceacutenariseacute

61

CHAPITRE VI

CADRE CONCEPTUEL DE COMPARAISON

Dans la revue de litteacuterature nous avons compileacute quelques eacutetudes de cas et expeacuteriences

dutilisations du TE dans lindustrie de test logiciel Nous avons preacutesenteacute un aperccedilu des

raisons que ont motiveacute les praticiens agrave utiliser le TE les faccedilons dont ils ont adopteacute et geacutereacute le

TE et les facteurs qui ont influenceacute ses reacutesultats dans la pratique Cela nous emmegravene dans ce

travail de recherche agrave eacutetudier plus profondeacutement et dune faccedilon geacuteneacuterale ces facteurs dans le

cadre dune eacutetude comparative des deux approches de test le TE et le TS Dans ce chapitre

nous preacutesenterons le contexte de notre eacutetude comparative Puis nous proposerons notre cadre

conceptuel de comparaison Ce cadre va guider notre analyse comparative de TE et TS NOlis

le deacutevelopperons en se basant sur la litteacuterature et les eacutetudes de cas des praticiens et

chercheurs dans lindustrie de test Agrave cet effet les recherches theacuteoriques ct empiriques

anteacuterieures preacutesenteacutees dans la revue de la litteacuterature seront consideacutereacutees

Mise en contexte de leacutetude comparative

Avant de preacutesenter le cadre comparatif de cette analyse nous proposons le contexte geacuteneacuteral

de notre analyse comparative et les choix que nous avons ducirc faire pour rendre possible une

comparaison et une discussion coheacuterente Tout dabord nous choisissons le type de test qui

va repreacutesenter chacune des deux approches dans cette eacutetude comparative En effet eacutetant

donneacute que les deux approches peuvent ecirctre repreacutesenteacutees sur un continuum (Figure 21) la

diffeacuterentiation entre le TE et le TS est difficile et imperceptible sans la speacutecification de type

choisi dc chacun dentre eux De ce fait nous avons choisi de repreacutesenter le TS par un

processus de test baliseacute dans les patrons de standard de documentation IEEE 829 que nous

avons proposeacute dans le chapitre Il Ce choix est motiveacute par notre besoin de normaliser

lanalyse et la comparaison Ainsi nous pourrons comparcr un processus f0l1ement planifieacute ct

75

disciplineacute de test avec un autre processus semi-planifieacute et libre (SBET) Quant au TE nous

avons choisi de le repreacutesenter par lapproche Session Based Exploratory Testing (SBET)

Cette forme de TE dapregraves la revue de la litteacuterature que nous avons preacutesenteacute dans le chapitre

IV est la plus adopteacutee dans lindustrie de test du logiciel comme une meacutethode primaire de test

(ltkonen et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003 Wood et James

2003) tandis que le TE libre est toujours consideacutereacute comme un test ad hoc (Lyndsay van

Eeden 2003) 11 faut noter que mecircme avec le choix de lapproche SBET nous restons dans la

limite de notre comparaison de TE et TS puisque le TE libre constitue Je cœur de lapproche

SBET La seule diffeacuterence entre les deux types est les notes produites agrave la fin de la session

dans le SBET Or ce sont ces notes qui ont favoriseacute son utilisation dans Jindustrie mecircme lagrave

ougrave les tests sont le plus documenteacutes et formels tel le domaine du logiciel meacutedical (James et

Wood 2003)

Lanalyse comparative des deux approches le TE et le TS va nous permettre de ressortir les

contextes favorables pour utiliser le TE agrave la place de la meacutethode sceacutenariseacutec habituelle de test

(TS) En fait on peut dire quun contexte est lensemble des facteurs speacutecifiques de projet de

test du logiciel Par exemple dire que le logiciel agrave tester est petit repreacutesente un facteur de

contexte deacutetermineacute selon le facteur laquo Caracteacuteristiques du logiciel agrave tester raquo

Notre comparaIson est restreinte au type de test boicircte nOIre du fait que Je TE est une

technique de test boicircte noire (Craig et Jaskiel 2002 Kaner et al 2002) Dans ce type de test

on ne sinteacuteresse pas agrave laspect impleacutementation du code mais uniquement au comportement

du logiciel

Nous voulons signaler aussi que dans notre analyse comparative nous ne consideacuterons que

les modegraveles traditionnels de deacuteveloppement On a vu les modegraveles agiles de deacuteveloppement

constituent un cas reacuteel ougrave Je TE et le TS automatiseacute sont utiliseacutes ensemble pour tester le

logiciel (section 24) Or dans notre eacutetude nous voulons identifier les contextes ougrave le TE

pourrait ecirctre utiliseacute comme une meacutethode primaire de test agrave la place de TS Agrave cet effet les

modegraveles agi les ne seront pas consideacutereacutes dans cette eacutetude

76

Dans ce chapitre et les chapitres suivants nous utilisons labreacuteviation laquo TE raquo pour deacutesigner

lapproche SBET afin dalleacuteger le texte

62 Cadre conceptuel de comparaison

La comparaison entre le TS et le TE est peu abordeacutee dans la litteacuterature Les travaux qui ont

traiteacute le sujet eacutetaient plus axeacutes sur la proposition et la promotion des avantages de TE par

rapport au TS (Kaner 2006 Bach 2003) Pour cela nous nous sommes fixeacute comme objectif

dans ce travail de recherche de comparer dune faccedilon neutre les deux approches en mettant

laccent sur les apports et les contextes ougrave le TE pourrait remplacer le TS Nous tentons par le

biais de cette eacutetude comparative dexplorer ces contextes en se basant sur nos deacuteductions

personnelles tireacutes de la base theacuteorique de test du logiciel et la revue de litteacuterature des travaux

de praticiens dans Jindustrie de test (Chapitre IV) et sur leacutetude empirique preacutesenteacutee au

chapitre preacuteceacutedent

Tout dabord afin que notre analyse eomparative soit meneacutee agrave bien nous preacutesenterons notre

cadre conceptuel de comparaison Ce cadre doit permettre de guider et focaliser notre analyse

comparative entre le TE et le TS Il regroupe les critegraveres autour desquels la discussion et

lanalyse seront centreacutees Lidentification des facteurs de comparaison a eacuteteacute deacuteveloppeacutee dune

part en se basant sur les reacutesultats des expeacuteriences dutilisation du TE par les chercheurs et les

praticiens preacutesenteacutes dans la litteacuterature Nous nous sommes aussi inspireacutes des facteurs

proposeacutes par Boehm et Turner (2004)

Le cadre proposeacute par Boehm et Turner (2004) a pour objectif la comparaison des approches

agiles et les approches disciplineacutees de deacuteveloppement du logiciel Or notre comparaison

pourrai1 ecirctre vue aussi comme la comparaison entre deux meacutethodes de test disciplineacute et agile

ougrave le TS repreacutesente la meacutethode disciplineacutee et le TE la meacutethode laquoagileraquo On entend par agile

le fait que le TE se caracteacuterise par les deux caracteacuteristiques essentielles de lagiliteacute identifieacutee

dans (Boehm Turner 2004) La premiegravere eacutetant sa capaciteacute de reacutepondre ou de sadapter

rapidement aux changements du logiciel agrave tester (ltkonen ct Rautiainen 2005 Petty 2005

Lyndsay et van Eedcn 2003 Amland et Vaga 2002) La deuxiegraveme est la leacutegegravereteacute de la

documentation utiliseacutee ct produite pendal1t le TE

77

Le cadre proposeacute par Boehm et Turner (2004) est axeacute sur quatre dimensions agrave savoIr

Caracteacuteristiques dutilisations caracteacuteristiques de gestion caracteacuteristiques techniques et

caracteacuteristiques du personnel Or une meacutethode de test du logiciel doit ecirctre adapteacutee agrave un

contexte particulier (Craig et Jaskiel 2002 Perry 2000) Ce contexte se reacutesulte de

linteraction de plusieurs facteurs relieacutes aux objectifs principaux de lactiviteacute de test les

ressources financiegraveres techniques humaines et organisationnelles existantes Agrave cet effet le

cadre de comparaison de deux meacutethodes de test se composait de mecircmes dimensions citeacutees

par Boehm et Turner (2004) Notre cadre de comparaison va regrouper les axes de

comparaisons suivantes caracteacuteristiques d uti lisations caracteacuteristiques de gestion

caracteacuteristiques techniques et caracteacuteristiques de personnels Cependant il nous revient de

deacuteterminer les facteurs de comparaison associeacutes agrave chaque dimension De plus nous ajoutons

une cinquiegraveme dimension traitant la productiviteacute dc lactiviteacute de test puisque la veacuterification

dc la productiviteacute de TE est lun des objectifs principaux de ce travail de recherche Alors

notre cadre conceptuel de comparaison se constitue des dimensions et facteurs suivants

preacutesenteacutes dans les sections ci-dessous

621 Les caracteacuteristiques dutilisation

Selon Turner et Boehm (2004) les caracteacuteristiques dutilisations repreacutesentent les aspects et les

types de projets approprieacutes pour chaque approche du deacuteveloppement Ils ont identifieacute sous

cette dimension les facteurs suivants les objectifs principaux dutilisation de chaque

approche du deacuteveloppement la taille de projet du deacuteveloppement en termes de nombre de

personnes participants dans le projet la complexiteacute le volume du logiciel et le type

denvironnement daffaire ougrave se deacuteveloppe le projet Dans notre cas les caracteacuteristiques

dutilisation regroupent les facteurs suivants

bull Les raisons dutilisation ou les motivations pour utiliser chacune de deux approches de

tesl le TE ct le TS

bull Les caracteacuteristiques du logiciel agrave tester en termes de la taille de la complexiteacute et de la

crit ical iteacute

bull Le type denvironnement daffaire ougrave se produit le projet de test

78

bull Les ressources financiegraveres

bull Le temps disponible pour remplir lactiviteacute de test

622 Les caracteacuteristiques de gestion

Selon les auteurs Boehm el Turner (2004) les caracteacuteristiques de gestion deacutecrivent les faccedilons

de geacuterer Je projet du deacuteveJoppement dans Ies deux meacutethodes du deacuteveloppement agiles et

disciplineacutees Ils ont identifieacute sous cette dimension les facteurs suivants La planification et le

controcircle de projet de deacuteveloppement la relation avec Je client et la communication dans le

projet du deacuteveloppement Dans notre cas de recherche cette dimension de comparaison

regroupe les mecircmes facleurs discuteacutes par Boehm et Turner mais dans Je cadre de projel de

test Il sagit de la planification de tesl le controcircle et le suivi de la progression de test la

communication dans le projet de test el Ja relation avec le client

623 Les caracteacuteristiques techniques

Selon Boehm et Turner (2004) les caracteacuteristiqucs techniques deacutecrivent comment chacune de

deux meacutethodes du deacuteveloppement agile et disciplineacute abordent les eacutetapes essentielles du cycle

de deacuteveloppement du logiciel la speacutecification des exigences Je deacuteveloppement el le test

Dans notre cas cette dimension deacutecrit comment les deux approches de test le TE et le TS

abordent les eacutetapes essentielles de lactiviteacute de test Selon (Pyhajarvi el al 2003 Swebok

2004 Craig et Jaskiel 2002 Perry 2000) ces activiteacutes sont la planification de tests la

conception de tests lexeacutecution de tests Toutefois les activiteacutes de test deacutecoulent selon

(Bolton et aL 2005) de trois facteurs loracle de test les risques du logiciel agrave lester et la

couverture du test Ces eacuteleacutements seront donc discuteacutes sous cette rubrique

624 Les caracteacuteristiqucs du pClSonnel

Les auteurs Boehm et Turner (2004) abordent sous cette dimension les caracteacuteristiques du

personnel impliqueacute dans les projets de deacuteveloppement qui pouvaient favoriser JutiJisation de

chacune de deux approches de deacuteveloppement agile et disciplineacute Ils ont identifieacute les facteurs

suivants les caracteacuteristiques du client les caracteacuteristiques des deacuteveloppeurs et la culture de

lorganisation ougrave se deacuteroule le projet de deacuteveloppement Dans notre analyse comparative de

79

TE el le TS cette dimension ugravee comparaIson regroupe les facleurs suivants les

caracteacuteristiques des testeurs et la culture de lorganisation ougrave se deacuteroule le projet de test

625 La productiviteacute

Nous avons ajouteacute cette dimension agrave notre cadre vu limportance de cet aspect dans notre

travail de recherche Ce critegravere constitue le centre de cc travail de rechercbe agrave cause de la

productiviteacute du TE annonceacutee dans la litteacuterature surtout par les praticiens du CDS (Bach

2003 Kaner 2006) Les facteurs dc cette dimension sont le nombre de deacutefauts deacutetecteacutes et

limporlance de deacutefauts deacutetecteacutes par chacunc des dcux approches de test le TE et le TS Ces

facteurs de comparaison vont ecirctre traiteacutes dc dcux faccedilons theacuteoriquc cn se basant sur la

1itteacuterature et empirique ou expeacuterimenta le en se basant sur les reacute su hats dc notre eacutetude

cmplfJque

En reacutesumeacute notre cadre comparatif sc compose dcs dimensions et des facteurs de

comparaison illustreacutes sur la figurc 6)

80

Figure 61 Le cadre conceptuel de comparaison

1 Les raisons dutilisation 1 1

1 Les caracteacuteristiques du ~ 1 logiciel 1Les caracteacuteristiques

dutilisation 1 Le type denvironement daffaire1 1

1 Les ressources finacieacuteres 1 1

=-1 Le temps de test disponible 1

1 La planification ~ 1 1

1 Le controcircle et le suivi de progression de test1 1Les caracteacuteristiques

de gestion 1 La communication dans le 1 ~ 1 projet de test

1 La relation avec le client 1 1

1 Les activiteacutes de test 1 1

Les caracteacuteristiques

1 1

Les risques du logiciel 1

techniques 1 La couverture de test 1 1

1 ~ 1 Loracle de test

1

1 Les caracteacuteristiques du testeur1 1Les caracteacuteristiques

du personnel -J La c1uture de lorganisation 1

1 Le nombre de deacutefauts ~ 1 deacutetecteacutes 1

La productiviteacute 1 Limportance de deacutefauts

~ 1 deacutetecteacutes 1

81

63 Conclusion

Au cours de ce chapitre nous avons preacutesenteacute un cadre conceptuel de comparaison Nous

avons identifieacute et deacutefini dans ce cadre cinq dimensions principales de comparaison les

caracteacuteristiques dutilisation les caracteacuteristiques de gestion les caracteacuteristiques techniques

les caracteacuteristiques du personnel la productiviteacute Chacune de ces dimensions se deacutecompose

en plusieurs facteurs Ces facteurs vont nous servir dans notre analyse comparative du TE ct

du TS qui sera abordeacutee dans le chapitre qui suit

CHAPITRE VII

ANALYSE COMPARATIVE DU TEST EXPLORATOIRE ET DU TEST SCEacuteNARISEacute

Dans ce chapitre nous allons poursuIvre notre discussion plus en deacutetails sur les factcurs

influenccedilant ladoption et ladaptation de test exploratoire (TE) dans le cadre dune analyse

comparative des deux approches de test le test exploratoire (TE) et le test sceacutenariseacute (TS)

Nous COmparons les deux approches en se basant sur les facteurs deacutevaluation de notre cadre

conceptuel de comparaison que nous avons deacuteveloppeacute dans Je chapitre preacuteceacutedent Lobjectif

de ce preacutesent chapitre est didentifier les contextes de test ougrave le TE pourrait ecirctre utiliseacute en

remplaccedilant la meacutethode habituelle sceacutenariseacutee de test En terminant nous proposons un guide

de seacutelection de lapproche de test Ce guide reacutecapitule les reacutesultats de notre analyse

comparative et tente de baliser une deacutemarche danalyse pouvant ecirctre inteacutegreacutee agrave la reacuteflexion

strateacutegique des entreprises lors de choix de lapproche de test

71 Comparaison selon les caracteacuteristiques dutilisation

Dans cette section nous allons discuter les caracteacuteristiques dutilisation speacutecifiques pour

chacune des deux approches de test le TE et le TS Tout dabord nous aborderons les raisons

dutilisation de chacune des deux approches de test Puis nous discutons linfluence des

caracteacuteristiques du logiciel agrave tester sur le choix de lapproche de test Ces caracteacuteristiques

regroupent la taille du logiciel sa complexiteacute et sa criticiteacute Ensuite nous discuterons

linfluence de type denvironnement daffaire sur le choix de lapproche de test Finalement

nous aborderons linfluence des facteurs le temps de test disponible et les ressources

financiegraveres sur le choix de Japproche de test

711 Les raisons dutilisation

La raison principale de lutilisation du TE comme une approche primaire de test eacutetait pour

83

saccommoder agrave Jinstabiliteacute du logiciel deacuteveloppeacute etou labsence des exigences du logiciel

(Itkonen et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003 Amland et Vaga

2002) Ces eacutetudes ont montreacute que le TE sadapte agrave de telles situations Cette adaptation

se~plique par la possibiliteacute dutiliser le TE sans avoir besoin dutiliser les exigences du

logiciel En effet le TE nexige pas lexistence dexigences formelles du fait que les chal1es

de tests (le contenu de la mission de chaque session de test) pourraient ecirctre identifieacutees en

utilisant nimporte quelle source dinformation existante mises agrave part les exigences du

logiciel Les auteurs Kaner et Bach (2004) ont deacutecrit plusieurs reacutefeacuterences peuvent servir

pendant lidentification des chartes Souvent le manuel dutilisateur est utiliseacute pour identifier

ces chartes Ces chartes identifient seulement les grandes lignes de la mission de test agrave

accomplir Par conseacutequent lintroduction des changements sur le logiciel sous test ne

pourrait introduire que des mises agrave jour minimes au pire des cas comme lajout de nouvelles

chal1es correspondant aux nouvelles fonctionnaliteacutes ajouteacutees au logiciel

Parmi les principes de leacutecole CDS on retrouve que les projets se deacuteroulent souvent dune

maniegravere impreacutevisible Ceci implique que lapproche de test devrait sadapter agrave cette

impreacutevisibiliteacute A cet effet nous pouvons constater que lobjectif principal du TE est de

sadapter agrave Jimpreacutevisibiliteacute de projet de test du fait quil est baseacute sur les principes de CDS

La recherche meneacutee par les auteurs Itkonen et Rautiainen (2005) a deacutevoileacute dautres raisons

d uti lisation du TE agrave savoir premiegraverement la possibiliteacute de tester le systegraveme du point de vue

de lutilisateur autrement dit tester la combinaison de plusieurs sceacutenarios dutilisation du

logiciel Deuxiegravemement la difficulteacute de concevoir des cas de tests sceacutenariseacutes deacutetailleacutes agrave cause

de linterdeacutependance entre plusieurs uniteacutes logicielles Troisiegravemement la possibiliteacute

dexploiter la creacuteativiteacute et lexpertise des testeurs dans la deacutetection des deacutefauts imponants

Finalement la limitation du temps de test et les ressources financiegraveres disponibles

Par contre les raisons dutilisation de TS ne pourraient pas ecirctre deacutenombreacutees dans une liste

deacutetermineacutee de raisons dutilisation Du fait que le TS constitue toujours la meacutethode

habituelle et naturelle de test dans plusieurs entreprises Cependant nous avons constateacute

dapregraves notre revue de litteacuterature que Je TS ne saccommode pas facilement aux changements

84

du logiciel En effet nimporte quel changement dans le logiciel neacutecessite la mise agrave jour de

tous les artefacts de test deacutejagrave conccedilus toucheacutes par ce changement Leffort neacutecessaire pour

mettre agrave jour ces artefacts augmente proportionnellement avec laugmentation de niveau de

deacutetail de ces artefacts Lutilisation de standard de documentation IEEE 829 dans le TS

neacutecessite aussi un eff0l1 significatif pour mettre agrave jour les artefacts de test deacutejagrave conccedilus (Craig

et Jaskiel 2002 Petty 2005) Notant que le volume de modifications neacutecessaire accroicirct

propol1ionnellement avec le volume de changements introduit sur le logiciel Or avec la

culture rapide du deacuteveloppement du logiciel actuelle les praticiens tendent souvent agrave

commencer le deacuteveloppement du logiciel le plus tocirct possible avant que les exigences soient

stables et mucircries afin de reacuteduire le temps de mise en marcheacute Par la suite la probabiliteacute

dintroduire des changements ulteacuterieurs sur le logiciel est fort possible parfois assez

nombreux

Agrave cet effet nous pouvons constatcr que la stabiliteacute de projet du deacuteveloppement pourrait ecirctre

lune des raisons essentielles pour utiliser le TS Notant que mecircme le TE pourrait ecirctre utiliseacute

dans ce type de projet Dans une telle situation dautres facteurs pourront influencer le choix

de lapproche convenable dc tcst agrave saVOir ladoption de lorganisation du modegravele

dameacutelioration de processus logicicl comme le CMMI (Capability Maturity Model

Integration) Dans ce genre dc processus la documentation ct la mesure constituent des

eacuteleacutements fondamentaux Par conseacutequent Je TS constitue le choix ideacuteal dans ce type de projet

de deacuteveloppement Le domaine daffaire de quelques types de projet du deacuteveloppement exige

lutilisation de TS Autrement la neacutecessiteacute dune documentation deacutetailleacutee de Jactiviteacute de test

exige lutilisation de TS comme les projets de test dapplications critiques par exemple Par

la suite le besoin de documentation de processus de test pourrait ecirctrc lune des raisons pour

utiliser le TS

Nous concluons de cettc discussion que Je TE est plus approprieacute dans les projets dc

deacuteveloppement instables gracircce agrave sa grande capaciteacute dadaptation agrave limpreacutevisibiliteacute de projet

dc test Tandis que Je TS est plus approprieacute dans les projets dc deacuteveloppement stables et qui

ont besoin de documenter et mesurer lactiviteacute de test

85

712 Les caracteacuteristiques du logiciel

7121 La taille du logiciel

Il apparaicirct que le TE est plus approprieacute dans les petits et moyens projets de test Cest agrave dire

le test des petites et moyennes applications Cela sexplique par leffort neacutecessaire pour la

gestion et le controcircle de TE En effet la gestion de TE neacutecessite que le responsable de test

deacutebriefe chaque testeur apregraves lexeacutecution de chaque session de test afin d eacuteva luer et

dapprouver les reacutesultats de la session Or ceci ne semblait pas ecirctre facile dans une grande

eacutequipe Nous avons constateacute ceci agrave travers les travaux de la litteacuterature que nous avons

preacutesenteacute dans le chapitre IV Alors tous les logiciels qui ont eacuteteacute lobjet des eacutetudes de cas

eacutetaient des petites applications deacuteveloppeacutees par des petites ou moyennes entreprises (ltkonen

et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003 Amland et Vaga 2002)

Selon Lyndsay et van Eeden (2003) la collaboration et le partage ues connaissances entre les

membres de leacutequipe de test peuvent ameacuteliorer la qualiteacute de TE effectueacute Cependant nous

croyons que la collaboration est plus facile entre les membres dune petite eacutequipe de test

quentre les membres dune grande eacutequipe

Par contre le TS est plus approprieacute dans les grands projets de test associeacutes agrave des grands

projets du deacuteveloppement En effet dans ces projets le projet de test constitue souvent un

sous projet organiseacute et geacutereacute seacutepareacutement du projet de deacuteveloppement du logieiel (Pyhajarvi et

al 2003) Agrave cet effet la planification et la documentation sont les moyens de gestion et de

communication agrave linteacuterieur et agrave lexteacuterieur de projet de test Sajoute agrave ceci le fait que les

grands projets puissent seacutetaler sur plusieurs mois Par la suite la meacutemorisation et

lenregistrement des cas de test sont neacutecessaires afin de maintenir et tester lapplication dans

les phases ulteacuterieures du deacuteveloppement dune faccedilon rentable (Beizer 1990)

Nous concluons que le TE est plus approprieacute dans les petits et moyens projets de test cest-agraveshy

dire le test des petits et moyens logiciels Tandis que le TS est plus approprieacute dans les grands

projets de test cest-agrave-dire pour les grands logiciels

86

7122 La complexiteacute du logiciel

La complexiteacute du logiciel fait reacutefeacuterence agrave la difficulteacute de compreacutehension et dappreacutehension du

logiciel Autrement dit la compreacutehension du logiciel nest pas agrave la porteacutee de tous les testeurs

dans le projet Par exemple un logiciel qui impleacutemente une nouvelle technologie Alors le

TE ne semblait pas le meilleur choix dans cette situation puisque lapprentissage et

lappreacutehension du logiciel neacutecessaires pour remplir lactiviteacute de TE ne pourront pas ecirctre agrave la

porteacutee de tous les testeurs dans le projet de test Le TS pourrait ecirctre la meilleure strateacutegie

dans ce cas de test du fait que les cas de tests pourraient ecirctre conccedilus par des experts dans la

technologie impleacutementeacutee et exeacutecuteacutes par des testeurs novices

Il faut noter que parfois les logiciels complexes se deacuteveloppent en collaboration entre

plusieurs compagnies (Kaner et al 1999) Dans une telle situation le TS repreacutesente le bon

choix surtout sil est documenteacute par le standard de la documentation IEEE 829 La

documentation de lactiviteacute de test permet de veacuterifier et dinspecter formellement la qualiteacute

de test effectueacute au niveau de chaque entreprise participante dans le deacuteveloppement du

logicieL Le standard IEEE 829 peut introduire un protocole commun de communication entre

les entreprises paJ1icipantes dans le projet du deacuteveloppement (IEEE829 1998)

Nous concluons que le TS est plus approprieacute dans les projets de test de logiciel complexe

Tandis que lutilisation de TE dans tels projets deacutepend des compeacutetences ct de leXpeJ1ise des

testeurs impliqueacutes dans le projet

7123 La criticaliteacute du logiciel

En ce qui concerne le test des logiciels critiques seulement le TS pourrait ecirctre utiliseacute En

effet pour les logiciels critiques comme les logiciels temps reacuteel ou embarqueacutes seulement les

meacutethodes seeacutenariseacutees peuvent ecirctre utiliseacutees Lun des eacuteleacutements essentiels de ces meacutethodes de

tests est la documentation deacutetailleacutee de lactiviteacute de test Cette documentation fera lobjet de

plusieurs eacutevaluations et inspections afin de sassurer de la qualiteacute de lactiviteacute de test

effectueacutee Dans certaines situations la documentation ct lactiviteacute de test devront suivre des

normes et des standards speacutecifiques dans quelques domaines daffaires Nous avons constateacute

87

ce fait agrave travers leacutetude ugravee cas ugravee James et Wood (2003) preacutesenteacute dans le chapitre IV Les

deux auteurs ont utiliseacute le TE comme une meacutethode compleacutementaire agrave Japproche sceacutenariseacutee

habituelle Cette derniegravere devait suivre les normes de qualiteacute du systegraveme (Quality System

Regulation) dans le domaine de construction dappareils meacutedicaux

Il faut rappeler que mecircme Bach et al (2002) ont signaleacute que les pnnclpes et les leccedilons

preacutesenteacutes dans (Bach et al 2002) de leacutecole de penseacutee Context Driven School (CDS)

concernent les logiciels commerciaux seulement Agrave cet effet nous croyons que le TE

sapplique lui aussi agrave ce type de logiciels du fait quil est baseacute sur les mecircmes principes de

leacutecole

Nous concluons de cette discussion que seule le TS pourrait ecirctre utiliseacute dans le test des

logiciels cri tiques

713 Le type denvironnement daffaire

Le type denvironnement daffaire pourrait influencer le choix de lapproche de test entre le

TE et le TS Dapregraves notre revue de litteacuterature nous avons constateacute que le TE sadapte

faci lement aux changements du logiciel agrave tester Par la suite nous pouvons constateacute que le

TE est plus approprieacute dans les environnements dynamiques Le dynamisme fait reacutefeacuterence au

dynamisme de la technologie utiliseacutee dans le deacuteveloppement du logiciel ouet de la volatiliteacute

des besoins du client Agrave linverse le TS ne sadapte pas facilement aux environnements

dynamiques De fait que la maintenance des artefacts de test neacutecessite du temps et des

ressources financiegraveres consideacuterables qui ne sont pas souvent disponibles dans la pratique du

test surtout dans les petites ct moyennes entreprises Dailleurs nous avons constateacute cela agrave

travers notre revue de litteacuterature La deacutecouverte et lutilisation de TE ont eacuteteacute motiveacutees dans la

plupart des eacutetudes de cas que nous avons preacutesenteacutees par lincapaciteacute de TS agrave reacutepondre aux

besoins des praticiens dans la limite du temps ct des ressources disponibles (Petty 2005

Amland et Vaga 2002)

Le TS sadapte tregraves bien aux environnements stables Dans ces environnements les artefacts

de test peuvent ecirctre speacutecifieacutes tocirct dans le processus du deacuteveloppement dans la limite des

88

ressources disponibles et aucun coucirct suppleacutementaire de changement nest neacutecessaire Le TS

est plus approprieacute aussi dans dautres types denvironnements daffaires comme les logiciels

eacutevolutifs et les logiciels deacuteveloppeacutes sous contrat Dans ce type denvironnements le plan de

test et les cas de tests uevraient ecirctre Jivreacutes avec le logiciel Parfois le client deacutetermine et

neacutegocie la structure le format et le niveau de deacutetail de ces artefacts dans le contrat Il pourrait

exiger lutiliseacuteltion de la norme de documentation IEEE 829 dans quelques situations (Kaner

et al 1999)

Les logiciels deacuteveloppeacutes dans quelques domaines dindustrie exigent Jutilisation de TS agrave

cause de la neacutecessiteacute dune documentation deacutetailleacutee de processus de test Souvent cest le cas

dans le test des logiciels qui peuvent causer des pertes importantes en cas de deacutefaillance du

logiciel dans le site de production Alors la documentation de test pourrait constituer un outil

de deacutefense dans les causes judiciaires (Kaner et al 1999)

Nous pouvons conclure de cette analyse que le TE est plus approprieacute dans les

environnements dynamiques Par contre le TS est plus approprieacute dans les environnements

stables eacutevolutifs ou sous contrat et ceux qui neacutecessitent la documentation deacutetailleacutee du

processus de test

714 Les ressources financiegraveres

Nous avons constateacute dapregraves notre revue de lilteacuterature que les ressources financiegraveres

disponibles dans Je projet de test jouent un rocircle important et crucial dans le choix de

lapproche de test (ltkonen et Rautiainen 2005 Petty 2005 Lyndsay et van Eeden 2003

Amland Vaga 2002)

Le TS neacutecessite des ressources financiegraveres importantes La preacuteparation la conception des cas

de tests et la documentation du processus de test occasionnent des frais significatifs En effeL

leffort neacuteccssaire en nombre de personnesjours pendant le processus de test est plus grand

en TS quen TE Ce fait empecircche lutilisation de TS quand le budget de test est serreacute

(Lyndsay van Eeden 2003) Contrairement le TE ne neacutecessite pas une documentation

rigoureuse pendant le processus de test agrave pm1 un investissement minime dans le processus

didentification des cbaI1es de tests La moindre coucirct dc TE a eacuteteacute signaleacute par les praticiens qui

89

ont utiliseacute lapproche dans lindustrie de test (Petty 2005 Lyndsay Van Eeden 2003 James

Wood 3003)

Cependant la diffeacuterence dans les coucircts entre le TE et le TS apparaicirct clairement lors de

lintroduction des changements sur le produit sous test Alors la maintenance des artefacts de

tests sceacutenariseacutes a un coucirct suppleacutementaire qui augmente en fonction du volume de

changements introduits Par contre le changement du logiciel dans une activiteacute de TE ne

pourrait geacuteneacuterer que quelques changements sur les chartes existantes tel que lajout des

nouvelles chartes Par la suite le TE ne geacutenegravere pas des coucircts suppleacutementaires importants

comme le TS En fait le coucirct moindre de TE eacutetait le principal motif de la deacutecouverte et de

lutilisation de cette approche par les professionnels et les praticiens dans lindustrie de test

(Petty 2005 Amland Vaga 2002)

Nous concluons de cette discussion que le TE est plus approprieacute dans les projets de test agrave

ressources financiegraveres limiteacutees Tandis que le TS est plus approprieacute dans les projets de test

qui ont des ressources financiegraveres importantes pour suppol1er ses frais

715 Le temps de test disponible

Le temps disponible pour accomplir lactiviteacute de test est lun des facteurs essentiels pouvant

influencer le choix de lapproche de test (ltkonen et Rautiainen 2005 Petty 2005 Lyndsay

et van Eeden 2003 Amland Vaga 2002) Le TS neacutecessite du temps consideacuterable pour la

planification et la conception des cas de tests avant Je deacutebut de Jexeacutecution physique des tests

Toutefois avec la tendance preacuteventive actuelle de test du logiciel la planification et la

conception de cas de tests sceacutenariseacutes peuvent commencer degraves le deacutebut de projet du

deacuteveloppement parallegravelement avec limpleacutementation du logiciel Agrave cet effet il y a toujours

suffisamment de temps pour planifier et preacuteparer les cas de tests sceacutenariseacutes Le problegraveme de

temps se pose lors de Jintroduction de changements sur le logiciel ulteacuterieurement dans le

cycle du deacuteveloppement cest-agrave-dire le changement de la conception du logiciel apregraves

leacutelaboration des cas de tests associeacutes agrave celle-ci Dans ce cas le temps neacutecessaire pour mettre

agrave jour les artefacts de test deacutejagrave conccedilus ct le temps disponible pour tester le logiciel pourrait

avoir une incidence sur le deacuteroulement normal de Jactiviteacute de lest qui peul changer

90

subtilement vers un test ad hoc ou dans la meilleure des cas au TE En effet la preacuteparation

des cas de tests tocirct dans le processus nest pas toujours fructueuse parce que les exigences ne

sont pas toujours stables au deacutebut du projet de deacuteveloppement Par la suite la planification et

la preacuteparation des cas de tests en se basant sur ces speacutecifications changent souvent et geacutenegraverent

des modifications et des mises agrave jour eacutenormes Aussi lemplacement des testeurs agrave la fin de

la chaicircne du deacuteveloppement cest-agrave-dire sur Je chemin critique de livraison du logiciel

sajoute au problegraveme que nous venons de citer Alors les testeurs accumulent les retards faits

au deacutebut de la chaicircne du deacuteveloppement et se retrouvaient souvent dans des situations

difficiles ougrave ils doivent faire de compromis entre le temps disponible pour le test la qualiteacute

attendue du logiciel et le budget Dans de telles situations souvent les praticiens renoncent

aux cas de tests sceacutenariseacutes et sen remettent au TE (Petty 2005 Bach et al 2002) Le TE leur

permet dinvestir le temps disponiblc dans le test du logiciel au lieu de mettre agrave jour les cas

de tests sceacutenariseacutes Selon Bach et al (2002) la preacuteparation des cas de tests pendant la phase

de conception du logiciel est une perte du temps du fait que ces cas de tests pourraient ecirctre

deacutesuets ulteacuterieuremcnt dans le cyclc du deacuteveloppement

Par contre le TE nc neacutecessite pas beaucoup du temps pour la preacuteparation de cha11es de test ]]

suffi t que le responsable de test preacutepare les chartes de tests en se basant sur nimporte quelle

source dinformation disponible (Kaner et Bach 2004) Nous pouvons dire quc cest

eacutequivalent agrave la preacuteparation dun plan de test selon le patron IEEE 829 puisque lobjectif dans

les deux cas est didentifier ce qui doit ecirctre testeacute les responsabiliteacutes lestimation de leffort

neacutecessaire pour remplir chaque mission dans le processus de tcst Notons quavant

lintroduction de la technique Session Based Exploratory Testing (SBET) Amland et Vaga

(2002) ont utiliseacute un plan de test sceacutenariseacute pour identifier les chartes des sessions de tests

exploratoires

Nous concluons de cette discussion que le TE est plus approprieacute dans les projets de test ougrave il

ya peu de temps pour le tcst surtout si les ressources financiegraveres ne permettent pas dajouter

de personnel ou de fairc dautres contingences Tandis que le TS est plus approprieacute dans les

projets de test ougrave il ya suffisamment de temps pour la preacuteparation ct la planification de test

91

72 Comparaison selon les caracteacuteristiques de gestion

Dans cette section nous abordons les eacuteleacutements principaux de gestion de lactiviteacute de test dans

les deux approches de test le TS et le TE Il sagit de la planification de test le controcircle et le

suivi de la progression de test la communication dans le projet de test et la relation avec le

client

721 La planification

Selon Joffice queacutebeacutecois de la langue franccedilaise la planification est un ensemble de deacutecisions

ayant pour but deacutetablir un ordre dapplication ugravees actions avant leur exeacutecution Dans cette

section nous allons discuter comment Ics deux approches abordent la planification en se

basant sur eelle deacutefinition

En ce qui concerne le TS lactiviteacute de test est piloteacutee par le plan de test eacutelaboreacute au deacutebut du

projet de test Ce plan situe les activiteacutes de test dans la strateacutegie globale de livraison du

logiciel La preacuteparation de plan dc test pcut commencer au moment de la formulation des

besoins et se deacuteveloppcr et se raffiner pendant la phase de conception du logiciel Cela

sinclut dans le cadre de test preacuteventif Ce type de test dicte que la planification de TS peut

preacutevenir les erreurs dans la phase de conception avant que celles ci se transforment agrave des

deacutefauts dans le code (Craig et Jaskiel 2002 Perry 2002 Swebok 2004) Alors du processus

de planification reacutesulte le plan de test Ce plan deacutecrit les items et les caracteacuteristiques

(fonctionnaliteacute performance utilisabiliteacute etc) qui devraient ecirctre testeacutes les caracteacuteristiques

qui ne devraient pas ecirctre testeacutees les responsabiliteacutes les livrables les besoins

environnementaux et leacutecheacuteancier du projct de test Par la suite tous les deacutetails des tests sont

identifieacutes et rigoureusement planifieacutes avant le deacutebut de leur exeacutecution En fait le plan de test

dans une activiteacute de TS vise deux objectifs essentiels le premier la planification de lactiviteacute

de test Je deuxiegraveme leacutetablissement des canaux de communications entre les intervenants agrave

linteacuterieur et lexteacuterieur du projet de test Selon (IEEE 829 1998) lutilisation de standard

IEEE 829 pourrait ameacuteliorer la qualiteacute de ces canaux de communication

Le TE introduit lui aussi la planification mais avec un rocircle et une signification diffeacuterents Au

deacutebut de lactiviteacute de test le responsable de test identifie une liste des items agrave tester Ces

92

itcms constituent les chartes de tests (deacutejagrave eacutevoqueacute dans le chapitre III) Cependant il ne sagit

pas dune identification complegravete de toutes les chal1es avant le deacutebut de lexeacutecution de test

mais dune planification preacuteliminaire agrave quelques chartes de test en se basant sur les

informations disponibles au deacutebut du projet de test Ce plan sameacuteliore pendant le

deacuteroulement du projet de test gracircce aux notes reacutesu hant de Jexeacutecution de chartes de test

Autrement dautres chartes de test sajoutent au fur et agrave mesure que les chartcs preacuteliminaires

sexeacutecutent En effet pendant lexeacutecution de charte de test le testeur peut explorer nimpone

quel panie du logiciel et rapporter ses constations el ses observations dans les notes de

session ce que Jonathan Bach (2000) appelle laquoOpportuniteacuteraquo Ces notes font lobjet dune

eacutevaluation avec le responsable de test Suite agrave cette eacutevaluation le responsable de test pourrait

ajouter des nouvelles chartes correspondant et mettre agrave jour le plan de chartes Selon James

et Wood (2003) la planification de TE est une planification continue (Figure32) Dans la

mecircme perspective Copeland (2003) classifie la planification de TE comme une planification

adaptative qui se change agrave chaque moment agrave la venue de nouvelles informations pendant le

processus de test alors que la planification sceacutenariseacutec est une pIani fication classique qui

identifie toutes les actions et les deacutetails de test avant lexeacutecution de ces actions

Nous pouvons constater que la planification dans une activiteacute de TE constitue un moyen de

controcircle et dencadrement de processus En fait il nc sagit pas dune planification telle

quelle est deacutefinie par le dictionnaire ougrave toutes les actions devraient ecirctre speacutecifieacutees avant leur

exeacutecution Mais cest une planification introduite par Jonathan Bach (2000) pour geacuterer

lactiviteacute de test et introduire le controcirclc ct la mesure sur le TE libre Donc il sagit dune

planification qui vise lexeacutecution de la mission de test du logiciel plutocirct que la documentation

ct larchivage en texte Nous pouvons constater aussi que la planification de TS est plus

cenaine et rigoureuse que la planification de TE En effet la planification de TS tend agrave

preacuteciser tous les deacutetails fins du processus de test avant le deacutebut de Icur exeacutecution tandis que

le TE tend agrave preacuteciser Jessentiel du processus de test et compte sur Jexploration des testeurs

pendant lexeacutecution des sessions de test pour raffiner et ameacuteJiorcr le plan initial

Nous concluons de cette discussion que Ic TS est plus approprieacute dans les projcts de test qui

neacutecessitent une planification cel1aine et rigoureuse de lactiviteacute de test Par exemple les

93

situations ougrave la plate-forme de test est disponible seulement par intermittence Comme un

projet client serveur ougrave les serveurs configureacutes devraient ecirctre partageacutes par lactiviteacute de test et

le deacuteveloppement La logistique dune telle situation peut exiger lutilisation de TS qui

pourrait fournir une planification rigoureuse de lactiviteacute de test pour profiter au maximum du

temps limiteacute pour les tests (Bach 2003) Par contre le TE est plus approprieacute dans Ics projets

de test flexibles

722 Le controcircle et le suivi de progression de test

Lobjectif de controcircle et du suivi du test est de foumir un retour et une visibiliteacute sur les

activiteacutes de test Les informations agrave suivre peuvent ecirctre recueillies manuellement ou

automatiquement et peuvent ecirctre utiliseacutees pour eacutevaluer les critegraveres de sonies comme la

couvenure de test Des mesures peuvent aussi ecirctre utiliseacutees pour eacutevaluer lavancement par

rapport au ca lendrier et au budget planifieacutes

Selon Craig et JaskieJ (2002) le controcircle et le suivi du test sont panni les problegravemes auxquels

le responsable devrait faire face dans un projet de test Alors le responsable devrait trouver

une meacutethode pour retracer ou suivre le deacuteroulement de lactiviteacute de test Par la suitc il devrait

ecirctre capable de faire un rapport sur le statut des tests agrave nimporte que 1 moment tant que le

produit est toujours sous test ]1 devrait aussi pouvoir reacutepondre aux questions typiqucs qui se

posent reacuteguliegraverement pendant les tests

bull Comment se deacuteroulent les tests

bull Quel est le pourcentage des tests accomplis

bull Qucl est le pourcentage des tests reacuteussis

Le TS se precircte tregraves bien agrave la mesure Un nombre total de cas de tests peut ecirctre calculeacute et une

meacutetrique de test peut ecirctrc creacuteeacutee mesurant par exemple Je pourcentage des cas de tests qui ont

eacuteteacute exeacutecuteacutes Des meacutethodes speacutecifiques proposeacutees dans la 1illeacuterature permellent de mesurer la

progression de lactiviteacute de TS et de preacutevoir la date de livraison du logiciel en se basant sur le

nombre de cas de tests restants avant la compleacutetude de lactiviteacute de test (Kan 2001 Craig et

Jaskiel 2002)

94

Quant au TE les mesures collecteacutecs pendant le test et le deacutebriefing permettent destimer la

productiviteacute ou le rendement de chaque membre de leacutequipe de test pendant le projct de test

en cours Cela avec le nombre de sessions compleacuteteacutees pourrait aider dans lestimation de la

quantiteacute du travail restant avant la fin du cycle de test (Jonathan Bach 2000) Notons que le

sujet du controcircle de la progression nest pas toujours bien abordeacute dans la litteacuteraturc agrave part ce

meacutecanisme proposeacute par Jonathan Bach (2000) Toutefois ce meacutecanisme aide sculcmcnt dans

leacutelaboration dune estimation de la quantiteacute du travail restant avant la fin du cycle dc test Il

ne sagit que dune estimation la preacutevision se basant sur cette estimation eacutetant incertaine

Nous pouvons conclure de cette discussion que le controcircle et le suivi de la progression de test

dans le TS est mesurable alors quil nest quun estimeacute En conseacutequence nous concluons que

le TS est plus approprieacute dans les projets de tests qui ont un eacutecheacuteancier fixe alors que le TE

est approprieacute dans les projets de test qui ont un eacutecheacuteancier flexible et toleacuterant au retard qui

pourrait reacutesulter dune mauvaise estimation

723 La communication dans le projet de test

Le TE mise fOl1ement sur les connaissances tacites et sur les compeacutetenccs interpersonnelles

Comme nous avons deacutejagrave vu dans la revue de litteacuterature le TE est baseacute sur les connaissances

tacites du testeur et son expertise (Itkonen et Rautiainen 2005 Petty 2005 Lyndsay ct van

Eeden 2003 Wood et James 2003) Les compeacutetences interpersonnelles jouent aussi un rocircle

important dans la qualiteacute du travail (Lyndsay et van Eeden 2003) la communication eacutetant

essentielle dans le TE Nous avons constateacute dapregraves notre revue de litteacuterature que la

communication et leacutechange des connaissances interviennent de diffeacuterentes faccedilons dans le

TE La premiegravere est Je partage des connaissances entre le testeur et dautres intervenants hors

de leacutequipe de test comme le client En effet le testeur chargeacute de lexeacutecution dune mission

de TE pourrait collecter les informations neacutecessaires sur le logiciel agrave tester agrave paI1ir des

reacuteunions ou des discussions avec diffeacuterents intervenants dans le projet de deacuteveloppemcnt du

logiciel agrave tester afin de comprendre et dapprcndre le logiciel el ses caracteacuteristiques

fonctionnelles (Kaner et Bach 2004)

La deuxiegraveme forme dc communication est entre testeurs et responsablc du test Ce dcmier

devrait deacutebriefer chaquc testeur apregraves Jexeacutecution dc chacune des chartes dc test pour eacutevaluer

95

le travail accompli Alors pendant le deacutebriefing le responsable pourrait eacutechanger ses

connaissances avec le testeur pour le guider (Jonathan Bach 2004 Lyndsay et van Eeden

2003) La communication pourrait aussi prendre la forme dune collaboration entre les

testeurs La communication entre les membres de leacutequipe de test pourrait ameacuteliorer la

qualiteacute de TE effectueacute En effet de bons canaux de communication permettent deacutechanger les

expeacuteriences et les connaissances dans leacutequipe de faccedilon agrave ce que les membres plus

expeacuterimenteacutes aident et encadrent les membres moins expeacuterimenteacutes (Lyndsay et van Eeden

2003)

La troisiegraveme forme deacutechanges des connaissances peut apparaicirctre pendant la session de test

entre deux personnes qui se chargent de lexeacutecution de la mecircme mission de test deacutefinie sous

le terme de laquotest par pairesraquo Nous avons noteacute cela agrave travers les eacutetudes de cas que nous avons

proposeacute dans la revue de litteacuterature parfois entre deux testeurs (Amand et Vaga 2002) ou

entre un testeur et un deacuteveloppeur (Petty 2005)

Le TS au contraire se mise beaucoup sur les connaissances explicitement documenteacutees La

communication entre les praticiens dans le projet de test est centreacutee autour dcs livrables bien

deacutetermineacutes En effet souvent les testeurs chargeacutes de la conception (testeurs seniors)

communiquent avec les testeurs chargeacutes de lexeacutecution des tests (testeurs juniors) par les

proceacutedures de test Ces derniers communiquent reacuteciproquement par les rapports dincidents

En ce qui concerne la communication entre les testeurs et les deacuteveloppeurs dans la plupart

des cas la communication se fait agrave travers laquole Bug Traeking System raquo le systegraveme qui

enregistre les deacutefauts deacutetecteacutes Nous notons que dans quelques situations il regravegne une

relation difficile entre les deacuteveloppeurs et les testeurs (Bach et al 2002) du fait que les

deacuteveloppeurs sentent que les testeurs deacutetruisent leur travail et se sentent responsables des

deacutefaillances deacutetecteacutees

Nous pouvons conclure que la gesti on de TE se fonde sur la communication entre les

intervenants dans le projet de test mecircme la qualiteacute des tests effectueacutes deacutepend de la qualiteacute de

communication entre le responsable des tests et les testeurs tandis que la gestion dans le TS

se fonde sur la documentation

96

En conseacutequence il semble que les contextes supportant la communication informelle sont

plus approprieacutes et favorables au TE

724 La relation avec le client

Selon Kaner et Bach (2004) la conversation avec le client pourrait ecirctre une source

dinformation importante pour la compreacutehension et lappreacutehension du logiciel dans une

activiteacute de TE Agrave cet effet une bonne relation avec le client est essentielle dans le TE Par

contre celte relation nest pas neacutecessaire dans une activiteacute de TS du fait que les cas de test

sont conccedilus agrave partir des exigences du systegraveme Cependant il est faux de dirc que celte

relation entre le testeur et le client nest pas souhaiteacutee dans le TS Selon Craig et Jaskiel

(2002) le client peut jouer un rocircle important dans lactiviteacute de TS par la participation dans les

reacuteunions didentification de la liste des risques du logiciel Ceci pourrait optimiser et orienter

lactiviteacute de test vers les risques importants du logiciel

Nous concluons de celte discussion quune bonne relation avec le client est essenticllc dans le

TE et pourrait ameacuteliorer la compreacutehension du logiciel Par contre elle est souhaiteacutee ct non

obligatoire dans le TS

73 Comparaison selon les caracteacuteristiques techniques

Nous allons discuter dans cette section des caracteacuteristiques techniques de deux approches de

test le TE et le TS Ces caracteacuteristiques portent sur le processus de test les activiteacutes de test

les artefacts creacutees et les eacuteleacutements neacutecessaires pour le bon deacuteroulement de test Nous allons

cssayer de deacuteceler comment les deux approches de test le TE et le TS abordent chaquc eacutetapc

de lactiviteacute de test Selon (Swebok 2004 Pyhajarvi ct aL 2003 Craig et Jaskicl 2002

Perry 2000) les activiteacutes de test comportent les eacutetapes suivantes la planification la

conception dc tests et lexeacutecution de tests Toutefois ces activiteacutes sont influenceacutees selon

(Bolton 2005) par trois facteurs agrave savoir les risqucs du logiciel Joracle de tcst ct la

couverture de test tel quillustreacute sur la figure 71

97

Figure 71 Les eacuteleacutements essentiels du test du logiciel (Bolton Kaner et Bach 2005)

Les risques du logiciel

Les activiteacutes de test 1 La couvertu~ Ee d~ t~)

731 Les activiteacutes de test

En ce qui concerne le TS les cas de test sont conccedilus au deacutebut de lactiviteacute de test

principalement agrave partir des exigences du logiciel Chaque cas de tcst devrait ecirctre sous le

controcircle de la gestion de configuration du logiciel et inclure les reacutesultats preacutevus dc chaque

test (Swebok 2004 Perry 2000 Hetzel 1988) La conception ct la planification pourraient

commencer en parallegravele avcc le projet de deacuteveloppement

Tel quillustreacute agrave la figure 72 la preacuteparation de plan de test et des cas de test se font par le

testeur souvent un testeur senior en utilisant les entreacutees speacutecifiques de projet de test en

cours Alors ces entreacutees peuvent inclure les exigences du logiciel les standards ct les normes

agrave respecter qui varient selon le domaine de test Dans certaines situations le test peut ecirctre

guideacute par divers objectifs comme les risques du logiciel ou les cas dutilisations pour

identifier les prioriteacutes de test et focaliser sa strateacutegie (Swebok 2004) Quant aux tcchniques

de tesl elles sont choisies selon la nature du logiciel sous test lefficaciteacute et la preacutecision

souhaiteacutees (Craig el Jaskiel 2003 Biezer J990)

Sajoutenl agrave ces entreacutees citeacutees ci dessus les compeacutetences et les quaI ifications du testeur

senior chargeacute de la conception de tests ses connaissances comme les connaissances du

98

domaine du logiciel agrave tester ses expeacuteriences anteacuterieures ses connaissances techniques et ses

qualiteacutes personnelles Linteraction de toutes les entreacutees permet didentifier le plan et les cas

de test Le pourcentage de cOLlvel1ure de test atteint pourrait ecirctre mesureacute agrave cc niveau du

processus de test agrave laide de a matrice de traccedilabiliteacute figure 2

Figure 72 Les activiteacutes de test sceacutenariseacute (Adapteacute et traduit de Bach 2006)

Les entreacutees Les connaissances du domaine Les sorties Les expeacuteriences anteacuterieures Les connaissances techniques Les qualiteacutes personnelles

Les Les cas Le plan

risques dutilisations de test

Les Les standards Les cas de

exigences tests

Les techniques de La couverture Seacuteparation dans le temps

tests et fou dans lespace

Les entreacutees Les sorties

Rapports

Les cas de dincidents tests

Systegraveme sous test

99

Les cas de tests sont souvent exeacutecuteacutes ulteacuterieurement par des testeurs juniors quand le

logiciel devient disponible pour le test Ces testeurs se chargent de Jexeacutecution des proceacutedures

de test Ces derniegraveres deacutecrivent tous les deacutetails fins neacutecessaires agrave lexeacutecution des tests

incluant les reacutesultats preacutevus comme nous lavons deacutejagrave proposeacute dans le chapitre II Il suffit

que les testeurs comparent les reacutesultats preacutevus et les reacutesultats observeacutes En cas dapparition

dune deacutefaillance le testeur rapporte les reacutesultats dans le rapport dincident preacutevu agrave cet effet

selon la norme IEEE 829

Figure 73 Les activiteacutes de test exploratoire (Adapteacute et traduit de Bach 2006)

Les entreacutees Les connaissances du domaine Les sorties Les expeacuteriences anleacuterieures Les connaissances techniques Les qualiteacutes personnelles La charte de

session

Rapport de session Nimporte quelle

documentation existante o Les Deacutefauts

les exigences le manuel

dutilisateur E-mail o Les notes

Les techniques de o Ips nrnhlpmls

test

Systegraveme sous test

Par contre tel quillustreacute agrave la figure 73 les cas de tests de TE sont conccedilus pendant le test En

effet le testeur reccediloit en entreacutee la charte de la session de test qui identifie les grandes lignes

de sa mission de test Il doit sinformer sur le logiciel en utilisant nimporte quelle source

dinformation existante dans le projet de test en cours comme Je manuel dutilisateur des

discussions avec le client et les deacuteveloppeurs et dautres Par la suite il doit identifier les

techniques convenables de test Parfois ces techniques de test peuvent ecirctre mentionneacutees dans

la charte de test selon la complexiteacute ct le risque ditems agrave tester traiteacutes dans la charte Alors

100

pendant lexeacutecution de sa mission le testeur apprend explore conccediloit et exeacutecute les tests

(Bach 2003) Chaque cas de test beacuteneacuteficie de (information obtenue de tests anteacuterieurs et la

maturiteacute des connaissances accumuleacutees agrave chaque moment de lactiviteacute de test (Bach et aL

2002) Les reacutesultats de la session de test sont rapporteacutes dans le rapport de la session Ce

rapport fera lobjet dun deacutebriefing avec le responsable de test afin de valider le travail

effectueacute par le testeur

Nous concluons de cette discussion que le TS est plus approprieacute dans les projets de test

favorisant la reacutepeacutetitiviteacute et lauditabiliteacute de tests Par contre le TE est plus approprieacute dans les

projets de test favorisant la creacuteativiteacute et ladaptabiliteacute agrave chaque moment de processus de test

732 Les risques du logiciel

Selon le dictionnaire de loffice queacutebeacutecois de la langue franccedilaise le risque informatique est la

probabiliteacute plus au moins grande de voir une menace informatique se transformer en

eacuteveacutenement reacuteel entraicircnant une perte II se mesure agrave la fois par la probabiliteacute doccurrence

dune menace et par limpact de sa reacutealisation Dans la litteacuterature de test du logiciel le risque

du logiciel se deacutefinit comme la probabiliteacute doccurrence et limpact de la reacutealisation dune

deacutefaillance dans le logiciel (Craig et ]askiel 2002 Lyndsay et van Eeden 2003)

Limpossibiliteacute de test complet du logiciel (Pressman 1997 Kaner 1997 Hetzel 1988) et

les cycles de deacuteveloppement de plus en plus courts ont pousseacute les intervemmts dans le

domaine de test du logiciel agrave chercher des techniques leur permettant dexploiter le temps

consacreacute au test dune faccedilon optimale telle que lanalyse de risque du logiciel Selon

Swcbok (2004) les diffeacuterentes eacutetapes de tests pourraient ecirctre guideacutees par les risques associeacutes

au logiciel pour identifier sa prioriteacute et focaliser sa strateacutegie Ces risques sont identifieacutes par le

biais dune analyse qui pourrait ecirctre faite pendant la phase de preacuteparation de lactiviteacute de test

Cette analyse permet de deacuteterminer les eacuteleacutements du logiciel les plus susceptibles de contenir

le plus de deacutefauts Les reacutesultats de cette activiteacute sont utiliseacutes pendant le planning pour

deacuteterminer la strateacutegie de test les prioriteacutes et la profondeur de test neacutecessaire (Craig et

]askiel 2002 Lyndsay et van Ecdcn 2003 Perry 2000)

Le standard de documentation IEEE 829 a identifieacute une section dans le patron de plan de test

101

pour les risqucs ct contingences En fait cette section nidentifie que les risques pouvant

empecirccher le deacuteroulement normal de plan de test Dans la pratique de test les entreprises

divisent celle clause de plan de test a deux clauses une traite les risques pouvant empecirccher

lexeacutecution normale de plan de test ainsi les contingences convenables pour les surmonter

lautre traitc et identifie les risques du logiciel (Craig et Jaskiel 2002) et cite les proceacutedures agrave

entreprendre dans le test pour minimiser ses probabiliteacutes docculTence et ses impacts en cas

de reacutealisation

Dans une activiteacute de TS lanalyse de risques associeacutes au logiciel se fait agrave partir de documents

des exigenccs et de conception du logiciel Le livrable de cette phase est une matrice de

risque montrant le degreacute de risque acceptable pour chaque fonction ou secteur du logiciel et

sa criticiteacute aux affaires (Craig et Jaskiel 2002) Par la suite lapproche de test et leffort de

test neacutecessaire de chaque eacuteleacutement de cette matrice pourront ecirctre fixeacutes et documcnteacutes selon le

degreacute de risque calculeacute Ainsi les cas de test conccedilus pourront ecirctre revus et inspecteacutes par

plusieurs intervenants dans le projet de test autant de fois que neacutecessaire pour sassurer de la

profondeur et la couverture de tests des zones risqueacutees du logiciel

Selon (Bach 2003 Kaner et Tinkham 2003) le TE pourrait ecirctrc guideacute par une liste de

risques Lc responsable de test identifie cette 1iste en se basant sur nimporte quclle reacutefeacuterence

ou source dinformation existant dans Je projet de test (Jonathan Bach 2004 Lyndsay et van

Eeden 2003) Suite agrave cette identification les chartes com~spondant aux eacuteleacutements de cette

liste seront plus deacutetai lIeacutees que les autres chartes et pourront mecircme deacutecrire les techniques agrave

utiliser pcndant le tcst (Jonathan Bach 2004) Cependant le degreacute au bas niveau pour lequel

chaque eacuteleacutement de la liste est testeacute ne pourrait pas ecirctre assureacute mecircme avec les notes de session

et le deacutebriefing avec le responsable Par conseacutequent le TE pOl1e le risque que certaines parties

de grands risques ne soient pas testeacutecs correctement

Nous concluons de cette discussion que lauditabiliteacute de TS assure que les risques du logiciel

soient bien testeacutes par conseacutequent le TS pourrait ecirctre plus approprieacute dans les projets de test

preacutescntent un niveau eacuteleveacute de risque Tandis que le TE ne garantit pas que les secteurs agrave

risque soicnt bicn couvel1s

102

733 La couverture de test

La couverture de test est la mesure de ce qui a eacuteteacute testeacute proportionnellement agrave ce qui pourrait

ecirctre testeacute (Kaner 1996) Cest le degreacute exprimeacute en pourcentage selon lequel un eacuteleacutement de

couverture (les exigences lignes de code branches etc) a eacuteteacute exeacutecuteacute lors dune suite de

tests Cest une meacutetrique importante dans lactiviteacute de test logiciel Sa pertinence reacuteside dans

Je fait quil permet deacutevaluer la qualiteacute des tests effectueacutes et de savoir si le logiciel a subi

assez de tests (Swebok 2004) Pratiquement la mesure de la couverture des exigences et de

la couverture du code sont les deux formes de mesures de couverture les plus utiliseacutees et

discuteacutees dans la litteacuterature et les plus supporteacutees par les outils dans le domaine de test du

logiciel

La matrice de traccedilabiliteacute (Figure 21) constitue la premiegravere forme de mesure de couverture en

type de test boicircte noire En effet cette matrice montre agrave quel degreacute chaque exigence ou

caracteacuteristique du logiciel (la fiabiliteacute lutilisabiliteacute etc) a eacuteteacute testeacutee en illustrant le nombre

de cas de tests qui la couvre (Craig et Jaskiel 2002 Bach et al 2002) Puis des inspections et

des revues formelles des cas de tests permettent deacutevaluer la qualiteacute des cas de tests conccedilus et

de sassurer que les secteurs identifieacutes pendant lanalyse de risque du logiciel sont bien

couverts par Ics tests (Craig ct Jaskiel 2002)

La deuxiegraveme forme est la mesure de eouvcI1ure de code Cest une meacutethode danalyse qui

deacutetermine quelles parties du programme ont eacuteteacute exeacutecuteacutees (couvertes) par une suite de tests et

quelles parties ne lont pas eacuteteacute par exemple la couverture des lignes de code des deacutecisions

ou des conditions Dans Je type de test de type boicircte noire la couverture de lignes de code

sutilise souvent en utilisant un logiciel outil appeleacute laquomoniteur de testraquo Ce moniteur mesure

ou calcule le pourcentage de lignes de code exeacutecuteacute lors de lexeacutecution des cas de tests

sceacutenariseacutes (Kaner et al 1999 Marick 1997) Alors si le pourcentage mesureacute est insuffisant

des cas de tests peuvent ecirctre ajouteacutes afin datteindre le pourcentage viseacute

Bach (2003) a mentionneacute que les chartes de tests peuvent ecirctre identifieacutees selon une liste ou

matrice de couverture cest-agrave-dire une liste des eacuteleacutements du logiciel agrave recouvrir dans le test

Cependant la couverture de bas niveau ne pouvait pas ecirctre mesureacutee du fait que les meacutethodes

103

traditionnelles que nous venons de citer dans le TS ne pourraient pas ecirctre utiliseacutees dans le TE

En conseacutequence la couverture du test nest pas claire ni mesurable dans le TE Les auteurs

Itkonen et Rautiainen (2005) ont mentionneacute que ce manque de mesure de couverture est la

plus grande lacune du TE Lindsay et van Eeden (2003) ont proposeacute une technique pour

mesurer la couverture de test que nous avons deacutecrite dans la revue de litteacuterature Quoique la

technique soit innovatrice son succegraves deacutepend aussi de Jexpeltise de testeur et de sa capaciteacute

de faire un bon jugement sur Je pourcentage couvert par les tests pendant la session de test

Dun autre point de vue la mesure de couverture est tregraves utile pour la prise de deacutecision de

larrecirct de test En effet une des choses les plus difficiles dans le test de logiciel est de savoir

quand le logiciel est suffisamment testeacute et precirct agrave ecirctre livreacute Eacutevidemment le logiciel est bien

testeacute quand tous les bogues sont trouveacutes Cependant impossible de savoir sils sont tous

trouveacutes Ce problegraveme a eacuteteacute reconnu par Dijstra en 1972 par sa citation ceacutelegravebre qui deacuteclare que

laquole test du programme peut ecirctre utiliseacute pour montrer la preacutesence des bogues mais jamais

pour montrer leur absenceraquo De ce fait le recours aux critegraveres permettant la prise de deacutecision

de larrecirct de tests reste neacutecessaire Selon Copeland (2004) les critegraveres les plus utiliseacutes dans

la pratique sont le budget le calendrier de test et la couverture de tests En conseacutequence la

couverture fournit un appui utile pour la prise de deacutecision de larrecirct de tests (Swebok 2004)

Toutefois les praticiens dans lindustrie de test qui ont utiliseacute le TE comme une

meacutethodologie primaire de test et les auteurs fondateurs de lapproche (Bach et al 2002)

nont pas preacutesenteacute les meacutecanismes et les techniques quils ont utiliseacutes pour prendre la

deacutecision darrecircter le test

Nous concluons de cette discussion que la mesure de couverture de test ne peut pas ecirctre

mesureacutee dans le TE Par conseacutequent le TE nest pas approprieacute dans les projets de test qui

neacutecessitent que la couverture de test soit mesureacutee

734 Loracle de test

Selon Hoffman (1999) le test du logiciel est la comparaison du comportement du logiciel

avec le comportement attendu de celui-ci Ce compol1cmcnt attendu est connu sous Je terme

laquoOrac leraquo

104

Nous allons aborder dans cette section les faccedilons deacutelaboration de loracle de test dans le les

deux approches de test le TS et le TE

Selon Swebok (2004) un oracle de test est nimporte quel agent humain ou meacutecanique qui

statue si un programme sest comporteacute correctement dans un test donneacute et produit en

conseacutequence un verdict de passage ou eacutechec de test Selon Biezer (1990) un oracle de test est

nimporte quel programme processus ou ensemble de donneacutees qui speacutecifient les reacutesultats

preacutevus

Dans une approche sceacutenariseacutee leacutevaluation de comportement du logiciel sous test est deacutejagrave

intrinsegraveque aux cas des tests qui mentionnent les reacutesultats preacutevus Ccs reacutesultats servent

comme un oracle et guident le testeur pendant le test Cet oracle de test est de type

entreacuteesortie (Biezer 1990) cest-agrave-dire le testeur devrait exeacutecuter le logiciel en utilisant les

entreacutees speacutecifieacutees dans Je cas de test puis comparer les reacutesultats observeacutes aux sorties

speacutecifieacutees dans le cas de tesl Sils sont semblables le logiciel passe le test sinon il eacutechoue le

test

Selon Bach (1999) loracle de test est une strateacutegie eacutelaboreacutee au moment du test pour

deacuteterminer si un comportement observeacute du logiciel est correct ou non Alors nous pouvons

constater de cette deacutefinition que Joracle de test dans Je TE sc construit en temps reacutee) pendant

le tesl Le testeur formule une ideacutee sur le comportement normal et correct du logiciel en se

basant sur ses intuitions et anticipations ses compeacutetences et sa compreacutehension du logiciel agrave

tester

Afin de faciliter et guider la reacuteflexion de testeur exploratoire pendant la session de test Bach

et Kaner (2005) ont proposeacute une liste des heuristiques Ces demiegraveres pourraient aider le

testeur agrave construire Joracle de test en se basant sur la veacuterification de la coheacuterence selon

plusieurs dimensions Chacune de ces dimensions exploite un aspect particulier de contexte

de projet de test pour savoir si le comportement observeacute apregraves lexeacutecution dun test donneacute est

normal ou non par la suite prendre une deacutecision dc passage ou deacutechec dc tesl

105

Cette liste inclut

bull Coheacuterence du logiciel le comportement de chaque fonction est coheacuterent avec le

comportement de dautres fonctions comparables du logiciel ou avec le pattern

fonctionnel

bull Coheacuterence par rapport aux logiciels comparables le comportement de chaque

fonction du logiciel est coheacuterent avec le comportement dautres fonctions de logiciels

comparables

Coheacuterence avec lhistorique le comportement actuel du logicicl est coheacuterent avec

son comportement anteacuterieur

bull Coheacuterence avec limage de lorganisation le comportement du logiciel est coheacuterent

avec limage que lorganisation voulait projeter

bull Coheacuterence avec les exigences le comportement est coheacutercnt avec la documentation

existante et ce qui est annonceacute sur le produit

bull Coheacuterence avec les speacutecifications et les reacutegulations le comportement cst coheacuterent

avcc les exigences et les normes qui devaient ecirctre respecteacutees dans le projet de test

Coheacuterence avec les attentes de Jutilisatcur le cOmpoJ1ement est coheacuterent avec ce que

lutilisateur attend du logiciel

bull Coheacuterence avec Jobjectif du produit le comportemcnt cst coheacuterent avec le but

apparent et la fonction globale du produit

Dans la mecircme perspective Whittaker (2003) a proposeacute un modegravele intituleacute laquo Fault Modelraquo

pour guider le testeur dans Jeacutelaboration de loracle de test Lideacutee principale de ce modegravele est

que le logiciel a quatre capaciteacutes principales acccptcr les entreacutees enregistrer les donneacutees

traiter les donneacutees entreacutees et enregistreacutees ct produire des sorties Donc si le logiciel ne fait

pas lune de ces eacutetapes correctement pendant lexeacutecution dun cas de test il eacutechoue le test Ce

modegravele fait paJ1ie dcs techniques citeacutees et rccommandeacutees par Bach et Kaner (2004) Ces

106

meacutecanismes sajoutent agrave dautres qui visent la simplification de la mission de testeur pendant

la session de test ainsi que lameacutelioration des reacutesultats de TE Mais une question qui se pose

est-ce que nimporte quel testeur pourrait ecirctre capable dutil iser toutes ces techniques Il

semblerait que ces tcchniques neacutecessitent un testeur compeacutetent et expeacuterimenteacute

Dun autre point de vue selon Kaner (2004) la speacutecification des reacutesultats preacutevus de chaque

test dans le TS pourrait avoir des conseacutequences neacutegatives sur lefficaciteacute de lactiviteacute de test

Selon cet auteur le logiciel ou le systegraveme informatique pourrait eacutechoucr de plusieurs faccedilons

impreacutevues Par conseacutequent loracle entreacuteesortie de TS pourrait desservir au lieu de servir

dans le test parce quil peut empecirccher la deacutetection des deacutefauts non preacutevus dans le cas de test

Nous concluons de cette discussion que le TS permet davoir le mecircme oracle de test chaque

fois que les cas de test sont exeacutecuteacutes li permet aussi de veacuterifier le logiciel formcllement par

rapport ses speacutecifications Par contre loracle de TE est variable et permet dc comparer le

logiciel contre les preacutevisions du testeur

74 Comparaison selon les caraeacuteteacuteristiques du personnel

Dans cette section nous allons discuter de linflucncc des caracteacuteristiqucs du personncl sur le

choix de lapproche de test Les caracteacuteristiqucs du personncl rcgroupcnt deux factcurs les

caracteacuteristiques du testeur et la culture de lorganisation ougrave se deacuteroulc Ic projet de test

74J Les carateacuteristiques du testeur

En geacuteneacuteral tel quillustreacute sur les figures 72 et 73 les deux approches le TE et le TS

neacutecessitent des qualifications et des compeacutetences pour que le test soit efficace et attcigne ses

objectifs La diffeacuterence reacuteside dans le niveau dapplication de ces compeacutetences En effet dans

une activiteacute de TS nimporte quel testeur peut exeacutecuter les proceacutedures de tests Ces

proceacutedures sont deacutecomposeacutees en eacutetapes claires et faciles agrave suivre comme nous lavons deacutejagrave

eacutevoqueacute dans le chapitre Il Par conseacutequent lexeacutecution des tests sceacutenariseacutes nexige pas des

testeurs tregraves expeacuterimenteacutes et fortement habiles et mecircme un testeur qui vient juste de

commencer sa carriegravere en test logiciel pourrait faire face (Craig Jaskiel 2002)

Par contre la conception des cas de tests exige la compeacutetence Donc cest agrave ce niveau que

107

les qualifications et lexpertise sont neacutecessaircs Parcc quil y a un deacutelai entre la creacuteation des

cas de tests et leur exeacutecution diffeacuterents testeurs peuvent concevoir et exeacutecuter les cas de

tests De ce fait les tests peuvent ecirctre conccedilus par des testeurs compeacutetents ou mecircme par un

seul testeur expert ct ecirctre deacuteleacutegueacutes agrave plusieurs moins expeacuterimenteacutes Bref il ny a aucun

besoin davoir seulement des tesleurs experts dans une eacutequipe de test sceacutenariseacute

Par contre le TE neacutecessite des compeacutetences et de qualifications importantes pour la

conception et lexeacutecution des tests (Itkonen et Rautiainen 2005 Petty 2005 Swebok 2004

Lyndsay et van Eeden 2003 James et Wood 2003 Amland et Vaga 2002) Selon Kaner

(2004) nimporte quelle activiteacute de test neacutecessite la creacuteativiteacute et les compeacutetences pour ecirctre

efficace incluant le TS Selon ce mecircme auteur les cas de tests sceacutenariseacutes peuvent limiter la

creacuteativiteacute de testeur et la transformer en un robot exeacutecutant les tacircches demandeacutees sans aucune

reacuteflexion critique surtout si le rendement du testeur est eacutevalueacute par le nombrc de cas de test

exeacutecuteacutes et par les erreurs deacutetecteacutees Dans une telle si tuation le testeur se concentre sur

lexeacutecution des proceacutedures de test et eacutevite la deacuteviation ellimprovisation

Dans le but de montrer les effets neacutegatifs de TS sur la creacuteativiteacute du testeur Kaner et son

eacutequipe (Kaner et Bach 2005) ont eacutelaboreacute plusieurs expeacuteriences et recherches dans les

laboratoires de Florida Institut sur des souris dont les deacutemonstrations sont disponibles dans

(Kaner et Bach 2005) Ces recherches ont prouveacute que les proceacutedures de test pourraient

empecirccher le testeur de voir dautres problegravemes non speacutecifieacutes dans les proceacutedures mais qui

peuvent apparaicirctre pendant lexeacutecution agrave cause du fait que le testeur se concentre seulement

sur les reacutesultats identifieacutes dans les proceacutedures de tests Cela est connu en psychologie sous le

terme anglophone laquoInattentional Blindnessraquo (Mack et Rock 2000) Selon Kaner (2004) le TE

aide le testeur agrave apprendre de nouvelles meacutethodes ct strateacutegies de test en lui permettant

dameacuteliorer sa capaciteacute danalyse et de reacuteflexion critique Selon les constations de Petty

(2005) la possibiliteacute dapprentissage dans le TE est plus grande que celle en TS

Nous concluons que le TE est approprieacute dans les projets de test ayant des testeurs compeacutetents

et experts Tandis que le TS est plus approprieacute dans les projets de test que ont un nombre

limiteacute de testeurs expelis et plusieurs non expeacuterimenteacutes

108

742 La culture de lorganisation

La culture de lorganisation pourrait fortement influencer le choix de lapproche de test

Selon Craig et laskiel (2002) un processus de TS ne pourrait pas ecirctre mis en place sil

nexistait pas un proccssus de deacuteveloppement formel et bien structureacute qui supporte le projet

de test Souvent les entreprises qui utilisent les bonnes pratiques et les meacutethodes disciplineacutees

de deacuteveloppement favorisent plus lutilisation de TS qui convient plus avec leur

meacutethodologie de deacuteveloppement Tandis que les entreprises qui possegravedent des processus

immatures ou chaotiques de deacuteveloppement ne pourraient pas utiliser le TS Ces entreprises

favorisent souvent des meacutethodes de test informelles comme le TE (Lyndsay van Eeden

2003 ltkonen et Rautiainen 2005)

Nous concluons gue le TS est plus approprieacute dans les projets de test des entreprises favorisant

la discipline Tandis gue le TE est plus approprieacute dans les entreprises qui ont des processus de

deacuteveloppement immatures et qui sappuient sur les compeacutetences et la creacuteativiteacute du personnel

pour mener les activiteacutes de deacuteveloppement ct eacuteviter le chaos

75 Comparaison selon la productiviteacute

Dans cette section nous allons comparer les deux approches de test le TS et le TE selon le

facteur de laquola productiviteacute raquo Nous discutons la productiviteacute en termes du nombre de deacutefauts

deacutetecteacutes et de limportance de deacutefauts deacutetecteacutes

Depuis son apparition dans Je domaine du test le TE sest fait promouvoir comme une

meacutethode efficace Selon Bach (2003) le TE pourrait ecirctre plus productif que le TS Cependant

il ny a aucune preuve jusquagrave maintenant dans la litteacuterature prouvant cette productiviteacute agrave part

quelques anecdotes et expeacuteriences veacutecues des praticiens

Theacuteoriquement lefficaciteacute pourrait ecirctre perccedilue autrement gue baseacutee seulement sur la base du

compte des deacutefauts trouveacutes Selon Copeland (2004) le TS est plus avantageux que Je TE du

fait quil pourrait sintroduire tocirct dans le cycle du deacuteveloppement du logiciel En effet dans

les vues preacuteventives actuelles le TS peut commencer des le deacutebut de projet du

deacuteveloppement Par la suite il pourrait deacutelecter les erreurs dans la conception et les exigences

avant que ces derniegraveres ne se transforment en des deacute1agraveuts dans le logiciel Par contre le TE

109

ne pourrait sintroduire quapregraves le codage du logiciel De ce point de vue nous pouvons

conclure que le TS est plus efficace que le TE vu sa capaciteacute de preacutevenir les deacutefauts Dun

autre point de vue selon (Copland 2004 Kaner 2003) les cas de tests sceacutenariseacutes deviennent

laquofatigueacutesraquo cest-agrave-dire incapables de deacutetecter de nouveaux deacutefauts dans les cycles ulteacuterieurs

de test Par conseacutequent le TE pourrait ecirctre plus efficace dans cette situation

Les auteurs Itkonen Rautiainen (2005) ont tenteacute de collecter des donneacutees quantitatives

pouvant leur donner une ideacutee de la productiviteacute de TE Malheureusement les donneacutees

collecteacutees neacutetaient pas fiables Sajoute agrave ce fait labsence des reacutesultats de TS pouvant servir

comme une reacutefeacuterence de comparaison Dans les autres eacutetudes de cas que nous avons

proposeacutees dans la revue de litteacuterature les praticiens ont tous rappol1eacute que leur expeacuterience

dans Jutilisation de TE comme une approche primaire de test a eacuteteacute fmetueuse et reacuteussie

Cependant ils nont pas preacutesenteacute des donneacutees quantitatives sur lefficaciteacute reacutealiseacutee et les

reacutesultats obtenus

Quant agrave notre expeacuterience qui sest deacuterouleacutee dans les laboratoires informatiques de lUQAgraveM

nous navons pas pu tirer des conclusions fiables et geacuteneacuteraliseacutees agrave cause des limites du

contexte de lexpeacuterience Cette limite est causeacutee par la taille du programme utiliseacute dans

lexpeacuterience choisi pour faciliter la tacircche des sujets et eacuteviter les reacutesultats nuls Le contexte ne

nous a pas permis daborder lactiviteacute de test dune faccedilon professionnelle Le manque

dexpeacuterience des sujets dans le domaine de test du logiciel sajoute aussi aux limitations de

contexte Ces limitations ont influenceacute les reacutesultats de lexpeacuterience Cela est appam

clairement dans les reacutesultais de TS obtenus Quoique nous ayons proposeacute aux sujets les

mecircmes sceacutenarios de cas de test nous avons constateacute que les sujets ont interpreacuteteacute les reacutesultats

observeacutes diffeacuteremment ct ils ont eu de la difficulteacute agrave classifier les deacutefagraveuts deacutetecteacutes

correctement Nous avons dailleurs duuml les reclasser apregraves lexpeacuterience

Les reacutesultats recueillis de cette eacutetude empirique nous a permis de conclure que le TE est plus

productif en terme de nombre des deacutefauts deacutetecteacutes que le TS Ainsi nous avons conclu que Je

TE pourraient deacutetecter des deacutefauts plus importants point de vue graviteacute que le test sceacutenariseacute

110

76 Discussion et synthegravese

Dans ce chapitre nous avons compareacute les deux approches de test Je TE et le TS selon les

facteurs du cadre de comparaison que nous avions eacutelaboreacute Dans cette section nous allons

reacutecapituler les reacutesultats et conclure Le tableau ci-bas reacutecapitule les reacutesultats de notre analyse

comparative Il inclut les facteurs principaux qui doivent ecirctre pris en compte pendant la

seacutelection de lapproche de test pour eacuteviter de proposer une solution inadeacutequate

En fait ce tableau constitue un guide de seacutelection de lapproche de test parmi les deux

discuteacutes dans ce travail de recherche agrave savoir le TE ct le TS Alors ce guide identifie

comment chaque facteur de contexte de test sapplique agrave chacune des deux approches de test

En analysant chaque facteur dun contexte de test pm1iculier suivant ce guide (Tableau 71)

nous pouvons savoir si le contexte est favorable pour utiliser le TE agrave la place de la meacutethode

traditionnelle sceacutenariseacutee Ce guide tente de baliser une deacutemarche danalyse pouvant ecirctre

inteacutegreacutee agrave la reacuteflexion strateacutegique des entreprises pendant la seacutelection de [approche de test

Ainsi il pourrait aider agrave comprendre les apports et les besoins de TE ce qui va permettre

dassimiler et adopter lapproche

JJ1

Tableau 71 Le guide de seacutelection de lapproche de test

Facteurs Test sceacutenariseacute Test exploratoire

1 Caracteacuteristiques dutilisation

Les raisons La stabiliteacute de projet de Linstabiliteacute de projet de dutilisation deacuteveJoppement le besoin de deacuteveloppement labsence des

documenter et mesurer lactiviteacute eXlgences de test

Les caracteacuteristiques du logiciel

La taille du logiciel Les grands logiciels Les logiciels petits et moyens La complexiteacute du Plus approprieacute Deacutepend des compeacutetences logiciel existant dans le projet de test La criticiteacute du logiciel Exigeacute Ne devrait pas ecirctre utiliseacute

Le type Stable eacutevolutif sous contrat et Dynamique denvironnement nimporte quel environnement daffaire qui neacutecessite une documentation

deacutetailleacutee des tests Les ressources Ressources importantes Ressources raisonnables ou financiegraveres limiteacutees Le temps de test Temps consideacuterable requis Peu de temps requis disponible

2 Caracteacuteristiques de gestion

La planification Rigoureuse classique et cel1aine Adaptative continue non rigoureuse

Le controcircle et le suivi Mesurable Estimeacute de progression de test La relation avec le Souhaiteacutee Essentielle peut ameacuteliorer la client qualiteacute du test La communication Souhaiteacutee Essentielle la qualiteacute de test dans le projet de test effectueacute deacutepend de la qualiteacute de

communication existante dans le projet de test

3 Caracteacuteristiques techniques

Les activiteacutes de test Reacutepeacutetitives audi tables Creacuteatives adaptatives

Loracle de test Fixe deacuteriveacute agrave partir des Variable deacuteriveacute agrave partir des exigences du logiciel et les preacutevisions du testeur standards

Les risques du logiciel La couverture de tous les risques La couverture de tous les risques est assureacutee nest pas assureacutee

112

Facteurs Test sceacutenariseacute Test exploratoire

3 Caracteacuteristiques techniques

La couverture de test Mesureacutee Nest pas assureacutee ni mesureacutee

4 Caracteacuteristiques du personnel

Les caracteacuteristiques Testeurs compeacutetents et experts Nombre limiteacute dexperts et du testeur plusieurs non expeacuterimenteacutes La culture de Disciplineacutee Immature lorganisation

5 Productiviteacute

Le nombre des Moins productive que le TE Plus productive que le TS deacutefauts deacutetecteacutes Limportance des Moins importants que ceux qui Importants et critiques sil est deacutefauts deacutetecteacutes pourraient ecirctre deacutetecteacutes avec le exeacutecuteacute par des personnes

TE compeacutetentes

Or les facteurs identifieacutes nont pas tous le mecircme poids ni la mecircme importance dans le

contexte de test Nous avons constateacute dapregraves notre analyse comparative que la couve11urc de

test est le facteur le plus important dans le contexte de test Du fait que les autres facteurs

sont inter-relieacutes dune maniegravere ou dune autre avec la couverture du tes Aussi nous avons

constateacute que les qualifications et les compeacutetences existantes dans les projets de test pourraient

influencer le choix de lapproche de tes Alors dans les projets de test ougrave les qualifications

personnelles sont insuffisantes il apparaicirct difficile dutiliser le TE Nous pouvons conclure

que le TE pourrait remplacer Je TS dans nimporte quel projet de test ougrave le controcircle de la

couverture ne constitue pas une exigence et ougrave les compeacutetences ct les quaJificati~ns du

personnel aident agrave utiliser le TE

Pourtant il est difficile de cerner un contexte ougrave une seule approche de test palmi le TS et le

TE conviendrai Agrave cet effet nous croyons quune approche hybride peut convenir mieux ougrave

certaines parties du logiciel pourraient ecirctre testeacutees en utilisant le TS et dautres en utiJisantle

TE Ainsi la meacutethodologie de test pourrait beacuteneacuteficier des avantages de chacune des deux

approches

113

77 Conclusion

Au cours de ce chapitre nous avons compareacute et analyseacute les deux approches de test selon le

cadre comparatif de comparaison que nous avons eacutelaboreacute dans le chapitre preacuteceacutedent Nous

sommes revenues sur les reacutesultats de leacutetude empirique que nous avons meneacutee dans le cadre

de ce travail de recherche afin deacutevaluer empiriquement la productiviteacute de test exploratoire

en termes du nombre et de limportance de deacutefauts deacutetecteacutes Lanalyse comparative selon les

facteurs du cadre de comparaison nous a permis de ressortir les contextes favorables pour

utiliser le TE comme une meacutethodologie primaire de test agrave la place de la meacutethode sceacutenariseacutee

habituelle En terminant nous avons eacutelaboreacute un guide de seacutelection de lapproche dc test Ce

guide reacutecapitule les reacutesultats de lanalyse comparative et tente de baliser une deacutemarche

danalyse pouvant ecirctre inteacutegreacute agrave la reacuteflexion strateacutegique des entreprises pendant la seacutelection

de lapproche de test

CHAPITRE VIII

ANALYSE DES REacuteSULATS

Cc chapitre preacutesente une analyse des reacutesultats de lanalyse comparative preacutesenteacutee au chapitre

preacuteceacutedent et les reacutesultats de leacutetude empirique preacutesenteacutee dans le chapitre V Ce chapitre fait

aussi ressortir la contribution de leacutetude et les pistes potentielles de recherche

8] Analyse des reacutesultats theacuteoriques

Lanalyse comparative du TE et du TS que nous avons effectueacutee dans le chapitre preacuteceacutedent

nous a permis didentifier les facteurs de contexte pouvant influencer le choix de lapproche

de test Nous avons identifieacute comment chaque facteur sapplique dans le cadre de chacune

des deux approches Agrave cet effet nimporte quel contexte de test pourrait ecirctre analyseacute selon les

facteurs identifieacutes dans le guide de seacutelection de lapproche de test (tableau 71) Cela permet

de savoir a priori lapproche la plus approprieacutee aux besoins du contexte de test

Selon Copeland (2004) le TS pourrait ecirctre utiliseacute nimporte ougrave lobjectiviteacute la reacutepeacutetitiviteacute et

lauditabiliteacute sont neacutecessaires (Section 22) Bach (2003) a mentionneacute que le TE pourrait ecirctre

plus productif que le TS dans certaines situations Or ces situations nont pas eacuteteacute identifieacutees

dans aucune eacutetude Dans notre recherche nous avons eacutetudieacute ces situations dans Je cadre

dune analyse comparative theacuteorique et empirique entre le TE et le TS selon un cadre de

comparaison (figure5l) que nous avons deacuteveloppeacute afin de guider notre analyse comparative

des deux approches Par le biais de celle analyse comparative nous avons pu eacutetudier

identifier et analyser les contextes qui favorisant ladaptation et [utilisation de TE comme

une meacutethodologie indeacutependante de test Notre eacutetude a mis en eacutevidence que dautres facteurs

que ceux identifieacute par Copland (2004) pourraient favoriser lutilisation de TS Toutefois

] 15

nous avons constateacute que la couverture du test ct les qualifications et lexpertise des

personnels preacutesents dans le contcxte de test sont les deux facteurs les plus importants

La premiegravere contribution dc cette recherche est de preacutesenter un guide de seacutelection de

lapproche de test qui reacutecapitule tous les facteurs du contexte de test et comment ils

sappliquent dans le cadre du TS et du TE Ce guide pourrait ecirctre inclus dans la reacuteflexion

strateacutegique des entreprises pour seacutelectionner lapproche le mieux approprieacutee agrave nimporte quel

contexte de test li constituc aussi un outil denseignement de TE qui peut aider les eacutetudiants

agrave mieux comprendre et agrave mieux diffeacuterencier les contextes favorables pour utiliser chacune des

deux approches

82 Analyse des reacutesultats empiriques

Leacutevaluation empirique de la productiviteacute de TE na pas eacuteteacute bien abordeacutee dans les travaux de

recherches Bach (2003) a proposeacute les reacutesultats de ces expeacuteriences veacutecues comme preuves de

la productiviteacute du TE Les auteurs Jtkonen et Rautiainen (2005) ont collecteacute des donneacutees

quantitatives de TE de deux petites entreprises qui utilisent le TE comme une meacutethode

primaire de test Toutcfois ccs donneacutees ne sont pas fiables ni repreacutesentatives agrave cause de

labsence de donneacutees quantitatives de TS dans les deux cas qui pourraient ecirctre consideacutereacutees

comme reacutefeacuterence afin de prouver la productiviteacute de TE Labsence des eacutetudes empiriques

dans la litteacuterature nous a obligeacute agrave consideacuterer les reacutesultats dJtkonen et Rautiainen (2005) dans

notre eacutetude comparative

Loriginaliteacute de notre eacutetude empirique reacuteside dans la conception innovatrice que nous avons

choisie pour Jeffectuer Cette conception nous a permis deacutevaluer plusieurs aspects

o La productiviteacute de TE cn terme du nombre et de limportance des deacutefauts deacutetecteacutes

pendant lcxpeacuterience puis la comparaison des reacutesultats de lexpeacuterience avec les reacutesultats

rapporteacutes par les auteurs ltkonen et Rautiainen (2005)

o Lcffct dc la technique dc tcst (TE TS) sur la perfUumllmance des sujets pendant lactiviteacute

de test De cette faccedilon nous avons pu eacutevaluer la capaciteacute des sujets dexeacutecuter et de

116

reproduire les cas de tests dc la mecircme faccedilon preacutevue par le concepteur (lauteur ltle ce

travail) Cela nous a pennis dexplorer Jhypothegravese de Kaner et Bach (2005) qui cite que

le testeur dans le TS ne pourrait pas reproduire les cas de test de la mecircme faccedilon que leur

conceptcur Nous avons aussi pu explorer la deuxiegraveme hypothegravese de Kaner et Bach qui

cite que le TS empecircche le testeur dapercevoir dautres deacutefauts que ceux qui sont

documenteacutes dans le cas de test Ce pheacutenomegravene est connu dans le domaine de psychologie

sous le terme anglophone laquoInattentional Blindnessraquo (Mack et Rock 2000)

Lanalyse des reacutesultats recueillis de lexpeacuterience a montreacute que la moyenne des deacutefauts

deacutetecteacutes est de 95 dans une session de 45 minutes Cette moyenne est proche de eelle

proposeacutee par la reeherche des auteurs Itkonen et Rautiainen (2005) soit 87 dans une session

de 60 minutes

En ce qui concerne limportance des deacutefauts deacutetccteacutes par le TE nous avons conclu que plus

que la moitieacute des deacutefauts deacutetecteacutes ont eacuteteacute des deacutefauts graves tandis que les deacutefauts fatals ont

constitueacute 10 de total des deacutefauts deacutetccteacutes Les auteurs ltokens et Rautiainen (2005) ont

rapporteacute un pourcentage dc 15 des deacutefauts fatales deacutetecteacutes dans une session de 60 minutes

Ce pourcentage est proche de pourcentage que nous avons obtenu dans notre eacutetude

empirique si nous prenons en consideacuteration la diffeacuterence dans les programmes utiliseacutes Nous

avons aussi eacutetudieacute dans notre eacutetude empirique JinOuence de lexpertise de testeur sur les

reacutesultats de TE Agrave cet effet nous avons eacutetudieacute la relation entre le niveau de connaissance en

Java et Je nombre des deacutefauts deacutetecteacutes Notons que le niveau de connaissance en Java

repreacutesente dans notre eacutetudc empirique lcxpe11isc ct les qualifications de lexpeacuterimentateur

Alors les reacutesultats ont montreacute que la moyenne de deacutefauts deacutetecteacutes croicirct en fonction de niveau

de connaissance en Java

En ee qui concerne la productiviteacute du TE par rapport au TS nous avons conclu que le TE est

plus productif que le TS du fait que la performancc des sujets dans le TE a eacuteteacute supeacuterieure de

celle reacutealiseacutee dans le TS Par la suite nous avons conclu que le TE a un effet positif sur le

rendement des sujets en comparaison avec le TS Ces reacutesultats appuient les hypothegraveses de

117

Kancr ct Bach (2005) Toutcfois la limitation de contexte de leacutetude empirique a affaibli la

validiteacute externe des reacutesultats De ce fait ces reacutesultats ne pourront pas ecirctre geacuteneacuteraliseacutes

Les reacutesultats quantitatifs de cette eacutetude empirique all1S1 que sa conception constituent la

deuxiegraveme contribution de notre travail de recherche Nous pensions que les conclusions tireacutees

de cette eacutetude sont susceptibles de sappliquer dans des reacuteplications futures et les chercheurs

inteacuteresseacutes par leacutevaluation de la productiviteacute de TE empiriquement pourront reacuteutiliser notre

eacutetude empirique eomme eacutebauche pour leurs eacutetudes

83 Pistes potentielles de recherche

Le but de ee travail eacutetait deacutevaluer empiriquement la productiviteacute de TE et dexplorer les

contextes qui favorisent son utilisation agrave la place de la meacutethode sceacutenariseacutee habituelle Suite a

cette recherche plusieurs avenues meacuteriteraient decirctre approfondies

o Enrichir le guide de seacutelection de lapproche de test

Nous avons consideacutereacute dans le deacuteveloppement du guide de seacutelection de lapproche de test les

facteurs qui ont influenceacute les reacutesultats de lutiJisation de TE dans lindustrie Or avec la

croissance de ladoption et de ladaptation du TE par les entreprises dautres facteurs

pourront apparaicirctre Lessai de ce guide dans Jindustrie pourrait engendrer aussi des

feedbacks et des apports utiles Agrave cet effet il serait inteacuteressant de veacuterifier si dautres facteurs

peuvent sappliquer et venir enrichir le guide

o Reacuteplication de leacutetude empirique dans un contexte industriel

Le contexte acadeacutemique ou sest deacuterouleacute Jeacutetude empIrIque a influenceacute neacutegativement la

validiteacute externe de lexpeacuterience et a constitueacute sa limite majeure Pour deacutepasser cette limite il

serait inteacuteressant de reprendre leacutetude dans un contexte industriel en utilisant plusieurs projets

de test Ainsi leacutevaluation de la productiviteacute pourrait ecirctre faite sur deux eacutetapes pendant

lactiviteacute de test et apregraves lactiviteacute de test cest agrave dire dans Je site de production de chacun des

logiciels qui faisaient Jobjet de cette eacutetude

118

o Explorer Jinfluence de lexpertise et les connaissances du domaine sur la qualiteacute de

TE

Il serait inteacuteressant deacutetudier linfluence de lexpertise et les connaissances du domaine sur la

qualiteacute de TE effectueacute en termes du nombre des deacutefauts deacutetecteacutes et de limportance de ces

deacutefauts dans un contexte industriel en utilisant le nombre danneacutees dexpeacuterience dans le

domaine du test comme une meacutetrique de lexpertise

84 Conclusion

Au eours de ce chapitre nous avons effectueacute L1ne analyse et preacutesenteacute une discussion des

reacutesultats de notre recherche dans laquelle nous avons situeacute ses contributions au niveau

theacuteorique et empirique Par la suite nous avons preacutesenteacute des pistes de recherche futures dans

lesquelles nous avons identifieacute dautres probleacutematiques qui peuvent ecirctre utiles en vue

dinitier des travaux futurs de recherches

CONCLUSION

Nous avons eacutetudieacute dans ce travail deux approches de test du logiciel le test exploratoire (TE)

et le test sceacutenariseacute (TS) La partie theacuteoriquc de cc travail a eu comme but lexploration des

contextes du test ougrave le TE pourrait remplacer le TS et ecirctre utiliseacute comme une meacutethodologie

primaire du test La partie empirique a eu pour objectif leacutevaluation de la productiviteacute de TE

annonceacutee dans la litteacuterature

Apregraves la deacutefinition du sujet de recherche nous avons preacutesenteacute une vue densemble de TS et

de TE successivement Par la suite nous avons preacutesenteacute une revue de litteacuterature de quelques

eacutetudes de cas et expeacuteriences dutilisation de TE dans lindustrie du test Cest ainsi que nous

avons identifieacute les facteurs influenccedilant ladoption et ladaptation de TE dans la pratique du

test Par la suite nous avons preacutesenteacute les reacutesultats de leacutetude empirique que nous avons

meneacutec dans les laboratoires de lUQAgraveM Puis nous avons eacutelaboreacute un cadre conceptuel de

comparaison dans lequel nous avons identifieacute les dimensions principales de notre analyse

comparative de TE et TS Ce cadre pourra servir dans dautres eacutetudes compmatives des

approches du test

Lanalyse comparative reacutealiseacutee a permis de ressortir les facteurs contextuels favorables pour

utiliser chacune des deux approches du test Entre autres nous avons montreacute que le TE nest

pas approprieacute dans les projets de test neacutecessitant que la couverture de test soit mesureacutee

Aussi nous avons montreacute quc la deacutependance de TE agrave lexpertise et les qualifications du

testeur rend difficile son utilisation dans les contextes ougrave les qualifications ct les compeacutetences

du personnel sont insuffisantes Agrave cet effet Nous avons conclu que le TE pourrait remplacer

le TS dans nimporte quel projct de test ougrave le controcircle de la couverture ne constitue pas une

exigence etougrave les compeacutetences et les qualifications du personnel permettcnt dutiliser le TE

Notre eacutetude empirique a montreacute la productiviteacute de TE en tennes de nombre et Jimportance

des deacutefauts deacutetecteacutes Toutefois nous ne pouvons pas geacuteneacuteraliser les reacutesultats obtenus dans

120

cette eacutetude agrave cause de la limitation du contexte ou sest deacuterouleacute notre expeacuterience Agrave cet effet

nous reportons cette question agrave des travaux futurs de recherches de preacutefeacuterence dans des

contextes industriels

Au niveau pratique ce travail de recherche sinscrit dans un courant de preacuteoccupation des

entreprises qui ont agrave la recherche des meacutethodes du test plus efficaces qui pounaient sadapter

avec la culture rapide actuelle de deacuteveloppement du logiciel Il est agrave noter que cette eacutetude

constitue une ouverture sur le deacuteveloppement dun guide visant Jadaptation de TE dans

lindustrie du test Nous espeacuterons que le guide de seacutelection de Japproche de test aide les

entreprises et les praticiens agrave mieux choisir leur approche de test selon leur contexte du test

Nos objectifs personnels eacutetaient dexplorer les apports de TE et deacutevaluer sa productiviteacute

fortement mise de lavant par les praticiens de CDS Lanalyse comparative de TE ct le TS

nous a pousseacutee agrave approfondir nos connaissances dans Je domaine du test logiciel pour que

nous puissions identifier les apports et les lacunes de chacune des deux approches Ce travail

nous a permis de deacutecouvrir limportance de lactiviteacute du test dans le processus de

deacuteveloppement logiciel Cela nous a montreacute les diffeacuterents cocircteacutes de test du logiciel ses deacutefis

son cocircteacute quasi artistique matheacutematique et critique Bref nous avons trouveacute un autre domaine

dinteacuterecirct outre que la programmation et le deacuteveloppement

ANNEXE A

CADRE DE BASILI ADAPTEacute Agrave LA RECHERCHE EXPLORATOIRE

Les tableaux preacutesenteacutes dans celle annexe reacutecapitulent les phases du projet de recherche selon

le cadre de Basili agrave la recherche exploratoire adapteacute par Abran et al (J 999)

1 Deacutefinition Motivation Porteacutee Objectif Utilisateurs

J Explorer les Comparaison theacuteorique Reacutepondre agrave la question - Les chercheurs et apports de TE et empirique de TE et principale de recherche les praticiens

TS selon un proceacutedeacute Est-ce que le TE pourrait inteacuteresseacutes al eacutetude 2 Explorer de tesl boicircte noire remplacer Je test du TE lampleur de la sceacutenariseacute Si oui dans quel divergence enlre contexle - Les entreprises les deux vues deacutesirant mettre en

oeuvre ces 3Eacutevaluer la approches de test productiviteacute dc TE

4Eacutelaborer un guide de seacutelection de lapproche de test

122

2 Planification du projet Les eacutetapes Les intrants Les livrables

1 Proposer dun modegravele du La norme IEEE 829 - Un cadre conceptuel de processus de TS comparaison des approches

de test 2Eacutelaborer un cadre de comparaIson - Les reacutesultats quantitatifs de

leacutetude empirique 3 Faire leacutetude comparative empirique de TE et TS - Un guide deacutevaluation des

facteurs de contexte de projet 4 Faire leacutetude comparative de test pour le choix dune de TE et TS en se basant sur approche de test le cadre eacutelaboreacute et les reacutesultats empirique

5 Analyser et discuter des reacutesultats

3 Ooeacuteration Analyse des documents Feedback des Modegraveles proposeacutes

praticiens

1 Identifier les facteurs qui ont Cadre conceptuel de comparaison des influenceacute ladoption et ladaptation approches de test qui inclut les cinq de TE dans lindustrie dimensions agrave savoir

2 Analyser leacutetude comparative de 1 Les caracteacuteristiques dutilisations Boehm et Turner

2 Les caracteacuteristiques du logiciel agrave 3 Eacutetudier et analyser les tester connaissances theacuteoriques de test du logiciel 3 Les caracteacuteristiques de gestion

4 Eacutetudier et analyser les apports et 4 Les caracteacuteristiques du personnel les meacutecanismes de TE

5 La productiviteacute

Proposition dun guide de seacutelection de lapproche de test

]23

4 Interpreacutetation

Contexte dinterpreacutetation Extrapolation des reacutesultats Travaux futurs

) La comparaison theacuteorique - Les reacutesultats de Jeacutetude empirique sont - Reacuteplication de et empirique des deux limiteacutes Ils deacutependent du contexte leacutetude empirique et approches de test le TE et acadeacutemique ougrave sest deacuterouleacutee comparative de TE le TS a eacuteteacute reacutealiseacutee lexpeacuterience et TS dans un

environnement 2 Lanalyse comparative de - Lanalyse comparative entre le TE et le industriel TE et TS selon les facteurs TS est associeacutee au cadre de comparaison de notre cadre conceptuel de eacutelaboreacute dans ce travail de recherche et les - Leacutetude de comparaison a permis reacutesultats de leacutetude empirique Agrave cet linfluence des didentifier les contextes effet celte analyse est limiteacutee et en partie connaissances du favorables pour utiliser le subjective Elle deacutepend des domaine et TE agrave la place de TS connaissances et de Jexpeacuterience de lexpeliise de testeur

auteure dans le domaine de test du sur les reacutesu Ilats de 3 Lanalyse comparative a logiciel TE permis deacutelaborer un guide de seacutelection de lapproche - Lameacutelioration du de test guide de seacutelection de

lapproche de test 4 Cette recherche pourrait eacutelaboreacute dans ce contribuer agrave mieux travail de recherche comprendre le TE Elle facilite Jadoption de TE au sein des entreprises qui oeuvrent dans le domaine du deacuteveloppement

ANNEXEB

PLAN DE TEST IEEE829 (ADAPTEacute ET TRADUIT DE IEEE 8291998)

1 Identificateur de plan de test

bull Identificateur unique de document qui pourrait le distinguer des autres documents

2 Introduction

bull lintroduction pourrait inclure les paragraphes suivants

Description du logiciel sous test ce paragraphe donne un aperccedilu du logiciel

ses opeacuterations maintenance histoire son code ct toute autre information

pertinente

Une liste de reacutefeacuterences agrave dautres documents utiles pour la compreacutehension du

plan de test Selon la norme IEEE 829 les reacutefeacuterences aux documents

suivants sils existent doivent ecirctre mentionneacutees

o Autorisation du projet

o Plan du projet de deacuteveloppement

o Plan dassurance qualiteacute

o Plan de gestion de configuration

o Politique pertinente de la compagnie et du client

o Normes pertinentes de la compagnie du client ou de lindustrie

3 Items de test

bull Identifie les items agrave tester incluant leur versionniveau de reacutevision

125

4 Caracteacuteristiques agrave tester

bull Identifie les caracteacuteristiques agrave tester telles que fonctionnaliteacute performance seacutecuriteacute

portabiliteacute etc

5 Caracteacuteristiques qui ne doivent pas ecirctre testeacutees

bull Identifie les caracteacuteristiques qui nc vont pas ecirctre testeacutees ainsi les raisons de ce fait

6 Approche

bull Propose la strateacutegie globale de test afin dassurer gue tous les items et leurs

caracteacuteristiques seraient testeacutes adeacutequatement

7 Critegravere de passageeacutechec

Deacutefinit le critegravere de passage et deacutechec de test de chaque item

8 Critegravere de suspension et conditions de reprise

bull Deacutefinit les circonstances dans lesquelles le test pourrait ecirctre arrecircteacute ct les conditions

pour quil reprenne (deacutefauts critiques gui neacutecessitent la re-conception cnvironnement

de test incomplet etc)

9 Livrable du test

bull Identifie les documents de test ainsi que les autres livrables devant ecirctre produits au

cours du projet de test (ex speacutecifications de conception de test speacutecifications de cas

de test speacutecifications de proceacutedure de test registre de test rapport dincident de

tcst rappol1 de synthegravese de test matrice de traccedilabiliteacute etc)

10 Tacircche de test Identifie les tacircches de test et linterdeacutependance entre clics ainsi que la

dureacutee et les rcssources requises pour les accomplir

126

II Besoins environnementaux

bull Speacutecifie lenvironnement requis pour accomplir lactiviteacute de test incluant mateacuteriel

logiciel outils etc

12 Responsa biliteacutes

Identifie la responsabiliteacute ct la tacircche de chaque membre de [eacutequipe de test

13 Besoins en personnel et en formation

bull Les personnes et les qualifications neacutecessaires pour reacutealiser le plan

14 Calendrier

bull Speacutecifie les eacutetapes importantes dans le plan de projet de deacuteveloppement ainsi que les

items qui devraient ecirctre transmis agrave chaque eacutetape

15 Risques ct contingences

bull Identifie les risques qui peuvent empecirccher le suivi du plan et les mesures agrave prendre

pour les surmonter

16 Approbation

ANNEXE C

SOIREacuteE DE TESTS

Document remis aux participant(e)s

Lobjcctif premIer de cet exercIce est daugmenter votre niveau dexpeacuterience dans

Jexeacutecution de tests preacutepareacutes par dautres et dans le domaine des tcsts exploratoires Pour ce

faire vous uti liserez dabord jusquagrave 2000 lapproche des tests exploratoires agrave laide des

directives donneacutees dans la section suivante Dans la deuxiegraveme partie de la sOireacutee vous

exeacutecuterez des tests sceacutenariseacutes qui vous seront remis agrave 2000

Dans les dcux cas vous prendrez en note sur les formulaires ci-joints (voir Annexe D) les

deacutefauts que vous constaterez Par la suite vous compleacuteterez les rapports demandeacutes en

reacutepondant aux questions proposeacutees Toutes ces informations serviront de base agrave un travail de

maicirctrise sur les diffeacuterences entre le TE et le test sceacutenariseacute

Quelques directives et informations pour exeacutecuter le TE

Deacutefinition du programme

IJ sagit dun gestionnaire simple de messages Chaque message contient les informations

suivantes eacutemelleur destinataire sujet du message texte du message et une information

suppleacutementaire qui indique si le message a eacuteteacute lu ou non eacutelimineacute ou non Pour chaque

message le logiciel allribue un numeacutero automatiquement supeacuterieur agrave 100 Le programme

utilisc un tablcau de taille 10 pour geacuterer les messages Le programme doit afficher un

message un message derreur si on tente de geacuteneacuterer plus de 10 messages

Les directives agrave utiliser

Nous proposons cer1aines techniques qui peuvent vous aider dans vos tests exploratoires

128

Vous pouvez choisir une ou plusieurs de ces techniques Vous necirctes pas obligeacutes de les

appliquer strictement et vous avez toujours la possibiliteacute dintroduire vos propres techniques

Cependant rappelez-vous que le but de lexercice est de deacutecouvrir le plus possible de bogues

importants de faccedilon agrave ameacuteliorer la qualiteacute du logiciel

o Exeacutecution du programme en utilisant des donneacutees valides (parmi les choix afficheacutes

dans le menu principal) pour avoir une ideacutee sur ses fonctions et ses caracleacuteristiques

principales

o Suivez votre intuition et explorez le programme si vous avez une ideacutee sur les types

derreurs quil peut inclure

o Essayez de geacuteneacuterer des questions sur la capaciteacute du programme daccomplir certaines

fonctions que vous sont apparu essentielles mais toujours dans le cadre de la

description ci-dessus Essayez ensuite de transformer chaque queslion en un jeu

dessai (cas de test)

o Geacuteneacuterez diffeacuterents sceacutenarios dutilisation de logiciel Ensuite essayez dexplorer les

aspects de vos sceacutenarios par exemple utilisez diffeacuterentes valeurs dentreacutee surtout

les valeurs extrecircmes (limites) pour le mecircme sceacutenario

o Veacuterifiez les messages derreurs du programme autrement dit veacuterifiez sils se

deacuteclenchent au bon moment et sous les bonnes conditions

o Choisissez une variable puis essayez de tracer son flux dans le programme Les

meacutethodes quellcs lutilisent ainsi que ses interactions avec dautres variables

Ensuite utilisez ces informations pour interfeacuterer avec la variable

o Choisissez une tacircche parmi les fonctionnaliteacutes du programme et essayez de deacutecrire

eacutetape par eacutetape comment elle est accomplie et manipuleacutee dans le logiciel puis essayez

dimproviser et de concevoir des techniques pour la tester (par exemple en utilisant

des valeurs dentreacutees qui peuvent pousser la fonction dans dautres chemins)

o Utilisez un diagramme deacutetats pour deacutecrire les diffeacuterentes actions et transitions que

129

lapplication peut prendre pour toutes les entreacutees possibles Essayez ensuite de

trouver les contradictions dans Je modegravele

La proceacutedure

bull Le travail doit ecirctre fait individuellement et aucun contact avec un(e) autre eacutetudiant(e)

nest permis durant toute lactiviteacute de test

bull Notez Jheure de deacutebut et de fin de vos tests exploratoire

bull Durant votre activiteacute de test agrave chaque fois que vous trouvez un bogue inscrivez les

informations demandeacutees dans la liste que vous a eacuteteacute remise Vous devez deacutecrire en

deacutetail lerreur Vous devez deacutecrire briegravevement comment vous avez reacutealiseacute quil sagit

dune eueur par exemple labsence dun menu ou changement dans la valeur de

sortie preacutevue etc Vous devez aussi classer lerreur selon sa graviteacute Ces

informations sont aussi donneacutees avec Je fonnulaire dinscription des deacutefectuositeacutes

ANNEXE D

RAPPORT DE LA SESSION DE TEST

Nom de leacutetudiant(e)

bull Comment eacutevaluez-vous vos connaissances en Java

Niveau Jamais vu Introduction Intermeacutediaire Avanceacute Expeacuterimenteacute

Estimation

bull Classification

On classifie la seacuteveacuteriteacute des erreurs en trois niveaux

o Fatale (F) Japplication est inopeacuterable complegravetement (Crash)

o Grave (G) lapplication fonctionne mais certaines fonctions sont inopeacuterables ou certains reacutesultats sont erroneacutes

o Mineure (M) limpact est mineur sur Jutilisation du systegraveme ex certains formats sont erroneacutes bien que les reacutesultats soient corrects ou encore les deacutelais sont supeacuterieurs agrave ce quon attend dune telle application

Noubliez pas de prendre des notes sur les techniques dexploration que vous utilisez

Description de lerreur Classification

REacuteFEacuteRENCES

Abran Alain Lucie Laframboise et Pierre Bourque 1999 laquo A Risk Assessment Method and Grid for Software Engineering Measurement Programsraquo Montreacuteal Universiteacute du Queacutebec agrave Montreacuteal

Amland Stale et Jarle Vaga 2002 laquo Managing High Speed Web Testing raquo In Software Quality and Software Testing in Internet Times sous la dir de Meyerhoff Dirk Begona Laibarra Rob Van Der Pouw Kraan et Alan Wallet P 23-30 Berlin Springcr

Amland Stale 2002a laquoExploralory Testing Planning Execution and Documentationraquo Version (120) wwwtestingeducationorg

Amland Stale 2002b laquoExploratory Testing Stylesraquo Version (120) wwwtestingeducationorg

Bach James 2007 laquoRapid Software Testing raquo Version (132) wwvvsatisficccom

Bach James et Jonathan Bach 2006 laquoExploratory Testing Dynamics raquo Version 16

Bach James 2003 laquoExploratory Testing Explained raquoVersion (13)

Bach James Bret Pettichord ct Cem Kaner 2002 Lessons Learned in Sofiware Testing New York Johon Wiley amp Sons

Bach James 2001 laquoExploratory Testing and Planning Mythraquo (StickymindsCom) 19 mars

Bach James 1999 laquoGeneral Functionality and Stability Test Procedureraquo wwwsatisficecom

Bach James J996 laquoHeuristic Test Strategy Moderaquo wwwsntisficccom

Bach Jonathan 2000 laquo Session Bascd Test Management raquo SofilVare Testing and Quality Engineering novembre

Basili Victor Richard Selby ct David Hutchens J986 laquoExperimentation in Software Engineeringraquo IEEE Transactions on software engineering vol J 2 no 7 p 733-743

J32

Beedle Mike et al 200 J laquoManifesto for Agi le Software Developmentraquo Consulteacute janvier 2007 httpagilemanifcstoorg

Black Rex 1999 Managing the Testing Process Redmond (Wachington) Microsoft Press

Beizer Boris 1995 Black Box Testing Techniques for Functional Testing of Software and Systems New York Johon Wiley amp Sons

Beizer Boris 1990 Software Testing Techniques 2 eeacuted New York Van Nostrand Reinhold

Boehm Barry W et Richard Turner 2004 Baancing Agility and Discipline Boston Addison-Wesley

Boehm Barry W 198 1Software Engineering Economics Upper Sadd le River (NJ) Prentice-Hall

Bolton Michael James Bach et Cem Kaner 2005 laquo Rapid Testing ExpJained raquo International Quality Conference 200SToronto octobre

Copeland Lee 2004 A Practitioners Guide 10 Software Tesl Design Boston Artcch HOllse Publ ishers

Craig Rick et Stefan Jaskiel 2002 Systematic Sojiware Tesling Boston Artech Housc Publishers

Hendriekson Elizabeth 2005 laquo Agile Testing raquo Video de Googlc wwwgooglecom

Hetzel William C1988 The Campete Guide la Sojiware Tesling 2 C eacuted New York Johon WiJeyamp Sons

Hoffman Douglas 1999 laquoHeuristie Test Oraclesraquo Sofiware Testing and Quairy Engineering marsavril wwwsoftwnrequalitymcthodscomPapersSTOE20Heuristicpdf

ltkonen Juha et Kristian Rautiainen 2005 laquo Exploratory Testing A Multiple Case Studyraquo Empirica Software Engineering 2005 1l1lernationa Symposium novembre

1EEE829 1998 Standardfor Soflware Test Documentotion New York IEEE press

lEEE729 1983 laquolEEE Computer Society 1EEE Standard Glossary of Software Engineering TerminoJogyraquo

133

JEEE610 1990 laquoIEEE Standard Glossary of Software Engineering TerminologyraquoJEEE STD6102

James David et Bill Wood 2003 laquoApplying Session Based Testing to Medical Softwareraquo Medical Deviceamp Dignostic lndustry mai

Jones TCapers 1998 Estimating Software Costs New York McGraw-Hill pSS4

Kan Parrish et Manlove 2001 laquoIn-process Metrics for Software Testingraquo IBM Systems Journa vol 40 no 01

Kaner Cern 2006 laquoExploratory Testing after 23 Yearsraquo Conference of the Association for Software Testing Indianapolis (US) wwwTestingeducationcom

Kaner Cern et James Bach 2005 laquo Scripting An Jndustry Worst Practice raquo Back Box Testing Course wwwTestingeducationcom

Kaner Cern 2004 laquoThe Ongoing Revolution in Software Teslingraquo Software Test amp Performance Conference (Baltimore MD 7-9 deacutecembre 2004) wwwTcstingeducationcom

Kaner Cern et James Bach 2004 laquoThe Nature of Exploratory Teslingraquo Software Tesling Day University Tampere Finland consulteacute le 15012007

Kaner Cern 2003 laquoWhat is a Good Test Case raquo STarEast Conference May 2003 httpwwwkanercompdfsGoodTestpdf

Kaner Cern et Andy Tinkham 2003a laquoExploring Exploratory Testingraquo STarEast Conference on Software Testing Analysis and Review (Orlando FL May 12-16 2003)

Kaner Cern et Andy Tinkham 2003b laquoLearning Style and Exploratory Testingraquo Pacifie Northwest Software Quality Conference (Portland OR October 13- J 52003)

Kaner Cern Jack Falk ct Hung Quoc Nguyen 1999 Testing Computer Sojiware 2 e eacuted New York John Wiley and Sons

Kaner Cern 1997 laquo The lmpossibiity of Complete teting raquo Low of Sofiware Quairy Coumn Software QA vol 04 no 04 hltpvwwkancrcompdfslimposspdf

Kaner Cem1996 laquoSoftware Negligence and Testing Coverageraquo Sofiware QA quartery vol 02 no 03 p 18 httpwwwkanercomcovcragchtm

Kaner Cern 1988 Testing Computer Sojiware 1 erceacutedi New York McGraw-Hill

Kohl Jonathan 2005 laquoExploratory Tesling on Agile Teamsraquo InformitCom 18 Novembre httpwwwinformitcomartielcs

134

Lindsay James et Neil Van Eeden 2003 laquoAd ventures in Session Based Testingraquo Version 12 hltplwwwworkroom-productionscomlpapcrsAiSBTv 12pdf

Lott Christopher et Rombach Dieter J997 laquo Repeatable software engineering experiments for comparing defect detection techniquesraquo Empirical Software Engineering vol 0 l no 03 p241-277

Mack Arien et Irvin Rock 2000 laquoInaltentional Blindnessraquo Cambridge (MA) Bradford BooksMIT press

Marick Brian 2003 laquo Agile Methods and Agile Testing raquoSoftware Testing and Quality Engineering vol 03 no 05

Myers Glenford J 1979 The Art ofSoftware Testing 1 ere eacutedi New York Johon Wiley

Osterweil Leon 1996 laquoStrategie directions in software quality raquo ACM Computing SUIveys vol 04 no 04

Perry William E 2000 Effective Methodsfor Software Testing 2 C eacutedi Johon WiJey and Sons

Petty Kenn 2005 laquoReflections on the Use of Session Based Exploratory Testing as the Primary Test Methodology for Software in an Agile Environmentraquo lndianapolis Workshops on Software Testing hltpwwwiwst2007comlimagcsRefleelions on the use of SessionshyBased Exploratory Tcsting in an_ Agile _Environmcntdoc

Pettichord Brel 2002 laquoAgile testing What is it Can it work raquo Consulteacute Janvier 2007 wwwPeltichordcom

Pressman Roger 1997 Software Engineering A Practitioner s Approach 4 Ceacutedi New York MeGraw-Hill

Pyhajarvi Maarct KJistian Rautiainen ct Juha ltkonen 2003 laquolncreasing understanding of the modern testing perspective in software product development projects raquo IEEE Computer Society Proceedings of the Hawaii International Conference on System Sciences

Royce Wiston J 970 laquoManaginw the Development of Large Software Systems Concepts and Techniquesraquo Reprinted in 9 International Conference in Software Engineering Los1

Alamitos (CA) IEEE Computer Society Press p 328-338

SWEBOK 2004 laquo Guide to the Software Engineering Body of Knowledge raquo IEEE Computer Society Version 2004 httpwWvswcbokorg

13S

Thompson Neil 2003 laquoBest Practices and Context-Driven Building a Bridgeraquo International Conference on Software Testing Analysis and Review StarEast FJorida StickyMinds Magazine

Whittaker James A 2003 How to Break softwaremiddot A Practica Guide to Testing Boston Addison Wisely

Winer Ben James 1971 Statistica Principes in Experimental Design 2 e eacutedi New York McGraw Hill

Wood Murray Marc Roper Andrew Brooks et James Miller 1997 laquo Comparing and Combining Software Defect Detection Techniques A Replicated Empirical Study raquo ACM SIGSOFT Proceeding on the Foundations of Software Engineering NdegS Zurich SUISSE (22091997) vol 22 no 6 New York Springer-Verlag (ACM Press)