ISTQB CTFL Syllabus Niveau Fondation v4.0 PDF

Testeur Certiﬁé Syllabus Niveau Fondation v4.0 (version remise en page EQL) INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD COMITÉ FRANÇAIS DES TESTS LOGICIELS © International Software Testing Qualiﬁcations Board v4.0 4 Ce document a pour objet de vous proposer une version améliorée du Syllabus, aﬁn d’en faciliter l’étude, tant en ce qui concerne la lecture que la compréhension. Il reprend le texte intégral du Syllabus ISTQB Foundation v.4, remis en page, en y ajoutant des notes de bas de page, des éclaircissements et des exemples, clairement identiﬁés par « Note EQL ». La section 7.4 a été ajoutée (p.119 à 131), aﬁn d’apporter un éclairage sur les articles proposés par le Syllabus dans la section 7.3. Les livres proposés dans la section 7.2 font l’objet d’une présentation individuelle dans un document distinct, en raison du volume de celui-ci (170 pages). Table des matières INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD........................................... 4 0. INTRODUCTION........................................................................................................................... 9 0.1. OBJECTIF DE CE SYLLABUS...................................................................................................... 9 0.2. LE NIVEAU FONDATION POUR LES TESTEURS DE LOGICIELS CERTIFIÉS................................................ 9 0.3. PARCOURS DE CARRIÈRE POUR LES TESTEURS............................................................................ 10 0.4. OBJECTIFS MÉTIERS.............................................................................................................. 10 0.5. OBJECTIFS D'APPRENTISSAGE EXAMINABLES ET NIVEAUX DE CONNAISSANCE................................... 11 0.6. L'EXAMEN DE CERTIFICATION DE NIVEAU FONDATION................................................................... 12 0.7. ACCRÉDITATION.................................................................................................................. 12 0.8. PRISE EN COMPTE DES NORMES.............................................................................................. 13 0.9. RESTER À JOUR.................................................................................................................... 13 1. Fondamentaux des tests – 180 minutes........................................................... 16 1.1 Qu'est-ce que le test?..................................................................................................... 18 1.1.1 Objectifs du test.......................................................................................................... 19 1.1.2 Test et débogage......................................................................................................... 20 1.2 Pourquoi est-il nécessaire de tester ?.............................................................................. 20 1.2.1 Contributions du test au succès.................................................................................. 21 1.2.2 Test et assurance qualité............................................................................................. 21 1.2.3 Erreurs, défauts, défaillances et causes racine............................................................. 22 1.3 Principes du test............................................................................................................. 23 1.4 Activités de test, testware et rôles dans le test................................................................. 24 © International Software Testing Qualiﬁcations Board v4.0 5 1.4.1 Activités et tâches de test............................................................................................ 25 1.4.2 Le processus de test selon le contexte......................................................................... 27 1.4.3 Testware..................................................................................................................... 29 1.4.4 Traçabilité entre base de test et testware...................................................................... 30 1.4.5 Rôles dans le test........................................................................................................ 31 1.4.6 Compétences essentielles et bonnes pratiques en matière de test.............................. 32 2 Tester tout au long du cycle de vie du développement logiciel – 130 minutes... 36 2.1 Tester dans le contexte d'un cycle de vie du développement logiciel................................. 37 2.1.1 Impact du cycle de vie du développement logiciel sur le test......................................... 38 2.1.2 Cycle de vie du développement logiciel et bonnes pratiques de test............................. 39 2.1.3 Le test en tant que moteur du développement de logiciels............................................ 39 2.1.4 DevOps et tests........................................................................................................... 40 2.1.5 Approche shift left....................................................................................................... 42 2.1.6 Rétrospectives et amélioration de processus............................................................... 44 2.2 Niveaux de test et types de test....................................................................................... 45 2.2.1 Niveaux de test........................................................................................................... 46 2.2.2 Types de test............................................................................................................... 48 2.2.3 Test de conﬁrmation et test de régression..................................................................... 50 2.3 Test de maintenance....................................................................................................... 52 3 Test statique – 80 minutes............................................................................. 53 3.1 Bases du test statique..................................................................................................... 55 3.1.1 Produits d'activités examinables par le test statique..................................................... 55 3.1.2 Valeur du test statique................................................................................................. 56 3.1.3 Différences entre le test statique et le test dynamique.................................................. 57 3.2 Processus de feedback et de revue.................................................................................. 58 3.2.1 Bénéﬁces d'un feedback précoce et fréquent des parties prenantes............................. 58 3.2.2 Activités du processus de revue................................................................................... 59 3.2.3 Rôles et responsabilités dans les revues...................................................................... 60 3.2.4 Types de revues.......................................................................................................... 61 3.2.5 Facteurs de réussite des revues................................................................................... 63 4 Analyse et conception des tests – 390 minutes............................................... 64 4.1 Aperçu des techniques de test........................................................................................ 65 4.2 Techniques de test boîte noire......................................................................................... 66 © International Software Testing Qualiﬁcations Board v4.0 6 4.2.1 Partitions d'équivalence.............................................................................................. 66 4.2.2 Analyse des valeurs limites.......................................................................................... 68 4.2.3 Test par tables de décisions......................................................................................... 70 4.2.4 Test de transition d'état............................................................................................... 76 4.3 Techniques de test boîte blanche.................................................................................... 81 4.3.1 Test des instructions et couverture des instructions...................................................... 82 4.3.2 Test des branches et couverture des branches............................................................. 82 4.3.3 La valeur des tests boîte blanche................................................................................. 84 4.4 Techniques de tests basés sur l'expérience...................................................................... 84 4.4.1 Estimation d'erreurs.................................................................................................... 84 4.4.2 Test exploratoire.......................................................................................................... 85 4.4.3 Test basé sur des checklists........................................................................................ 86 4.5 Approches de test basées sur la collaboration................................................................. 87 4.5.1 Rédaction collaborative d’User Stories......................................................................... 87 4.5.2 Critères d'acceptation................................................................................................. 88 4.5.3 Développement piloté par les tests d'acceptation (ATDD)............................................. 89 5 Gestion des activités de test – 335 minutes.................................................... 91 5.1 Planiﬁcation des tests..................................................................................................... 92 5.1.1 Objet et contenu d'un plan de test............................................................................... 92 5.1.2 Contribution du testeur à la planiﬁcation des itérations et des releases......................... 93 5.1.3 Critères d'entrée et critères de sortie............................................................................ 94 5.1.4 Techniques d'estimation.............................................................................................. 95 5.1.5 Priorisation des cas de test.......................................................................................... 96 5.1.6 Pyramide des tests...................................................................................................... 97 5.1.7 Les quadrants de tests................................................................................................ 98 5.2 Gestion des risques........................................................................................................ 99 5.2.1 Déﬁnition du risque et attributs du risque................................................................... 100 5.2.2 Risques projet et risques produit................................................................................ 100 5.2.3 Analyse des risques produits..................................................................................... 101 5.2.4 Contrôle des risques produit..................................................................................... 103 5.3 Pilotage des tests, contrôle des tests et clôture des tests............................................... 103 5.3.1 Métriques utilisées pour les tests............................................................................... 104 5.3.2 Objet, contenu et destinataires des rapports de tests................................................. 105 © International Software Testing Qualiﬁcations Board v4.0 7 5.3.3 Communication de l'état d'avancement des tests...................................................... 107 5.4 Gestion de conﬁguration............................................................................................... 107 5.5 Gestion des défauts...................................................................................................... 108 6 Outils de test – 20 minutes...........................................................................111 6.1 Les outils pour soutenir les tests................................................................................... 112 6.2 Avantages et risques de l'automatisation des tests......................................................... 112 7 Références..................................................................................................115 7.1 Standards.................................................................................................................... 115 7.2 Livres........................................................................................................................... 115 7.3 Articles et pages web.................................................................................................... 118 7.4 NOTE EQL : Développement des articles et pages web................................................... 119 8 Annexe A - Objectifs d'apprentissage/Niveau de connaissance......................132 9 Annexe B - Matrice de traçabilité des objectifs métiers avec les objectifs d'apprentissage 134 10 Annexe C - Notes de livraison ("Release Notes").......................................150 11 Index......................................................................................................153 © International Software Testing Qualiﬁcations Board v4.0 8 0. INTRODUCTION 0.1. OBJECTIF DE CE SYLLABUS Ce syllabus forme la base du niveau Fondation de la qualiﬁcation internationale en tests de logiciels. L’International Software Testing Qualiﬁcations Board (ISTQB®) et le Comité Français des Tests Logiciels (ci-après appelé CFTL) fournissent ce syllabus comme suit : aux Membres de l’ISTQB, aﬁn de traduire dans leur langue locale et d'accréditer les fournisseurs de formation. Les Membres peuvent adapter ce syllabus à leurs besoins linguistiques particuliers et ajouter des références pour l'adapter à leurs publications locales. aux organismes de certiﬁcation, aﬁn de produire les questions d'examen dans leur langue locale en fonction des objectifs d'apprentissage pour ce syllabus. aux organismes de formation, aﬁn de produire le matériel de formation et déterminer les méthodes pédagogiques appropriées. aux candidats à la certiﬁcation, pour se préparer à l'examen de certiﬁcation (dans le cadre d'un cours de formation ou indépendamment). à la communauté internationale de l'ingénierie des logiciels et des systèmes, pour faire progresser les pratiques professionnelles en tests de logiciels et de systèmes, et comme base pour des livres articles. 0.2. LE NIVEAU FONDATION POUR LES TESTEURS DE LOGICIELS CERTIFIÉS La certiﬁcation de niveau Fondation s'adresse à toute personne impliquée dans les tests de logiciels. Il s'agit notamment des testeurs, des analystes de test, des ingénieurs de test, des consultants en test, des test managers, des développeurs de logiciels et des membres de l'équipe de développement. Cette qualiﬁcation de niveau Fondation convient également à toute personne souhaitant avoir une compréhension de base des tests de logiciels, comme les chefs de projets, les responsables qualité, les Product Owners, les responsables du développement de logiciels, les analystes métier, les directeurs informatiques et les consultants en management. © International Software Testing Qualiﬁcations Board v4.0 9 Les titulaires du certiﬁcat de niveau Fondation pourront accéder à des certiﬁcations de niveau supérieur en matière de tests de logiciels. 0.3. PARCOURS DE CARRIÈRE POUR LES TESTEURS Le programme de l'ISTQB® apporte un soutien aux professionnels du test à tous les stades de leur carrière, en leur offrant des connaissances à la fois étendues et approfondies. Les personnes ayant obtenu la certiﬁcation ISTQB® de niveau Fondation peuvent également être intéressées par les niveaux Avancés principaux (Analyste de Test, Analyste Technique de Test et Test Manager) et par la suite le niveau Expert (Management des tests ou Amélioration du processus de test). Toute personne cherchant à développer ses compétences en matière de pratiques de test dans un environnement Agile pourrait envisager les certiﬁcations Testeur Technique Agile ou "Agile Test Leadership at Scale". La ﬁlière Spécialiste offre une connaissance approfondie des domaines qui ont des approches de test et des activités de test spéciﬁques (par exemple, dans l'automatisation des tests, les tests d'IA, les tests basés sur des modèles, les tests d'applications mobiles) ; qui sont liés à des domaines de test spéciﬁques (par exemple, les tests de performance, les tests d'utilisabilité, les tests d'acceptation, les tests de sécurité) ; ou qui regroupent le savoir-faire en matière de tests pour certains domaines industriels (par exemple, l'automobile ou les jeux). Pour obtenir les dernières informations sur le programme de certiﬁcation des testeurs de l'ISTQB® et du CFTL, veuillez consulter les sites www.istqb.org et www.cftl.fr. 0.4. OBJECTIFS MÉTIERS Cette section liste les 14 objectifs métiers attendus d'une personne ayant obtenu la certiﬁcation de Niveau Fondation. © International Software Testing Qualiﬁcations Board v4.0 10 Un testeur certiﬁé Niveau Fondation peut … FL-BO1 Comprendre ce qu'est le test et pourquoi il est bénéﬁque FL-BO2 Comprendre les concepts fondamentaux du test logiciel Identiﬁer l'approche et les activités de test à mettre en œuvre FL-BO3 en fonction du contexte du test FL-BO4 Évaluer et améliorer la qualité de la documentation FL-BO5 Accroître l'efficacité et l'efficience des tests Aligner le processus de test sur le cycle de vie du FL-BO6 développement logiciel FL-BO7 Comprendre les principes de la gestion des tests Rédiger et communiquer des rapports de défauts clairs et FL-BO8 compréhensibles Comprendre les facteurs qui inﬂuencent les priorités et les FL-BO9 efforts liés aux tests FL-BO10 Travailler au sein d'une équipe interfonctionnelle Connaître les risques et les bénéﬁces liés à l'automatisation FL-BO11 des tests FL-BO12 Identiﬁer les compétences essentielles requises pour le test FL-BO13 Comprendre l'impact des risques sur les tests Rendre compte efficacement de l'état d'avancement et de la FL-BO14 qualité des tests 0.5. OBJECTIFS D'APPRENTISSAGE EXAMINABLES ET NIVEAUX DE CONNAISSANCE © International Software Testing Qualiﬁcations Board v4.0 11 Les objectifs d'apprentissage soutiennent les objectifs métier et sont utilisés pour créer les examens Testeur Certiﬁé de niveau Fondation. En général, tous les contenus des chapitres 1 à 6 de ce syllabus sont examinables au niveau K1. C'est-à-dire qu'il peut être demandé au candidat de reconnaître, de se souvenir ou de rappeler un mot-clé ou un concept mentionné dans l'un des six chapitres. Les niveaux spéciﬁques des objectifs d'apprentissage sont indiqués au début de chaque chapitre et classés comme suit: K1: se souvenir K2: comprendre K3: appliquer Des détails supplémentaires et des exemples d'objectifs d'apprentissage sont donnés dans l'annexe A. Tous les termes listés comme mots-clés, juste en dessous des titres des chapitres, doivent être mémorisés (K1), même s'ils ne sont pas explicitement mentionnés dans les objectifs d'apprentissage. 0.6. L'EXAMEN DE CERTIFICATION DE NIVEAU FONDATION L'examen de certiﬁcation du niveau Fondation est basé sur ce syllabus. Les réponses aux questions de l'examen peuvent nécessiter l'utilisation d'éléments basés sur plus d'une section de ce syllabus. Toutes les sections du syllabus sont examinables, à l'exception de l'introduction et des annexes. Le contenu des standards et des livres inclus comme référence (chapitre 7), n'est pas examinable au-delà des extraits résumés dans le syllabus lui- même. Se référer au document Structures et règles de l'examen de Niveau Fondation. 0.7. ACCRÉDITATION Un Membre de l'ISTQB® peut accréditer des organismes de formation dont le matériel de formation suit ce syllabus. Les organismes de formation doivent obtenir les directives d'accréditation auprès du Membre ou de l'organisme qui effectue l'accréditation. Un cours accrédité est reconnu comme étant conforme à ce syllabus et peut comporter un examen de l'ISTQB®. © International Software Testing Qualiﬁcations Board v4.0 12 Les directives d'accréditation pour ce syllabus suivent les directives générales d'accréditation publiées par le groupe de travail sur la gestion des processus et la conformité. 0.8. PRISE EN COMPTE DES NORMES Certaines normes sont référencées dans le syllabus de base (par exemple, les normes IEEE ou ISO). Ces références fournissent un cadre (comme les références à la norme ISO 25010 concernant les caractéristiques de qualité) ou une source d'informations supplémentaires si le lecteur le souhaite. Les documents de normalisation ne sont pas destinés à être examinés. Pour plus d'informations sur les normes, voir le chapitre 7. 0.9. RESTER À JOUR L'industrie du logiciel évolue rapidement. Pour faire face à ces changements et permettre aux parties prenantes d'accéder à des informations pertinentes et actuelles, les groupes de travail de l'ISTQB® ont créé des liens sur le site web www.istqb.org, qui renvoient à des documents complémentaires et à des modiﬁcations apportées aux normes. Ces informations ne sont pas examinables dans le cadre du syllabus de niveau Foundation. 0.10 NIVEAU DE DÉTAIL Le niveau de détail de ce syllabus permet de proposer des formations et des examens cohérents à l'échelle internationale. Pour atteindre cet objectif, le syllabus se compose: o Des objectifs généraux d’instruction, décrivant les intentions du niveau Fondation o D’une liste de termes (mots-clés) que les candidats doivent être capables de mémoriser o Des objectifs d'apprentissage pour chaque domaine de connaissance, décrivant les résultats d'apprentissage cognitifs à atteindre o D’une description des concepts clés, y compris des références à des sources reconnues © International Software Testing Qualiﬁcations Board v4.0 13 Le contenu du syllabus n'est pas une description de l'ensemble du domaine de connaissance des tests de logiciels ; il reﬂète le niveau de détail à couvrir dans les cours de formation de niveau Fondation. Il se concentre sur les concepts et techniques de test qui peuvent être appliqués à tous les projets logiciels indépendamment du Cycle de Vie du Développement Logiciel employé. 0.11 ORGANISATION DU SYLLABUS Il y a six chapitres qui comportent un contenu pouvant être examiné. Le titre de niveau supérieur de chaque chapitre indique le temps de formation pour le chapitre. Le minutage n'est pas fourni en dessous du niveau du chapitre. Pour les formations accréditées, le syllabus exige un minimum de 18,75 heures (18 heures et 55 minutes) d'enseignement, réparties entre les six chapitres comme suit: Chapitre 1 : Fondamentaux des tests (180 minutes) o Le candidat apprend les principes de base sur les tests, les raisons pour lesquelles les tests sont requis et quels sont les objectifs des tests. o Le candidat comprend le processus de test, les principales activités de test et le testware. o Le candidat comprend les compétences essentielles pour les tests. Chapitre 2 : Tester tout au long du développement logiciel (130 minutes) o Le candidat apprend comment les tests sont intégrés dans les différentes approches de développement. o Le candidat apprend les concepts des approches pilotées par les tests, ainsi que DevOps. o Le candidat apprend les différents niveaux de test, les types de test et les tests de maintenance. Chapitre 3 : Test statique (80 minutes) o Le candidat apprend les bases du test statique, le processus de feedback et de revue. © International Software Testing Qualiﬁcations Board v4.0 14 Chapitre 4 : Analyse et conception des tests (390 minutes) o Le candidat apprend à appliquer les techniques de test boîte noire, boîte blanche et les techniques de test basées sur l'expérience pour dériver des cas de test à partir de divers produits activités. o Le candidat apprend à connaître l'approche de test basée sur la collaboration. Chapitre 5 : Gestion des activités de test (335 minutes) o Le candidat apprend à planiﬁer les tests en général et à estimer l'effort de test. o Le candidat apprend comment les risques peuvent inﬂuencer le périmètre des tests. o Le candidat apprend à piloter et contrôler les activités de test o Le candidat apprend comment la gestion de la conﬁguration soutient les tests. o Le candidat apprend à rapporter les défauts d'une manière claire et compréhensible. Chapitre 6: Outils de test (20 minutes) o Le candidat apprend à classer les outils et à comprendre les risques et les bénéﬁces de l'automatisation des tests. © International Software Testing Qualiﬁcations Board v4.0 15 1. Fondamentaux des tests – 180 minutes Mots-clés couverture, débogage, défaut, erreur, défaillance, qualité, assurance qualité, cause racine, analyse de test, base de test, cas de test, clôture des tests, condition de test, contrôle des tests, données de test, conception des tests, exécution des tests, implémentation des tests, pilotage des tests, objet de test, objectif de test, planiﬁcation des tests, procédure de test, résultat de test, test, testware, validation, vériﬁcation. Objectifs d’apprentissage pour le chapitre 1: 1.1 Qu'est-ce que le test ? FL-1.1.1 (K1) Identiﬁer les objectifs habituels du test FL-1.1.2 (K2) Faire la différence entre tester et déboguer 1.2 Pourquoi est-il nécessaire de tester? FL-1.2.1 (K2) Donner des exemples montrant la nécessité des tests FL-1.2.2 (K1) Rappeler la relation entre les tests et assurance qualité FL-1.2.3 (K2) Faire la distinction entre la cause racine, l'erreur, le défaut et la défaillance. 1.3 Principes du test FL-1.3.1 (K2) Expliquer les sept principes du test 1.4 Activités de test, testware et rôles dans le test FL-1.4.1 (K2) Résumer les différentes activités et tâches de test FL-1.4.2 (K2) Expliquer l'impact du contexte sur le processus de test FL-1.4.3 (K2) Différencier les composants du testware qui soutiennent les activités de test FL-1.4.4 (K2) Expliquer la valeur du maintien de la traçabilité FL-1.4.5 (K2) Comparer les différents rôles dans le test © International Software Testing Qualiﬁcations Board v4.0 16 1.5 Compétences essentielles et bonnes pratiques en matière de test FL-1.5.1 (K2) Donnez des exemples de compétences génériques requises pour le test FL-1.5.2 (K1) Rappeler les avantages de l'approche équipe intégrée FL-1.5.3 (K2) Distinguer les avantages et les inconvénients de l'indépendance du test © International Software Testing Qualiﬁcations Board v4.0 17 1.1 Qu'est-ce que le test? Retour Table des matières Les systèmes logiciels font partie intégrante de notre vie quotidienne. La plupart des gens ont déjà eu affaire à un logiciel qui ne fonctionnait pas comme prévu. Un logiciel qui ne fonctionne pas correctement peut entraîner de nombreux problèmes, notamment une perte d'argent, de temps ou de réputation de l'entreprise et, dans des cas extrêmes, des blessures ou la mort. Le test de logiciels permet d'évaluer la qualité des logiciels et de réduire le risque de défaillance en cours d'utilisation. Le test de logiciels est un ensemble d'activités visant à découvrir les défauts et à évaluer la qualité des artefacts logiciels. Ces artefacts, lorsqu'ils sont testés, sont connus sous le nom d'objets de test. Une idée fausse très répandue à propos du test (en tant qu’activité) est qu'il consiste uniquement à exécuter des tests (c'est-à-dire à faire fonctionner le logiciel et à vériﬁer les résultats des tests). Cependant, le test de logiciels comprend également d'autres activités et doit être aligné sur le cycle de vie du développement logiciel (voir chapitre 2). Une autre idée fausse et très répandue à propos du test est qu’il se concentre entièrement sur la vériﬁcation de l'objet de test. Si le test implique la vériﬁcation, c'est-à-dire le contrôle de la conformité du système aux exigences spéciﬁées, il implique également la validation, c'est-à-dire le contrôle de la conformité du système aux besoins des utilisateurs et des autres parties prenantes dans son environnement opérationnel. Le test peut être dynamique ou statique. Le test dynamique implique l'exécution du logiciel, ce qui n'est pas le cas du test statique. Le test statique comprend les revues (voir chapitre 3) et l'analyse statique. Le test dynamique utilise différents types de techniques de test et d'approches de test pour dériver des cas de test (voir chapitre 4). Le test n'est pas seulement une activité technique. Il doit également être correctement planiﬁé, géré, estimé, piloté et contrôlé (voir chapitre 5). Les testeurs utilisent des outils (voir chapitre 6), mais il est important de rappeler que le test est en grande partie une activité intellectuelle, exigeant des testeurs qu'ils aient des connaissances spécialisées, qu'ils utilisent des compétences analytiques © International Software Testing Qualiﬁcations Board v4.0 18 et qu'ils appliquent la pensée critique et la pensée systémique (Myers 2011, Roman 2018). Le standard ISO/IEC/IEEE 29119-1 fournit de plus amples informations sur les concepts du test de logiciels. 1.1.1 Objectifs du test Retour Table des matières Les objectifs typiques du test sont les suivants: Évaluer les produits d'activités tels que les exigences, les User Stories, les conceptions et le code. Provoquer des défaillances et trouver des défauts. Assurer la couverture requise d'un objet de test. Réduire le niveau de risque d'une qualité logicielle insuffisante. Vériﬁer si les exigences spéciﬁées ont été satisfaites. Vériﬁer qu'un objet de test est conforme aux exigences contractuelles, légales et réglementaires. Fournir des informations aux parties prenantes pour leur permettre de prendre des décisions éclairées. Construire la conﬁance dans la qualité de l'objet de test. Valider si l'objet de test est complet et fonctionne comme attendu par les parties prenantes. Les objectifs du test peuvent varier en fonction du contexte, qui comprend le produit d'activités testé, le niveau de test, les risques, le cycle de vie du développement logiciel (SDLC) suivi les facteurs liés au contexte métier, par exemple o la structure de l'entreprise, o les considérations concurrentielles o le délai de mise sur le marché. © International Software Testing Qualiﬁcations Board v4.0 19 1.1.2 Test et débogage Le test et le débogage sont des activités distinctes. Les tests peuvent déclencher des défaillances causées par des défauts dans le logiciel (test dynamique) ou constater directement des défauts dans l'objet de test (test statique). Lorsque le test dynamique (voir chapitre 4) déclenche une défaillance, le débogage consiste à trouver les causes de cette défaillance (défauts), à analyser ces causes et à les éliminer. Dans ce cas, le processus de débogage typique implique les tâches suivantes: Reproduction d'une défaillance. Diagnostic (trouver la cause racine). Correction de la cause. Un test de conﬁrmation ultérieur permet de vériﬁer si les correctifs apportés ont résolu le problème. De préférence, le test de conﬁrmation est effectué par la même personne que celle qui a réalisé le test initial. Des tests de régression ultérieurs peuvent également être effectués pour vériﬁer si les corrections entraînent des défaillances dans d'autres parties de l'objet de test (voir la section 2.2.3 pour plus d'informations sur les tests de conﬁrmation et les tests de régression). Lorsque le test statique identiﬁe un défaut, le débogage consiste à l'éliminer. Il n'est pas nécessaire de le reproduire ou de le diagnostiquer, puisque le test statique constate directement les défauts et ne peut pas provoquer de défaillances (voir chapitre 3). 1.2 Pourquoi est-il nécessaire de tester ? Retour Table des matières Le test, en tant que forme de contrôle de la qualité, aide à atteindre les objectifs convenus dans les limites du périmètre, du temps, de la qualité et du budget impartis. La contribution du test au succès ne doit pas être limitée aux activités de l'équipe de test. Toute partie prenante peut utiliser ses compétences en matière de test pour rapprocher le projet de la réussite. © International Software Testing Qualiﬁcations Board v4.0 20 Le test des composants, des systèmes et de la documentation associée permet d'identiﬁer des défauts dans les logiciels. 1.2.1 Contributions du test au succès Le test est un moyen efficace et peu coûteux de détecter des défauts. Ces défauts peuvent ensuite être éliminés (par débogage - une activité qui ne relève pas du test), de sorte que le test contribue indirectement à l'obtention d'objets de test de meilleure qualité. Le test fournit un moyen d'évaluer directement la qualité d'un objet de test à différents stades du cycle de vie du développement logiciel. Ces mesures sont utilisées dans le cadre d'une activité de gestion de projet plus large, contribuant aux décisions de passer à l'étape suivante du cycle de vie du développement logiciel, telle que la décision de procéder à la livraison. Le test offre aux utilisateurs une représentation indirecte du projet de développement. Les testeurs veillent à ce que leur compréhension des besoins des utilisateurs soit prise en compte tout au long du cycle de vie du développement logiciel. L'autre solution consisterait à impliquer un ensemble représentatif d'utilisateurs dans le projet de développement, ce qui n'est généralement pas possible en raison des coûts élevés et du manque de disponibilité des utilisateurs adéquats. Le test peut également être requis pour répondre à des exigences contractuelles ou légales, ou pour se conformer à des standards réglementaires. 1.2.2 Test et assurance qualité Retour Table des matières Bien que les termes "test" et "assurance qualité" (Quality Assurance, QA) soient souvent utilisés de manière interchangeable, ils ne sont pas les mêmes. Le test est une forme de contrôle de la qualité (Quality Control, QC). Le contrôle de la qualité (QC) est une approche corrective axée sur le produit, qui se concentre sur les activités permettant d'atteindre des niveaux de qualité appropriés. Le test constitue une forme majeure de contrôle de la qualité, tandis que d'autres incluent les méthodes formelles (modèle de test et preuve d'exactitude), la simulation et le prototypage. © International Software Testing Qualiﬁcations Board v4.0 21 L'assurance qualité (QA) est une approche préventive axée sur les processus, qui se concentre sur la mise en œuvre et l'amélioration des processus. Elle part du principe que si un bon processus est suivi correctement, il générera un bon produit. L'assurance qualité s'applique à la fois aux processus de développement et de test, et relève de la responsabilité de tous les acteurs d'un projet. Les résultats de test sont utilisés par l'assurance qualité et le contrôle de la qualité. Dans le cadre du contrôle de la qualité, ils servent à corriger les défauts, tandis que dans le cadre de l'assurance qualité, ils fournissent un retour d'information sur l'efficacité des processus de développement et de test. 1.2.3 Erreurs, défauts, défaillances et causes racine Retour Table des matières Les êtres humains commettent des erreurs, qui produisent des défauts (fautes, bogues), lesquels peuvent à leur tour entraîner des défaillances. Les êtres humains commettent des erreurs pour diverses raisons, telles que la pression du temps, la complexité des produits d'activités, des processus, de l'infrastructure ou des interactions, ou simplement parce qu'ils sont fatigués ou qu'ils n'ont pas reçu une formation adéquate. Les défauts peuvent se trouver dans la documentation, comme une spéciﬁcation des exigences ou un script de test, dans le code source ou dans un artefact de support tel qu'un ﬁchier de build. S'ils ne sont pas détectés, les défauts dans les artefacts produits au début du cycle de vie du développement logiciel conduisent souvent à des artefacts défectueux plus tard dans le cycle de vie. Si un défaut dans le code est exécuté, le système peut ne pas faire ce qu'il devrait faire ou faire quelque chose qu'il ne devrait pas faire, ce qui entraîne une défaillance. Certains défauts entraîneront toujours une défaillance s'ils sont exécutés, tandis que d'autres n'entraîneront une défaillance que dans des circonstances spéciﬁques, et d'autres encore n'entraîneront jamais de défaillance. © International Software Testing Qualiﬁcations Board v4.0 22 Les erreurs et les défauts ne sont pas les seules causes de défaillance. Les défaillances peuvent également être causées par les conditions environnementales, par exemple lorsque les radiations ou les champs électromagnétiques provoquent des défauts dans les microprogrammes. Une cause racine est une raison fondamentale de l'apparition d'un problème (par exemple, une situation qui conduit à une erreur). Les causes racines sont identiﬁées par l'analyse des causes racines, qui est généralement effectuée lorsqu'une défaillance se produit ou qu'un défaut est identiﬁé. On estime qu'il est possible d'éviter d'autres défaillances ou défauts similaires ou de réduire leur fréquence en s'attaquant à la cause racine, par exemple en la supprimant. 1.3 Principes du test Retour Table des matières Un certain nombre de principes du test, offrant des lignes directrices générales applicables à tous les tests, ont été proposés au ﬁl des ans. Ce syllabus décrit sept de ces principes. o Le test montre la présence, et non l'absence, de défauts. o Le test peut montrer que des défauts sont présents dans l'objet de test, mais ne peut pas prouver qu'il n'y a pas de défauts (Buxton 1970). Le test réduit la probabilité que des défauts ne soient pas découverts dans l'objet de test, mais même si aucun défaut n'est trouvé, le test ne peut pas prouver que l'objet de test est correct. o Le test exhaustif est impossible. Il n'est pas possible de tout tester, sauf dans les cas triviaux (Manna 1978). Plutôt que d'essayer de tester de manière exhaustive, les techniques de test (voir chapitre 4), la priorisation des cas de test (voir section 5.1.5) et le test basé sur les risques (voir section 5.2) doivent être utilisés pour concentrer les efforts de test. o Tester tôt économise du temps et de l'argent. Les défauts qui sont éliminés tôt dans le processus n'entraîneront pas de défauts ultérieurs dans les produits d'activités dérivés. Le coût de la qualité sera réduit puisque moins de défaillances se produiront plus tard © International Software Testing Qualiﬁcations Board v4.0 23 dans le cycle du développement logiciel (Boehm 1981). Pour trouver les défauts le plus tôt possible, les tests statiques (voir chapitre 3) et les tests dynamiques (voir chapitre 4) doivent être lancés le plus tôt possible. o Regroupement des défauts. Un petit nombre de composants du système contiennent généralement la plupart des défauts découverts ou sont responsables de la plupart des défaillances opérationnelles (Enders 1975). Ce phénomène est une illustration du principe de Pareto. o Les groupements de défauts prévus et les groupements de défauts réels observés pendant les tests ou en cours d'exploitation constituent une donnée d'entrée importante pour les tests basés sur les risques (voir section 5.2). o Usure des tests. Si les mêmes tests sont répétés plusieurs fois, ils deviennent de plus en plus inefficaces pour détecter de nouveaux défauts (Beizer 1990). Pour remédier à cet effet, il peut être nécessaire de modiﬁer les tests et les données de test existants, et de rédiger de nouveaux tests. Toutefois, dans certains cas, la répétition des mêmes tests peut avoir un effet bénéﬁque, par exemple dans les tests de régression automatisés (voir section 2.2.3). o Le test dépend du contexte. Il n'existe pas d'approche de test unique et universellement applicable. Les tests sont effectués différemment selon les contextes (Kaner 2011). o L'illusion de l'absence de défaut. Il est illusoire (c'est-à-dire erroné) de penser que la vériﬁcation d'un logiciel garantira le succès d'un système. Si l'on teste minutieusement toutes les exigences spéciﬁées et que l'on corrige tous les défauts constatés, on peut néanmoins obtenir un système qui ne répond pas aux besoins et aux attentes des utilisateurs, qui ne permet pas d'atteindre les objectifs métier du client et qui est inférieur à d'autres systèmes concurrents. Outre la vériﬁcation, il convient également de procéder à la validation (Boehm 1981). 1.4 Activités de test, testware et rôles dans le test Retour Table des matières © International Software Testing Qualiﬁcations Board v4.0 24 Le test dépend du contexte, mais, à un niveau élevé, il existe des ensembles communs d'activités de test sans lesquels le test a moins de chances d'atteindre les objectifs de test. Ces ensembles d'activités de test forment un processus de test. Le processus de test peut être adapté à une situation donnée en fonction de divers facteurs. Les activités de test qui sont incluses dans ce processus de test, la manière dont elles sont implémentées et le moment où elles ont lieu sont normalement décidés dans le cadre de la planiﬁcation des tests pour la situation spéciﬁque (voir section 5.1). Les sections suivantes décrivent les aspects généraux de ce processus de test en termes d'activités et de tâches de test, d'impact du contexte, de testware, de traçabilité entre la base de test et le testware, et de rôles de test. Le standard ISO/IEC/IEEE 29119-2 fournit de plus amples informations sur les processus de test. 1.4.1 Activités et tâches de test Retour Table des matières Un processus de test se compose généralement des principaux groupes d'activités décrits ci-dessous. Bien que nombre de ces activités semblent suivre une séquence logique, elles sont souvent mises en œuvre de manière itérative ou en parallèle. Ces activités de test doivent généralement être adaptées au système et au projet. La planiﬁcation des tests consiste à déﬁnir les objectifs du test, puis à sélectionner une approche qui permette d'atteindre au mieux les objectifs dans le cadre des contraintes imposées par le contexte général. La planiﬁcation des tests est expliquée plus en détail au point 5.1. Pilotage et contrôle des tests. Le pilotage des tests implique la vériﬁcation continue de toutes les activités de test et la comparaison des progrès réels par rapport au plan. Le contrôle des tests consiste à prendre les mesures nécessaires pour atteindre les objectifs du test. Le pilotage et le contrôle des tests sont expliqués plus en détail au point 5.3. © International Software Testing Qualiﬁcations Board v4.0 25 L'analyse de test comprend l'analyse de la base de test pour identiﬁer les caractéristiques testables et pour déﬁnir et prioriser les conditions de test associées, ainsi que les risques et les niveaux de risque correspondants (voir section 5.2). La base de test et les objets de test sont également évalués pour identiﬁer les défauts qu'ils peuvent contenir et pour évaluer leur testabilité. L'analyse de test est souvent soutenue par l'utilisation de techniques de test (voir chapitre 4). L'analyse de test répond à la question "que tester ?" en termes de critères de couverture mesurables. La conception des tests comprend l'élaboration des conditions de test dans des cas de test et autres éléments du testware (par exemple, chartes de test). Cette activité implique souvent l'identiﬁcation d'éléments de couverture, qui servent de guide pour spéciﬁer les entrées des cas de test. Les techniques de test (voir chapitre 4) peuvent être utilisées pour soutenir cette activité. La conception des tests comprend également la déﬁnition des exigences en matière de données de test, la conception de l'environnement de test et l'identiﬁcation de toute autre infrastructure et de tout autre outil nécessaires. La conception des tests répond à la question "comment tester ?". L'implémentation des tests comprend la création ou l'acquisition du testware nécessaire à l'exécution des tests (par exemple, les données de test). Les cas de test peuvent être organisés en procédures de test et sont souvent assemblés en suites de tests. Des scripts de test manuels et automatisés sont créés. Les procédures de test sont classées par ordre de priorité et organisées dans un calendrier d'exécution des tests pour une exécution efficiente des tests (voir section 5.1.5). L'environnement de test est construit et l'on vériﬁe qu'il est correctement conﬁguré. © International Software Testing Qualiﬁcations Board v4.0 26 L'exécution des tests comprend l'exécution des tests conformément au calendrier d'exécution des tests. L'exécution des tests peut être manuelle ou automatisée. L'exécution des tests peut prendre de nombreuses formes, notamment celle du test en continu ou de sessions de test en binôme. Les résultats réels des tests sont comparés aux résultats attendus. Les résultats des tests sont enregistrés. Les anomalies sont analysées aﬁn d'en identiﬁer les causes probables 1. Cette analyse nous permet de signaler les anomalies sur la base des défaillances observées (voir section 5.5). Les activités de clôture des tests ont généralement lieu lors des jalons du projet (par exemple, la livraison, la ﬁn de l'itération, la clôture d'un niveau de test) pour tous les défauts non résolus, les demandes de changement (ou les éléments créés dans le Product Backlog, en Agile). NB EQL : On parle de clôture à la ﬁn d’une itération comme à la ﬁn de la campagne, mais cette dernière est plus globale. Le testware qui pourrait être utile à l'avenir est identiﬁé et archivé ou remis aux équipes appropriées. L'environnement de test est arrêté dans un état convenu. Les activités de test sont analysées aﬁn d'identiﬁer les leçons apprises et les améliorations à apporter aux futures itérations, versions ou projets (voir section 2.1.6). Un rapport d'achèvement des tests est créé et communiqué aux parties prenantes. 1.4.2 Le processus de test selon le contexte Retour Table des matières Le test n'est pas effectué de manière isolée. Les activités de test font partie intégrante des processus de développement menés au sein d'une organisation. Le test est également ﬁnancé par les parties prenantes et son objectif ﬁnal est d'aider à répondre aux besoins métier des parties prenantes. Par conséquent, la manière dont le test est effectué dépendra d'un certain nombre de facteurs contextuels, notamment les suivants: 1 NOTE EQL : Attention ! « cause probable » = identiﬁer la donnée ou la procédure qui a causé l’anomalie. Mais PAS faire le travail du développeur qui va déboguer ! © International Software Testing Qualiﬁcations Board v4.0 27 o Parties prenantes : o besoins, o attentes, o exigences, o volonté de coopérer, etc. o Membres de l'équipe : o compétences, o connaissances, o niveau d'expérience, o disponibilité, o besoins de formation, etc. o Domaine d'activité : o criticité de l'objet de test, o risques identiﬁés, o besoins métier, o réglementations légales spéciﬁques, etc. o Facteurs techniques : o type de logiciel, o architecture du produit, o technologie utilisée, etc. o Contraintes du projet : o portée, o temps, o budget, o ressources, etc. o Facteurs organisationnels : o structure organisationnelle, o politiques existantes, o pratiques utilisées, etc. o Cycle de vie du développement logiciel : o pratiques d'ingénierie, o méthodes de développement, etc. o Outils : o disponibilité, o facilité d'utilisation, o conformité, etc. © International Software Testing Qualiﬁcations Board v4.0 28 Ces facteurs auront un impact sur de nombreuses exigences liées aux tests, notamment : la stratégie de test, les techniques de test utilisées, le degré d'automatisation des tests, le niveau de couverture requis, le niveau de détail de la documentation des tests, le reporting, etc. 1.4.3 Testware Retour Table des matières Les composants du testware sont créés en tant que produits d'activités issus des activités de test décrites dans la section 1.4.1. La manière dont les différentes organisations produisent, façonnent, nomment, organisent et gèrent leurs produits d'activités varie considérablement. Une bonne gestion de la conﬁguration (voir section 5.4) garantit la cohérence et l'intégrité des produits d'activités. La liste suivante de produits d'activités, classés par activité, n'est pas exhaustive: Planiﬁcation des tests : plan de test, calendrier des tests, référentiel des risques et critères de sortie (voir section 5.1). Le référentiel des risques est une liste de risques accompagnée de la probabilité du risque, de l'impact du risque et d'informations sur l'atténuation des risques (voir section 5.2). Le calendrier des tests, le référentiel des risques et les critères d'entrée et de sortie font souvent partie du plan de test. Pilotage et contrôle des tests: rapports d'avancement des tests (voir point 5.3.2), documentation des directives de contrôle (voir point 5.3) et informations sur les risques (voir point 5.2). Analyse de test: conditions de test ( priorisées) (par exemple, critères d'acceptation, voir section 4.5.2), et rapports de défauts concernant les défauts © International Software Testing Qualiﬁcations Board v4.0 29 dans la base de test (s'ils ne sont pas corrigés directement). Conception des tests: cas de test ( priorisés), chartes de test, éléments de couverture, exigences en matière de données de test et exigences en matière d'environnement de test. Implémentation des tests: procédures de test, scripts de test automatisés, suites de tests, données de test, calendrier d'exécution des tests, et éléments de l'environnement de test. Des éléments de l'environnement de test sont par exemple: les bouchons, les pilotes, les simulateurs et les virtualisations de services. Exécution des tests: logs de test et rapports de défaut (voir section 5.5). Complétude des tests: rapport de clôture des tests (voir section 5.3.2), mesures à prendre pour améliorer les projets ou itérations ultérieurs, leçons apprises documentées et demandes de changement (par exemple, en tant qu'éléments du product backlog). 1.4.4 Traçabilité entre base de test et testware Retour Table des matières Aﬁn d'implémenter un pilotage et un contrôle des tests efficaces, il est important d'établir et de maintenir la traçabilité tout au long du processus de test entre les éléments de la base de test, le testware associé à ces éléments (par exemple, les conditions de test, les risques, les cas de test), les résultats des tests et les défauts détectés Une traçabilité précise soutient l'évaluation de la couverture, il est donc très utile que des critères de couverture mesurables soient déﬁnis dans la base de test. Les critères de couverture peuvent servir d'indicateurs de performance clés (KPIs) pour piloter les activités qui montrent dans quelle mesure les objectifs du test ont été atteints (voir section 1.1.1). Par exemple: © International Software Testing Qualiﬁcations Board v4.0 30 La traçabilité des cas de test aux exigences permet de vériﬁer que les exigences sont couvertes par les cas de test. La traçabilité des résultats de test aux risques peut être utilisée pour évaluer le niveau de risque résiduel d'un objet de test. Outre l'évaluation de la couverture, une bonne traçabilité permet de déterminer l'impact des changements, facilite les audits de test et aide à répondre aux critères de gouvernance informatique. Une bonne traçabilité rend également les rapports d'avancement et de clôture des tests plus facilement compréhensibles en incluant le statut des éléments de la base de test. Cela peut également aider à communiquer les aspects techniques des tests aux parties prenantes, de manière compréhensible. La traçabilité fournit des informations permettant d'auditer la qualité du produit, la capacité du processus et l'avancement du projet par rapport aux objectifs métiers. 1.4.5 Rôles dans le test Retour Table des matières Dans ce syllabus, deux rôles principaux dans le test sont couverts : un rôle de test manager et un rôle de testeur. Les activités et les tâches assignées à ces deux rôles dépendent de facteurs tels que le contexte du projet et du produit, les compétences des personnes occupant ces rôles, et l'organisation. Le rôle de test manager implique une responsabilité globale pour le processus de test, l'équipe de test et la direction des activités de test. Le rôle de test manager est principalement axé sur les activités de planiﬁcation des tests, de pilotage et de contrôle des tests et de clôture des tests. La manière dont le rôle de test manager est exercé varie en fonction du contexte. Par exemple, dans le cadre du développement logiciel Agile, certaines des tâches du rôle de test manager peuvent être gérées par l'équipe Agile. © International Software Testing Qualiﬁcations Board v4.0 31 Les tâches qui s'étendent à plusieurs équipes ou à l'ensemble de l'organisation peuvent être réalisées par des test managers en dehors de l'équipe de développement. 2 Le rôle de testeur implique une responsabilité globale pour l'aspect technique des tests. Le rôle de testeur est principalement axé sur les activités d'analyse de test, de conception des tests, d'implémentation des tests et d'exécution des tests. Différentes personnes peuvent assumer ces rôles à différents moments. Par exemple, le rôle de test manager peut être assumé par un responsable de test, par un chef de projet de test, par un responsable des développements, etc. Il est également possible qu'une personne assume à la fois les rôles de testeur et de test manager. 1.4.6 Compétences essentielles et bonnes pratiques en matière de test Retour Table des matières La compétence est l'aptitude à bien faire quelque chose qui découle des connaissances, de la pratique et des aptitudes d'une personne. Les bons testeurs doivent posséder certaines compétences essentielles pour bien faire leur travail. Les bons testeurs doivent être des membres efficaces d'une équipe et doivent être capables de mener des tests à différents niveaux d'indépendance du test. 1.4.6.1 Compétences génériques requise pour le test Retour Table des matières Bien qu'elles soient génériques, les compétences suivantes sont particulièrement pertinentes pour les testeurs: Connaissance en matière de test (pour accroître l'efficacité des tests, par exemple en utilisant des techniques de test). Rigueur, attention, curiosité, souci du détail, méthode (pour identiﬁer les défauts, en particulier ceux qui sont difficiles à trouver). 2 Note EQL : On entend ici l’ « équipe de développement » au sens Agile, incluant développeurs et testeurs, càd tous ceux qui participent activement au développement du produit. © International Software Testing Qualiﬁcations Board v4.0 32 Bonne communication, écoute active, esprit d'équipe (pour interagir efficacement avec toutes les parties prenantes, pour transmettre des informations aux autres, pour se faire comprendre, et pour signaler et discuter des défauts). Réﬂexion analytique, esprit critique, créativité (pour accroître l'efficacité des tests). Connaissances techniques (pour accroître l'efficience des tests, par exemple en utilisant les outils de test appropriés). Connaissance du domaine (pour être en mesure de comprendre les utilisateurs ﬁnaux/représentants métier et de communiquer avec eux). Les testeurs sont souvent les porteurs de mauvaises nouvelles. C'est un trait humain courant que de blâmer le porteur de mauvaises nouvelles. C'est pourquoi les compétences en matière de communication sont cruciales pour les testeurs. La communication des résultats des tests peut être perçue comme une critique du produit et de son auteur. Le biais de conﬁrmation peut rendre difficile l'acceptation d'informations en désaccord avec les convictions actuelles. Certaines personnes peuvent percevoir le test comme une activité destructrice, alors qu'il contribue grandement à la réussite du projet et à la qualité du produit. Pour tenter d'améliorer cette perception, les informations sur les défauts et les défaillances doivent être communiquées de manière constructive. 1.4.6.2 Approche équipe intégrée Retour Table des matières L'une des compétences importantes pour un testeur est la capacité à travailler efficacement dans un contexte d'équipe et à contribuer positivement aux objectifs de l'équipe. L'approche équipe intégrée - une pratique issue de la programmation extrême (XP) (voir section 2.1) - repose sur cette compétence. Dans l'approche intégrée, tout membre de l'équipe disposant des connaissances et des compétences nécessaires peut effectuer n'importe quelle tâche, et chacun est responsable de la qualité. © International Software Testing Qualiﬁcations Board v4.0 33 Les membres de l'équipe partagent le même espace de travail (physique ou virtuel), car le regroupement facilite la communication et l'interaction. L'approche équipe intégrée améliore la dynamique d'équipe, la communication et la collaboration au sein de l'équipe, et crée une synergie en permettant aux différents ensembles de compétences au sein de l'équipe d'être exploités au proﬁt du projet. Les testeurs travaillent en étroite collaboration avec les autres membres de l'équipe aﬁn de garantir que les niveaux de qualité souhaités sont atteints. Ils collaborent notamment avec les représentants métier pour les aider à créer des tests d'acceptation adaptés et travaillent avec les développeurs pour convenir de la stratégie de test et décider des approches d'automatisation des tests. Les testeurs peuvent ainsi transférer leurs connaissances en matière de test aux autres membres de l'équipe et inﬂuencer le développement du produit. Selon le contexte, l'approche équipe intégrée n'est pas toujours appropriée. Par exemple, dans certaines situations, telles que les situations critiques pour la sécurité, un niveau élevé d'indépendance du test peut être nécessaire. 1.4.6.3 Indépendance du test Un certain degré d'indépendance rend le testeur plus efficace pour trouver des défauts en raison des différences entre les biais cognitifs de l'auteur et ceux du testeur (cf. Salman 1995). L'indépendance ne remplace toutefois pas la proximité ; par exemple, les développeurs peuvent trouver efficacement de nombreux défauts dans leur propre code. Les produits d'activités peuvent être testés par leur auteur (pas d'indépendance), les pairs de l'auteur appartenant à la même équipe (un peu d'indépendance), des testeurs extérieurs à l'équipe de l'auteur mais au sein de l'organisation (indépendance élevée), des testeurs extérieurs à l'organisation (indépendance très élevée). © International Software Testing Qualiﬁcations Board v4.0 34 Pour la plupart des projets, il est généralement préférable d'effectuer les tests avec plusieurs niveaux d'indépendance Par exemple : les développeurs effectuant les tests de composants et d'intégration de composants, l'équipe de test effectuant les tests de systèmes et d'intégration de systèmes, et les représentants métier effectuant les tests d'acceptation. Le principal avantage de l'indépendance du test est que les testeurs indépendants sont susceptibles de repérer différents types de défaillances et de défauts par rapport aux développeurs en raison de leurs différents antécédents, perspectives techniques et biais. En outre, un testeur indépendant peut vériﬁer, contester ou réfuter les hypothèses formulées par les parties prenantes lors de la spéciﬁcation et de la mise en œuvre du système. Cependant, il y a aussi quelques inconvénients. Les testeurs indépendants peuvent être isolés de l'équipe de développement, ce qui peut entraîner un manque de collaboration, des problèmes de communication ou une relation d'opposition avec l'équipe de développement. Les développeurs peuvent perdre le sens de la responsabilité en matière de qualité. Les testeurs indépendants peuvent être considérés comme un goulot d'étranglement ou être tenus pour responsables des retards dans la release. © International Software Testing Qualiﬁcations Board v4.0 35 2 Tester tout au long du cycle de vie du développement logiciel – 130 minutes Mots clés tests d'acceptation, tests boîte noire, tests d'intégration de composants, tests de composants, tests de conﬁrmation, tests fonctionnels, tests d'intégration, tests de maintenance, tests non fonctionnels, tests de régression, shift-left, tests d'intégration de systèmes, tests de systèmes, niveau de test, objet de test, type de test, tests boîte blanche. Objectifs d’apprentissage pour le chapitre 2: 2.1 Tester dans le contexte d'un cycle de vie du développement logiciel FL-2.1.1 (K2) Expliquer l'impact du cycle de vie du développement logiciel choisi sur le test FL-2.1.2 (K1) Rappeler les bonnes pratiques de test qui s'appliquent à tous les cycles de vie du développement logiciel FL-2.1.3 (K1) Rappeler des exemples d'approches de développement piloté par les tests FL-2.1.4 (K2) Résumer la façon dont DevOps pourrait avoir un impact sur le test FL-2.1.5 (K2) Expliquer l'approche shift-left FL-2.1.6 (K2) Expliquer comment les rétrospectives peuvent être utilisées comme mécanisme d'amélioration des processus. 2.2 Niveaux de test et types de test FL-2.2.1 (K2) Distinguer les différents niveaux de test FL-2.2.2 (K2) Distinguer les différents types de tests FL-2.2.3 (K2) Distinguer les tests de conﬁrmation des tests de régression 2.3 Tests de maintenance FL-2.3.1 (K2) Résumer les tests de maintenance et leurs déclencheurs © International Software Testing Qualiﬁcations Board v4.0 36 2.1 Tester dans le contexte d'un cycle de vie du développement logiciel Retour Table des matières Un modèle de cycle de vie du développement logiciel (SDLC : Software Development Life Cycle) est une représentation abstraite et de haut niveau du processus de développement logiciel. Un modèle de cycle de vie du développement logiciel déﬁnit la manière dont les différentes phases de développement et les types d'activités réalisées dans le cadre de ce processus sont liés les uns aux autres, à la fois logiquement et chronologiquement. Parmi les exemples de modèles, on peut citer : les modèles de développement séquentiel (par exemple, le modèle en cascade, le modèle en V), les modèles de développement itératif (par exemple, le modèle en spirale, le prototypage) et les modèles de développement incrémental (par exemple, le Processus Uniﬁé). Certaines activités au sein des processus de développement logiciel peuvent également être décrites par des méthodes de développement logiciel plus détaillées et des pratiques Agile. En voici quelques exemples : développement piloté par les tests d'acceptation (ATDD), développement piloté par le comportement (BDD), conception pilotée par le domaine (DDD), programmation extrême (XP), développement piloté par les fonctionnalités (FDD), Kanban, Lean IT, Scrum, et développement piloté par les tests (TDD). © International Software Testing Qualiﬁcations Board v4.0 37 2.1.1 Impact du cycle de vie du développement logiciel sur le test Retour Table des matières Pour réussir, le test doit être adapté au cycle de vie du développement logiciel. Le choix du cycle de vie du développement logiciel a une incidence sur: Le périmètre et le calendrier des activités de test (par exemple, les niveaux de test et les types de test). Le niveau de détail de la documentation des tests. Le choix des techniques de test et de l'approche de test. Le degré d'automatisation des tests. Le rôle et les responsabilités d'un testeur. Dans les modèles de développement séquentiel, au cours des phases initiales, les testeurs participent généralement à la revue des exigences, à l'analyse de test et à la conception des tests. 3 Le code exécutable est généralement créé [après,]dans les phases ultérieures, de sorte que les tests dynamiques ne peuvent généralement pas être effectués au début du cycle de vie du développement logiciel. Dans certains modèles de développement incrémental et itératif, on suppose que chaque itération fournit un prototype fonctionnant ou un incrément de produit. Cela implique qu'à chaque itération, des tests statiques et dynamiques peuvent être effectués à tous les niveaux de test. La livraison fréquente d'incréments nécessite un feedback rapide et des tests de régression poussés. Le développement logiciel agile part du principe que des changements peuvent intervenir tout au long du projet. C'est pourquoi les projets agiles privilégient une documentation légère des produits d'activités et une automatisation poussée des tests pour faciliter les tests de régression. En outre, [en agile] la plupart des tests manuels tendent à être effectués à l'aide de techniques de test basées sur l'expérience (voir section 4.4) qui ne nécessitent pas d'analyse et de conception des tests préalables approfondies. 3 Note EQL : Il s’agit là des tâches de la phase de PRÉPARATION de la Recette © International Software Testing Qualiﬁcations Board v4.0 38 2.1.2 Cycle de vie du développement logiciel et bonnes pratiques de test Retour Table des matières Les bonnes pratiques de test, indépendantes du modèle de cycle de vie du développement logiciel choisi, préconisent notamment que: o Pour chaque activité de développement logiciel, il existe une activité de test correspondante, de sorte que toutes les activités de développement sont soumises à un contrôle de qualité. Les différents niveaux de test (voir chapitre 2.2.1) ont des objectifs de test spéciﬁques et différents, ce qui permet aux tests d'être suffisamment complets tout en évitant la redondance. L'analyse et la conception des tests pour un niveau de test donné commencent pendant la phase de développement correspondante du cycle du développement logiciel, de sorte que les tests puissent adhérer au principe du test précoce (voir section 1.3). Les testeurs sont impliqués dans la revue des produits d'activités dès que les versions préliminaires de cette documentation sont disponibles, de sorte que ces tests et cette détection de défauts plus précoces puissent soutenir la stratégie shift left (voir section 2.1.5). 2.1.3 Le test en tant que moteur du développement de logiciels Retour Table des matières TDD, ATDD et BDD sont des approches de développement similaires, dans lesquelles les tests sont déﬁnis comme un moyen d'orienter le développement. © International Software Testing Qualiﬁcations Board v4.0 39 Chacune de ces approches implémente le principe des tests précoces (voir section 1.3) et suit une approche shift left (voir section 2.1.5), puisque les tests sont déﬁnis avant que le code ne soit écrit. Elles soutiennent un modèle de développement itératif. Ces approches se caractérisent comme suit: Développement piloté par les tests (TDD): Dirige le codage par le biais de cas de tests (au lieu d'une conception approfondie du logiciel) (Beck 2003). Les tests sont écrits en premier, puis le code est écrit pour satisfaire les tests, et enﬁn les tests et le code sont refactorisés 4. Développement piloté par les tests d'acceptation (ATDD) (voir section 4.5.3): Dérive des tests à partir des critères d'acceptation, dans le cadre du processus de conception des systèmes (Gärtner 2011). Les tests sont écrits avant que la partie de l'application ne soit développée pour satisfaire aux tests. Développement piloté par le comportement (BDD) : Exprime le comportement souhaité d'une application avec des cas de test écrits dans une forme simple de langage naturel, qui est facile à comprendre par les parties prenantes - en utilisant généralement le format Given/When/Then (Etant donné/Lorsque/Alors). (Chelimsky 2010) Les cas de test sont ensuite automatiquement traduits en tests exécutables. Pour toutes les approches ci-dessus, les tests peuvent persister en tant que tests automatisés aﬁn de garantir la qualité du code lors des adaptations / refactorisations futures. 2.1.4 DevOps et tests Retour Table des matières DevOps est une approche organisationnelle visant à créer une synergie en amenant le développement (y compris le test) et l’exploitation à travailler ensemble pour atteindre un ensemble d'objectifs communs. 4 Refactoriser : améliorer le code pour le rendre plus propre, lisible et efficace, sans modiﬁer son comportement fonctionnel. © International Software Testing Qualiﬁcations Board v4.0 40 DevOps exige un changement culturel au sein d'une organisation pour combler les écarts entre le développement (y compris le test) et l’exploitation tout en traitant leurs fonctions avec la même valeur. DevOps favorise l'autonomie des équipes, le retour d'information rapide, les chaînes d'outils intégrées et les pratiques techniques telles que l'intégration continue (CI) 5 et la livraison continue (CD). Cela permet aux équipes de construire, de tester et de livrer plus rapidement un code de haute qualité par le biais d'un pipeline de livraison DevOps ( 6 (Kim 2016). Du point de vue du test, voici quelques-uns des avantages de DevOps: Fournir un feedback rapide sur la qualité du code et sur l'impact éventuel des modiﬁcations sur le code existant. Favoriser une approche shift left du test (voir section 2.1.5) en encourageant les développeurs à soumettre un code de haute qualité accompagné de tests de composants et d'une analyse statique. Favoriser l'automatisation de processus tels que CI/CD qui facilitent la mise en place d'environnements de test stables. Augmenter la vue sur les caractéristiques qualité non fonctionnelles (par exemple, la performance, la ﬁabilité). Réduire le besoin de tests manuels répétitifs grâce à l’automatisation par le biais d'un pipeline de livraison. Minimiser le risque de régression grâce à l'ampleur et à la portée des tests de régression automatisés. DevOps n'est pas sans risques et déﬁs, lesquels incluent notamment que : Le pipeline de livraison DevOps doit être déﬁni et établi. Les outils de CI/CD doivent être introduits et maintenus L'automatisation des tests nécessite des exigences supplémentaires et peut être difficile à mettre en place et à maintenir 5 CI : Continuous Integration / CD : Continuous Delivery ATTENTION CD est souvent mal compris comme « Continuous Development », ce qui est FAUX ! 6 Pipeline de livraison DevOps : Série automatisée d'étapes (comme le test, le déploiement et la surveillance) qui guide le code de sa création jusqu'à sa mise en production, permettant des mises à jour rapides, ﬁables et continues des applications © International Software Testing Qualiﬁcations Board v4.0 41 Bien que DevOps s'accompagne d'un niveau élevé de tests automatisés, des tests manuels - en particulier du point de vue de l'utilisateur - seront toujours nécessaires. 2.1.5 Approche shift left Retour Table des matières Le principe du test précoce (voir section 1.3) est parfois appelé shift left parce qu'il s'agit d'une approche dans laquelle le test est effectué plus tôt dans le cycle de vie du développement logiciel (SDLC). NOTE EQL : Le schéma ci-dessous NE FIGURE PAS DANS LE SYLLABUS. Il illustre le « déplacement » de l’effort de test dans le cadre du modèle Shift Left par rapport au schéma classique séquentiel. © International Software Testing Qualiﬁcations Board v4.0 42 Le principe du shift left suggère normalement que les tests doivent être effectués plus tôt (par exemple, sans attendre que le code soit implémenté ou que les composants soient intégrés), mais il ne signiﬁe pas que les tests doivent être négligés dans les phases ultérieures du cycle de vie du développement logiciel. Il existe quelques bonnes pratiques qui illustrent comment réaliser un "shift left" dans le test : Examiner la spéciﬁcation du point de vue des tests. Ces activités de revue des spéciﬁcations permettent souvent de trouver des défauts potentiels, tels que des ambiguïtés, des incomplétudes et des incohérences. Rédiger des cas de test avant l'écriture du code et faire exécuter le code dans un harnais de test pendant l'implémentation du code. Utiliser l’Intégration Continue et, mieux encore, le Développement Continu, permettant un feedback rapide et des tests de composants automatisés pour accompagner le code source lorsqu'il est déposé dans le référentiel de code. Clôturer les tests statiques du code source avant les tests dynamiques, ou dans le cadre d'un processus automatisé © International Software Testing Qualiﬁcations Board v4.0 43 Effectuer des tests non fonctionnels en commençant par le niveau de test de composants, dans la mesure du possible. Il s'agit d'une forme de shift left, car ces types de tests non fonctionnels ont généralement tendance à être réalisés plus tard dans le cycle de vie du développement logiciel, lorsqu'un système complet et un environnement de test représentatif sont disponibles. Une approche shift left peut entraîner des formations, des efforts et/ou des coûts supplémentaires au début du processus, mais devrait permettre d'économiser des efforts et/ou des coûts à un stade ultérieur du processus. Pour l'approche shift left, il est important que les parties prenantes soient convaincues et adhèrent à ce concept. 2.1.6 Rétrospectives et amélioration de processus Retour Table des matières Les rétrospectives (également appelées "réunions post-projet" et rétrospectives de projet) sont souvent organisées à la ﬁn d'un projet ou d'une itération, lors d'une étape de livraison, ou peuvent être organisées en cas de besoin. Le calendrier et l'organisation des rétrospectives dépendent du modèle de cycle de vie du développement logiciel suivi. Lors de ces réunions, les participants (non seulement les testeurs, mais aussi, par exemple, les développeurs, les architectes, le Product Owner, les analystes métier) discutent des points suivants: Qu'est-ce qui a été un succès et qui devrait être conservé ? © International Software Testing Qualiﬁcations Board v4.0 44 Qu'est-ce qui n'a pas fonctionné et qui pourrait être amélioré ? Comment intégrer les améliorations et conserver les succès à l'avenir ? Les résultats doivent être enregistrés et font normalement partie du rapport de clôture des tests (voir section 5.3.2). Les rétrospectives sont essentielles pour la mise en œuvre réussie de l'amélioration continue et il est important que toutes les améliorations recommandées soient suivies. Les avantages typiques pour les tests sont les suivants: Augmentation de I'efficacité et de I'efficience des tests (par exemple, en mettant en œuvre des suggestions d'amélioration du processus de test). Augmentation de la qualité du testware (par exemple, en examinant conjointement les processus de test). Consolidation de l'équipe et apprentissage (par exemple, en raison de la possibilité de soulever des problèmes et de proposer des points d'amélioration). Amélioration de la qualité de la base de test (par exemple, car les lacunes dans l'étendue et la qualité des exigences peuvent être abordées et résolues). Amélioration de la coopération entre le développement et le test (par exemple, parce que la collaboration est régulièrement examinée et optimisée). 2.2 Niveaux de test et types de test Retour Table des matières Les niveaux de test sont des groupes d'activités de test qui sont organisés et gérés ensemble. Chaque niveau de test est une instance du processus de test, exécutée en relation avec un logiciel à un stade de développement donné, depuis les composants individuels jusqu'aux systèmes complets ou, le cas échéant, aux systèmes de systèmes. Les niveaux de test sont liés à d'autres activités du cycle du développement logiciel. © International Software Testing Qualiﬁcations Board v4.0 45 Dans les modèles séquentiels de cycle de vie du développement logiciel, les niveaux de test sont souvent déﬁnis de manière à ce que les critères de sortie d'un niveau fassent partie des critères d'entrée du niveau suivant. Dans certains modèles itératifs, cela peut ne pas s'appliquer 7. Les activités de développement peuvent s'étendre sur plusieurs niveaux de test. Les niveaux de test peuvent se chevaucher dans le temps. Les types de test sont des groupes d'activités de test liées à des caractéristiques- qualité spéciﬁques et la plupart de ces activités de test peuvent être réalisées à chaque niveau de test. 2.2.1 Niveaux de test Retour Table des matières Ce syllabus décrit les cinq niveaux de test suivants: Les tests de composants (également connus sous le nom de tests unitaires) se concentrent sur les tests de composants isolés. Ils nécessitent souvent un support spéciﬁque, tel que des harnais de tests 8 ou des frameworks de tests unitaires. Les tests de composants sont normalement effectués par les développeurs dans leur environnement de test. Les tests d'intégration de composants (également connus sous le nom de tests d'intégration unitaires) se concentrent sur le test des interfaces et des interactions entre les composants. Les tests d'intégration de composants dépendent fortement des approches de la stratégie d'intégration : ascendante, descendante ou big-bang. NOTE EQL : En développement logiciel, ces termes désignent des stratégies d’intégration pour assembler et tester les différents modules d’une application : 7 Note EQL : En contexte agile, les différents niveaux de test (des TU/TI jusqu’aux tests de système de systèmes, s’enchaînent et se chevauchent au sein d’une même itération (sprint) 8 Un harnais de test (ou test harness) est un ensemble d'outils et de logiciels créés (parfois par l’équipe de développement elle-même) pour exécuter des tests automatisés en isolant le code à tester, en fournissant des entrées contrôlées et en capturant les sorties pour vériﬁer le comportement attend © International Software Testing Qualiﬁcations Board v4.0 46 Intégration ascendante : Les modules de bas niveau sont intégrés en premier et testés progressivement avec les modules de niveau supérieur, jusqu’à atteindre le niveau le plus élevé de l'application. Intégration descendante : Les modules de haut niveau sont intégrés et testés en premier, puis les modules de niveaux inférieurs sont ajoutés et testés à mesure qu’ils sont intégrés. Intégration big-bang : Tous les modules sont intégrés simultanément après leur développement individuel, puis l’ensemble de l'application est testé en une seule phase, bien que cette méthode complique souvent l'identiﬁcation des bugs. Dans ce cadre, les modules de bas niveau et modules de haut niveau désignent la hiérarchie de dépendance et de complexité des composants dans une application : Modules de bas niveau : Ce sont les composants qui effectuent des tâches spéciﬁques et souvent simples (par exemple, une fonction pour calculer une somme ou pour lire une base de données). Ils ne dépendent pas d'autres modules mais sont souvent utilisés par les modules de niveau supérieur. Modules de haut niveau : Ce sont les composants plus abstraits qui orchestrent le comportement de plusieurs modules de bas niveau pour réaliser des fonctions plus complexes (par exemple, un module de gestion de commande qui utilise des modules de paiement, d'inventaire, et d'utilisateur). Ils dépendent souvent de plusieurs modules de bas niveau pour fonctionner. Les tests système se concentrent sur le comportement global et les capacités d'un système ou d'un produit entier, et comprennent souvent des tests fonctionnels, des tâches de bout en bout et des tests non fonctionnels de caractéristiques-qualité. Pour certaines caractéristiques-qualité non fonctionnelles, il est préférable de les tester sur un système complet dans un environnement de test représentatif 9 (par exemple, l’utilisabilité). Il est également possible d'utiliser des simulateurs de sous-systèmes. Le test système peut être effectué par une équipe de test indépendante et est lié aux spéciﬁcations du système. Les tests d'intégration du système visent à tester les interfaces entre le système sous test et d'autres systèmes et services externes. 10 9 Note EQL : ISTQB entend ici un environnement de pré-production 😉😉 10 Note EQL : Il s’agit des tests de bout-en-bout © International Software Testing Qualiﬁcations Board v4.0 47 Les tests d'intégration du système exigent des environnements de test appropriés, de préférence similaires à l'environnement opérationnel. Les tests d'acceptation sont axés sur la validation et la démonstration de l'aptitude au déploiement, ce qui signiﬁe que le système répond aux besoins métier de l'utilisateur. Idéalement, les tests d'acceptation devraient être effectués par les utilisateurs prévus. Les principales formes de tests d'acceptation sont : les tests d'acceptation des utilisateurs (UAT), les tests d'acceptation opérationnelle, les tests d'acceptation contractuels et réglementaires, les tests alpha et les tests bêta. Les niveaux de test se distinguent par la liste, non exhaustive, suivante d'attributs, aﬁn d'éviter le chevauchement des activités de test: Objet de test. Objectifs du test. Base de test. Défauts et défaillances. Approche et responsabilités. NOTE EQL : Cela signiﬁe que TOUS ces attributs sont nécessaires pour déﬁnir un niveau de test 2.2.2 Types de test Retour Table des matières Il existe de nombreux types de tests qui peuvent être appliqués dans les projets. Dans ce syllabus, les quatre types de tests suivants sont abordés: Le test fonctionnel évalue les fonctions qu'un composant ou un système doit remplir. Les fonctions sont "ce que" l'objet de test doit faire. L'objectif principal du test fonctionnel est de vériﬁer la complétude fonctionnelle, l'exactitude fonctionnelle et l'adéquation fonctionnelle. © International Software Testing Qualiﬁcations Board v4.0 48 Le test non fonctionnel évalue les attributs autres que les caractéristiques fonctionnelles d'un composant ou d'un système. Le test non fonctionnel est le test de "comment le système se comporte". L'objectif principal du test non fonctionnel est de vériﬁer les caractéristiques-qualité non fonctionnelles du logiciel. Le standard ISO/IEC 25010 fournit la classiﬁcation suivante des caractéristiques qualité non fonctionnelles des logiciels: Efficacité de la performance. Compatibilité. Utilisabilité. Fiabilité. Sécurité. Maintenabilité. Portabilité. Il est parfois approprié que le test non fonctionnel commence tôt dans le cycle de vie du développement logiciel (par exemple, dans le cadre des revues et du test de composants ou du test de systèmes). De nombreux tests non fonctionnels sont dérivés des tests fonctionnels, car ils utilisent les mêmes tests fonctionnels, mais vériﬁent que lors de l'exécution de la fonction, une contrainte non fonctionnelle est satisfaite (par exemple, vériﬁer qu'une fonction s'exécute dans un délai spéciﬁé, ou qu'une fonction peut être portée sur une nouvelle plateforme). La découverte tardive de défauts non fonctionnels peut constituer une menace sérieuse pour la réussite d'un projet. Le test non fonctionnel nécessite parfois un environnement de test très spéciﬁque, comme un laboratoire d'utilisabilité pour les tests d'utilisabilité. Le test boîte noire (voir section 4.2) est basé sur les spéciﬁcations et dérive les tests de la documentation externe à l'objet de test. L'objectif principal du test boîte noire est de vériﬁer le comportement du système par rapport à ses spéciﬁcations. Le test boîte blanche (voir section 4.3) est basé sur la structure et dérive les tests de l'implémentation ou de la structure interne du système (par exemple, le code, l'architecture, les ﬂux métier et les ﬂux de données). © International Software Testing Qualiﬁcations Board v4.0 49 L'objectif principal du test boîte blanche est de couvrir la structure sous-jacente par les tests jusqu'au niveau acceptable. Les quatre types de tests susmentionnés peuvent être appliqués à tous les niveaux de test, même si l'accent sera mis différemment à chaque niveau. Différentes techniques de test peuvent être utilisées pour dériver des conditions de test et des cas de test pour tous les types de test mentionnés. 2.2.3 Test de conﬁrmation et test de régression Retour Table des matières Des modiﬁcations sont généralement apportées à un composant ou à un système, soit pour l'améliorer par l'ajout d'une nouvelle caractéristique, soit pour le corriger par l'élimination d'un défaut. Les tests devraient alors également inclure des tests de conﬁrmation et des tests de régression. Le test de conﬁrmation conﬁrme qu'un défaut original a été corrigé avec succès. En fonction du risque, on peut tester la version corrigée du logiciel de plusieurs manières, notamment : En exécutant tous les cas de test qui ont précédemment échoué à cause du défaut, ou encore… En ajoutant de nouveaux tests pour couvrir les modiﬁcations nécessaires à la correction du défaut. Toutefois, lorsque le temps ou l'argent manque pour corriger les défauts, le test de conﬁrmation peut se limiter à l'exécution des étapes qui devraient reproduire la défaillance causée par le défaut et à la vériﬁcation que la défaillance ne se produit pas. © International Software Testing Qualiﬁcations Board v4.0 50 Le test de régression conﬁrme qu'aucune conséquence négative n'a été causée par une modiﬁcation, y compris un correctif qui a déjà fait l'objet d'un test de conﬁrmation. Ces conséquences négatives pourraient affecter le composant où la modiﬁcation a été apportée, d'autres composants du même système, voire d'autres systèmes connectés. Le test de régression peut ne pas se limiter à l'objet de test lui-même, mais peut également concerner l'environnement. Il est conseillé d'effectuer d'abord une analyse d'impact pour optimiser l'étendue du test de régression. L'analyse d'impact montre quelles parties du logiciel pourraient être affectées. Les suites de test de régression sont exécutées de nombreuses fois et, en général, le nombre de cas de test de régression augmente à chaque itération ou release, de sorte que les tests de régression sont de bons candidats à l'automatisation. L'automatisation de ces tests devrait commencer dès le début du projet. Lorsque l’intégration continue est utilisée, comme dans DevOps (voir section 2.1.4), c'est une bonne pratique d'inclure également des tests de régression automatisés. Selon la situation, cela peut inclure des tests de régression à différents niveaux. Des tests de conﬁrmation et/ou de régression de l'objet du test sont nécessaires à tous les niveaux de test si des défauts sont corrigés et/ou si des modiﬁcations sont apportées à ces niveaux de test. © International Software Testing Qualiﬁcations Board v4.0 51 2.3 Test de maintenance Retour Table des matières Il existe différentes catégories de maintenance : elle peut être corrective, s'adapter aux changements de l'environnement ou améliorer la performance ou la maintenabilité (voir ISO/IEC 14764 pour plus de détails). La maintenance peut donc impliquer des livraisons/déploiements planiﬁés et des livraisons/déploiements non planiﬁés (correctifs à chaud). Une analyse d'impact peut être effectuée avant une modiﬁcation, pour aider à décider si le changement doit être effectué, sur la base des conséquences potentielles dans d'autres domaines du système. Le test des changements apportés à un système en pro

ISTQB CTFL Syllabus Niveau Fondation v4.0 PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue