Testeur Certifié. Syllabus Niveau Fondation

Transcription

1 Syllabus Niveau Fndatin Versin 2011 FR Internatinal Sftware Testing Qualificatins Bard Cmité Lgiciels

2 Syllabus Niveau Fndatin Cmité Français des Lgiciels Internatinal Sftware Testing Qualificatins Bard Cpyright Ce dcument peut être cpié dans sn intégralité, u partiellement, si la surce est mentinnée. Cpyright Ntice Internatinal Sftware Testing Qualificatins Bard (ci-après appelé ISTQB ) ISTQB est une marque enregistrée de l Internatinal Sftware Testing Qualificatins Bard, Cpyright 2011 les auteurs pur la mise à jur 2011 (Thmas Müller (respnsable), Debra Friedenberg, et l'istqb Fndatin WG Level) Cpyright 2010 les auteurs pur la mise à jur 2010 (Thmas Müller (respnsable), Armin Beer, Martin Klnk, Rahul Verma) Cpyright 2007 les auteurs pur la mise à jur 2007 (Thmas Müller (respnsable), Drthy Graham, Debra Friedenberg et Erik van Veenendaal) Cpyright 2005, les auteurs (Thmas Müller (respnsable), Rex Black, Sigrid Eldh, Drthy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geff Thmpsn et Erik van Veenendaal). Tus drits réservés. Les auteurs transfèrent leurs drits à l Internatinal Sftware Testing Qualificatins Bard (ci-après appelé ISTQB). Les auteurs (en tant que pssesseurs actuels des drits d auteurs) et l ISTQB (en tant que pssesseur futur des drits d auteurs) nt cnclu l accrd suivant prtant sur les cnditins d utilisatin : 1) Tut individu u rganisme de frmatin peut utiliser ce syllabus cmme base pur une frmatin si les auteurs et l ISTQB snt cités cmme surce et pssesseurs des drits de ce syllabus, et pur autant que tute publicité sur une telle frmatin mentinne ce syllabus uniquement après demande d accréditatin fficielle de cette frmatin auprès d un Cmité Natinal recnnu par l ISTQB ; 2) Tut individu u grupe d individus peut utiliser ce syllabus cmme une base pur des articles, livres, u autres écrits dérivés, si les auteurs et l ISTQB snt recnnus cmme surce et pssesseurs des drits de ce syllabus ; 3) Tut Cmité Natinal recnnu par l ISTQB peut traduire ce syllabus et permettre l utilisatin de ce syllabus par des tiers. Versin 2011 Page 2 de Mar-2010 Internatinal Sftware Testing Qualificatins Bard

3 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 4) Histrique des mdificatins Versin Date Remarques CFTL 2011FR 3-Nv-2011 Testeur Certifié Niveau Fndatin Mise à jur vir Annexe E Changements intégrés dans le Syllabus CFTL 2010FR 1-Sept-2010 Testeur Certifié Niveau Fndatin Mise à jur vir Annexe E Changements intégrés dans le Syllabus 2010 ISTQB Mars-2010 Certified Tester Fundatin Level Syllabus Maintenance Release vir Annexe E Changements intégrés dans le Syllabus 2010 ISTQB Mai-2007 Certified Tester Fundatin Level Syllabus Maintenance Release vir Appendix E Release Ntes Syllabus 2007 CFTL 2005FR 01-Juillet-2005 Testeur Certifié Niveau Fndatin ISTQB Juillet-2005 Certified Tester Fundatin Level Syllabus ASQF V2.2 Juillet-2003 ASQF Syllabus Fundatin Level Versin 2.2 Lehrplan Grundlagen des Sftware-testens ISEB V Février-1999 ISEB Sftware Testing Fundatin Syllabus V February 1999 Traductin française: Bernard HOMES, Eric RIOU du COSQUER, Alain RIBAULT, Bertrand CORNANGUER, Cyrille RIVIERE, Olivier DENOO, Vérnique JOURDY-COTTEN Versin 2011 Page 3 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

4 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Table des Matières Remerciements... 7 Intrductin à ce syllabus Fndamentaux des (K2) Purqui les tests snt-ils nécessaires? (K2) Cntexte des systèmes lgiciels (K1) Origine des défauts lgiciels (K2) Rôle des tests dans le dévelppement, la maintenance et l pératin des lgiciels (K2) et qualité (K2) Cmbien de test est suffisant? (K2) Que snt les tests? (K2) Les 7 principes généraux des tests (K2) Prcessus de test fndamental (K1) Planificatin et cntrôle des tests (K1) Analyse et Cnceptin des tests (K1) Implémentatin et exécutin des tests (K1) Evaluer les critères de srtie et infrmer (K1) Activités de clôture des tests (K1) La psychlgie des tests (K2) Cde d éthique Tester Pendant le Cycle de Vie Lgiciel (K2) Mdèles de Dévelppement Lgiciel (K2) Mdèle en V (K2) Mdèle de dévelppement itératif (K2) Tester au sein d un mdèle de cycle de vie (K2) Niveaux de tests (K2) de cmpsants (K2) d intégratin (K2) système (K2) d acceptatin (K2) Types de tests (K2) des fnctins (tests fnctinnels) (K2) des caractéristiques nn fnctinnelles des prduits lgiciels (tests nnfnctinnels) (K2) de la structure / architecture lgicielle (tests structurels) (K2) liés au changement (tests de cnfirmatin et de régressin) (K2) de maintenance (K2) Techniques Statiques (K2) Techniques statiques et prcessus de test (K2) Prcessus de revue (K2) Phases d une revue frmelle (K1) Rôles et respnsabilités (K1) Types de revues (K2) Facteurs de succès des revues (K2) Analyse statique avec des utils (K2) Techniques de Cnceptin de (K3) Le prcessus de dévelppement de test (K3) Catégries de techniques de cnceptin de tests (K2) Techniques basées sur les spécificatins u techniques bîte nire (K3) Partitins d équivalence (K3) Analyse des valeurs limites (K3) par tables de décisins (K3) Test de transitin d états (K3) de cas d utilisatin (K2) Versin 2011 Page 4 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

5 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 4.4 Technique de cnceptin basée sur la structure u technique de cnceptin bîte blanche (K3) Test des instructins et cuverture (K3) Test des décisins et cuverture (K3) Autres techniques basées sur les structures (K1) Techniques basées sur l expérience (K2) Sélectinner les techniques de tests (K2) Gestin des (K3) Organisatin des tests (K2) Organisatin du test et indépendance (K2) Tâches du respnsable des tests et des testeurs (K1) Estimatin et planificatin des tests (K3) Planificatin des tests (K2) Activités de planificatin des tests (K3) Critères d entrée (K2) Critères de srtie (K2) Estimatin des tests (K2) Stratégie de test, Apprche de test (K2) Suivi et cntrôle du dérulement des tests (K2) Suivi de l avancement des tests (K1) Reprting des tests (K2) Cntrôle des tests (K2) Gestin de cnfiguratin (K2) Test et risques (K2) Risques liés au prjet (K2) Risques liés au prduit (K2) Gestin des incidents (K3) Outils de Supprt aux (K2) Types d'utils de test (K2) Outils de supprt aux tests (K2) Classificatin des utils de test (K2) Outils d aide à la gestin du test et des tests (K1) Outils d aide aux tests statiques (K1) Outils d aide à la spécificatin des tests (K1) Outils d aide à l'exécutin et à l enregistrement des tests (K1) Outils de supprt de perfrmance et de surveillance (K1) Outils de supprt pur des besins de tests spécifiques (K1) Utilisatin efficace des utils : Bénéfices ptentiels et Risques (K2) Bénéfices ptentiels et risques liés aux utils de test (pur tus les utils) (K2) Cnsidératins spéciales pur quelques types d'util (K1) Intrduire un util dans une rganisatin (K1) Références Standards Livres Annexe A Infrmatins sur le syllabus Histrique de ce dcument Objectifs de la qualificatin internatinale (adapté de la réunin ISTQB de Nvembre 2001 à Sllentuna) Annexe B Objectifs de cnnaissance/niveaux de cnnaissance Niveau 1: Se suvenir (K1) Niveau 2: cmprendre (K2) Niveau 3: Appliquer (K3) Niveau 4: Analyser (K4) Annexe C Règles appliquées au syllabus ISTQB niveau Fndatin Règles générales Cntenu actualisé Objectifs de cnnaissance Versin 2011 Page 5 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

6 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Structure générale Annexe D Nte pur les rganismes de frmatin Tus les bjectifs de niveau K3 et K4 nécessitent de pratiquer des exercices. Annexe E Changements intégrés dans le Syllabus Versin Index Versin 2011 Page 6 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

7 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Remerciements Internatinal Sftware Testing Qualificatins Bard Wrking Grup Fundatin Level (Editin 2011): Thmas Müller (chair), Debra Friedenberg. Le grupe de travail remercie l équipe de revue (Dan Almg, Armin Beer, Rex Black, Julie Gardiner, Judy McKay, Tuula Pääkkönen, Eric Riu du Csquier Hans Schaefer, Stephanie Ulrich, Erik van Veenendaal) et tus les Cmités Natinaux pur leurs suggestins pur la versin actuelle du syllabus. Internatinal Sftware Testing Qualificatins Bard Wrking Grup Fundatin Level (Editin 2010): Thmas Müller (respnsable), Rahul Verma, Martin Klnk et Armin Beer. Le grupe de travail remercie l équipe de revue (Rex Black, Mette Bruhn-Pedersn, Debra Friedenberg, Klaus Olsen, Tuula Pääkkönen, Meile Psthuma, Hans Schaefer, Stephanie Ulrich, Pete Williams, Erik van Veenendaal) et tus les Cmités Natinaux pur leurs suggestins pur la versin actuelle du syllabus. Internatinal Sftware Testing Qualificatins Bard Wrking Grup Fundatin Level (Editin 2007): Thmas Müller (respnsable), Drthy Graham, Debra Friedenberg, et Erik van Veendendaal Le grupe de travail remercie l équipe de revue (Hans Schaefer, Stephanie Ulrich, Meile Psthuma, Anders Petterssn, et Wnil Kwn) et tus les Cmités Natinaux pur leurs suggestins. Internatinal Sftware Testing Qualificatins Bard Wrking Grup Fundatin Level (Editin 2005): Thmas Müller (respnsable), Rex Black, Sigrid Eldh, Drthy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geff Thmpsn, Erik van Veenendaal et l'équipe de revue ainsi que tus les Cmités Natinaux pur leurs suggestins. Versin 2011 Page 7 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

8 Syllabus Niveau Fndatin Intrductin à ce syllabus Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Objectif de ce dcument Ce syllabus frme la base du niveau Fndatin de la qualificatin Internatinale en tests de lgiciels. L Internatinal Sftware Testing Qualificatins Bard (ISTQB) et le Cmité Lgiciels (ci-après appelé CFTL) furnissent ce syllabus aux cmités natinaux d examens pur accréditer les furnisseurs de frmatins et pur en dériver des questins d examens dans leur langue natinale. Les furnisseurs de frmatins prduirnt leurs curs et déterminernt les méthdes de frmatin apprpriées pur l accréditatin, et le syllabus aidera les candidats à se préparer aux examens. Des infrmatins sur l histrique et le cntexte du syllabus peuvent être truvées en Annexe A. Le Niveau Fndatin pur les Testeurs de Lgiciels Certifiés La qualificatin de niveau fndatin vise tutes les persnnes impliquées dans les tests de lgiciels. Ceci inclut les persnnes ayant des rôles de testeurs, analystes de tests, ingénieurs de tests, cnsultants en tests, gestinnaires de tests, testeurs en phase d acceptatin utilisateur et dévelppeurs de lgiciels. Cette qualificatin de niveau Fndatin est aussi apprpriée pur tute persnne suhaitant une cmpréhensin de base des tests de lgiciels, tels que les gestinnaires de prjets, respnsables qualité, respnsables de dévelppements lgiciels, analystes métier et cnsultants en management. Les pssesseurs du Certificat Fndatin sernt capables de cntinuer afin d atteindre un niveau supérieur de certificatin en tests de lgiciels. Objectifs de cnnaissance /niveaux de cnnaissance Les niveaux de cnnaissance snt furnis pur chaque sectin de ce syllabus et classés de la façn suivante K1: se suvenir; K2: cmprendre; K3: utiliser; K4: analyser De plus amples détails et des exemples d bjectifs de cnnaissance snt dnnés en Annexe B. Tus les termes listés sus la rubrique termes après les titres de chapitre sernt retenus (K1), même s ils ne snt pas explicitement mentinnés dans les bjectifs de cnnaissance. L examen L examen pur l btentin du Certificat Fndatin sera basé sur ce syllabus. Les répnses aux questins d examen peuvent requérir l utilisatin d infrmatins cntenues dans plus d une sectin de ce syllabus. Tutes les sectins de ce syllabus peuvent dnner lieu à des questins d examen. Le frmat de l examen est un questinnaire à chix multiples. Les examens peuvent faire partie d une frmatin accréditée u être passés indépendamment (p.ex. dans un centre d examen u lrs d un examen public). La participatin à une frmatin accréditée n est pas un pré-requis au passage de l examen. Accréditatin Les furnisseurs de frmatins dnt le cntenu du curs suit ce syllabus peuvent être accrédités par un cmité natinal recnnu par l ISTQB et le CFTL. Les directives d accréditatin divent être btenues auprès de l rganisme u du cmité effectuant l accréditatin. Un curs accrédité est recnnu cmme se cnfrmant à ce syllabus, et peut inclure un examen ISTQB CFTL cmme partie du curs. Pur de plus amples infrmatins à destinatin des furnisseurs de frmatin, vir l Annexe D. Versin 2011 Page 8 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

9 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Niveau de détail Le niveau de détail dans ce syllabus permet un enseignement et des examens cmpatibles internatinalement. Pur atteindre cet bjectif, le syllabus cntient : Des bjectifs généraux d instructin, décrivant les intentins du niveau fndatin Une liste des infrmatins à enseigner, incluant une descriptin, et des références à des surces additinnelles si besin. Des bjectifs de cnnaissance pur chaque dmaine de cnnaissance, décrivant les résultats cgnitifs d enseignements et la mentalité à acquérir. Une liste de termes que les étudiants divent se rappeler et cmprendre. Une descriptin des cncepts clé à enseigner, incluant des surces cmme des nrmes u de la littérature recnnue. Le cntenu du syllabus n est pas une descriptin de l ensemble du dmaine de cnnaissance en tests de lgiciels; il reflète le niveau de détail devant être cuvert par les curs et frmatins du niveau fndatin. Organisatin du syllabus Ce syllabus cmprend six chapitres majeurs. Le titre principal de chaque chapitre mntre l bjectif d apprentissage cuvert par le chapitre, et spécifie la durée minimale pur traiter ce chapitre. Par exemple: 2. Tester pendant le Cycle de Vie (K2) 115 minutes Ce titre indique que le Chapitre 2 a un bjectif de cnnaissance K1 (suppsé quand un niveau supérieur est spécifié) et K2 (mais pas K3), et qu une durée de 115 minutes est suggérée pur cuvrir le matériel de ce chapitre. Chaque chapitre cmprte plusieurs sectins. Chaque sectin pssède aussi un bjectif de cnnaissance et la durée requise en minutes. Les sus-sectins qui n nt pas de durée précisée snt inclues dans la durée ttale de la sectin. Versin 2011 Page 9 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

10 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 1. Fndamentaux des (K2) 155 minutes Objectifs de cnnaissance pur Fndamentaux des Les bjectifs identifient ce que vus serez en mesure de faire en fin de chaque mdule. 1.1 Purqui les tests snt-ils nécessaires? (K2) LO LO LO LO LO Décrire, avec des exemples, la manière par laquelle un défaut dans un lgiciel peut causer des dmmages à des persnnes, à l envirnnement u à la sciété. (K2) Faire la différence entre la cause initiale du défaut et ses effets. (K2) Dnner des raisns pur lesquelles les tests snt nécessaires en dnnant des exemples. (K2) Décrire purqui les tests fnt partie de l assurance qualité et dnner des exemples sur cmment les tests cntribuent à une qualité accrue. (K2) Expliquer et cmparer les termes faute, défaut, défaillance et les termes assciés erreur et bug. (K2) 1.2 Que snt les tests? (K2) LO LO LO Rappeler les bjectifs habituels des tests. (K1) Furnir des exemples pur les bjectifs des tests lrs des différentes phases du cycle de vie lgiciel (K2) Faire la différence entre tester et débguer (K2) 1.3 Les 7 Principes généraux des tests (K2) LO Expliquer les 7 principes généraux des tests (K2) 1.4 Prcessus de test fndamental (K1) LO Rappeler les 5 activités de test fndamentales et les tâches assciées, de la planificatin aux activités de clôture (K1) 1.5 La psychlgie des tests (K2) LO LO Rappeler les facteurs psychlgiques ayant une influence sur le succès des tests (K1) Cmparer la mentalité d un testeur avec celle d un dévelppeur (K2) Versin 2011 Page 10 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

11 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 1.1 Purqui les tests snt-ils nécessaires? (K2) 20 minutes Termes Bug, défaut, erreur, défaillance, défaut, méprise, qualité, risques, lgiciel, test Cntexte des systèmes lgiciels (K1) Les systèmes lgiciels deviennent une part intégrante de ntre existence, des applicatins cmmerciales (p.ex. bancaires) aux prduits de grande cnsmmatin (p.ex. autmbiles). La plupart d entre nus nt eu l expérience d un lgiciel qui n a pas fnctinné cmme attendu. Des lgiciels ne fnctinnant pas crrectement peuvent générer de nmbreux prblèmes, depuis des pertes financières, de temps u de réputatin, et puvant même aller jusqu à causer des blessures u la mrt Origine des défauts lgiciels (K2) Un être humain peut faire une erreur (méprise), qui prduit un défaut (bug) dans le cde, dans un lgiciel u un système, u dans un dcument. Si un défaut dans du cde est exécuté, le système n effectuera pas ce qu il aurait dû faire (u fera ce qu il n aurait pas dû faire), générant une défaillance. Des défauts dans les lgiciels, systèmes u dcuments peuvent générer des défaillances, mais tus les défauts ne le fnt pas. Les défauts apparaissent parce que les humains peuvent se trmper et à cause des échéanciers serrés, de la cmplexité du cde et des infrastructures, des mdificatins de technlgies et/u de multiples interactins entre les systèmes. Les défaillances peuvent être aussi causées par des cnditins d envirnnement : radiatins, magnétisme, champs électrniques et pllutin peuvent causer des défauts dans les micrprgrammes u influencer l exécutin des lgiciels en mdifiant les cnditins matérielles Rôle des tests dans le dévelppement, la maintenance et l pératin des lgiciels (K2) Des tests rigureux des systèmes et de la dcumentatin peuvent aider à réduire les risques d ccurrence de prblèmes dans l envirnnement pératinnel et cntribuent à la qualité des systèmes lgiciels, si les défauts décuverts snt crrigés avant la livraisn du système pur un usage pératinnel. Les tests de lgiciels peuvent aussi être nécessaires pur respecter des exigences légales u cntractuelles, u atteindre des nrmes industrielles spécifiques et qualité (K2) Avec l aide des tests, il est pssible de mesurer la qualité des lgiciels en termes de défauts truvés, pur des caractéristiques et exigences tant fnctinnelles que nn-fnctinnelles (p.ex. fiabilité, utilisabilité, rentabilité, maintenabilité et prtabilité). Pur plus d infrmatins sur les tests nn-fnctinnels vir Chapitre 2; pur plus d infrmatins sur les caractéristiques lgicielles vir Sftware Engineering Sftware Prduct Quality (ISO 9126). Les tests peuvent augmenter le niveau de cnfiance en la qualité d un lgiciel s ils truvent peu u pas de défauts. Un test cnçu crrectement et qui est exécuté sans erreur réduit le niveau de risque général du système. Quand les tests truvent des défauts, la qualité du système lgiciel s accrît quand ces défauts snt crrigés. Versin 2011 Page 11 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

12 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Des leçns devraient être apprises à partir des prjets précédents. En cmprenant les causes premières des défauts truvés dans d autres prjets, les prcessus peuvent être amélirés, ce qui ensuite peut prévenir l apparitin de ces défauts et, en cnséquence, amélirer la qualité des systèmes futurs. C est un aspect de l assurance qualité. Les tests devraient être intégrés cmme une activité de l assurance qualité (p.ex. au côté des standards de dévelppement, de la frmatin et de l analyse des défauts) Cmbien de test est suffisant? (K2) Décider de cmbien de test est suffisant devrait prendre en cmpte le niveau de risque, incluant les risques techniques, les risques liés à la sureté et au prjet, ainsi que les cntraintes du prjet telles que le temps et le budget. Les risques sernt dévelppés au chapitre 5. Les tests divent furnir suffisamment d infrmatins pur que les respnsables puissent prendre des décisins infrmées cncernant la mise en prductin du lgiciel u du système en curs de test, pur l étape de dévelppement suivante u la livraisn aux clients. Versin 2011 Page 12 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

13 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 1.2 Que snt les tests? (K2) 30 minutes Termes débgage, exigences, revues, cas de test, test, bjectifs des tests, test, Cntexte Une perceptin habituelle des tests est qu ils cnsistent uniquement en l exécutin de tests, en fait exécuter le lgiciel. C est une partie des tests, mais pas l ensemble des activités de test. Des activités de test existent avant et après l exécutin des tests. Ces activités incluent la planificatin et le cntrôle, la sélectin des cnditins de test, la cnceptin et l exécutin des cas de tests, la vérificatin des résultats, l évaluatin des critères de srtie, l infrmatin sur le prcessus de test et sur le système en curs de test ; elles incluent aussi la réalisatin et la finalisatin des activités de clôture définitive à la fin d une phase de test. Les tests incluent aussi la revue de dcuments (incluant le cde surce) et les analyses statiques. Les tests dynamiques et les tests statiques peuvent être utilisés cmme des myens pur atteindre des bjectifs similaires, et furnirnt des infrmatins permettant l améliratin du système à tester et des prcessus de dévelppement et de test. Les bjectifs de tests peuvent varier : Truver des défauts Acquérir de la cnfiance sur le niveau de qualité Furnir de l infrmatin utile aux prises de décisin Prévenir des défauts Le prcessus de réflexin et les activités visant à cncevir des tests tôt dans le cycle de vie (vérifier les bases de tests via la cnceptin des tests) peuvent aider à prévenir l intrductin de défauts dans le cde. Les revues de dcuments (p.ex. exigences), l identificatin et la réslutin de prblèmes peuvent aussi aider à prévenir l apparitin de défauts dans le cde. Les pints de vue différents des tests prennent en cmpte des bjectifs différents. Par exemple, dans les tests de dévelppement (p.ex. tests des cmpsants, d intégratin u système), l bjectif principal peut être de générer le plus de défaillances pssible de façn à identifier et à crriger les défauts dans le lgiciel. Dans les tests d acceptatin, l bjectif principal peut être de cnfirmer que le système fnctinne cmme attendu, pur s assurer qu il atteint les exigences. Dans certains cas l bjectif principal des tests peut être d évaluer la qualité d un lgiciel (sans chercher à truver des anmalies), de façn à furnir aux respnsables de l infrmatin sur les risques de distribuer un système à un mment précis. Les tests de maintenance incluent suvent des tests pur s assurer que de nuvelles anmalies n nt pas été intrduites pendant le dévelppement des évlutins. Pendant les tests d pératin, les bjectifs principaux peuvent être d évaluer les caractéristiques du système telles la dispnibilité u la fiabilité. Tester et débguer snt différents. Les tests dynamiques peuvent mntrer des défaillances causées par des défauts. Débguer est l activité de dévelppement qui truve, analyse et supprime les causes de la défaillance. Les tests de cnfirmatin ultérieurs effectués par un testeur assurent que la crrectin résut effectivement la défaillance. La respnsabilité de chaque activité est différente : les testeurs testent, les dévelppeurs débguent. Le prcessus de test et les activités de test snt expliqués en Sectin 1.4. Versin 2011 Page 13 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

14 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 1.3 Les 7 principes généraux des tests (K2) 35 minutes Termes exhaustifs. Principes Un nmbre de principes de test nt été suggérés au curs des 40 dernières années et ffrent des indicatins cmmunes à tus les tests. Principe 1 Les tests mntrent la présence de défauts Les tests peuvent pruver la présence de défauts, mais ne peuvent pas en pruver l absence. Les tests réduisent la prbabilité que des défauts restent cachés dans le lgiciel mais, même si aucun défaut n est décuvert, ce n est pas une preuve d exactitude. Principe 2 Les tests exhaustifs snt impssibles Tut tester (tutes les cmbinaisns d entrées et de pré-cnditins) n est pas faisable sauf pur des cas triviaux. Plutôt que des tests exhaustifs, nus utilisns l analyse des risques et des prirités pur fcaliser les effrts de tests. Principe 3 Tester tôt Pur truver des défauts tôt, les activités de tests devraient cmmencer aussi tôt que pssible dans le cycle de dévelppement du lgiciel u du système, et devraient être fcalisées vers des bjectifs définis. Principe 4 Regrupement des défauts L effrt de test devrait être fixé prprtinnellement à la densité des défauts prévus et cnstatés dans les différents mdules. Un petit nmbre de mdules cntiennent généralement la majrité des défauts détectés lrs des tests pré-livraisn, u affichent le plus de défaillances en pératin. Principe 5 Paradxe du pesticide Si les mêmes tests snt répétés de nmbreuses fis, il arrivera que le même ensemble de cas de tests ne truvera plus de nuveaux défauts. Pur prévenir ce paradxe du pesticide, les cas de tests divent être régulièrement revus et révisés, et de nuveaux tests, différents, divent être écrits pur cuvrir d autres chemins dans le lgiciel u le système de façn à permettre la décuverte de nuveaux défauts. Principe 6 Les tests dépendent du cntexte Les tests snt effectués différemment dans des cntextes différents. Par exemple, les lgiciels de sécurité critique sernt testés différemment d un site de cmmerce électrnique. Principe 7 L illusin de l absence d erreurs Truver et crriger des défauts n aide pas si le système cnçu est inutilisable et ne cmble pas les besins et les attentes des utilisateurs. Versin 2011 Page 14 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

15 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 1.4 Prcessus de test fndamental (K1) 35 minutes Termes de cnfirmatin, incident, test de régressin, base de tests, cnditins de tests, cuverture de test, dnnées de tests, exécutin des tests, critères de srtie, registre de test, plan de test, stratégie de test,prcédure de test, plitique de test, suite de test, rapprt de synthèse de tests, testware. Cntexte La partie la plus visible des tests est l exécutin des tests. Mais pur être efficaces et rentables, les plans de tests devraient aussi inclure du temps pur planifier les tests, cncevir les cas de tests, préparer les exécutins et évaluer l état. Le prcessus de test fndamental cmprend les activités principales suivantes: Planificatin des tests et cntrôle Analyse et cnceptin des tests Implémentatin et exécutin des tests Evaluer les critères de srtie et infrmer Activités de clôture des tests Bien que lgiquement séquentielles, les activités du prcessus peuvent se chevaucher partiellement u être cncurrentes. Une adaptatin de ces activités principales au cntexte du système u du prjet est en général requise Planificatin et cntrôle des tests (K1) La planificatin des tests cnsiste à définir les bjectifs du test et à spécifier les activités de test à mettre en œuvre pur atteindre les bjectifs et la missin. Le cntrôle des tests est une activité cntinue de cmparaisn de l avancement actuel par rapprt au plan, et d infrmatin sur l état, y cmpris les déviatins par rapprt au plan. Cela implique de prendre les actins nécessaires pur atteindre la missin et les bjectifs du prjet. Afin de cntrôler les tests, les activités de test devraient être cntrôlées tut au lng du prjet. La planificatin des tests prend en cmpte le feed-back des activités de cntrôle et de suivi. Les tâches de planificatin et cntrôle snt définies au chapitre 5 de ce syllabus Analyse et Cnceptin des tests (K1) L analyse et la cnceptin des tests représentent les activités ù les bjectifs de test généraux snt transfrmés en des cnditins de test et des cnceptins de test tangibles. L analyse et la cnceptin des tests se cmpsent des tâches majeures suivantes: Réviser les bases du test (telles que les exigences, le niveau d intégrité lgiciel 1 (niveau de risque), les rapprts d analyse de risque, l architecture, la cnceptin et les interfaces) Evaluer la testabilité des exigences et du système Identifier et pririser les cnditins de test sur la base de l analyse des articles de test, la spécificatin, le cmprtement et la structure du lgiciel 1 Le degré de cnfrmité auquel le lgiciel satisfait u dit satisfaire par rapprt à un ensemble de caractéristiques sélectinnées par les parties-prenantes u basées sur les systèmes lgiciels, et devant être définies pur refléter l imprtance du lgiciel pur les persnnes cncernées (p.ex: cmplexité lgicielle, niveau de sureté, niveau de sécurité, perfrmance suhaitée, rbustesse u cût). Versin 2011 Page 15 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

16 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Cncevir et pririser les tests de haut niveau Identifier les dnnées de test nécessaires pur les cnditins de test et les cas de test Cncevir l initialisatin de l envirnnement de test et identifier les infrastructures et utils requis Créer une traçabilité bi-directinnelle entre les bases de test et les cas de test Implémentatin et exécutin des tests (K1) L implémentatin et l exécutin des tests est l activité ù les prcédures u scripts de test snt spécifiés en arrangeant les cas de test seln un rdre précis et en ajutant tute infrmatin utile pur l exécutin des tests; l envirnnement est initialisé et les tests snt lancés. L implémentatin et l exécutin des tests se cmpsent des tâches majeures suivantes: Finaliser, dévelpper et pririser les cas de test (yc l identificatin des dnnées de test) Dévelpper et pririser les prcédures de test, créer les dnnées de test et, éventuellement, préparer les harnais de test et écrire les scripts de tests autmatiques Créer des suites de tests à partir des prcédures de test pur une exécutin rentable des tests Vérifier que les envirnnements de tests nt été mis en place crrectement Vérifier et mettre à jur la traçabilité bi-directinnelle entre les bases de test et les cas de test Exécuter les prcédures de test sit manuellement sit en utilisant des utils d exécutin de tests, en suivant la séquence planifiée Cnsigner les résultats de l exécutin des tests et enregistrer les identités et versins des lgiciels en test, utils de test et testware Cmparer les résultats actuels et les résultats attendus. Signaler les divergences cmme des incidents et les analyser de façn à établir leur cause (p.ex. défaut dans le cde, dans les dnnées de test, dans la dcumentatin de test, u méprise dans la manière d exécuter le test) Répéter les activités de test en répnse aux actins prises pur chaque divergence. Par exemple, réexécutin d un test qui était préalablement défaillant de façn à valider une crrectin (test de cnfirmatin), exécutin d un test crrigé et/u exécutin de tests de façn à s assurer que des défauts n nt pas été intrduits dans des secteurs nn mdifiés du lgiciel u que le défaut crrigé n a pas décuvert d autres défauts (test de régressin) Evaluer les critères de srtie et infrmer (K1) Evaluer les critères de srtie est l activité ù l exécutin des tests est évaluée en fnctin des bjectifs définis. Ceci devrait être fait pur chacun des niveaux de test. Evaluer les critères de srtie cntient les tâches majeures suivantes: Vérifier les registres de tests en fnctin des critères de srtie spécifiés dans la planificatin des tests Evaluer si des tests supplémentaires snt requis u si les critères de srtie divent être changés Ecrire un rapprt de synthèse des tests pur les parties prenantes Activités de clôture des tests (K1) Les activités de clôture des tests rassemblent les dnnées des activités de tests terminées de façn à cnslider l expérience, les testwares, les faits et les valeurs. Ces activités snt menées aux jalns d un prjet, par exemple, quand un système lgiciel est mis en prductin, un prjet de test est terminé (u annulé), un jaln est atteint, u une versin de maintenance est terminée. Les activités de clôture des tests incluent les tâches majeures suivantes: Vérifier quels livrables prévus nt été livrés Clôturer les rapprts d incidents u créer des demandes d évlutin pur ceux restant uverts Dcumenter l acceptatin du système Versin 2011 Page 16 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

17 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Finaliser et archiver les testwares, envirnnements de test et infrastructures de test pur une réutilisatin future Furnir les testwares à l rganisatin en charge de la maintenance Analyser les leçns apprises pur identifier les changements nécessaires pur les versins et prjets futurs Utiliser l infrmatin cllectée pur amélirer la maturité des tests Versin 2011 Page 17 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

18 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 1.5 La psychlgie des tests (K2) 25 minutes Termes Estimatin d erreur, test indépendant. Cntexte La turnure d esprit à utiliser pendant les tests et les revues est différente de celle utilisée lrs de l analyse u du dévelppement. Avec la mentalité apprpriée, des dévelppeurs snt capables de tester leur prpre cde, mais affecter cette respnsabilité à des testeurs permet typiquement de fcaliser l effrt et de furnir des bénéfices additinnels tels qu une perspective indépendante par des ressurces de test entraînées et prfessinnelles. Les tests indépendants peuvent être effectués à n imprte quel niveau des tests Un certain degré d indépendance (évitant le parti-pris de l auteur) est suvent plus efficace pur détecter des défauts et des défaillances. L indépendance n est pas cependant un remplacement de la familiarité, et les dévelppeurs peuvent efficacement truver beaucup d erreurs dans leur prpre cde. Plusieurs niveaux d indépendance peuvent être définis, cmme les niveaux suivants présentés du plus faible au plus élevé : cnçus par la (les) persnne(s) qui a (nt) écrit le lgiciel à tester (niveau faible d indépendance). cnçus par une (des) autre(s) persnne(s) (p.ex. de l équipe de dévelppement). cnçus par une (des) persnne(s) d un grupe différent au sein de la même rganisatin (p.ex. équipe de test indépendante) u par des spécialistes de test (p.ex. spécialistes en tests de perfrmance u utilisabilité) cnçus par une (des) persnne(s) d une rganisatin u sciété différente (p.ex. sustraitance u certificatin par un rganisme externe) Les persnnes et les prjets snt dirigés par des bjectifs. Les persnnes nt tendance à aligner leurs plans en fnctin des bjectifs mis en place par le management et les autres respnsables, par exemple, pur truver des défauts u cnfirmer qu un lgiciel fnctinne. De ce fait, il est imprtant de spécifier clairement les bjectifs des tests. L identificatin de défaillances pendant les tests peut être perçue cmme une critique cntre le prduit et cntre sn(ses) auteur(s). Les tests snt, de ce fait, suvent vus cmme une activité destructrice, même si c est très cnstructif dans la gestin des risques du prduit. Rechercher des défaillances dans un système requiert de la curisité, du pessimisme prfessinnel, un eil critique, une attentin au détail, une bnne cmmunicatin avec ses pairs en dévelppement, et de l expérience sur laquelle baser l estimatin d erreurs. Si des erreurs, défauts u défaillances snt cmmuniqués de manière cnstructive, l animsité entre les testeurs et les analystes, cncepteurs et dévelppeurs peut être évitée. Ceci s applique autant aux revues qu aux tests. Les testeurs et le respnsable des tests nt besin de bnnes cmpétences relatinnelles pur cmmuniquer des infrmatins factuelles sur les défauts, les prgrès et les risques, de manière cnstructive. Pur l auteur du lgiciel u du dcument, une infrmatin sur les défauts peut permettre d amélirer leur savir-faire. Les défauts truvés et crrigés pendant les tests permettrnt de gagner du temps et de l argent plus tard, et de réduire les risques. Des prblèmes de cmmunicatin peuvent survenir, particulièrement si les testeurs snt vus uniquement cmme messagers prteurs de mauvaises nuvelles cncernant des défauts. Versin 2011 Page 18 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

19 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Cependant, il existe plusieurs manières d amélirer la cmmunicatin et les relatins entre les testeurs et leurs interlcuteurs : Cmmencer par une cllabratin plutôt que par des cnflits rappeler à chacun l bjectif cmmun de systèmes de meilleure qualité Cmmuniquer les décuvertes sur le prduit de façn neutre et factuelle sans critiquer la persnne respnsable, par exemple, écrire des rapprts d incidents (u des résultats de revues) bjectifs et factuels Essayer de cmprendre ce que ressent une autre persnne et purqui elle réagit cmme elle le fait Cnfirmer que l autre persnne a cmpris ce que l n a dit et vice versa Versin 2011 Page 19 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

20 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 1.6 Cde d éthique 10 minutes L implicatin dans le test lgiciel permet aux individus d avir accès à des infrmatins cnfidentielles et privilégiées. Un cde d éthique est nécessaire, ntamment pur assurer que les infrmatins ne sient pas utilisées dans des cas nn apprpriés. En référence au cde d éthique d ACM et de l IEEE pur les ingénieurs, l ISTQB définit le cde d éthique suivant : PUBLIC les testeurs de lgiciels certifiés divent agir en fnctin de l intérêt public CLIENT ET EMPLOYEUR les testeurs de lgiciels certifiés divent agir pur l intérêt de leur client et de leur emplyeur tut en respectant l intérêt public PRODUIT les testeurs de lgiciels certifiés divent assurer que les furnitures qu ils prduisent (cncernant les prduits et les systèmes qu ils testent) répndent le plus pssible aux standards prfessinnels JUGEMENT les testeurs de lgiciels certifiés divent cnserver leur intégrité et leur indépendance dans leur jugement prfessinnel GESTION les chefs de prjet de test de lgiciels certifiés et les respnsables divent respecter et prmuvir une apprche mrale dans la gestin de prjets de test de lgiciels PROFESSION les testeurs de lgiciels certifiés divent mettre en avant l intégrité et la réputatin du métier en chérence avec l intérêt public COLLEGUES les testeurs de lgiciels certifiés divent être lyaux, aider leurs cllègues, et prmuvir le partenariat avec les dévelppeurs de lgiciels PERSONNELLEMENT les testeurs de lgiciels certifiés divent participer en permanence à de la frmatin pur leur métier et divent prmuvir une apprche mrale cncernant sa pratique. References Black, 2001, Kaner, Beizer, 1990, Black, 2001, Myers, Beizer, 1990, Hetzel, 1988, Myers, Hetzel, Black, 2001, Craig, Black, 2001, Hetzel, 1988 Versin 2011 Page 20 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

21 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 2. Tester Pendant le Cycle de Vie Lgiciel (K2) 115 minutes Objectifs de cnnaissance pur Tester Pendant le Cycle de Vie Lgiciel Les bjectifs identifient ce que vus serez capable de faire après avir suivi ce mdule. 2.1 Les mdèles de dévelppement lgiciel (K2) LO LO LO Cmprendre les relatins entre le dévelppement, les activités de test et les livrables dans le cycle de vie de dévelppement, et dnner des exemples basés sur des caractéristiques et cntextes de prduits et de prjets (K2). Recnnaître que les mdèles de dévelppement lgiciel divent être adaptés au cntexte du prjet et aux caractéristiques du prduit (K1). Rappeler que les bnnes pratiques de test snt applicables dans tus les mdèles de cycle de vie (K1) 2.2 Niveaux de tests (K2) LO Cmparer les différents niveaux de tests: bjectifs principaux, types d bjets habituels à tester, types de tests habituels (p.ex. fnctinnels u structurels) et livrables assciés, persnnes en charge des tests, types de défauts et de défaillances à identifier. (K2) 2.3 Types de tests: les cibles de tests (K2) LO LO LO LO LO Cmparer les quatre types de tests (fnctinnels, nn-fnctinnels, structurels et liés aux changements) avec des exemples. (K2) Recnnaître que les tests fnctinnels et structurels peuvent apparaître à n imprte quel niveau. (K1) Identifier et décrire des types de tests nn-fnctinnels basés sur des exigences nnfnctinnelles. (K2) Identifier et décrire des types de tests basés sur l analyse de la structure u de l architecture d un système lgiciel. (K2) Décrire l utilité des tests de cnfirmatin et des tests de régressin. (K2) 2.4 de maintenance (K2) LO LO LO Cmparer les tests de maintenance (tester un système existant) et les tests d une nuvelle applicatin en ce qui cncerne les types de tests, les déclencheurs des tests et la quantité de tests. (K2) Recnnaitre les indicateurs pur les tests de maintenance (mdificatin, migratin et abandn). (K1) Décrire le rôle des tests de régressin et de l analyse d impact en maintenance. (K2) Versin 2011 Page 21 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

22 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 2.1 Mdèles de Dévelppement Lgiciel (K2) 20 minutes Termes Lgiciel cmmercial sur étagère (en anglais : Cmmercial Off The Shelf u COTS), mdèle de dévelppement incrémental niveaux de tests, validatin, vérificatin, mdèle en V. Cntexte Les tests n existent pas de façn islée; les activités de test snt liées aux activités de dévelppement lgiciel. Les différents mdèles de cycle de dévelppement nécessitent des apprches de tests différentes Mdèle en V (K2) Bien que des variantes du mdèle en V existent, un mdèle en V standard utilise quatre niveaux de tests, crrespndant aux quatre niveaux de dévelppement. Les quatre niveaux utilisés dans le syllabus snt: de cmpsants (unitaires); d intégratin; système; d acceptatin. En pratique, un mdèle en V peut avir des niveaux de dévelppement et de tests différents, en mins u en plus, en fnctin des prjets et des prduits lgiciels. Par exemple, il peut y avir des tests d intégratin des cmpsants après les tests de cmpsants, et des tests d intégratin de systèmes après des tests systèmes. Les livrables lgiciels (tels les scénaris d utilisatin u les cas d empli, les spécificatins d exigences, les dcuments de cnceptin et le cde) prduits pendant le dévelppement snt suvent les bases des tests d un u plusieurs niveaux de tests. Des références pur des livrables génériques snt dispnibles dans le mdèle CMMI (Capability Maturity Mdel Integratin) u dans l IEEE/IEC (Prcessus de cycle de vie lgiciel Sftware life cycle prcesses ). La vérificatin et la validatin (ainsi que la cnceptin au plus tôt des tests) peuvent être effectuées pendant le dévelppement des livrables lgiciels Mdèle de dévelppement itératif (K2) Le mde de dévelppement itératif est une successin d activités exécutées cmme une série de petits dévelppements: exigences, cnceptin, cnstructin et tests d un système. Exemples : prttypage, dévelppement rapide d applicatins (RAD), Ratinal Unified Prcess (RUP) et les mdèles de dévelppement agiles. Le système lgiciel résultant (l incrément) d une itératin peut être testé à plusieurs niveaux de tests à chaque itératin. Un incrément, ajuté à ceux dévelppés préalablement, frme un système partiel en crissance, qui devrait également être testé. Les tests de régressin snt de plus en plus imprtants sur tutes les itératins après la première. La vérificatin et la validatin peuvent être effectuées sur chaque incrément Tester au sein d un mdèle de cycle de vie (K2) Quel que sit le mdèle de cycle de vie, plusieurs bnnes pratiques de tests s appliquent: A chaque activité de dévelppement, crrespnd une activité de test. Chaque niveau de test a des bjectifs de tests spécifiques pur ce niveau. L analyse et la cnceptin des tests pur un niveau de test devraient cmmencer pendant l activité crrespndante de dévelppement. Versin 2011 Page 22 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

23 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Les testeurs divent être impliqués dans la revue des dcuments aussi tôt que des bruillns snt dispnibles dans le cycle de dévelppement. Les niveaux de tests peuvent être cmbinés u rérganisés seln la nature du prjet u de l architecture du système. Par exemple, pur l intégratin d un lgiciel sur étagère (COTS) dans un système, l acheteur peut effectuer des tests d intégratin au niveau système (Ex. intégratin dans l infrastructure et les autres systèmes, u dépliement du système) ainsi que des tests d acceptatin (fnctinnels et/u nn-fnctinnels, et tests d acceptatin utilisateurs et/u pératinnels). Versin 2011 Page 23 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

24 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 2.2 Niveaux de tests (K2) 40 minutes Termes Alpha tests, Beta tests, tests de cmpsant (aussi cnnus cmme tests unitaires, de mdules u de prgrammes), tests d acceptatin cntractuelle, piltes, tests sur le terrain, exigences fnctinnelles, intégratin, tests d intégratin, exigences nn-fnctinnelles, tests de rbustesse, buchns, tests système, envirnnement de test, niveau de tests, dévelppement dirigé par les tests, tests d acceptatin utilisateurs. Cntexte Pur chaque niveau de tests, les aspects suivants peuvent être identifiés: les bjectifs génériques, le(s) livrable(s) référencé(s) pur dériver des cas de tests (c est à dire la base de test), les bjets de tests (càd. ce qui est testé), les défauts et les défaillances typiques à truver, les exigences en harnais de tests et en supprt d utils, ainsi que les apprches et respnsabilités spécifiques au niveau. Les tests des dnnées de cnfiguratin du système divent être pris en cmpte au curs de la plannificatin des tests de cmpsants (K2) Bases de tests: Exigences des cmpsants Cnceptin détaillée Cde Objets habituels de test: Cmpsants Prgrammes Cnversins de dnnées / utilitaires u prgrammes de migratin Mdules de bases de dnnées Les tests de cmpsants (également cnnus sus les nms de tests unitaires, de mdules u de prgrammes) cherchent des défauts dans, et vérifient le fnctinnement des, lgiciels (p.ex. mdules, prgrammes, bjets, classes, etc.) qui snt testables séparément. Cela peut se faire de façn islée par rapprt au reste du système, en fnctin du cntexte du cycle de dévelppement du lgiciel et du système. Des buchns, piltes et simulateurs peuvent être utilisés. Les tests de cmpsants peuvent inclure des tests de fnctinnalités et des tests de caractéristiques nn-fnctinnelles, telles que le cmprtement des ressurces (p.ex. fuites mémire) u des tests de rbustesse, ainsi que des tests structurels (p.ex. cuverture des branches). Les cas de test snt dérivés des livrables tels que les spécificatins des cmpsants (spécificatins détaillées), la cnceptin du lgiciel u le mdèle de dnnées. La plupart du temps, les tests de cmpsants se fnt avec l accès au cde du lgiciel testé et sur un envirnnement de dévelppement cmme un framewrk de tests unitaire u avec les utils de débgage. En pratique ils impliquent généralement le prgrammeur ayant écrit le cde. Habituellement, les défauts snt crrigés dès qu ils snt truvés, sans frmellement enregistrer des incidents. Une apprche des tests de cmpsants est de préparer et autmatiser des cas de tests avant le cdage. Cela s appelle l apprche «Tester d abrd» (en anglais : «test first»)u «Dévelppement pilté par les tests. Cette apprche, frtement itérative est basée sur des cycles de dévelppement de cas de tests, puis cnstructin et intégratin de petits buts de cde, puis exécutin des tests de cmpsants et crrectin des défauts truvés jusqu à leur réussite. Versin 2011 Page 24 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

25 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard d intégratin (K2) Bases de : Cnceptin du lgiciel et du système Architecture Wrkflws Cas d utilisatin Objets habituels de test: Sus-systèmes Implémentatin de bases de dnnées Infrastructure Interfaces Cnfiguratin système et dnnées de cnfiguratin Les tests d intégratin testent les interfaces entre les cmpsants, les interactins entre différentes parties d un système cmme par exemple le système d explitatin, le système de fichiers, le matériel u les interfaces entre les systèmes. Plusieurs niveaux de tests d intégratin peuvent être effectués sur des bjets de taille variable. Par exemple: d intégratin des cmpsants testant les interactins entre les cmpsants lgiciels et effectués après les tests de cmpsants; d intégratin système testant l intégratin entre les différents systèmes u entre lgiciel et matériel et puvant être effectués après les tests système. Dans ce cas, l rganisatin en charge du dévelppement peut ne cntrôler qu un côté de l interface. Cela peut être cnsidéré cmme un risque métier. Les prcessus cmmerciaux mis en œuvre cmme les wrkflws peuvent impliquer plusieurs systèmes. Les aspects inter-platefrmes peuvent être significatifs. Plus la prtée de l intégratin est vaste, plus il devient difficile d isler les défauts liés à un cmpsant u un système particulier. Cela peut cnduire à un accrissement des risques et du temps nécessaire pur résudre les prblèmes. Des stratégies d intégratin systématique peuvent être basées sur l architecture des systèmes (telles que tp-dwn u bttm-up), les tâches fnctinnelles, les séquences d exécutin de transactins, u d autres aspects du système u du cmpsant. Afin d isler facilement les fautes, et détecter les défauts au plus tôt, l intégratin devrait nrmalement être incrémentale plutôt qu être effectuée en une fis ( big bang ). Les tests de caractéristiques nn-fnctinnelles particulières (p.ex. perfrmances) peuvent être inclus dans les tests d intégratin. A chaque étape de l intégratin, les testeurs se cncentrent uniquement sur l intégratin elle même. Par exemple, s ils snt en train d intégrer le mdule A avec le mdule B, les testeurs s appliquent à tester la cmmunicatin entre les mdules et nn pas leurs fnctinnalités individuelles. Les apprches fnctinnelles et structurelles peuvent tutes deux être utilisées. Idéalement, les testeurs devraient cmprendre l architecture et influencer le planning d intégratin. Si les tests d intégratin snt prévus avant que les cmpsants u les systèmes ne sient fabriqués, les tests purrnt être cnçus dans le bn rdre pur être efficaces et efficients système (K2) Bases de Test: Spécificatins d exigences Système et lgiciel Versin 2011 Page 25 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

26 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Cas d utilisatin Spécificatins fnctinnelles Rapprts d analyse des risques Objets de tests habituels: Manuels système, utilisateur et pératinnels Cnfiguratin système et dnnées de cnfiguratin Les tests systèmes traitent le cmprtement d un système/prduit cmplet. Le périmètre des tests dit être clairement défini dans le plan de test maitre u le plan de test du niveau. Pur les tests système, l envirnnement de test devrait crrespndre à la cible finale u à un envirnnement de prductin de façn à minimiser les risques de défaillances dues à l envirnnement. Les tests système peuvent inclure des tests basés sur les risques et/u sur les spécificatins et les exigences, les prcessus cmmerciaux, les cas d utilisatin, u autres descriptins de haut niveau du cmprtement du système, les mdèles de cmprtement, les interactins avec le système d explitatin et les ressurces système. Les tests système devraient examiner à la fis les exigences fnctinnelles et les nnfnctinnelles du système ainsi que la qualité des dnnées. Les testeurs divent également s adapter aux exigences peu u pas dcumentées. Les tests fnctinnels au niveau système cmmencent par l utilisatin des techniques de spécificatin de tests les plus apprpriées (bîte nire). Par exemple, une table de décisin peut être crée pur les cmbinaisns d effets décrits dans les prcessus cmmerciaux. Les techniques basées sur les structures (bîte blanche) peuvent ensuite être utilisées pur évaluer la minutie des tests par rapprt à un élément cmme la structure de menu u la navigatin dans la page web. (vir Chapitre 4.) Une équipe de tests indépendante exécute suvent des tests système d acceptatin (K2) Bases de test: Exigences utilisateur Exigences du système Cas d utilisatin Prcessus métier Rapprts d analyse des risques Objets habituels de test: Prcessus métier sur l intégralité du système Prcessus pératinnels de maintenance Prcédures utilisateur Frmulaires Rapprts Dnnées de cnfiguratin Les tests d acceptatin relèvent suvent de la respnsabilité des clients u utilisateurs d un système; d autres respnsables (parties prenantes) peuvent aussi être impliqués. Les bjectifs des tests d acceptatin snt de prendre cnfiance dans le système, dans des parties du système u dans des caractéristiques nn-fnctinnelles du système. La recherche d anmalies n est pas l bjectif principal des tests d acceptatin. Les tests d acceptatin peuvent évaluer si le système est prêt à être déplyé et utilisé, bien que ce ne sit pas nécessairement le dernier niveau Versin 2011 Page 26 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

27 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard de tests. Par exemple, une intégratin système à grande échelle peut arriver après les tests d acceptatin du système. Les tests d acceptatin peuvent se faire à plusieurs niveaux de tests, par exemple: Des tests d acceptatin peuvent avir lieu sur un cmpsant sur étagère quand il est installé u intégré. Les tests d acceptatin de l utilisabilité d un cmpsant peuvent être effectués pendant les tests unitaires. Les tests d acceptatin d une évlutin fnctinnelle peuvent être exécutés avant les tests système. Les frmes habituelles des tests d acceptatin incluent : d acceptatin utilisateur Ces tests vérifient l aptitude et l utilisabilité du système par des utilisateurs. (d acceptatin) pératinnelle L acceptatin du système par les administrateurs système, dnt: des backups et restauratins; Reprise après sinistre; Gestin des utilisateurs; Tâches de maintenance; Chargements de dnnées et tâches de migratin Vérificatin péridique des vulnérabilités de sécurité. d acceptatin cntractuelle et réglementaire Les tests d acceptatin cntractuelle snt exécutés sur base des critères d acceptatin cntractuels pur la prductin de lgiciels dévelppés sur mesure. Les critères d acceptatin devraient être définis lrs de la rédactin du cntrat. Les tests d acceptatin réglementaires snt exécutés par rapprt aux règlements et législatins qui divent être respectés, telles que les bligatins légales, guvernementales u de sécurité. alpha et beta (u sur le terrain) Les dévelppeurs de lgiciels pur le public, u de COTS (lgiciel cmmercial sur étagère), suhaitent suvent recueillir l avis des clients ptentiels u existants sur leur marché, avant de mettre en vente. Les Alpha tests snt exécutés sur le site de l rganisatin effectuant le dévelppement mais pas par les équipes de dévelppement. Les Béta tests u tests sur le terrain snt exécutés par des persnnes sur leurs sites prpres. Les rganisatins peuvent aussi utiliser d autres termes, tels que «tests d acceptatin usine» u «tests d acceptatin sur site» pur des systèmes qui snt testés avant d être transférés sur le site client. Versin 2011 Page 27 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

28 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 2.3 Types de tests (K2) 40 minutes Termes tests bîte nire, cuverture du cde, tests fnctinnels, tests d interpérabilité, tests de charge, tests de maintenabilité, tests de perfrmances, tests de prtabilité, tests de fiabilité, tests de sécurité, tests de stress, tests structurels, tests d utilisabilité, tests bîte blanche. Cntexte Un grupe d activités de tests peut être axé sur la vérificatin du système lgiciel (u d une partie du système) pur une raisn u une cible particulière. Un type de tests est fcalisé sur un bjectif de tests particulier, qui peut être le test d une fnctin devant être effectuée par le lgiciel; une caractéristique nn-fnctinnelle, telle que la fiabilité u l utilisabilité, la structure u l architecture du lgiciel u du système; lié aux changements, p.ex. cnfirmer que des anmalies nt été crrigées (tests de cnfirmatin) et pur rechercher la présence de mdificatins nn vulues (tests de régressin). Un mdèle du lgiciel peut être dévelppé et/u utilisé dans des tests structurels et fnctinnels (p.ex un diagramme de cntrôle de flux u une structure de menu), dans des tests nn fnctinnels (mdèles de menaces de sécurité), dans les tests fnctinnels (p.ex un diagramme de flux de prcessus, un diagramme de transitins d état u des spécificatins en langage naturel) des fnctins (tests fnctinnels) (K2) Les fnctinnalités qu un système, sus-système u cmpsant dit effectuer peuvent être décrites dans des livrables tels que des spécificatins d exigences, les cas d utilisatin, u les spécificatins fnctinnelles, u encre nn dcumentées. Les fnctins snt ce que «fait» le système. Les tests fnctinnels snt basés sur ces fnctins et caractéristiques (décrites dans des dcuments u cmprises par les testeurs), et leur interpérabilité avec d autres systèmes. Ils peuvent être exécutés à tus les niveaux de tests (p.ex. les tests d un cmpsant peuvent être basés sur les spécificatins du cmpsant). Des techniques basées sur les spécificatins peuvent être utilisées pur dériver des cnditins de tests et des cas de tests à partir des fnctinnalités du lgiciel u du système (vir Chapitre 4.) Les tests fnctinnels cncernent le cmprtement extérieur du lgiciel (tests bîte nire). Un type de test fnctinnel, le test de sécurité, examine les fnctins (p.ex. pare-feu) liées à la détectin de menaces, cmme des virus, prvenant de tiers malveillants. Un autre type de test fnctinnel, le test d interpérabilité, évalue la capacité du lgiciel à interagir avec un u plusieurs cmpsants u systèmes spécifiés des caractéristiques nn fnctinnelles des prduits lgiciels (tests nn-fnctinnels) (K2) Les tests nn-fnctinnels incluent, mais pas uniquement, les tests de perfrmances, tests de charge, tests de stress, tests d utilisabilité, tests de maintenabilité, tests de fiabilité et les tests de prtabilité. Ces tests évaluent cmment le système fnctinne. Les tests nn-fnctinnels peuvent être effectués à tus les niveaux de tests. Le terme de tests nn-fnctinnels décrit les tests requis pur mesurer les caractéristiques des systèmes et lgiciels qui peuvent être quantifiées sur une échelle variable, cmme les temps de répnse pur les tests Versin 2011 Page 28 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

29 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard de perfrmances. Ces tests peuvent être référencés dans un mdèle qualité tel que celui défini par l ISO9126 Ingénierie Lgicielle Qualité des Prduits Lgiciels ( Sftware Engineering Sftware Prduct Quality ). Les tests nn fnctinnels cncernent l aspect extérieur du lgiciel et la plupart du temps utilisent les techniques de cnceptin de tests bîte nire de la structure / architecture lgicielle (tests structurels) (K2) Les tests structurels (bîte blanche) peuvent être effectués à tus les niveaux de tests. Les techniques structurelles snt utilisées de façn ptimale après les techniques basées sur les spécificatins, pur aider à mesurer l ampleur des tests via l évaluatin de la cuverture d un type de structure. La cuverture indique à quel pint une structure a été testée par une suite de tests. Elle est exprimée en purcentage d éléments cuverts. Si la cuverture n est pas de 100%, alrs de nuveaux tests peuvent être cnçus pur tester les éléments manquants et ainsi augmenter la cuverture. Les techniques de cuverture snt traitées dans le chapitre 4. A tus les niveaux de tests, mais spécialement dans les tests de cmpsants et les tests d intégratin de cmpsants, des utils peuvent être utilisés pur mesurer la cuverture du cde des éléments, telle que les instructins u les décisins. Les tests structurels peuvent être basés sur l architecture du système cmme par exemple la hiérarchie d appels. Les apprches de tests structurels peuvent être aussi appliquées au niveau système, à l intégratin système u aux niveaux de tests d acceptatin (p.ex. pur les prcessus métier u les structures de menus) liés au changement (tests de cnfirmatin et de régressin) (K2) Quand un défaut est détecté et crrigé, le lgiciel devrait être re-testé pur cnfirmer que le défaut riginal a été crrectement ôté. Ceci est appelé test de cnfirmatin. Le débgage (lcalisatin et crrectin de défaut) est une activité de dévelppement, pas une activité de tests. Ré-exécuter des tests sur un prgramme déjà testé s appelle «test de régressin». Cela se fait après que des mdificatins du prgramme aient eu lieu, pur identifier tut nuveau défaut dû à ce(s) changement(s). Ces défauts peuvent se truver sit dans le lgiciel en curs de tests, sit dans d autres cmpsants lgiciels liés u nn. Les tests de régressin snt exécutés quand le lgiciel, u sn envirnnement, est mdifié. Le périmètre des tests de régressin est basé sur le risque de ne pas truver d anmalie dans un lgiciel fnctinnant auparavant. Les tests devraient être répétables s ils snt utilisés pur des tests de cnfirmatin u pur les tests de régressin. Les tests de régressin peuvent être exécutés à tus les niveaux de tests, et s appliquent aux tests fnctinnels, nn-fnctinnels et structurels. Les suites de tests de régressin snt exécutées plusieurs fis et évluent généralement lentement. Dnc les tests de régressin snt de bns candidats à l autmatisatin. Versin 2011 Page 29 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

30 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 2.4 de maintenance (K2) 15 minutes Termes Analyse d impact, tests de maintenance Cntexte Une fis déplyé, un système lgiciel est suvent en service pendant des années, vire des dizaines d années. Pendant ce temps, le système, sn paramétrage et sn envirnnement snt fréquemment crrigés, mdifiés u étendus. La planificatin au plus tôt des livraisns est cruciale pur le succès des tests de maintenance. Une distinctin dit être faite entre les livraisns planifiées et les mises à jur à chaud (ht fixes). Les tests de maintenance snt effectués sur un système pératinnel existant et snt déclenchés par des mdificatins, migratins u suppressin de lgiciels u de systèmes. Les mdificatins incluent les changements dûs aux évlutins planifiées (p.ex. livraisns de nuvelles versins), aux mdificatins crrectives et d urgence, ainsi qu aux changements d envirnnements tels que les mntées en versin planifiées des systèmes d explitatin, des bases de dnnées u des COTS. Elles incluent également les patchs de crrectin des vulnérabilités de sécurité ptentielles u décuvertes d un système d explitatin. Les tests de maintenance lrs de migratins (p.ex. d une plate-frme à une autre) devraient inclure les tests pératinnels du nuvel envirnnement tut cmme les tests des mdificatins du lgiciel. Les tests de migratin (tests de cnversin) snt également nécessaires lrsque les dnnées d une autre applicatin sernt migrées dans le système à maintenir. Les tests de maintenance pur la suppressin (mise au rebut) d un système incluent le test de la migratin des dnnées u leur archivage si de lngues pérides de stckage de dnnées snt nécessaires. En plus des tests des éléments changés, les tests de maintenance incluent des tests de régressin sur les parties du système qui n nt pas été mdifiées. Le périmètre des tests de maintenance est fnctin des risques liés aux mdificatins, à la taille du système existant et à la taille des mdificatins effectuées. Seln le changement, les tests de maintenance peuvent être effectués à chacun u à tus les niveaux de tests et pur certains u tus les types de tests. Déterminer cmment un système existant est affecté par les changements est appelé analyse d impact, et est utilisé pur décider de la quantité de tests de régressin devant être exécutés. L analyse d impacts peut être utilisée pur déterminer les suites de tests de régressin. Les tests de maintenance peuvent être difficiles si les spécificatins snt périmées u manquantes, u si les testeurs ayant la cnnaissance fnctinnelle ne snt pas dispnibles. Références CMMI, Craig, 2002, Hetzel, 1998, IEEE Hetzel, Cpeland, 2004, Myers, Beizer, 1990, Black, 2001, Cpeland, Black, 2001, ISO Beizer, 1990, Cpeland, 2004, Hetzel, Hetzel, 1998, IEEE Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829 Versin 2011 Page 30 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

31 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 3. Techniques Statiques (K2) 60 minutes Objectifs de cnnaissance pur Techniques Statiques Les bjectifs identifient ce que vus serez capable de faire à la suite de chaque mdule. 3.1 Techniques statiques et prcessus de test (K2) LO Recnnaître les livrables qui peuvent être examinés par les différentes techniques statiques. (K1) LO Décrire l imprtance et la valeur de l utilisatin de techniques statiques dans l évaluatin de livrables lgiciels. (K2) LO Expliquer les différences entre les techniques statiques et dynamiques, en cnsidérant les bjectifs, les types de défauts à identifier et le rôle de ces techniques dans le cycle de vie du lgiciel. (K2) 3.2 Prcessus de revue (K2) LO Rappeler les activités, rôles et respnsabilités d une revue frmelle typique. (K1) LO Expliquer les différences entre les différents types de revues: revue infrmelle, revue technique, relecture technique et inspectin. (K2) LO Expliquer les facteurs liés à l exécutin de revues curnnées de succès. (K2) 3.3 Analyse statique utillée (K2) LO Rappeler les défauts et erreurs typiques identifiées par les analyses statiques et les cmparer à ceux détectés par les revues et tests dynamiques. (K1) LO Décrire, en utilisant des exemples, les avantages typiques des analyses statiques. (K2) LO Lister les défauts typiques dans le cde et la cnceptin qui peuvent être identifiés par des utils d analyse statique. (K1) Versin 2011 Page 31 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

32 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 3.1 Techniques statiques et prcessus de test (K2) 15 minutes Termes Test dynamique, test statique. Cntexte Cntrairement au test dynamique, qui exige l exécutin du lgiciel, les techniques de tests statiques repsent sur l examen manuel (revues) u l analyse(analyse statique) du cde u de la dcumentatin du prjet sans exécutin du cde. Les revues snt une manière de tester des prduits lgiciels (y cmpris du cde) et peuvent être exécutées bien avant l exécutin de tests dynamiques. Les défauts détectés pendant les revues effectuées tôt dans le cycle de vie snt suvent bien mins cûteux à ôter que les défauts détectés lrs de l exécutin des tests (p.ex. défauts truvés dans les exigences). Une revue purrait être effectuée entièrement manuellement, mais il existe aussi des utils de supprt. L activité manuelle principale est d examiner le prduit et d en faire des cmmentaires. Tut prduit lgiciel peut être revu, y cmpris les exigences, les spécificatins, les spécificatins de cnceptin, le cde, les plans de test, les spécificatins de test, les cas de test, les scripts de test, les guides utilisateur u pages web. Les bénéfices des revues incluent une détectin et une crrectin anticipées des défauts, des améliratins de prductivité dans le dévelppement, des durées de dévelppement réduites, des durées et des cûts de tests réduits, des réductins de cûts tut au lng de l existence du lgiciel, mins de défauts et une meilleure cmmunicatin. Les revues peuvent détecter des missins, par exemple, dans des exigences, dnt la détectin pendant les tests dynamiques est peu prbable. Les revues, les analyses statiques et les tests dynamiques nt le même bjectif identifier des défauts. Ils snt cmplémentaires : les différentes techniques peuvent truver différents types de défauts efficacement et rapidement. Cntrairement aux tests dynamiques, les techniques statiques truvent les causes des défauts plutôt que les défaillances elles-mêmes. Les défauts typiques plus faciles à truver lrs de revues que pendant les tests dynamiques snt : déviatins par rapprt aux standards, défauts d exigences, défauts de cnceptin, maintenabilité insuffisante et spécificatins incrrectes d interfaces. Versin 2011 Page 32 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

33 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 3.2 Prcessus de revue (K2) 25 minutes Termes Critère d entrée, revue frmelle, revue infrmelle, inspectin, métriques, mdérateur, revue de pairs, réviseur, scribe, revue technique, relecture technique. Cntexte Les différents types de revues varient de «infrmel», caractérisé par l absence d instructins écrites pur les relecteurs, à «systématique», caractérisé par la participatin de l équipe, des résultats dcumentés de la revue, et des prcédures dcumentées pur mener la revue. La frmalité d un prcessus de revue est liée à des facteurs tels que la maturité du prcessus de dévelppement, tute dispsitin légale u exigence réglementaire u la nécessité de traces d audit. La manière dnt une revue est exécutée dépend des bjectifs cnvenus pur la revue (p.ex. truver des défauts, augmenter la cmpréhensin, frmer les testeurs et les nuveaux membres d une équipe u rganiser la discussin et décider par cnsensus) Phases d une revue frmelle (K1) Une revue frmelle typique cmprend les phases principales suivantes: 1. Planificatin : Définir les critères de revues Chisir le persnnel Alluer les rôles Définitin des critères d entrée et de srtie pur des types de revues plus frmels (p.ex., inspectins) Sélectinner la partie des dcuments à revir Vérificatin des critères d entrée (pur des types de revues plus frmels) 2. Lancement: Distribuer les dcuments Expliquer les bjectifs, le prcessus et les dcuments aux participants 3. Préparatin individuelle Préparer la réunin de revue en revyant le(s) dcument(s) Ecriture des défauts ptentiels, questins et cmmentaires 4. Examen/évaluatin/enregistrement des résultats (réunin de revue): Discuter u enregistrer, avec des résultats u minutes dcumentés (pur des types de revues plus frmels) Nter les défauts, faire des recmmandatins cncernant le traitement des défauts, prendre des décisins à prps des défauts Examen/évaluatin et enregistrement pendant tutes les réunins physiques u enregistrement de tutes les cmmunicatins électrniques 5. Re travail Crrectin des défauts détectés (réalisé généralement par l auteur) Enregistrer le statut mdifié des défauts (dans les revues frmelles) 6. Suivi: Vérifier que les défauts nt bien été traités Réclter les métriques Cntrôle sur la base des critères de srties (pur des types de revues plus frmels) Rôles et respnsabilités (K1) Une revue frmelle typique inclura les rôles ci-dessus : Versin 2011 Page 33 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

34 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Manager : décide l exécutin des revues, allue le temps dans la planificatin du prjet et détermine si les bjectifs de revue nt été atteints. Mdérateur: la persnne qui dirige la revue du dcument u de l ensemble des dcuments, incluant la planificatin de la revue, l exécutin de la revue, et le suivi pst-réunin. Si besin, le mdérateur peut servir d intermédiaire entre les différents pints de vue et est suvent la persnne sur qui repse le succès d une revue. Auteur : l auteur u la persnne à qui incmbe la respnsabilité principale du u des dcument(s) à revir. Réviseurs : les individus avec une culture technique u métier spécifique (aussi appelés vérificateurs u inspecteurs) qui, après la préparatin nécessaire, identifient et décrivent les cnstatatins (p.ex. défauts) dans le prduit en curs de revue. Les réviseurs devraient être chisis pur représenter les perspectives et rôles différents dans le prcessus de revue et prennent part à tute réunin de revue. Scribe (u greffier): dcumente tus les aspects, prblèmes et pints uverts identifiés pendant la réunin. En examinant des dcuments seln différentes perspectives, et en utilisant des check-lists, les revues peuvent devenir plus efficaces et rentables, par exemple, une check-list basée sur la perspective d un utilisateur, d un mainteneur, d un testeur u d un pérateur, u une check-list reprenant des prblèmes d exigences typiques Types de revues (K2) Un prduit lgiciel unique u les éléments assciés peuvent être le sujet de plusieurs revues. Si plus d un type de revue est utilisé, l rdre peut varier. Par exemple, une revue infrmelle peut être effectuée avant une revue technique, u une inspectin peut être effectuée sur une spécificatin d exigences, avant une relecture technique avec des clients. Les caractéristiques principales, ptins et bjectifs des types de revues habituelles snt: Revue infrmelle Pas de prcessus frmel; Peut inclure la prgrammatin par paires u une revue de cnceptin et de cde par un respnsable technique; Les résultats peuvent être dcumentés; Peut varier en utilité seln les réviseurs; Objectif principal : manière bn marché d btenir des résultats. Relecture technique Réunin dirigée par l auteur; Peut prendre la frme de scénaris, répétitins à blanc, participatin de grupes de pairs; Sessins sans limite de durée; Optinnellement une réunin de préparatin de revue par les réviseurs Optinnellement préparatin d un rapprt de revue incluant une liste de cnstatatins Optinnellement un scribe (qui n est pas l auteur) ; Varie en pratique de quasiment infrmel à très frmel; Objectifs principaux: apprendre, gagner en cmpréhensin, truver des défauts. Revue technique Dcumentée, prcessus de détectin de défauts défini incluant des pairs et des experts techniques avec ptinnellement la participatin de l encadrement; Peut être effectuée cmme une revue de pairs sans participatin de l encadrement; Idéalement dirigée par un mdérateur frmé (pas l auteur); Réunin de préparatin par les réviseurs; Peut ptinnellement utiliser des check-lists ; Versin 2011 Page 34 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

35 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Préparatin d un rapprt de revue incluant la liste de cnstatatins, le verdict indiquant si le prduit lgiciel répnd à ses exigences et, si apprprié, des recmmandatins relatives aux cnstatatins ; Peut varier en pratique de quasiment infrmelle à très frmelle; Objectifs principaux: discuter, décider, évaluer des alternatives, truver des défauts, résudre des prblèmes techniques et vérifier la cnfrmité aux spécificatins, plans, réglementatins et standards. Inspectin Dirigée par un mdérateur frmé (pas l auteur); Généralement menée cmme un examen par les pairs; Rôles définis; Inclut des métriques ; Prcessus frmel basé sur des règles et des check-lists ; Critères d entrée et de srtie spécifiés pur l acceptatin du prduit lgiciel ; Réunin de préparatin; Rapprt d inspectin incluant la liste de cnstatatins; Prcessus frmel de suivi (inclut le prcessus facultatif d améliratin des cmpsants); Lecteur (facultatif); Objectif principal: truver des défauts. Les relectures techniques, les revues techniques et les inspectins peuvent être réalisées au sein d un grupe de pairs, càd. des cllègues ayant le même niveau dans l rganisatin. Ce type de revue est appelé revue de pairs Facteurs de succès des revues (K2) Les facteurs de succès des revues incluent: Chaque revue a des bjectifs prédéfinis et clairs. Les persnnes impliquées snt adéquates pur les bjectifs de la revue. Les testeurs snt des réviseurs de valeur qui cntribuent à la revue et ainsi prennent cnnaissance du prduit afin de puvir préparer les tests plus tôt. Les défauts truvés snt bien acceptés, et exprimés bjectivement. Les aspects persnnels et psychlgiques snt traités (p.ex. en faisant de cela une expérience psitive pur l auteur)). La revue est menée dans une atmsphère de cnfiance ; les résultats ne snt pas utilisés pur évaluer les participants ; Les techniques de revue adaptées aux bjectifs, adaptées aux types et au niveau de livrable lgiciel, et adaptées aux types et niveau des réviseurs, snt appliquées. Des check-lists u des rôles snt utilisés lrsque cela est apprprié, afin d augmenter l efficacité de détectin des défauts. Des frmatins snt dnnées sur les techniques de revue, en particulier celles cncernant les techniques plus frmelles telles que les inspectins. L encadrement supprte un bn prcessus de revue (p.ex. en incrprant du temps pur les activités de revue dans les plannings des prjets). L accent est mis sur l apprentissage et l améliratin du prcessus. Versin 2011 Page 35 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

36 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 3.3 Analyse statique avec des utils (K2) 20 minutes Termes Cmpilateur, cmplexité, flux de cntrôle, flux de dnnées, analyse statique. Cntexte L bjectif de l analyse statique est de truver des défauts dans le cde surce et les mdèles lgiciels. L analyse statique est effectuée sans vraiment exécuter le cde examiné par l util ; les tests dynamiques exécutent le cde lgiciel. L analyse statique peut détecter des défauts qui snt difficiles à truver par les tests dynamiques. Cmme pur les revues, l analyse statique truve des défauts plutôt que des défaillances. Les utils d analyse statique analysent le cde du prgramme (p.ex. les flux de cntrôle et les flux de dnnées), ainsi que les srties générées telles que HTML et/u XML. La valeur des tests statiques est : La détectin très tôt de défauts avant l exécutin des tests. Une infrmatin très tôt sur certains aspects suspects du cde u de la cnceptin, par le calcul de métriques, par exemple une mesure de cmplexité élevée. L identificatin de défauts difficilement détectables par des tests dynamiques. La détectin de dépendances et d incnsistances dans les mdèles lgiciels tels que des liens dans les mdèles lgiciels L améliratin de la maintenabilité du cde et de la cnceptin. La préventin des défauts, si les leçns snt prises en cmpte lrs du dévelppement. Les défauts typiques décuverts par des utils d analyse statique incluent : Référencement d une variable avec une valeur indéfinie; Interface incnsistante entre mdules et cmpsants; Variables qui ne snt jamais utilisées u déclarées de façn incrrecte; Cde nn accessible (cde mrt); Lgique absente et errnée (ptentiellement des bucles infinies) ; Cnstructins trp cmpliquées ; Vilatin des standards de prgrammatin; Vulnérabilités de sécurité; Vilatin de syntaxe dans le cde et les mdèles lgiciels. Les utils d analyse statique snt typiquement utilisés par des dévelppeurs (vérificatin par rapprt à des règles prédéfinies u des standards de prgrammatin) avant et pendant les tests de cmpsants et les tests d intégratin, u pendant la mise à jur du cde dans les utils de gestin de cnfiguratin, et par les cncepteurs pendant la mdélisatin lgicielle. Les utils d analyse statique peuvent prduire un nmbre imprtant de messages d avertissement qui divent être gérés cnvenablement afin de permettre une utilisatin ptimale de l util. Les cmpilateurs peuvent ffrir un certain supprt aux analyses statiques, ntamment en incluant le calcul de métriques. Références 3.2 IEEE Gilb, 1993, van Veenendaal, Gilb, 1993, IEEE van Veenendaal, 2004 Versin 2011 Page 36 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

37 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 4. Techniques de Cnceptin de (K3) 255 minutes Objectifs de cnnaissance pur Techniques de Cnceptin de Les bjectifs identifient les capacités que vus aurez à la fin de chaque mdule. 4.1 Le prcessus de dévelppement de test (K3) LO Différencier la spécificatin de cnceptin de test de la spécificatin des cas de test et des spécificatins de prcédures de test. (K2) LO Cmparer les termes : cnditin de test, cas de test et prcédure de test. (K2) LO Evaluer la qualité des cas de test en terme de traçabilité vers les exigences et les résultats attendus (K2) LO Traduire les cas de test en des spécificatins de prcédures de tests crrectement structurées avec le niveau de détail adéquat par rapprt au niveau de cnnaissance des testeurs. (K3) 4.2 Catégries de techniques de cnceptin de tests (K2) LO Rappeler les raisns pur lesquelles les apprches basées sur les spécificatins (bîtenire) et celles basées sur les structures (bîte blanche) snt utiles, et lister les techniques habituelles pur chacune d entre elles. (K1) LO Expliquer les caractéristiques, les pints cmmuns et différences entre les tests basés sur les spécificatins, les tests basés sur les structures et les tests basés sur l expérience. (K2) 4.3 Techniques basées sur les spécificatins u bîte nire (K3) LO Ecrire les cas de test pur un mdèle lgiciel dnné en utilisant les partitins d équivalence, l analyse des valeurs limites, les tables de décisin et les diagrammes/tables de transitin d états (K3) LO Expliquer les bjectifs principaux de chacune des quatre techniques, quel niveau et type de test peut utiliser la technique, et cmment la cuverture peut être mesurée. (K2) LO Expliquer les cncepts des tests basés sur les cas d utilisatin et ses avantages. (K2) 4.4 Techniques basées sur la structure u bîte blanche (K3) LO Décrire le cncept et l imprtance de la cuverture du cde. (K2) LO Expliquer les cncepts de cuverture des instructins et des décisins, et dnner les raisns pur lesquelles ces cncepts peuvent aussi être utilisés pur d autres niveaux de tests que les tests de cmpsants (p.ex. sur les prcédures métier au niveau système). (K2) LO Ecrire les cas de test à partir des dnnées du flux de cntrôle en utilisant les techniques de cnceptin de tests de cuverture des instructins et cuverture des décisins. (K3) LO Evaluer la cmplétude des cuvertures d instructins et des décisins en respectant les critères de srtie définis. (K4) 4.5 Techniques basées sur l expérience (K2) LO Rappeler les raisns justifiant l écriture des cas de test basés sur l intuitin, l expérience et la cnnaissance des défauts cmmuns. (K1) LO Cmparer les techniques basées sur l expérience avec les techniques basées sur les spécificatins. (K2) 4.6 Sélectinner les techniques de test (K2) LO Classer les techniques de cnceptin de tests en fnctin de leur adaptatin à un cntexte dnné, pur la base de tests, les caractéristiques respectives aux mdèles et au lgiciel. (K2) Versin 2011 Page 37 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

38 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 4.1 Le prcessus de dévelppement de test (K3) 15 minutes Termes Spécificatin de cas de test, cnceptin de tests, rdnnancement de l exécutin de tests, spécificatin des prcédures de test, script de test, traçabilité. Cntexte Le prcessus de dévelppement de test décrit dans cette sectin peut être effectué de diverses manières, de «très infrmelles» avec peu u pas de dcumentatin, à «très frmelles» (cmme décrit dans cette sectin). Le niveau de frmalisme dépend du cntexte des tests incluant la maturité des tests et des prcessus de dévelppement, des cntraintes de temps, des exigences de sureté de fnctinnement u réglementaires et des persnnes impliquées. Pendant l analyse de cnceptin des tests, la dcumentatin de la base des tests est analysée de façn à déterminer ce qui est à tester, c est à dire à identifier les cnditins de test. Une cnditin de test est définie cmme un article u événement qui peut être vérifié par un u plusieurs cas de test (p.ex. une fnctin, transactin, caractéristique qualité u élément structurel). Etablir la traçabilité des cnditins de tests vers les spécificatins et exigences permet à la fis l analyse d impact, quand les exigences changent, et une cuverture des exigences à définir pur un ensemble de tests. Pendant l analyse de cnceptin des tests, les apprches détaillées de tests snt implémentées pur sélectinner des techniques de tests basées sur, entre autres cnsidératins, les risques identifiés (vir Chapitre 5 pur plus d infrmatins sur les analyses de risques). Pendant la cnceptin des tests, les cas de test et dnnées de test snt créés et spécifiés. Un cas de test se cmpse d un ensemble de valeurs d entrée, de pré-cnditins d exécutin, de résultats attendus et de pst-cnditins d exécutin, cnçu pur cuvrir certains bjectifs de tests et cnditins de tests. Le Standard pur la Dcumentatin de Lgiciel ( Standard fr Sftware Test Dcumentatin IEEE ) décrit le cntenu des spécificatins de cnceptin de tests (cntenant les cnditins de test) et des spécificatins des cas de test. Les résultats attendus devraient être prduits cmme faisant partie des spécificatins de cas de test et inclure les srties, mdificatins de dnnées et d états, et tute autre cnséquence du test. Si des résultats attendus n nt pas été définis alrs un résultat plausible mais errné peut être interprété cmme un résultat crrect. Les résultats attendus devraient idéalement être définis avant l exécutin des tests. Pendant l implémentatin des tests, les cas de test snt dévelppés, implémentés, pririsés et rganisés dans la spécificatin de prcédure de test (IEEE STD ). La prcédure de tests spécifie la séquence des actins pur l exécutin d un test. Si les tests snt exécutés avec un util d exécutin des tests, la séquence d actins est spécifiée dans un script de tests (qui est une prcédure de test autmatisée). Les diverses prcédures de tests et scripts de tests autmatisés snt ensuite cnslidées en un planning d exécutin de tests qui définit l rdre dans lequel les diverses prcédures de test, et ptentiellement les scripts de tests autmatisés, snt exécutés. Les plannings d exécutin des tests prendrnt en cmpte les facteurs tels que les tests de régressin, de pririsatin, et de dépendances technique et lgique. Versin 2011 Page 38 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

39 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 4.2 Catégries de techniques de cnceptin de tests (K2) 15 minutes Termes Technique de cnceptin bîte nire, technique de cnceptin basée sur l expérience, technique de cnceptin de test, technique bîte blanche. Cntexte L bjectif de la technique de cnceptin des tests est d identifier les cnditins de tests, les cas de test et les dnnées de tests. Il est fréquent de faire la distinctin entre les techniques de tests bîte blanche et les techniques de test bîte nire. Les techniques de cnceptin bîte nire (aussi appelées techniques basées sur les spécificatins) snt une façn de dériver et de sélectinner les cnditins de tests, les cas de test u les dnnées de test en se basant sur une analyse de la dcumentatin de la base des tests. Ceci inclut les tests fnctinnels et nn fnctinnels. Le test bîte nire, par définitin, n utilise aucune infrmatin cncernant la structure interne d un cmpsant u système à tester. Les techniques de cnceptin bîte blanche (aussi dites techniques structurelles u basées sur les structures) snt basées sur une analyse de la structure du cmpsant u du système. Les tests bîte nire et bîte blanche peuvent aussi être cmbinés avec des techniques s inspirant de l expérience des dévelppeurs, des testeurs et des utilisateurs pur déterminer ce qui dit être testé. Quelques techniques se retruvent dans une seule catégrie, d autres cmprennent des éléments de plus d une catégrie. Ce syllabus référence cmme techniques bîte nire les apprches basées sur les spécificatins, et référence cmme techniques bîte blanche les apprches basées sur les structures. De plus, les techniques de cnceptin basées sur l expérience snt cuvertes. Caractéristiques habituelles des techniques de cnceptin basées sur les spécificatins: Les mdèles, sit frmels sit infrmels, snt utilisés pur la spécificatin des prblèmes à résudre, des lgiciels u des cmpsants. Depuis ces mdèles les cas de test snt dérivés de façn systématique. Caractéristiques habituelles des techniques de cnceptin basées sur la structure: L infrmatin sur la manière dnt le lgiciel est cnstruit est utilisée pur dériver les cas de test (par exemple, le cde et les infrmatins de cnceptin détaillée). Le niveau de cuverture du lgiciel peut être mesuré à partir de cas de test existants, et des cas de test cmplémentaires peuvent être dérivés de façn systématique pur augmenter la cuverture. Caractéristiques habituelles des techniques de cnceptin basées sur l expérience: La cnnaissance et l expérience des persnnes snt utilisées pur dériver les cas de test. La cnnaissance des testeurs, dévelppeurs, utilisateurs et autres parties prenantes cncernant le lgiciel, sn utilisatin et sn envirnnement snt autant de surces d infrmatin; La cnnaissance des défauts pssibles et de leur distributin est une autre surce d infrmatin. Versin 2011 Page 39 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

40 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 4.3 Techniques basées sur les spécificatins u techniques bîte nire (K3) 120 minutes Termes Analyse des valeurs limites, tests par tables de décisins, partitins d équivalence, tests de transitin d états, tests de cas d utilisatin Partitins d équivalence (K3) Pur les partitins d équivalence, les entrées d un lgiciel u système snt divisées en grupes qui divent mntrer un cmprtement similaire, de ce fait elles aurnt un traitement identique. Les partitins (u classes) d équivalence peuvent être truvées pur des dnnées valides, c est-à-dire des dnnées qui devraient être acceptées et des dnnées invalides, c est-à-dire des valeurs qui devraient être rejetées. Les partitins peuvent aussi être identifiées pur les srties, les valeurs internes, les valeurs liées au temps (p.ex. avant u après un événement) et pur les paramètres d interface (p.ex. cmpsants intégrés en curs de test pendant les tests d intégratin). Des tests peuvent être cnçus pur cuvrir tutes les partitins valides et invalides. Les partitins d équivalence snt applicables à tus les niveaux de tests. Les partitins d équivalence peuvent être utilisées pur atteindre des bjectifs de cuverture d entrées et de srties. Elles peuvent être appliquées aux entrées humaines, aux entrées via l interface du système, u aux paramètres d interface des tests d intégratin Analyse des valeurs limites (K3) Le cmprtement au brd de chaque partitin d équivalence risque plus d être incrrect qu à l intérieur, dnc les limites snt des znes plus prpices pur décuvrir des défauts. Les valeurs maximum et minimum d une partitin snt ses valeurs limites. Une valeur limite pur une partitin valide est une valeur limite valide; la limite d une partitin invalide est une valeur limite invalide. Des tests peuvent être cnçus pur cuvrir les valeurs limites valides et invalides. Quand n cnçit des cas de test, une valeur de chaque limite est sélectinnée pur un test. L analyse des valeurs limites peut être appliquée à tus les niveaux de tests. C est relativement aisé à appliquer et la capacité de détectin de défauts est élevée. Des spécificatins détaillées snt utiles pur déterminer les limites intéressantes. Cette technique est suvent cnsidérée cmme une extensin des partitins d équivalences u autre technique de cnceptin bîte nire. Elle peut être utilisée pur les classes d équivalence aussi bien sur les dnnées d entrées humaines u écran, par exemple, que sur des limites de temps (par exemple, le time ut, les exigences de rapidité de transactins) u sur des limites de tableaux (par exemple, une taille de tableau de 256*256) par tables de décisins (K3) Les tables de décisins snt une bnne façn de capturer des exigences système cntenant des cnditins lgiques, et pur dcumenter la cnceptin système interne. Elles peuvent être utilisées pur enregistrer les règles de gestin cmplexes que dit implémenter un système. Lrs de la créatin des tables de décisins, la spécificatin est analysée, et les actins et cnditins du système snt identifiées. Les cnditins d entrée et les actins snt suvent décrites de façn à ce qu elles peuvent être sit vraies sit fausses (Bléen). Les tables de décisin cntiennent les cnditins de déclenchement, suvent des cmbinaisns de vrais et faux pur tutes les cnditins d entrée, et sur les actins résultantes pur chaque cmbinaisn de cnditins. Chaque clnne de la table crrespnd à une règle de gestin qui définit une cmbinaisn unique de cnditins qui résultent en l exécutin de l actin assciée à cette règle. La cuverture standard généralement utilisée avec les tables de décisins est d avir au mins un test par clnne, ce qui implique typiquement de cuvrir tutes les cmbinaisns de cnditins de déclenchement. Versin 2011 Page 40 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

41 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard La frce des tests par les tables de décisins est la créatin de cmbinaisns de cnditins qui autrement n auraient pas été traitées pendant les tests. Cela peut être appliqué à tutes les situatins quand l actin du lgiciel dépend de plusieurs décisins lgiques Test de transitin d états (K3) Un système peut mntrer plusieurs répnses différentes en fnctin des cnditins actuelles u passées (sn état). Dans ce cas, cet aspect du système peut être mntré par un diagramme d états et de transitins. Cela permet au testeur de visualiser le lgiciel en termes d états, de transitins entre les états, de dnnées d entrées u des événements qui déclenchent des changements d état (transitins) et des actins qui peuvent résulter de ces transitins. Les états du système u de l bjet sus test snt séparées, identifiables et en nmbre fini. Une table des états mntre la relatin entre les états et les entrées, et peut mettre en lumière des transitins pssibles invalides. Des tests peuvent être cnçus pur cuvrir une séquence typique d états, pur cuvrir chaque état, pur exécuter tutes les transitins, pur exécuter une séquence spécifique de transitins u tester des transitins invalides. Les tests de transitins d états snt fréquemment utilisés dans l industrie du lgiciel embarqué et généralement dans l autmatisatin technique. Cependant, la technique est aussi utilisable pur mdéliser les bjets métier pssédant des états spécifiques u pur tester les dialgues d interfaces écran (p.ex. pur les applicatins Internet u les scénaris métier) de cas d utilisatin (K2) Les tests peuvent être spécifiés à partir de cas d utilisatin. Un cas d utilisatin décrit l interactin entre acteurs ( utilisateurs et système), qui prduit un résultat ayant une valeur pur l utilisateur du système u le client. Les cas d utilisatin peuvent être décrits à un niveau abstrait (cas d utilisatin métier, indépendant de la technlgie, niveau prcessus métier). Chaque cas d utilisatin a des pré-cnditins, qui divent être atteintes pur que ce cas d utilisatin sit exécuté avec succès. Chaque cas d utilisatin se termine par des pst-cnditins, qui snt les résultats bservables et l état final du système après la fin de l exécutin du cas d utilisatin. Un cas d utilisatin a généralement un scénari dminant (c est à dire le plus plausible), et parfis des scénaris alternatifs. Les cas d utilisatin décrivent les flux du prcessus dans un système, basé sur une utilisatin prbable, dnc les cas de test dérivés des cas d utilisatin snt extrêmement utiles pur décuvrir les défauts dans le flux de traitement pendant l utilisatin réelle du système. Les cas d utilisatin, suvent appelés scénaris, snt très utiles pur cncevir des tests d acceptatin avec la participatin du client/utilisateur. Ils permettent aussi de décuvrir des défauts d intégratin causés par l interactin et les interférences entre divers cmpsants, ce que ne décuvrent pas les tests individuels de cmpsants. La cnceptin de cas de test à partir des cas d utilisatin peut être cmbinée avec d autres techniques de tests basées sur les spécificatins. Versin 2011 Page 41 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

42 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 4.4 Technique de cnceptin basée sur la structure u technique de cnceptin bîte blanche (K3) 60 minutes Termes Cuverture de cde, cuverture des décisins, cuverture des instructins, tests structurels. Cntexte Les tests basés sur la structure u tests bîte blanche suivent la structure identifiée du lgiciel u du système, cmme décrit dans les exemples suivants: Niveau cmpsant: la structure d un cmpsant lgiciel c est à dire instructins, décisins, branches u même des chemins distincts Niveau intégratin: la structure peut être un arbre (u graphe) d appel (un diagramme ù des mdules appellent d autres mdules). Niveau système: la structure peut être une structure de menus, des prcessus métier u la structure d une page web. Dans cette sectin, tris techniques structurelles liées à la cuverture du cde, prtant sur les instructins et les décisins, snt discutées. Pur les tests des décisins, un diagramme de cntrôle de flux peut être utilisé pur visualiser les alternatives de chaque décisin Test des instructins et cuverture (K3) Dans les tests de cmpsants, la cuverture des instructins est l évaluatin du purcentage d instructins exécutables qui nt été exercées par une suite de cas de test. Le test des instructins dérive des cas de test pur exécuter des instructins spécifiques, généralement pur accrître la cuverture des instructins. La cuverture des instructins est déterminée par le nmbre d instructins exécutables cuvertes par des cas de test (cnçus u exécutés) divisé par le nmbre de tutes les instructins exécutables dans le cde testé Test des décisins et cuverture (K3) La cuverture des décisins, liées aux tests de branches, est l évaluatin des purcentages de résultats de décisins (p.ex. les ptins Vrai et Faux d une instructin IF) qui nt été traitées par une suite de cas de test. Les cas de test prvenant des tests de décisins snt amenés à exécuter des résultats de décisins spécifiques. Les branches truvent leur rigine dans les pints de décisin du cde et mntrent le transfert du cntrôle vers différents endrits du cde. La cuverture des décisins est déterminée par le nmbre de tus les résultats des décisins cuvertes par des cas de test (cnçus u exécutés) divisé par le nmbre de tus les résultats pssibles des décisins dans le cde sus test. Les tests de décisins snt une frme de cntrôle de flux car ils génèrent un flux spécifique de cntrôle entre des pints de décisins. La cuverture des décisins est supérieure à la cuverture des instructins: une cuverture de 100% des décisins garantit une cuverture à 100% des instructins, mais l inverse n est pas vrai Autres techniques basées sur les structures (K1) Il existe des niveaux de cuverture structurelle plus frts que les cuvertures de décisins, par exemple les cuvertures de cnditins et les cuvertures de cnditins multiples. Versin 2011 Page 42 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

43 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Le cncept de cuverture peut aussi être appliqué aux autres niveaux de tests. Par exemple, au niveau intégratin, le purcentage des mdules, cmpsants u classes qui nt été exercées par une suite de cas de test peut être exprimé cmme une cuverture de mdules, cmpsants u classes. L aide via des utils est utile pur le test structurel de cde. Versin 2011 Page 43 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

44 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 4.5 Techniques basées sur l expérience (K2) 30 minutes Termes explratires, (faute) attaque. Cntexte Le test basé sur l expérience a lieu lrsque les tests snt cnçus à partir des cmpétences des testeurs, de leur intuitin et de leur expérience avec des applicatins et technlgies similaires. Quand ils snt utilisés pur amélirer les techniques systématiques, les tests intuitifs peuvent être utiles pur identifier des tests spéciaux, difficilement atteints par des apprches frmelles. Cependant, cette technique peut dnner des degrés d efficacité extrêmement différents, seln l expérience des testeurs. Une technique basée sur l expérience cmmunément utilisée est l estimatin d erreur. Généralement, les testeurs anticipent les défauts basés sur l expérience. Une apprche structurée pur la technique d estimatin d erreurs est d énumérer une liste des défauts pssibles et de cncevir des tests pur mettre en évidence ces défauts. Cette apprche systématique est appelée «attaque par faute». Ces listes de défauts et de défaillances peuvent être cnstruites sur la base de l expérience, des dnnées dispnibles sur les défauts et anmalies, et de la cnnaissance cmmune sur les causes de défaillances. Les tests explratires cmprennent la cnceptin et l exécutin des tests, l écriture des résultats de tests et l apprentissage (de l applicatin), basés sur une charte de tests cntenant les bjectifs de tests, et effectués dans des pérides de temps délimitées. C est l apprche la plus utile pur augmenter u cmpléter d autres méthdes de tests plus frmelles lrsque les spécificatins snt rares u nn adéquates, et que le test est sumis à de sévères cntraintes de temps. Cela peut servir cmme vérificatin de prcessus de tests, pur s assurer que les défauts les plus sérieux snt truvés. Versin 2011 Page 44 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

45 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 4.6 Sélectinner les techniques de tests (K2) 15 minutes Termes Pas de terme spécifique. Cntexte Le chix des techniques de tests à utiliser dépend de différents facteurs incluant le type de système, les standards réglementaires, les exigences client u cntractuelles, le niveau de risque, le type de risque, les bjectifs de test, la dcumentatin dispnible, la cnnaissance des testeurs, le temps dispnible et le budget, le cycle de vie de dévelppement utilisé, les mdèles de cas d utilisatin et l expérience sur les défauts décuverts précédemment. Quelques techniques snt plus applicables que d autres à certaines situatins et niveaux de tests, d autres snt applicables à tus les niveaux de tests. Lrs de la créatin de cas de test, les testeurs utilisent généralement une cmbinaisn de techniques de tests incluant les techniques rientées prcessus, règles et dnnées pur assurer une cuverture adéquate de l bjet testé. Références 4.1 Craig, 2002, Hetzel, 1998, IEEE Beizer, 1990, Cpeland, Cpeland, 2004, Myers, Cpeland, 2004, Myers, Beizer, 1990, Cpeland, Beizer, 1990, Cpeland, Cpeland, Beizer, 1990, Cpeland, Kaner, Beizer, 1990, Cpeland, 2004 Versin 2011 Page 45 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

46 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 5. Gestin des (K3) 170 minutes Objectifs de cnnaissance pur la gestin des tests Les bjectifs identifient les capacités que vus aurez à la fin de chaque mdule 5.1 Organisatin des tests (K2) LO Recnnaître l imprtance du test indépendant. (K1) LO Énumérer les avantages et incnvénients du test indépendant pur une rganisatin. (K2) LO Recnnaître les différents membres d une équipe à envisager lrs de la frmatin d une équipe de test. (K1) LO Rappeler les tâches typiques d un respnsable de test et d un testeur. (K1) 5.2 Estimatin et planificatin du test (K3) LO Recnnaître les différents niveaux et bjectifs de la planificatin du test. (K1) LO Résumer le but et le cntenu des dcuments plan de test, cnceptin de tests, spécificatin de tests et prcédure de test suivant le guide «Standard fr Sftware Test Dcumentatin» (IEEE 829). (K2) LO Faire la différence entre des apprches de test cnceptuellement différentes, telles que des apprches analytiques; basées sur des mdèles; méthdiques à des fins de cmpatibilité avec un prcessus u un standard; dynamique/heuristique; cnsultative et visant à empêcher la régressin. (K2) LO Faire la différence entre la planificatin des tests pur un système et l rdnnancement de l exécutin des tests. (K2) LO Ecrire un calendrier d exécutin des tests pur une série de cas de test dnnés en tenant cmpte des prirités ainsi que des dépendances lgiques et techniques (K3) LO Lister les activités de préparatin et d exécutin des tests qui divent être prises en cmpte lrs de la planificatin des tests (K1) LO Rappeler les facteurs typiques qui influencent l effrt de test (K1) LO Faire la différence entre deux apprches d estimatin cnceptuellement différentes : l apprche basée sur des mesures et l apprche basée sur l expertise. (K2) LO Recnnaître et justifier les critères de début et de fin de test apprpriés à des niveaux de test spécifiques et des grupes de cas de test (par exemple, test d intégratin, test de recette u cas de test pur un test d utilisabilité). (K2) 5.3 Suivre et cntrôler le dérulement du test (K2) LO LO LO Rappeler les mesures habituelles utilisées pur suivre la préparatin et l exécutin du test (K1) Cmprendre et interpréter les mesures de test pur la dcumentatin et le cntrôle du test (par exemple, les défauts truvés et crrigés, les tests réussis et défaillants) en fnctin du cntexte (K2) Résumer le but et le cntenu du rapprt de synthèse établi seln le guide «Standard fr Sftware Test Dcumentatin» (IEEE Std ) (K2) 5.4 Gestin de cnfiguratin (K2) LO Résumer la manière dnt la gestin de cnfiguratin assiste le test. (K2) 5.5 Test et risques (K2) LO LO Décrire un risque cmme un prblème prbable qui peut cmprmettre l atteinte des bjectifs de prjet d un u de plusieurs acteurs (K2) Se rappeler que le niveau de risque est déterminé par sa prbabilité (d ccurrence) et sn impact (dmmages en résultant) (K1) Versin 2011 Page 46 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

47 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard LO LO LO Distinguer entre les risques liés au prjet et ceux liés au prduit (K2) Recnnaître les risques typiques du prduit et du prjet (K1) Décrire, avec l appui d exemples, cmment utiliser l analyse et la gestin de risques pur la planificatin du test (K2) 5.6 Gestin d incidents (K3) LO LO Recnnaître le cntenu du rapprt d incident établi seln le guide «Standard fr Sftware Test Dcumentatin» (IEEE Std ) (K1) Rédiger un rapprt d incident cuvrant l bservatin d une défaillance pendant le test. (K3) Versin 2011 Page 47 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

48 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 5.1 Organisatin des tests (K2) 30 minutes Termes Testeur, respnsable du test, gestinnaire du test Organisatin du test et indépendance (K2) L efficacité de la décuverte d anmalies par le test et les revues peut être amélirée par l empli de testeurs indépendants. Les ptins pur l indépendance snt les suivantes : Pas de testeurs indépendants, dévelppeurs testant leur prpre cde Testeurs indépendants incrprés à l équipe de dévelppement. Équipe u grupe de test indépendant au sein de l rganisatin, qui réfère au gestinnaire du prjet u aux respnsables décisinnaires. Testeurs indépendants de l rganisatin, de la cmmunauté des utilisateurs et de l Infrmatique. Spécialistes de test indépendants pur des bjectifs spécifiques de test tels que des tests d utilisabilité, de sécurité infrmatique u de certificatin (qui certifient un prduit lgiciel par rapprt à des nrmes u réglementatins). Testeurs indépendants externes à l rganisatin Pur des prjets de grande taille, cmplexes u présentant un niveau de sécurité critique, il est habituellement préférable d avir plusieurs niveaux de tests, dnt certains u tus snt traités par des testeurs indépendants. L équipe de dévelppement peut prendre part aux tests, plus spécialement aux plus bas niveaux, mais sn manque d bjectivité limite sn efficacité. Les testeurs indépendants peuvent avir l autrité pur exiger et définir des prcessus et règles, mais les testeurs ne devraient accepter ce rôle tuchant aux prcessus qu en présence d un mandat clair du management. Les avantages de l indépendance cmprennent les suivants : Des testeurs indépendants vient des défauts différents et d une autre nature et snt impartiaux. Un testeur indépendant peut vérifier les hypthèses faites pendant la spécificatin et l implémentatin du système. Les incnvénients cmprennent les suivants : Décnnexin vis-à-vis de l équipe de dévelppement (en cas de ttale indépendance). Les dévelppeurs perdent le sens de la respnsabilité pur la qualité. Des testeurs indépendants peuvent cnstituer un gulet d étranglement cmme dernier pint de vérificatin et être accusés des retards. Les tâches de test peuvent être exécutées par des persnnes juant un rôle spécifique du test, mais aussi par quelqu un exerçant un autre rôle, cmme le respnsable de prjet, le gestinnaire de la qualité, un dévelppeur, un expert métier u dmaine, infrastructure u explitatin de l infrmatique Tâches du respnsable des tests et des testeurs (K1) Deux fnctins snt abrdées dans ce syllabus, celles du respnsable du test et du testeur. Les activités et tâches accmplies par des persnnes dans ces deux rôles dépendent du cntexte du prduit et du prjet, ainsi que des persnnes juant ces rôles et de l rganisatin. Versin 2011 Page 48 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

49 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Parfis, le respnsable de test est appelé gestinnaire de test u crdinateur de test. Ce rôle peut être rempli par un chef de prjet, un respnsable de dévelppement, un respnsable de la qualité u un respnsable d un grupe de test. Typiquement, le respnsable de test planifie, surveille et cntrôle les activités et tâches de test définies dans la sectin 1.4. Les tâches habituelles du respnsable de test peuvent cmprendre les suivantes : Crdnner la stratégie et le plan du test avec le chef de prjet et d autres acteurs. Établir u réviser une stratégie de test pur le prjet ainsi qu une plitique de test pur l rganisatin. Apprter le pint de vue du test aux autres activités du prjet, cmme la planificatin de l intégratin. Planifier les tests en cnsidérant le cntexte et en cmprenant les bjectifs et les risques y cmpris la sélectin des apprches de test, l estimatin du temps, de l effrt et des cûts du test, l acquisitin des ressurces, la définitin des niveaux de test, les cycles, l apprche et les bjectifs ainsi que la planificatin de la gestin d incidents; Démarrer la spécificatin, la préparatin, l implémentatin et l exécutin des tests ainsi que surveiller et cntrôler l exécutin. Adapter le planning en fnctin des résultats et de l avancement du test (parfis dcumenté dans un rapprt d état d avancement) et entreprendre les actins nécessaires pur résudre les prblèmes Mettre en place une gestin de cnfiguratin adéquate du lgiciel de test à des fins de traçabilité. Intrduire des mesures apprpriées pur mesurer l avancement du test et évaluer la qualité du test et du prduit Décider ce qui devrait être autmatisé, à quel degré et cmment. Sélectinner les utils pur aider le test et rganiser la frmatin des testeurs à l usage des utils. Décider de la mise en œuvre de l envirnnement de test. Établir des rapprts de synthèse de test à partir des infrmatins recueillies pendant le test. Les tâches habituelles des testeurs peuvent cmprendre les suivantes : Passer en revue les plans du test et y cntribuer. Analyser, passer en revue et évaluer, quant à leur testabilité, les exigences utilisateurs, les spécificatins et les mdèles. Créer des spécificatins de test. Mettre en place l envirnnement de test (suvent en crdinatin avec l administratin système et la gestin de réseau). Préparer et btenir les dnnées de test. Implémenter des tests à tus les niveaux, exécuter et cnsigner les tests, évaluer les résultats et dcumenter les écarts vis-à-vis des résultats attendus. Emplyer les utils d administratin u de gestin des tests et les utils de surveillance des tests en fnctin du besin. Autmatiser les tests (éventuellement avec l aide d un dévelppeur u d un expert en autmatisatin de test). Mesurer les perfrmances des cmpsants et systèmes (si pertinent). Passer en revue les tests dévelppés par d autres. Les persnnes travaillant sur l analyse, la cnceptin des tests, sur des types de tests spécifiques u l autmatisatin des tests peuvent être des spécialistes de ces rôles. Seln le niveau de test et les risques du prjet ainsi que ceux du prduit, des persnnes différentes peuvent juer le rôle de testeur, en gardant un certain niveau d indépendance. Typiquement, les testeurs au niveau du test de cmpsants et d intégratin sernt des dévelppeurs, ceux du test d acceptatin sernt des experts métier et des utilisateurs et ceux pur l acceptatin pératinnelle sernt des pérateurs. Versin 2011 Page 49 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

50 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 5.2 Estimatin et planificatin des tests (K3) 40 minutes Termes Apprche de test, stratégie de test Planificatin des tests (K2) Cette sectin cuvre l bjectif de la planificatin du test dans des prjets de dévelppement et d implémentatin ainsi que pur des activités de maintenance. La planificatin peut être dcumentée dans un plan de prjet u un plan de test maître ainsi que dans des plans de test séparés pur les niveaux de test, tels que le test système u le test d acceptatin. Le schéma des dcuments de planificatin de test est défini dans le guide «Standard fr Sftware Test Dcumentatin» (IEEE Std ). La planificatin est influencée par la plitique de test de l rganisatin, la prtée du test, les bjectifs, les risques, les cntraintes, la criticité, la testabilité et la dispnibilité des ressurces. Au fur et à mesure de l avancement du prjet et de la planificatin des tests, davantage d infrmatins sernt dispnibles et davantage de détails purrnt être inclus dans le plan. La planificatin du test est une activité cntinue et est effectuée tut au lng des prcessus et activités du cycle de dévelppement. Le retur issu des activités de test est emplyé pur cnstater l évlutin des risques et mdifier alrs la planificatin Activités de planificatin des tests (K3) Les activités de la planificatin des tests pur un système u pur une partie de celui-ci peuvent être: Définir le périmètre du test, les risques et identifier les bjectifs du test Définir l apprche générale du test (stratégie de test), y cmpris la définitin des niveaux de test ainsi que celle des critères d entrée et de srtie. Intégrer et crdnner des activités de test dans les activités du cycle de dévelppement : acquisitin, furniture, dévelppement, explitatin et maintenance. Prendre des décisins quant à ce qui dit être testé, quels rôles vnt exercer quelles activités, quand et cmment ces activités divent être exercées, cmment évaluer les résultats des tests et quand arrêter les tests (critères de srtie). Planifier les activités d analyse et de cnceptin des tests Planifier les activités de cnceptin, d exécutin et d évaluatin des tests Assigner les ressurces aux différentes tâches définies. Définir le vlume, le niveau de détail, la structure et les mdèles pur la dcumentatin du test. Sélectinner des mesures pur suivre et cntrôler la préparatin et l exécutin des tests, l éliminatin des défauts et la réslutin des prblèmes relatifs aux risques. Déterminer le niveau de détail pur les prcédures de test de façn à furnir suffisamment de détails pur permettre une préparatin et une exécutin reprductibles des tests Critères d entrée (K2) Les critères d entrée définissent quand démarrent les tests (par exemple quand débute un niveau de test, quand un jeu de test est prêt à être exécuté) Typiquement, les critères d entrée peuvent cuvrir: Dispnibilité et préparatin de l envirnnement de test Préparatin des utils de tests dans l envirnnement de test Dispnibilité de cde testable Dispnibilité des jeux de dnnées Versin 2011 Page 50 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

51 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Critères de srtie (K2) L bjectif des critères de srtie est de définir quand arrêter le test, par exemple, à la fin d un niveau de test u lrsqu une série de tests a atteint un bjectif dnné. Typiquement, les critères de srtie peuvent cmprendre les suivants : Des mesures d exhaustivité, cmme la cuverture de cde, de fnctinnalités u de risques. L estimatin de la densité des anmalies u des mesures de fiabilité. Le cût. Les risques résiduels, cmme les anmalies nn crrigées u le manque de cuverture du test dans certaines parties. Un calendrier, par exemple, basé sur la date de mise sur le marché Estimatin des tests (K2) Deux apprches pur l estimatin de l effrt de test snt cuvertes par le présent syllabus : Estimatin de l effrt de test basée sur des mesures issues de prjets antérieurs u similaires u basée sur des valeurs typiques. L apprche experte : estimatin des tâches par le détenteur de ces tâches u par des experts. Une fis que l effrt de test a été estimé, il est pssible d identifier les ressurces nécessaires et d établir un échéancier. L effrt de test peut dépendre d un certain nmbre de facteurs, dnt les suivants : Les caractéristiques du prduit : la qualité des exigences et autres infrmatins utilisées pur les mdèles de test (c est-à-dire la base de test), la taille du prduit, la cmplexité du dmaine, les exigences de fiabilité et de sécurité ainsi que celles de la dcumentatin. Les caractéristiques du prcessus de dévelppement : la stabilité de l rganisatin, les utils emplyés, le prcessus de test, le savir-faire des persnnes impliquées et les cntraintes de temps. Les résultats du tests : le nmbre de défauts et le vlume des reprises exigées Stratégie de test, Apprche de test (K2) L apprche de test est la mise en œuvre d une stratégie de test pur un prjet spécifique. Elle est définie et affinée dans les plans et scénarii de test. Elle cmprend typiquement les décisins basées sur le prjet (de test), ses buts ainsi qu une analyse des risques. Elle cnstitue le pint de départ pur la planificatin du prcessus de test, pur sélectinner les types et techniques de test qui sernt appliqués ainsi que pur définir les critères d entrée et de srtie. L apprche sélectinnée dépend du cntexte et peut prendre en cnsidératin les risques, la sécurité et les dangers, les ressurces dispnibles et leur niveau d expertise, la technlgie et la nature du système (par exemple spécifique u générique (COTS)), les bjectifs, les nrmes et règlements en vigueur. Les apprches typiques peuvent cmprendre: Une apprche analytique, cmme le test basé sur les risques ù le test est fcalisé sur les parties à plus haut risque. Les apprches basées sur les mdèles, cmme le test stchastique qui utilise des infrmatins statistiques sur les taux d erreurs (cmme les mdèles de crissance de fiabilité) u sur l utilisatin (cmme les prfils pératinnels). Les apprches méthdiques, cmme le test basé sur les erreurs (y cmpris l estimatin d erreurs et l attaque par faute), basées sur des listes de vérificatin et sur des caractéristiques de la qualité. Versin 2011 Page 51 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

52 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Des apprches basées sur la cnfrmité aux prcessus et nrmes, tels que ceux spécifiés par des nrmes industrielles spécifiques u les diverses méthdes agiles. Les apprches dynamiques et heuristiques, cmme le test explratire ù le test est plutôt réactif aux événements que planifié, et ù l exécutin et l évaluatin snt des tâches parallèles. Les apprches cnsultatives, cmme celles ù la cuverture de test est principalement définie par les avis et le guidage d experts métier u en technlgie étrangers à l équipe de test. Les apprches basées régressin, cmme celles qui cmprtent le réempli de matériel de test existant, une autmatisatin extensive du test de régressin fnctinnel et des suites de tests standard. Différentes apprches peuvent être cmbinées, par exemple, une apprche dynamique basée sur les risques. Versin 2011 Page 52 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

53 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 5.3 Suivi et cntrôle du dérulement des tests (K2) 20 minutes Termes Densité de défauts, taux de défaillance, cntrôle des tests, suivi des tests, rapprt de test Suivi de l avancement des tests (K1) L bjectif du suivi du test est de furnir un retur et une visibilité sur les activités de test. Les infrmatins à suivre peuvent être recueillies manuellement u autmatiquement et peuvent être utilisées pur évaluer les critères de srtie, cmme la cuverture. Des mesures peuvent aussi être utilisées pur évaluer l avancement par rapprt au calendrier et au budget planifiés. Les mesures de test habituelles snt: Le purcentage du travail cnsacré à la préparatin des cas de test (u purcentage des cas de test planifiés et préparés). Purcentage du travail cnsacré à la préparatin de l envirnnement de test. L exécutin de cas de test (par exemple, nmbre de cas de test exécutés u nn et nmbre de cas de test réussis u échués). Les infrmatins sur les défauts (par exemple, densité des défauts, défauts truvés et crrigés, taux des défaillances et résultats du re-test). Cuverture par le test des exigences, des risques u du cde. Cnfiance subjective des testeurs dans le prduit. Dates des jalns du test. Cût du test, y cmpris le cût de l avantage de truver le prchain défaut cmparé à celui de l exécutin du test suivant Reprting des tests (K2) Le reprting des tests cnsiste à résumer les infrmatins relatives à l entreprise du test ; il cmprend les activités suivantes : Ce qui s est passé pendant une phase de test, cmme les dates ù les critères de srtie nt été atteints. Les infrmatins et mesures analysées pur étayer les recmmandatins et décisins pur de futures actins, cmme une évaluatin des défauts restants, les avantages écnmiques de tests prlngés, les risques nn cuverts et le niveau de cnfiance dans le lgiciel testé. Le descriptif d un rapprt de synthèse de test se truve dans le guide «Standard fr Sftware Test Dcumentatin» (IEEE Std ). Des mesures devraient être recueillies pendant et à la fin d un niveau de test dans le but d évaluer : L adéquatin des bjectifs du test avec ce niveau de test. L adéquatin des apprches du test empruntées. L efficacité du test par rapprt à ses bjectifs Cntrôle des tests (K2) Le cntrôle du test décrit les actins d rientatin et de crrectin entreprises cmme résultat des infrmatins et mesures recueillies et cnsignées. Ces actins peuvent cuvrir tute activité de test et influencer tute autre activité u tâche du cycle de vie lgiciel. Exemples d actins de cntrôle des tests : Prendre des décisins sur la base des infrmatins recueillies lrs du suivi des tests Versin 2011 Page 53 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

54 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Une nuvelle affectatin de prirités aux tests en cas de mise en évidence d un risque identifié (par exemple, retard de livraisn du lgiciel). Une mdificatin du calendrier de test en raisn de la dispnibilité d un envirnnement de test. Définitin d un critère d entrée exigeant que des crrectins sient testées par le dévelppeur avant de les accepter dans une versin. Versin 2011 Page 54 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

55 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 5.4 Gestin de cnfiguratin (K2) 10 minutes Termes Gestin de cnfiguratin, cntrôle de versins Cntexte L bjectif de la gestin de cnfiguratin est d établir et de maintenir l intégrité des prduits (cmpsants, dnnées et dcumentatin) du lgiciel u du système durant le cycle de vie du prjet et du prduit. Pur le test, la gestin de cnfiguratin peut permettre d assurer que : Tus les éléments faisant partie du testware snt identifiés, sus cntrôle de versins, que les changements snt identifiés et re-traçables, reliés les uns aux autres et aux éléments de dévelppement (bjets de test), de srte que la traçabilité peut être maintenue pendant tut le prcessus du test. Tus les dcuments identifiés et les éléments du lgiciel snt référencés de manière nn ambiguë dans la dcumentatin de test. La gestin de cnfiguratin aide le testeur à identifier de manière unique (et à reprduire) l élément testé, les dcuments de test, les tests et le harnais de test. Pendant la planificatin du test, les prcédures et l infrastructure (utils) de la gestin de cnfiguratin devraient être chisis, dcumentés et implémentés. Versin 2011 Page 55 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

56 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 5.5 Test et risques (K2) 30 minutes Termes Risques liés au prduit, risques liés au prjet, risques, test basé sur les risques Cntexte Un risque peut être défini cmme la prbabilité qu un événement, un danger, une menace u une situatin arrive, et que les cnséquences indésirables qui en déculent cnstituent un prblème ptentiel. Le niveau de risque sera déterminé par la prbabilité qu un événement adverse arrive et par l impact de ce dernier (les dmmages résultant de cet événement) Risques liés au prjet (K2) Les risques liés au prjet snt les risques menaçant la capacité de ce dernier à atteindre ses bjectifs, tels que : Facteurs rganisatinnels : Manque de cmpétence et de frmatin du persnnel ; Prblèmes de persnnel; Prblèmes plitiques, tels que prblèmes dus au fait que des testeurs ne cmmuniquent pas leurs besins et les résultats du test ; incapacité à suivre les infrmatins recueillies pendant le test et les revues (par exemple, ne pas amélirer les pratiques de dévelppement et de test). Attitude u attentes inapprpriées vis-à-vis du test (par exemple, ne pas apprécier la valeur de la décuverte de défauts durant le test). Prblèmes techniques : Prblèmes pur définir des exigences crrectes ; La mesure seln laquelle les exigences sernt satisfaites en fnctin de cntraintes existantes ; Envirnnement de test indispnible Cnversin des dnnées tardive ; planning de migratin et de dévelppement ; cnversin des dnnées de test / utils de migratin Qualité de la cnceptin, du cde et des tests Prblèmes d acquisitin : Défaillance d une tierce partie ; Prblèmes cntractuels. Pur analyser, gérer et diminuer ces risques, le gestinnaire de test suivra les principes bien établis de la gestin de prjet. Le guide «Standard fr Sftware Test Dcumentatin» (IEEE Std ) pur le plan de test exige que les risques et cntingences sient dcumentés Risques liés au prduit (K2) Les défaillances ptentielles (événements futurs indésirables u dangers) des parties du lgiciel u du système snt définies cmme des risques liés au prduit, puisqu elles représentent un risque pur la qualité du prduit, cmme : Livraisn d un lgiciel défectueux. Pssibilité qu un lgiciel u système entraîne des dmmages à des persnnes u à des entreprises. Caractéristiques lgicielles de mindre qualité (par exemple, fnctinnalité, sécurité, fiabilité, utilisabilté et perfrmances). Intégrité et qualité des dnnées de faible qualité (par exemple en raisn de prblèmes liés à leur migratin, à leur cnversin, à leur transprt, à un nn respect des standards) Versin 2011 Page 56 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

57 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Lgiciel n ffrant pas les fnctinnalités vulues. Les risques snt emplyés pur décider quand cmmencer à tester et ù tester davantage ; le test est utilisé pur réduire le risque qu un événement indésirable ne survienne u pur réduire l impact de ce dernier. Les risques relatifs au prduit snt un type particulier de risque pur le succès d un prjet. Le test, cmme activité de cntrôle des risques furnit un retur quant aux risques restants par la mesure de l efficacité de l éliminatin des défauts critiques et des plans de cntingence. Une apprche des tests basée sur les risques furnit des pssibilités practives de réduire le niveau des risques relatifs au prduit, en partant des premières étapes d un prjet. Elle cmprend l identificatin des risques liés au prduit et de leur empli cmme guide pur la planificatin du test, la spécificatin, la préparatin et l exécutin des tests. Dans une apprche basée sur les risques, les risques identifiés peuvent être utilisés pur : déterminer les techniques de test à emplyer, déterminer le vlume du test à effectuer. définir les prirités à affecter aux tests dans le but de truver les défauts critiques le plus tôt pssible. déterminer si des activités ne faisant pas partie du test purraient aider à réduire les risques (par exemple, une frmatin furnie aux dévelppeurs inexpérimentés). Le test basé sur les risques repse sur les cnnaissances et la cmpréhensin cllectives des acteurs d un prjet pur déterminer les risques et les niveaux de test nécessaires pur cuvrir ces derniers. Pur s assurer que la prbabilité de défaillance d un prduit est minimisée, les activités de gestin des risques furnissent une apprche disciplinée pur : estimer (et re-estimer régulièrement) ce qui peut faillir (les risques), déterminer quels snt les risques imprtants à cuvrir, entreprendre des actins pur cuvrir ces risques. De plus, le test peut aider à identifier de nuveaux risques, à déterminer quels risques divent être minimisés et à réduire l incertitude relative aux risques. Versin 2011 Page 57 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

58 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 5.6 Gestin des incidents (K3) 40 minutes Termes Cnsignatin d incidents, gestin des incidents, rapprt d incidents Cntexte Cmme l un des bjectifs du test est de décuvrir des défauts, les différences entre les résultats attendus et les résultats effectifs divent être cnsignées en tant qu incidents. Un incident dit être analysé et peut par la suite devenir un défaut. Des actins adéquates divent être définies afin de traiter les incidents et les défauts. Les incidents et les défauts divent être suivis depuis leur décuverte et classificatin jusqu à leur crrectin et la cnfirmatin de leur réslutin. Pur puvir gérer tus les incidents jusqu à la fin d un prjet, une rganisatin devrait établir un prcessus de gestin des incidents et des règles pur leur classificatin. Les incidents peuvent survenir pendant le dévelppement, les revues, le test u l utilisatin d un prduit lgiciel. Ils peuvent survenir en raisn de prblèmes dans le cde, dans le système pératinnel u dans tut type de dcumentatin, ntamment les dcuments de dévelppement, les dcuments de test u les infrmatins destinées à l utilisateur tels que le manuel d utilisatin u le manuel d installatin. Les rapprts d incidents peuvent avir les bjectifs suivants : Furnir aux dévelppeurs et aux autres parties un retur sur le prblème cncerné pur en permettre l identificatin, la lcalisatin et la crrectin nécessaires. Furnir aux respnsables du test le myen de suivre la qualité d un système sus test et l avancement du test. Furnir des idées pur l améliratin du prcessus de test. Les détails du rapprt d incident peuvent inclure: Date de l incident, rganisatin faisant part de l incident, auteur Résultats attendus et effectifs. Identificatin u élément de cnfiguratin du lgiciel u système. Prcessus du cycle de vie du lgiciel u du système au curs duquel l incident a été bservé Descriptin de l anmalie pur permettre sn éliminatin, y cmpris les traces, extraits de la base de dnnées u captures d écrans Degré de l impact sur les intérêts des détenteurs d enjeux. Sévérité de l impact sur le système. Urgence u pririté de la crrectin. Etat de l incident (par exemple, uvert, sumis, dubln, en attente de crrectin, crrigé en attente de test de cnfirmatin, clôturé). Cnclusins et recmmandatins. Prblèmes glbaux, cmme d autres parties puvant être impactées par une mdificatin résultant de l incident. Histrique des mdificatins, telles que la séquence des actins entreprises par des membres de l équipe du prjet afin de lcaliser l incident, de crriger et d en cnfirmer la crrectin. Références, incluant l identité du cas de test u la spécificatin qui a permis d identifier le prblème La structure d un rapprt d incident est cuverte par le guide «Standard fr Sftware Test Dcumentatin» (IEEE Std ). References Black, 2001, Hetzel, Black, 2001, Hetzel, Black, 2001, Craig, 2002, IEEE Std , Kaner 2002 Versin 2011 Page 58 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

59 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Black, 2001, Craig, 2002, Hetzel, 1988, IEEE Std Craig, Black, 2001, IEEE Std Black, 2001, IEEE Std Versin 2011 Page 59 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

60 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 6. Outils de Supprt aux (K2) 80 minutes Objectifs de cnnaissance pur les utils de supprt aux tests Les bjectifs identifient ce que vus aurez à la fin de chacun des mdules. 6.1 Les types d'utils de tests (K2) LO LO Classer les différents types d utils de test seln leur sujet et les activités du prcessus de tests et le cycle de vie lgiciel. (K2) Recnnaître les utils qui peuvent aider les dévelppeurs dans leurs tests. (K2) 6.2 Utilisatin pertinente des utils : Avantages et risques ptentiels (K2) LO LO Résumer les bénéfices et risques ptentiels d autmatisatin et d utilisatin d utils pur les tests. (K2) Recnnaître les cnsidératins spécifiques pur les utils d exécutin des tests, l analyse statique, et les utils de gestin de tests. (K1) 6.3 Intrduire un util dans une rganisatin (K1) LO LO LO Expser les principes majeurs liés à l intrductin d un util dans une rganisatin. (K1) Expser les bjectifs d une preuve de cncept pur l évaluatin d un util et une phase de piltage pur l implémentatin d un util. (K1) Recnnaître que des facteurs autres que l acquisitin d un util snt nécessaires pur un bn supprt des tests par les utils. (K1) Versin 2011 Page 60 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

61 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 6.1 Types d'utils de test (K2) 45 minutes Termes Outils de gestin de cnfiguratin, utils de mesure de cuverture, utils de débgage, utils d analyse dynamique, utils de gestin d incidents, utils de tests de charge, utils de mdélisatin, utils de mnitring, utils de tests de perfrmances, effet de snde, utils de gestin d exigences, utils de supprt de revues, utils de sécurité, utils d analyse statique, utils de test de stress, cmparateur de tests, utils de préparatin de dnnées de tests, utils de cnceptin de tests, harnais de tests, utils d exécutin des tests, utils de gestin des tests, utils de tests unitaires et structurels Outils de supprt aux tests (K2) Des utils de test peuvent être utilisés pur une u plusieurs activités que supprte le test. Ceux-ci incluent : 1. Outils qui snt directement utilisés dans le test tel que les utils d'exécutin de test, utils de génératin de dnnées de test et utils de cmparaisn de résultats. 2. Outils qui aident en cntrôlant le prcessus de test cmme ceux emplyés pur gérer les tests, des résultats de test, des dnnées, des cnditins, des incidents, des défauts, etc., et pur reprter et cntrôler l'exécutin des tests 3. Outils qui snt utilisés dans la recnnaissance, u, en termes simples : explratin (par exemple, utils qui cntrôle l'activité d'un fichier pur une applicatin) 4. N'imprte quel util qui facilite le test (un tableur est également un util de test dans cette significatin) L util de supprt au test peut avir un u plusieurs des buts suivants seln le cntexte : Amélirer l'efficacité des activités de test en autmatisant des tâches répétitives u en supprtant des activités de test manuelles cmme la planificatin des tests, la cnceptin de tests, le cmpte-rendu et le cntrôle des tests Autmatiser les activités qui exigent les ressurces imprtantes une fis faites manuellement (par exemple, tests statiques) Autmatiser les activités qui ne peuvent pas être exécutées manuellement (par exemple, test de perfrmance exhaustif des applicatins client-serveur) Augmenter la fiabilité du test (par exemple, en autmatisant la cmparaisn de beaucup de dnnées u en simulant le cmprtement) Le terme "framewrk de test" est également fréquemment utilisé dans l'industrie, avec au mins tris significatins : Biblithèques réutilisables et extensibles de test qui peuvent être emplyées pur cnstruire des utils de test (appelées aussi harnais de tests) Un type de cnceptin d'autmatisatin des tests (par exemple, piltés par les dnnées, pilté par mts-clés) Prcessus glbaux d'exécutin de test Dans ce syllabus, le terme "framewrk de test" est utilisé dans ses deux premières significatins cmme décrit dans la sectin Classificatin des utils de test (K2) Il y a un certain nmbre d'utils qui supprtent les différents aspects du test. Des utils peuvent être classés seln plusieurs critères tels que le but, cmmercial/ libre / lgiciel libre / shareware, technlgie utilisée et ainsi de suite. Dans le présent syllabus, ces utils snt classés seln les activités du test qu ils assistent. Versin 2011 Page 61 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

62 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Certains utils supprtent clairement une seule activité; d autres supprtent plus d une activité, mais snt classés dans la rubrique relative à l activité à laquelle ils snt plus étritement assciés. Des utils d'un furnisseur unique, particulièrement ceux qui nt été cnçus pur fnctinner ensemble, peuvent être empaquetés dans un mdule. Quelques types d util de test peuvent être intrusifs, ce qui signifie qu'ils peuvent affecter le résultat btenu par le test.. Par exemple, une mesure de temps peut varier à cause des instructins supplémentaires exécutées par l util., u vus puvez btenir une mesure de cuverture de cde différente. La cnséquence des utils intrusifs s'appelle l'effet de snde. Quelques utils ffrent une assistance davantage turnée vers les dévelppeurs (càd. pendant les tests de cmpsants et d intégratin des cmpsants). Ces utils snt ntés avec un (D) dans les classificatins ci-dessus Outils d aide à la gestin du test et des tests (K1) Les utils de gestin s appliquent à tutes les activités de tests pendant tute la durée du cycle de vie du lgiciel. Outils de gestin des tests Ces utils furnissent des interfaces pur exécuter des tests, dépister des défauts et gérer les exigences, avec une aide pur l'analyse quantitative et le rapprt des bjets de tests. Ils supprtent également la traçabilité des bjets de tests vers les spécificatins des exigences. Ils peuvent psséder des fnctinnalités de gestin de versin indépendantes u s interfacer avec un util de gestin de versin externe. Outils de gestin des exigences Ces utils enregistrent les énncés des exigences, enregistrent les attributs des exigences (pririté y cmpris), furnissent des identifiants uniques et supprtent la traçabilité des exigences vers les tests individuels. Ces utils peuvent également aider à identifier des exigences cntradictires u manquantes. Outils de gestin d'incidents (utils de suivi de défauts) Ces utils enregistrent et gèrent les rapprts d'incidents, c.-à-d. les défauts, les défaillances, les demandes de mdificatin u les prblèmes et anmalies rencntrés. Ils aident à gérer le cycle de vie des incidents, éventuellement avec le supprt de l'analyse statistique. Outils de gestin de cnfiguratin Bien que pas strictement des utils de test, ceux-ci snt nécessaires pur le stckage et la gestin de versin du testware et du lgiciel asscié particulièrement lrsque snt cnfigurés plusieurs envirnnements matériel/lgiciel en termes de versins du système d'explitatin, cmpilateurs, navigateurs web, etc Outils d aide aux tests statiques (K1) Les utils de test statique furnissent une manière rentable de truver plus de défauts à une étape amnt dans le prcessus de dévelppement. Outils de revue Ces utils aident aux revues des prcessus, des check-lists, des directives de revue et snt utilisés pur enregistrer et cmmuniquer les cmmentaires des revues, et les rapprts sur les défauts et les essais. Ils peuvent être d une aide supplémentaire en furnissant l'assistance pur des revues en ligne pur des équipes de taille imprtante u gégraphiquement dispersées. Outils d'analyse statique (D) Versin 2011 Page 62 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

63 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Ces utils aident les dévelppeurs et les testeurs à truver des défauts avant le test dynamique en furnissant une aide pur intrduire des nrmes de cdage (cdage sécurisé y cmpris), l'analyse des structures et des dépendances. Ils peuvent également aider dans la planificatin u l analyse de risque en furnissant des métriques pur le cde (par exemple, cmplexité). Outils de mdélisatin (D) Ces utils snt emplyés pur valider les mdèles de lgiciel (par exemple, mdèle de dnnées physiques (MDP) pur une base de dnnées relatinnelle), en énumérant des inchérences et en truvant des défauts. Ces utils peuvent suvent aider en prduisant quelques cas de test basés sur le mdèle Outils d aide à la spécificatin des tests (K1) Outils de cnceptin de tests Ces utils snt utilisés pur générer des entrées de tests u des tests exécutables et/u des racles de tests à partir des exigences, des interfaces utilisateur graphiques, des mdèles de cnceptin (état, dnnées u bjet) u à partir du cde. Outils de préparatins de dnnées de tests Les utils de préparatin des dnnées agissent sur des bases de dnnées, fichiers u transferts de dnnées afin d élabrer des dnnées de tests utilisables lrs de l exécutin des tests, ceci en assurant la sécurité des dnnées grâce à leur annymisatin Outils d aide à l'exécutin et à l enregistrement des tests (K1) Outils d exécutin des tests Ces utils permettent à des tests d'être exécutés autmatiquement, u semi-autmatiquement, utilisant les entrées enregistrées et les résultats prévus, par l'utilisatin d un langage de script et furnissent habituellement un registre de test pur chaque exécutin de test. Ils peuvent également être emplyés pur enregistrer des tests, et dispsent habituellement d un langage de script u une cnfiguratin via une interface graphique utilisateur pur le paramétrage des dnnées et tute autre persnnalisatin dans les tests. Harnais de tests/outils framewrk de tests unitaires (D) Un harnais u framewrk de tests unitaires facilite le test des cmpsants u des parties d'un système en simulant l'envirnnement dans lequel cet bjet de tests s'exécutera, par la furniture d'bjets factices cmme des buchns u des piltes. Cmparateurs de tests Les cmparateurs de tests déterminent des différences entre les fichiers, bases de dnnées u résultats de tests. Les utils d'exécutin des tests incluent en général des cmparateurs dynamiques, mais les cmparaisns pst-exécutin peuvent être faites par un util de cmparaisn distinct. Un cmparateur de tests peut utiliser un racle de tests, en particulier s'il est autmatisé. Outils de mesure de cuverture (D) Ces utils, par des myens intrusifs u nn intrusifs, mesurent le purcentage de certains types de structures de cde qui nt été exercés (par exemple, des déclaratins, des branches u des décisins, et appels de mdule u fnctin) par un ensemble de tests. Outils de test de sécurité Ces utils snt utilisés pur évaluer les caractéristiques de sécurité du lgiciel. Ceci inclut l évaluatin de la capacité du lgiciel à prtéger la cnfidentialité, l'intégrité, l'authentificatin, l'autrisatin, la dispnibilité, et la nn-répudiatin des dnnées. Les utils de sécurité snt en grande partie cncentrés sur une technlgie, une plate-frme, et un but particulier. Versin 2011 Page 63 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

64 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Outils de supprt de perfrmance et de surveillance (K1) Outils d'analyse dynamique (D) Les utils d analyse dynamique détectent des défauts qui ne se manifestent que lrs de l exécutin du lgiciel, telles que les dépendances temprelles u les fuites de mémire. Ils snt typiquement utilisés dans des tests de cmpsants et d intégratin de cmpsants, et dans les tests de middleware. Outils de test de perfrmance/test de charge/test de stress Les utils de test de perfrmance surveillent et rapprtent sur la façn dnt se cmprte un système seln une grande variété de cnditins d usage simulées en termes de nmbre d'utilisateurs simulanés, de leur mdèle de mntée en charge, de fréquence et de purcentage relatif de transactins. La simulatin de la charge est réalisée au myen de la créatin d'utilisateurs virtuels effectuant un ensemble chisi de transactins diffusées à travers divers machines de test identifiés cmme injecteurs de charge. Outils de surveillance Les utils de surveillance analysent cntinuellement, vérifient et rendent cmpte de l'utilisatin de ressurces systèmes spécifiques, et dnnent des alertes sur de pssibles prblèmes de service Outils de supprt pur des besins de tests spécifiques (K1) Evaluatin de la qualité des dnnées Les dnnées snt au centre de certains prjets tels que des prjets de cnversin/migratin des dnnées et des applicatins cmme le stckage de dnnées. Leurs caractéristiques peuvent varier en termes de criticité et vlume. Dans de tels cntextes, des utils d évaluatin de la qualité des dnnées divent être utilisés pur revir et vérifier les règles de cnversin et de migratin des dnnées, pur s'assurer que les dnnées traitées snt crrectes, cmplètes et se cnfrment à une nrme prédéfinie spécifique au cntexte. D'autres utils de test existent pur le test d'utilisabilité. Versin 2011 Page 64 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

65 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 6.2 Utilisatin efficace des utils : Bénéfices ptentiels et Risques (K2) 20 minutes Termes piltés par les dnnées, tests piltés par mts clé, langage de script Bénéfices ptentiels et risques liés aux utils de test (pur tus les utils) (K2) Le simple achat, u la lcatin d un util ne garantit par le succès. Chaque type d util nécessite des effrts supplémentaires pur atteindre des bénéfices réels et durables. S il existe des pprtunités ptentielles de bénéfices à utiliser des utils dans le test, il existe aussi des risques. Bénéfices ptentiels à l utilisatin d utils : Réductin du travail répétitif (p.ex. exécutin de tests de régressin, réintrductin des mêmes dnnées de tests, et vérificatin du respect de standards de cdage). Répétabilité et chérence accrues (p.ex. tests exécutés par un util suivant un rdre et une fréquence précis et tests déduits des exigences). Evaluatin bjective (p.ex. mesure statiques, cuverture). Facilité d accès aux infrmatins cncernant les tests u leur exécutin (p.ex. statistiques et graphiques sur l avancement des tests, le taux d incidents et les perfrmances). Risques liés à l utilisatin d utils : Attentes irréalistes placées dans l util (dnt la facilité d utilisatin et la fnctinnalité). Sus-estimatin du temps, du cût et de l effrt pur l intrductin initiale d un util (dnt la frmatin et l expertise externe). Sus-estimatin du temps et de l effrt nécessaires pur btenir de l util des bénéfices significatifs et cntinus de l util (incluant le besin de mdificatin du prcessus de tests et l améliratin cntinue dans la manière d utiliser l util). Sus-estimatin de l effrt requis pur maintenir les acquis générés par l util. Cnfiance excessive dans l util (cmme substitut à la cnceptin des tests u alrs que des tests manuels seraient plus apprpriés). Négligence du cntrôle de versin des éléments de test dans l'util Négligence des prblèmes de relatin et interpérabilité entre les utils critiques, tels que des utils de gestin d'exigences, des utils de cntrôle de versin, des utils de gestin d'incidents, des utils de suivi de défauts et des utils de différents éditeurs Risque de faillite de l éditeur d'util, de retirer l'util, u de vendre l'util à un autre éditeur Faible réactivité du vendeur pur le supprt, les mises à jur, et crrectins des défauts Risque de suspensin d un lgiciel u prjet pen-surce u libre Imprévu, cmme l'incapacité de supprt d'une nuvelle plate-frme Cnsidératins spéciales pur quelques types d'util (K1) Outils d exécutin des tests Les utils d'exécutin de tests exécutent des bjets de tests utilisant des scripts de test autmatisés. Ce type d util nécessite suvent un effrt imprtant pur btenir des bénéfices significatifs. Saisir des tests en enregistrant les actins d un testeur manuel semble séduisant, mais cette apprche ne peut pas être appliquée lrsque le nmbre de tests autmatisés est imprtant. Un script capturé est une représentatin linéaire avec des dnnées et actins spécifiques faisant partie de chaque script. Ce type de script peut être instable lrs de l ccurrence d événements inattendus. Versin 2011 Page 65 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

66 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Une apprche guidée par les dnnées isle les entrées de tests (les dnnées), habituellement au myen d un tableur et utilise un script plus générique qui peut lire les dnnées de test et effectuer le même test avec des dnnées différentes. Les testeurs qui ne snt pas familiarisés avec le langage de scripts peuvent alrs entrer des dnnées de tests pur ces scripts prédéfinis. Il y a d'autres techniques utilisées avec des techniques piltées par les dnnées, ù au lieu des cmbinaisns cdées en dur de dnnées placées dans un tableur, des dnnées snt prduites utilisant des algrithmes basés sur des paramètres cnfigurables lrs de l'exécutin et furnis à l'applicatin. Par exemple, un util peut utiliser un algrithme, qui prduit un identifiant de l'utilisateur de façn aléatire, et pur la répétabilité dans le mdèle, une injectin est utilisée pur en cntrôler le caractère aléatire. Dans une apprche par mts-clés, le tableur cntient des mts-clés décrivant les actins à effectuer (aussi appelés mts d actin u actin wrds), et des dnnées de tests. Les testeurs (même s ils ne snt pas familiers avec le langage de script) peuvent ensuite définir des tests en utilisant les mts-clés, qui peuvent être adaptés en fnctin de l applicatin à tester. Une expertise technique quant au langage de script est requise pur tutes les apprches (sit par les testeurs, sit par des spécialistes en autmatisatin des tests). Quelle que sit la technique de script utilisée, le résultat attendu pur chaque test est archivé pur une cmparaisn ultérieure. Outils d'analyse statique Les utils d analyse statique appliqués au cde surce peuvent impser des standards de cdage, mais s ils snt appliqués à du cde existant, peuvent engendrer de nmbreux messages. Les messages d avertissement n empêchent pas le cde d être traduit en prgramme exécutable, mais divent être pris en cmpte afin de faciliter la maintenance du cde dans le futur. Une implémentatin graduelle avec des filtres initiaux pur exclure certains messages cnstitue une apprche efficace. Outils de gestin des tests Les utils de gestin des tests divent s interfacer avec d autres utils u des tableurs de façn à prduire les infrmatins dans le frmat le mieux adapté aux besins présents de l rganisatin. Versin 2011 Page 66 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

67 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 6.3 Intrduire un util dans une rganisatin (K1) 15 minutes Termes Aucun terme spécifique. Cntexte Les principes principaux liés à l intrductin d un util dans une rganisatin incluent: Evaluatin de la maturité de l rganisatin, de ses frces et de ses faiblesses et identificatin des pssibilités d améliratin du prcessus de test par le supprt d utils. Evaluatin au regard d exigences claires et de critères bjectifs. Une preuve de cncept, à l'aide d'un util de test pendant la phase d'évaluatin pur vérifier qu il fnctinne efficacement avec le lgiciel en curs de test et dans l'infrastructure curante u pur identifier des mdificatins requises de cette infrastructure pur utiliser l'util efficacement Evaluatin du vendeur (aspects de frmatin, de supprt et de cmmerce y cmpris) u des furnisseurs de service de supprt en cas d'utils nn cmmerciaux Identificatin des exigences internes pur le sutien et la tutelle dans l'utilisatin de l'util Evaluatin de besin de frmatin par rapprt aux cmpétences en autmatisatin de tests de l'équipe de test curante Evaluatin du rapprt cût/bénéfice basé sur un cas métier cncret Intrduire l'util chisi dans une rganisatin cmmence par un prjet pilte, qui a les bjectifs suivants : Apprendre l util plus en prfndeur. Vir cmment l util s adapte à des prcessus et pratiques existants, et cmment ces derniers devraient évluer. Décider d une manière standard d utiliser, de gérer, de stcker et de maintenir l util et le testware (p.ex. décider d une cnventin de nmmage pur les fichiers et les tests, créer des biblithèques et définir la mdularité des suites de tests). Evaluer si les bénéfices escmptés sernt atteints pur un cût raisnnable. Les facteurs de succès du dépliement d un util dans une rganisatin incluent : Etendre l util au reste de l rganisatin de façn incrémentale. Adapter et amélirer les prcessus de façn à les adapter à l utilisatin de l util. Furnir de la frmatin et une assistance aux nuveaux utilisateurs. Établir des guides d utilisatin. Implémenter une manière de tirer des enseignements de l utilisatin de l util. Surveiller l utilisatin de l util et les bénéfices recueillis Furnir le supprt pur l'équipe de test pur un util dnné Recueillir l'expérience acquise de tutes les équipes Références Buwalda, 2001, Fewster, Fewster, 1999 Versin 2011 Page 67 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

68 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 7. Références Standards Glssaire des tests de lgiciel F ISTQB.pdf ISTQB Glssary f terms used in Sftware Testing Versin 2.1 [CMMI] Chrissis, M.B., Knrad, M. and Shrum, S. (2004) CMMI, Guidelines fr Prcess Integratin and Prduct Imprvement, Addisn Wesley: Reading, MA Vir Sectin 2.1 [IEEE Std ] IEEE Std 829 (1998) IEEE Standard fr Sftware Test Dcumentatin, Vir Sectins 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6 [IEEE 1028] IEEE Std 1028 (2008) IEEE Standard fr Sftware Reviews and Audits, Vir Sectin 3.2 [IEEE 12207] IEEE 12207/ISO/IEC , Sftware life cycle prcessesvir Sectin 2.1 [ISO 9126] ISO/IEC :2001, Sftware Engineering Sftware Prduct Quality, Vir Sectin 2.3 Livres [Beizer, 1990] Beizer, B. (1990) Sftware Testing Techniques (3rd editin), Van Nstrand Reinhld: Bstn Vir Sectins 1.2, 1.3, 2.3, 4.2, 4.3, 4.4, 4.6 [Black, 2001] Black, R. (2001) Managing the Testing Prcess (2nd editin), Jhn Wiley & Sns: New Yrk Vir Sectins 1.1, 1.2, 1.4, 1.5, 2.3, 2.4, 5.1, 5.2, 5.3, 5.5, 5.6 [Buwalda, 2001] Buwalda, H. et al. (2001) Integrated Test Design and Autmatin, Addisn Wesley: Reading, MA Vir Sectin 6.2 [Cpeland, 2004] Cpeland, L. (2004) A Practitiner s Guide t Sftware Test Design, Artech Huse: Nrwd, MA Vir Sectins 2.2, 2.3, 4.2, 4.3, 4.4, 4.6 [Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Sftware Testing, Artech Huse: Nrwd, MAVir Sectins 1.4.5, 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4 [Fewster, 1999] Fewster, M. and Graham, D. (1999) Sftware Test Autmatin, Addisn Wesley: Reading, MA Vir Sectins 6.2, 6.3 [Gilb, 1993]: Gilb, Tm and Graham, Drthy (1993) Sftware Inspectin, Addisn Wesley: Reading, MA Vir Sectins 3.2.2, [Hetzel, 1988] Hetzel, W. (1988) Cmplete Guide t Sftware Testing, QED: Wellesley, MA Vir Sectins 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 4.1, 5.1, 5.3 [Kaner, 2002] Kaner, C., Bach, J. and Pettticrd, B. (2002) Lessns Learned in Sftware Testing, Jhn Wiley & Sns: New Yrk Vir Sectins 1.1, 4.5, 5.2 [Myers 1979] Myers, Glenfrd J. (1979) The Art f Sftware Testing, Jhn Wiley & Sns: New Yrk Versin 2011 Page 68 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

69 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Vir Sectins 1.2, 1.3, 2.2, 4.3 [van Veenendaal, 2004] van Veenendaal, E. (ed.) (2004) The Testing Practitiner (Chapters 6, 8, 10), UTN Publishers: The Netherlands Vir Sectins 3.2, 3.3 Versin 2011 Page 69 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

70 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 8. Annexe A Infrmatins sur le syllabus Histrique de ce dcument Ce dcument a été préparé entre 2004 et 2011 par un grupe de travail cmpsé de membres de l Internatinal Sftware Testing Qualificatins Bard (ISTQB). Il a été initialement révisé par une cmmissin de révisin, puis par des représentants de la cmmunauté internatinale des testeurs de lgiciels. Les règles utilisées pur la cnceptin de ce dcument snt décrites en Annexe C. Ce dcument est le syllabus pur le certificat niveau Fndatin en de Lgiciels, le premier niveau du schéma de qualificatin internatinal appruvé par l ISTQB ( Objectifs de la qualificatin Certificat Fndatin Acquérir une recnnaissance des tests cmme une spécialisatin prfessinnelle et essentielle de l ingénierie lgicielle. Furnir un cadre standard pur le dévelppement des carrières des testeurs. Permettre une recnnaissance des testeurs qualifiés prfessinnellement par les emplyeurs, clients et leurs pairs, et accrître le prfil des testeurs. Prmuvir de bnnes pratiques, régulières, dans les disciplines de l ingénierie lgicielle. Identifier des thèmes de tests qui snt pertinents et valables pur l industrie. Permettre aux furnisseurs de lgiciels d embaucher des testeurs certifiés et gagner ainsi un avantage cmmercial sur la cmpétitin en annnçant leur plitique de recrutement. Furnir une pprtunité aux testeurs et aux persnnes intéressées par les tests d acquérir une qualificatin recnnue internatinalement sur le sujet. Objectifs de la qualificatin internatinale (adapté de la réunin ISTQB de Nvembre 2001 à Sllentuna) Permettre de cmparer les cmpétences des tests de pays différents Permettre aux testeurs de traverser les frntières plus facilement. Faciliter une cmpréhensin cmmune des aspects de tests dans les prjets multi-natinaux et/u internatinaux Augmenter le nmbre de testeurs qualifiés dans le mnde Avir plus d impact u de valeur en tant qu initiative internatinale qu une apprche natinale spécifique Dévelpper une cmpréhensin et une cnnaissance cmmune internatinale sur les tests via un syllabus et une terminlgie, et accrître le niveau de cnnaissance des tests de tus les participants Prmuvir les tests en tant que prfessin dans plus de pays Permettre aux testeurs d acquérir une qualificatin recnnue dans leur langue maternelle Faciliter le partage de cnnaissances et de ressurces entre les pays. Furnir une recnnaissance internatinale des testeurs et de cette qualificatin par une participatin de nmbreux pays Cnditins d entrée pur cette certificatin Le critère d entrée pur passer l examen du certificat de Testeur de Lgiciels Certifié CFTL niveau Fndatin (ISTQB Fundatin Certificate in Sftware Testing) est que le candidat démntre un intérêt dans les tests lgiciels. Cependant il est frtement recmmandé que le candidat : Pssède une cnnaissance minimale sit du dévelppement de lgiciels, sit des tests de lgiciels, tels qu un minimum de six mis d expérience en tests systèmes u tests d acceptatin utilisateurs, u en tant que dévelppeur de lgiciels Suive un curs accrédité CFTL u au niveau des standards ISTQB (par un des cmités natinaux recnnus par l ISTQB) Versin 2011 Page 70 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

71 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Cntexte et histire du Certificat Fndatin en de Lgiciels La certificatin indépendante des testeurs de lgiciels a cmmencé en Grande Bretagne avec le «Infrmatin Systems Examinatin Bard (ISEB)» du British Cmputer Sciety, quand un Cmité des Lgiciels a été mis en place en 1998 ( En 2002, ASQF en Allemagne cmmença a supprter un schéma de qualificatin allemand ( Ce syllabus est basé sur les syllabus ISEB et ASQF; il inclut une rérganisatin et une mise à jur du cntenu, ainsi que du cntenu supplémentaire, et une emphase est mise sur les pints qui furnirnt une aide pratique aux testeurs. Un Certificat en de Lgiciels niveau Fndatin existant (p.ex. de l ISEB, de l ASQF u d un cmité natinal recnnu par l ISTQB) décerné avant la publicatin de ce Certificat Internatinal, sera cnsidéré cmme équivalent au Certificat Internatinal. Le Certificat niveau Fndatin n expire pas et ne dit pas être renuvelé. La date d attributin est indiquée sur le Certificat. Dans chaque pays participant, les aspects lcaux snt cntrôlés par un Cmité Natinal des Lgiciels recnnu par l ISTQB. Les devirs des cmités natinaux snt spécifiés par l ISTQB, mais implémentés dans chaque pays. Les devirs des cmités natinaux incluent l accréditatin des rganismes de frmatin et la tenue des examens. Versin 2011 Page 71 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

72 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 9. Annexe B Objectifs de cnnaissance/niveaux de cnnaissance Les bjectifs de cnnaissance suivants snt définis cmme s appliquant à ce syllabus. Chaque aspect de ce syllabus sera examiné en fnctin de sn bjectif de cnnaissance. Niveau 1: Se suvenir (K1) Le candidat recnnaîtra, se rappellera et se suviendra des termes u des cncepts. Mts clés: Se suvenir, retruver, recnnaître, mémriser, savir Exemple Peut recnnaître la définitin de défaillance cmme : nn livraisn d un service à l utilisateur final u tut autre persnne impliquée u Déviatin cnstatée du cmpsant u système de la furniture, service u résultat attendu. Niveau 2: cmprendre (K2) Le candidat peut sélectinner les raisns u explicatins pur des affirmatins liées au sujet traité, et peut résumer, différencier, classer et dnner des exemples sur les cncepts de test Mts clés: Résumer, classer, cmparer, relier, ppser, dnner des exemples, interpréter, traduire, représenter, déduire, cnclure, cnstruire des mdèles, classer, généraliser, faire abstractin Exemples Peut expliquer les raisns pur lesquelles les tests divent être exécutés aussi tôt que pssible : Pur truver des défauts quand il est intéressant de les supprimer. Pur truver d abrd les défauts les plus imprtants. Peut expliquer les similitudes et les différences entre les tests d intégratin et les tests système : Similitudes : tester plus d un cmpsant, et tester des aspects nn-fnctinnels. Différences : les tests d intégratin se cncentrent sur les interfaces et les interactins, les tests système se fcalisent sur les aspects de systèmes entiers, tels le prcessus de but en but. Niveau 3: Appliquer (K3) Le candidat peut sélectinner l applicatin crrecte d un cncept u d une technique et l appliquer à un cntexte dnné. Mts clés: Implémenter, exécuter, utiliser, suivre une prcédure, appliquer une prcédure Exemple Peut identifier les valeurs limites pur des partitins valides et invalides Peut sélectinner les cas de test nécessaires à la cuverture de tutes les transitins pur un diagramme d état dnné Niveau 4: Analyser (K4) Le candidat peut décmpser l infrmatin relative à la prcédure u à la technique en différentes parties pur une meilleure cmpréhensin et peut faire la différence entre des faits et les cnclusins qui en snt tirées. Une applicatin classique est de prpser, après l analyse d un dcument, d un lgiciel u de la situatin d un prjet, les actins apprpriées pur résudre un prblème u une tâche. Mts clés: Analyser, différencier, sélectinner, structurer, cibler, attribuer, décnstruire, rganiser, truver la chérence, intégrer, mettre en évidence, parcurir, distinguer, cibler, discriminer Exemple Versin 2011 Page 72 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

73 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Analyser les risques prduit et prpser des activités crrectives et préventives pur les atténuer Décrire quelles parties d un rapprt d incident snt factuelles et quelles parties nt été déduites des résultats. Références (pur les niveaux cgnitifs des bjectifs d apprentissage) Andersn, L. W. and Krathwhl, D. R. (eds) (2001) A Taxnmy fr Learning, Teaching, and Assessing: A Revisin f Blm's Taxnmy f Educatinal Objectives, Allyn & Bacn Versin 2011 Page 73 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

74 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 10. Annexe C Règles appliquées au syllabus ISTQB niveau Fndatin Les règles listées ci-après nt été utilisées dans le dévelppement et la revue de ce syllabus. (une référence TAG est précisée après chaque règle pur référencer celle-ci.) Règles générales SG1. le syllabus dit être cmpréhensible et absrbable par des persnnes ayant de 0 à 6 mis (u plus) d expérience en tests. (6-MOIS) SG2. Le syllabus dit être pratique plutôt que thérique. (PRATIQUE) SG3. Le syllabus dit être clair et nn ambigu pur sn lectrat prévu. (CLAIR) SG4. Le syllabus dit être cmpréhensible par des persnnes de pays différents, et facilement traduisible en différentes langues. (TRADUISIBLE) SG5. Le syllabus dit utiliser la turnure américaine de l anglais. (ANGLAIS-AMERICAIN) Cntenu actualisé SC1. Le syllabus dit inclure des cncepts de tests récents et dit refléter les meilleures pratiques actuelles en tests de lgiciels là ù elles snt généralement acceptées. Le syllabus est sujet à revue tus les tris u cinq ans. (RECENT) SC2. Le syllabus dit minimiser les aspects liés au temps, telles que les cnditins du marché, pur lui permettre d être valide pur une péride de tris à cinq ans. (DUREE-DE-VIE) Objectifs de cnnaissance LO1. Les bjectifs de cnnaissance divent distinguer entre des aspects à recnnaitre/mémriser (niveau cgnitive K1), les aspects que le candidat dit cmprendre cnceptuellement (K2), des aspects que le candidat dit être capable d utiliser et de mettre en pratique (K3) et des aspects que le candidat dit être capable d utiliser pur analyser un dcument, du lgiciel, la situatin d un prjet dans sn cntexte (K4). (NIVEAU DE CONNAISSANCE) LO2. La descriptin du cntenu dit être cnsistante avec les bjectifs de cnnaissance. (LO- CONSISTANT) LO3. Pur illustrer les bjectifs de cnnaissance, des exemples de questins d examen pur chacune des sectins majeures sernt furnies avec le syllabus. (LO-EXAMEN) Structure générale ST1. La structure du syllabus dit être claire et permettre une référence crisée à partir de (et vers) chaque partie, depuis les questins d examen et depuis d autres dcuments pertinents. (CROSS- REF) ST2. Le recuvrement entre les sectins du syllabus dit être minimisé. (RECOUVREMENT) ST3. Chaque sectin du syllabus dit avir la même structure. (CONSISTANCE STRUCTURELLE) ST4. Le syllabus dit cntenir versin, date d émissin et numér de page sur chaque page. (VERSION) Versin 2011 Page 74 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

75 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard ST5. Le syllabus dit inclure une infrmatin sur le temps à passer sur chaque sectin (pur refléter l imprtance relative de chaque aspect). (TEMPS PASSE) Références SR1. Surces et Références sernt furnis pur les cncepts du syllabus pur aider les furnisseurs de frmatins à truver plus d infrmatin sur le sujet. (REFS) SR2. Si la surce n est pas clairement identifiée et/u claire, plus de détails dit être furni dans le syllabus. Par exemple, les définitins snt dans le Glssaire, dnc seuls les termes snt listés dans le syllabus. (NON-REF DETAIL) Surces d infrmatins Les termes utilisés dans le syllabus snt ceux définis dans le Glssaire CFTL/ISTQB des termes utilisés en tests de lgiciels. Une versin de ce glssaire est dispnible sur les sites de l ISTQB et du CFTL. Une liste de livres recmmandés sur les tests de lgiciels est aussi furnie en parallèle à ce syllabus. La liste principale de livres est incluse dans la sectin référence. Versin 2011 Page 75 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

76 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 11. Annexe D Nte pur les rganismes de frmatin Chaque titre de sujet principal de ce syllabus est asscié à une durée en minutes. L bjectif de cette instructin est de dnner des indicatins sur la prprtin de temps à alluer à chaque sectin dans un curs accrédité, et en même temps furnir une durée minimum apprximative pur enseigner chaque sectin. Les furnisseurs de frmatins peuvent passer plus de temps qu indiqué et les candidats peuvent prendre plus de temps en lectures et en recherche. Un curriculum de curs ne dit pas spécifiquement suivre le même rdre que le syllabus. Le syllabus cntient des références à des nrmes établies, qui divent être utilisées dans la préparatin du matériel de frmatin. Chaque nrme utilisée dit être dans la versin mentinnée dans ce syllabus. D autres publicatins, mdèles u standards nn référencés dans ce syllabus peuvent aussi être utilisés et référencés, mais ne sernt pas examinés. Versin 2011 Page 76 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

77 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 12. Tus les bjectifs de niveau K3 et K4 nécessitent de pratiquer des exercices. Annexe E Changements intégrés dans le Syllabus Changements des bjectifs de cnnaissance (LO) pur y inclure des clarificatins a. Vcabulaire changé pur les LOs suivants (Le cntenu et le niveau des LOs demeure inchangé): LO-1.2.2,LO-1.3.1, LO-1.4.1, LO-1.5.1, LO-2.1.1, LO-2.1.3, LO-2.4.2, LO-4.1.3, LO-4.2.1, LO-4.2.2,, LO-4.3.1, LO-4.3.2, LO-4.3.3, LO-4.4.1, LO-4.4.2, LO-4.4.3, LO-4.6.1, LO-5.1.2, LO-5.2.2, LO-5.3.2, LO-5.3.3, LO-5.5.2, LO-5.6.1, LO-6.1.1, LO-6.2.2, LO b. LO a été réécrit et mis au niveau K2. Une cmparaisn des termes relatifs aux defaults peut être attendue. c. LO Le cntenu du syllabus versin 2007 le cuvrait déjà. d. (K2) cmbine maintenant le cntenu de LO et LO-3.1. e. LO Supprimé de la versin 2010 car redndant en partie avec le LO f. LO Réécrit en versin 2010 pur améliratin du cntenu. g. LO Mis à jur. Passe du niveau K1 à K2 pur cmpatibilité avec le LO h. LO a été mdifié pur plus de clarté et passe du niveau K3 à K4. Raisn :rédactin identique à un niveau K4. i. LO (K1) a été supprimé de la versin 2010 et remplacé par LO (K2).Il n existe pas de LO dans la versin 2010 du Syllabus. 2. Usage de l apprche de tests seln la définitin du glssaire. Le terme Stratégie de tests ne sera pas requis cmme devant être appris. 3. Le chapitre 1.4 cntient maintenant le cncept de traçabilité entre les bases de tests et les cas de test. 4. Le chapitre 2.x cntient maintenant les bjets de test et les bases de test. 5. Re-tester remplace maintenant de cnfirmatin en liaisn avec le syllabus. 6. Les aspects Qualité des dnnées et tests» nt été ajuté en plusieurs endrits du syllabus: Qualité des dnnées et risques dans les chapitres 2.2, 5.5, Les critères d entrée du chapitre nt été ajutés cmme un nuveau sus-chapitre. Raisn: La cnsistance du cntenu des Critères de srtie (-> critère d entrée ajuté au LO ). 8. Utilisatin des termes Stratégie de tests et Apprche de tests cnfrmément à leur définitin dans le glssaire. 9. Le chapitre 6.1 a été raccurci car les descriptins des utils étaient trp exhaustives pur une leçn de 45 minutes. 10. La nrme IEEE Std 829:2008 est parue. Cette versin du syllabus ne prend pas encre en cmpte cette nuvelle éditin. La sectin 5.2 fait référence au dcument Plan de Test. Le cntenu du Plan de Test Maitre est cuvert par le cncept qui dit que le Plan de test cuvre différents niveaux de planificatin de tests: Les plans de test s appliquent à tus les niveaux de tests cmme au niveau prjet qui lui cuvrira plusieurs niveaux de tests. Ce dernier est appelé Plan de Test Maitre dans ce syllabus et dans le glssaire de l ISTQB. 11. Le cde d éthique est déplacé du syllabus Avancé vers le syllabus Fndatin. Versin 2011 Changements réalisés dans le versin Tutes pages : mts «Wrking Party» remplacés par «Wrking Grup» 2. Intrductin : descriptin des niveaux cgnitifs retirée car redndante avec l annexe B 3. Paragraphe 1.6 : parce que le but n est pas de définir un bjectif d apprentissage au «cde d ethique», le niveau a été retiré. 4. Paragraphes 2.2.1, 2.2.2, and 2.2.4, 3.2.3: prblème de frmatage de liste réslu. 5. Paragraphe : mt défaillance imprpre difficile d isler les défaillances liés à un cmpsant..», remplacé par «défaut». Versin 2011 Page 77 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

78 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 6. Paragraphe 2.3.4: mise à jur de la descriptin du débgage pur chérence avec le glssaire. 7. Paragraphe 2.4 : retrait du mt apprnfndis, phrase «incluent des tests de régressin apprfndis» car la prfndeur dépend du changement (taille, risque, valeur, etc ) cmme expliqué dans la phrase suivante. 8. Paragraphe 3.2.1: suite à un prbleme de frmatage du paragraphe, le prcessus de revue cmprenait 12 activités principales au lieu de 6. Le frmatage à été repris et le cntenu est à nuveau chérent avec la versin 2007 du syllabus 9. Paragraphe 4 : mt «dévelppé» remplacé par «cnçu» car un cas de test est cnçu et nn dévelppé. 10. Paragraphe 4.2 : texte mdifié pur clarifier l utilisatin cnjinte des tests bite nire et bite blanche avec les techniques basées sur l expérience. 11. Paragraphe : mdificatin de texte «l interactin entre des acteurs utilisateurs et système». 12. Paragraphe : «des branches alternatives» remplacé par «des scénaris alternatifs» 13. Paragraphe : mdificatin de texte pur clarifier le pint sur les tests de branche. 14. Paragraphes 6.1 : mdificatin du titre «Cmprendre la significatin et le but des utils de supprt aux tests» en «Outils de supprt aux tests» 15. Paragraphe 7 / Livres : la 3 e éditin du livre [Black,2001] remplace la 2 nde éditin 16. Annexe D : liste des chapitres nécessitant des exercices remplacée par l bligatin générique pur tus les bjectifs d'apprentissage K3 et supérieur de pratiquer des exercices. Obligatin issue de l the ISTQB Accreditatin Prcess (Versin 1.26). 17. Annexe E : les différences entre la versin 2007 et 2010 snt maintenant listés crrectement. Versin 2011 Page 78 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

79 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard 13. Index accréditatin... 8 actin wrds activités de planificatin des tests alpha tests analyse d impact... 31, 43 analyse de test analyse des valeurs limites analyse statique... 34, 39 apprche basée sur les risques apprche de test... 43, 58, 59 apprche guidée par les dnnées apprche par mts-clés apprche test first apprche tester d abrd architecture archivage attaque de faute attaque par faute autmatisatin avantages de l indépendance base de tests bénéfices liés à l utilisatin d utils beta tests... 24, 27 bttm-up buchn buchns bug cas d utilisatin... 28, 48 cas de test13, 16, 28, 34, 41, 42, 43, 45, 46, 47, 48, 49, 50, 71 cause première check-list... 36, 37 cibles de tests... 21, 28 classe d équivalence classificatin des utils de test... 69, 70 clôture des tests... 10, 17 cde d éthique cmparateur de tests... 69, 72 cmpilateur cmplexité... 39, 71 cnceptin de test... 41, 43, 51 cnceptin de tests... 43, 45 cnceptin des tests cnditin de test... 16, 28, 43, 45 cnditins de test... 13, 43 cnditins de tests cnsidératins spéciales pur quelques types d utils cnsignatin d incidents cntrôle de flux... 49, 50 cntrôle de versins cntrôle des tests... 15, 61, 62 crrectins cuverture29, 41, 43, 45, 47, 48, 49, 50, 70, 72, 73 cuverture de cde... 41, 49, 70 cuverture de test cuverture des décisins... 41, 49, 50 cuverture des instructins cuverture des tests cuverture du cde critère d entrée... 35, 78 critère de srtie13, 15, 16, 35, 36, 37, 56, 59 débgage... 13, 24, 29 défaillance... 11, 39, 51 défaut11, 13, 34, 35, 36, 37, 39, 42, 47, 48, 51, 52, 70, 71 densité de défauts dévelppement.. 21, 22, 34, 35, 39, 43, 52, 63, 71 dévelppement dirigé par les tests dévelppement lgiciel dévelppement pilté par les tests dévelppement rapide d applicatins (RAD) 22 dnnée de test dnnées de test dnnées de tests... 15, 71, 74 effet de snde... 69, 70 effrt de test enregistrement de résultats envirnnement de test... 17, 24, 26 erreur... 11, 51 estimatin d erreur... 18, 51 estimatin des tests estimatin et planificatin des tests examen... 8 exécutin de test... 39, 51, 71 exécutin des tests13, 15, 16, 34, 43, 53, 68 exigence... 13, 34, 36 exigences exigences de spécificatin exigences fnctinnelles... 24, 26 exigences nn-fnctinnelles... 24, 26 facteurs de succès faute fiabilité... 28, 69 flux de cntrôle... 39, 41 flux de dnnées fnctinnalité... 24, 28 framewrk de test framewrk de test unitaire gestin de cnfiguratin gestin des incidents gestin des tests gestin d'incident gestinnaire du test greffier Versin 2011 Page 79 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

80 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard harnais de tests... 69, 71 implémentatin de tests implémentatin des tests incident... 15, 66, 70 incnvénients de l'indépendance indépendance... 18, 55 inspectin... 35, 36, 37 intégratin... 24, 25, 39, 47, 48, 50 intrductin d un util dans une rganisatin 68 intrduire un util dans une rganisatin 75 ISO , 76 lancement langage de script... 73, 74 langage de scripting lgiciel lgiciel cmmercial sur étagère lgiciel dévelppé sur mesure maturité... 17, 35, 43 méprise métrique métriques... 35, 37 mdèle de dévelppement incrémental.. 22 mdèle de dévelppement itératif mdèle de dévelppement lgiciel mdèle en V mdèles de dévelppement lgiciel mdérateur... 35, 36, 37 mdificatins d urgence mt d actin niveau de test... 23, 41, 47, 50, 52 niveau de tests niveaux de tests... 21, 22, 24, 28 bjectif de test... 51, 52 bjectifs de cnnaissance 8, 10, 21, 33, 41, 53, 68 bjectifs de la qualificatin Certificat Fndatin bjectifs de la qualificatin internatinale 78 bjectifs des tests racle de test rdnnancement de l exécutin de tests 43 rganisatin des tests util d aide à l exécutin et à l enregistrement des tests util d aide à la gestin du test et des tests util d aide à la spécificatin des tests util d aide au test statique util d analyse dynamique util d analyse statique util d analyse statique util d exécutin util d exécutin de test util d exécutin de tests... 43, 73 util d exécutin des tests util d exécutin des tests util de cnceptin de tests util de cnceptin de tests util de débgage util de gestin util de gestin d exigences util de gestin d incident util de gestin d incidents util de gestin de cnfiguratin util de gestin de cnfiguratin util de gestin des exigences util de gestin des tests... 70, 74 util de gestin des tests util de mesure de cuverture util de mdélisatin util de mdélisatin util de mnitring util de préparatin des dnnées de tests69 util de sécurité util de suivi des défauts util de supprt de perfrmance et de surveillance util de supprt de revues util de test de perfrmances util de test de sécurité util de test de stress util de test de stress util de test statique util de tests de charge util de tests de perfrmances util de tests unitaires et structurels util framewrk de test unitaire utils d analyse dynamique utils d analyse statique utils de gestin utils de gestin des tests utils de mesure de cuverture utils de préparatin des dnnées paradxe du pesticide partie prenante parties prenantes... 17, 27 partitins d équivalence patch pilte piltes plan de test... 15, 34 planificatin des tests... 15, 16, 54 planning d exécutin de tests plitique de test principes de test principes généraux prcédure de test... 15, 41, 43, 44 prcessus de dévelppement de test prduit sur étagère (COTS) prttypage qualité... 11, 13, 29, 41, 43, 71 rapprt d incident... 17, 66 rapprt de synthèse de tests rapprt de test Versin 2011 Page 80 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

81 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard Ratinal Unified Prcess (RUP) registre de test... 15, 71 relecture technique... 35, 36 répétable reprting des tests respnsabilités respnsable du test résultat attendu... 43, 74 résultats attendus réviseur... 35, 36 revue... 13, 34, 35, 36, 37, 38, 39 revue de pairs revue de pairs... 35, 37 revue frmelle... 35, 36 revue infrmelle... 35, 36 revue technique revue technique... 35, 36, 37 risque... 11, 43, 52 risque risque risque risque risque risque lié au prduit risque lié au prjet risque lié auprduit risque prjet risques liés à l utilisatin d utils rôle... 35, 36, 37, 57 scribe... 35, 36 script capturé script de test... 16, 34, 43, 44 sécurité sélectinner les techniques de tests séquences de transactin simulateur surces d infrmatins spécificatin de cas de test spécificatin de cas de test spécificatin de prcédure de test... 41, 43 spécificatin des cas de test spécificatins fnctinnelles stratégie de test... 15, 58, 59 structure de test unitaire suite de test suite de tests suivi... 35, 36, 37 suivi de l avancement des tests suivi des tests supprt d utils supprt utillé supprt utillé des tests supprt par les utils... 68, 73 table de décisins tâches tâches des testeurs tâches du respnsable de test Tâches du respnsable des tests tâches fnctinnelles taux de défaillance technique basée sur l expérience... 42, 45 technique basée sur la structure... 45, 50 technique basée sur les spécificatins42, 45 technique basée sur les spécificatins technique bîte blanche technique bîte nire... 41, 45 technique de cnceptin basée sur la structure technique de cnceptin bîte blanche.. 49 technique de cnceptin de test... 41, 45 technique de cnceptin de tests technique de test technique statique techniquebaséesurl expérience techniques de cnceptin de tests techniques statiques test... 11, 13 test basé sur les cas d utilisatin test basé sur les risques test basé sur les spécificatins test basé sur les structures test d acceptatin usine test d intégratin test d intégratin de cmpsants test de charge test de cmpsant... 41, 48, 49 test de cnfirmatin test de régressin test de stress test de transitin d états... 47, 48 test des décisins test dynamique... 34, 39 test fnctinnel test indépendant test statique test structurel... 28, 50 tester testeur... 36, 48, 51, 55 tests alpha tests basés sur la structure tests bîte blanche... 28, 49 tests bîte nire tests d acceptatin cntractuelle... 24, 27 tests d acceptatin pératinnelle tests d acceptatin sur site tests d acceptatin utilisateur tests d acceptatin utilisateurs tests d intégratin... 24, 39 tests d intégratin système tests d interpérabilité tests d utilisabilité... 28, 29 tests de cas d utilisatin... 47, 48 tests de charge... 28, 29 tests de cmpsant Versin 2011 Page 81 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard

82 Syllabus Niveau Fndatin Cmité Lgiciels Internatinal Sftware Testing Qualificatins Bard tests de cnfirmatin tests de fiabilité... 28, 29 tests de maintenabilité... 28, 29 tests de maintenance... 21, 31 tests de perfrmances... 28, 29 tests de prtabilité... 28, 29 tests de régressin tests de rbustesse tests de sécurité tests de stress... 28, 29 tests des décisins tests des instructins tests et qualité tests exhaustifs tests explratires tests fnctinnels tests nn-fnctinnels tests pératinnels tests par tables de décisins tests piltés par les dnnées tests piltés par mts clé tests structurels... 28, 49 tests sur le terrain... 24, 27 tests système testware... 15, 16 tp-dwn traçabilité... 43, 56 types d util de test types d utils de test... 69, 70 types de tests... 21, 28 utilisabilité validatin vérificatin Versin 2011 Page 82 de 80 3-Nv- Internatinal Sftware Testing Qualificatins Bard