Syllabus ISTQB Testeur certifié niveau Foundation

Termes

Test d’acceptation, test alpha, test bêta, logiciel commercial sur étagère (COTS), test d’intégration de composants, test de composants, test de confirmation, test d’acceptation contractuelle, test fonctionnel, analyse d’impact, test d’intégration, test de maintenance, test non-fonctionnel, test d’acceptation opérationnelle, test de régression, test d’acceptation réglementaire, modèle de développement séquentiel, test d’intégration de systèmes, test système, bases de test, cas de test, environnement de test, niveau de test, objet de test, objectif de test, type de test, test d’acceptation utilisateur, test boîte- blanche.

2.1 Les modèles de développement logiciel

Un modèle de cycle de vie de développement logiciel décrit les types d’activités réalisées à chaque étape d’un projet de développement logiciel, et la façon dont les activités sont reliées entre elles logiquement et chronologiquement. Il existe un certain nombre de modèles de cycle de développement de logiciels différents, chacun d’entre eux nécessitant des approches de test différentes.

2.1.1  Développement de logiciel et tests logiciels (K2)

Une partie importante du rôle d’un testeur est de se familiariser avec les principaux modèles de cycle de vie du développement logiciel afin que les activités de test adaptées puissent être réalisées.

Quel que soit le modèle de cycle de vie de développement logiciel, il y a plusieurs caractéristiques de bonnes pratiques des tests :

• Pour chaque activité de développement, il y a une activité de test correspondante
• Chaque niveau de test a des objectifs de test spécifiques à ce niveau
• L’analyse et la conception des tests pour un niveau de test donné commencent au cours de l’activité de développement correspondante
• Les testeurs participent aux discussions pour définir et affiner les exigences et la conception, et sont impliqués dans la revue des produits d’activités (p. ex. les exigences, la conception, les User Stories, etc.) dès que des versions préliminaires sont disponibles

Quel que soit le modèle de cycle de développement logiciel choisi, les activités de test devraient commencer dès les premières étapes du cycle de vie, en respectant le principe de « Tester tôt ».

Ce syllabus catégorise les modèles de cycle de vie de développement de logiciels courants comme suit :

• Modèles de développement séquentiel
• Modèles de développement itératif et incrémental

Un modèle de développement séquentiel décrit le processus de développement logiciel comme un flux linéaire et séquentiel d’activités. Cela signifie que toute phase du processus de développement devrait commencer lorsque la phase précédente est terminée. En théorie, il n’y a pas de chevauchement des phases, mais dans la pratique, il est bénéfique d’avoir un retour rapide de la phase suivante.

Dans le modèle ‘en cascade’, les activités de développement (p. ex. analyse des exigences, conception, codage, test) sont réalisées l’une après l’autre. Dans ce modèle, les activités de test ont seulement lieu une fois que toutes les autres activités de développement sont terminées.

Contrairement au modèle en ‘cascade’, le modèle en V intègre le processus de test tout au long du processus de développement, en appliquant le principe de « Tester tôt ». De plus, le modèle en V inclut des niveaux de test associés à chaque phase de développement correspondante, ce qui favorise le

« Tester tôt » (voir la section 2.2 pour une discussion sur les niveaux de test). Dans ce modèle, l’exécution des tests associés à chaque niveau de test se déroule séquentiellement, mais dans certains cas, il y a chevauchement.

Les modèles de développement séquentiels fournissent des logiciels qui contiennent l’ensemble des fonctionnalités, mais qui nécessitent généralement des mois ou des années pour être livrés aux parties prenantes et aux utilisateurs.

Le développement incrémental implique la définition des exigences, la conception, le développement et le test d’un système par morceaux, ce qui signifie que les fonctionnalités du logiciel augmentent de façon incrémentale. La taille de ces incréments de fonctionnalités varie, certaines méthodes ayant des étapes plus grandes et d’autres plus petites. Les incréments de caractéristiques peuvent être aussi petits qu’une unique modification d’un écran d’interface utilisateur ou qu’une nouvelle option de requête.

Le développement itératif se déroule lorsque des groupes de caractéristiques sont spécifiés, conçus, développés et testés ensemble dans une série de cycles, souvent  d’une  durée  fixe.  Les itérations peuvent impliquer des changements sur les caractéristiques  développées  dans  les  itérations précédentes, ainsi que des changements sur le périmètre du projet. Chaque itération délivre un logiciel opérationnel qui est un sous-ensemble croissant de l’ensemble global des  caractéristiques jusqu’à ce que le logiciel final soit livré ou que le développement soit arrêté.

En voici quelques exemples :

• Rational Unified Process : chaque itération a tendance à être relativement longue (p. ex. deux à trois mois), et les incréments de caractéristiques sont proportionnellement importants, de l’ordre de deux ou trois groupes de caractéristiques connexes
• Scrum : chaque itération a tendance à être relativement courte (p. ex., heures, jours ou quelques semaines), et les incréments de caractéristiques sont proportionnellement petits, de l’ordre de quelques améliorations et/ou deux ou trois nouvelles caractéristiques
• Kanban : mis en œuvre avec des itérations de durée fixe ou non, pouvant soit livrer à la fin une seule amélioration ou caractéristique, soit regrouper des groupes de caractéristiques pour les livrer en une fois
• Spiral (ou par prototypage) : il s’agit de créer des incréments expérimentaux, dont certains peuvent être fortement remaniés ou même abandonnés lors de travaux de développement ultérieurs

Les composants ou systèmes développés à l’aide de ces méthodes  impliquent  souvent  le chevauchement et l’itération sur les niveaux de test tout au long du développement. Idéalement, chaque caractéristique est testée à plusieurs niveaux de test au fur et à mesure qu’elle se rapproche de la  livraison. Dans certains cas, les équipes utilisent la livraison continue ou le déploiement continu, les deux impliquant une automatisation significative de multiples niveaux de test dans le cadre de leurs flux de livraison. De nombreux efforts de développement utilisant ces méthodes incluent également le concept d’équipes auto-organisées, ce qui peut changer la façon dont le travail de test est organisé ainsi que la relation entre les testeurs et les développeurs.

Ces méthodes produisent un système aux caractéristiques croissantes, qui peut être livré aux utilisateurs finaux caractéristique par caractéristique, itération par itération, ou de façon plus traditionnelle par version majeure. Que les incréments logiciels soient livrés aux utilisateurs finaux ou non, les tests de régression sont de plus en plus importants à mesure que le système grossit.

Contrairement aux modèles séquentiels,  les modèles itératifs et incrémentaux peuvent fournir des   logiciels utilisables en quelques semaines ou même en quelques jours, mais ne peuvent livrer l’ensemble des exigences que sur une période de plusieurs mois ou même années.

Pour plus d’informations sur les tests logiciels dans le contexte du développement Agile, voir le syllabus Testeur Certifié – Extension Niveau Fondation Testeur Agile CFTL / ISTQB, Black 2017, Crispin 2008, et Gregory 2015.

2.1.2  Modèles de cycle de vie du développement logiciel en contexte (K1)

Les modèles de cycle de vie du développement logiciel doivent être sélectionnés et adaptés au contexte du projet et aux caractéristiques du produit. Un modèle de cycle de vie du développement logiciel approprié devrait être choisi et adapté en fonction de l’objectif du projet, du type de produit développé,   des priorités métier (p. ex., délai de mise sur le marché) et des risques produit et projet identifiés. Par exemple, le développement et le test d’un système peu important de gestion interne devrait être différent du développement et du test d’un système critique pour la sécurité, comme un système de contrôle de freinage d’une automobile. Par ailleurs, dans certains cas, des problèmes organisationnels et culturels peuvent inhiber la communication entre les membres de l’équipe, ce qui peut gêner le développement itératif.

Selon le contexte du projet, il peut être nécessaire de combiner ou de réorganiser les niveaux de test et/ou les activités de test. Par exemple, pour l’intégration d’un logiciel commercial sur étagère (COTS) dans un système plus grand, l’acheteur peut effectuer des tests d’interopérabilité au niveau des tests d’intégration du système (p. ex., intégration à l’infrastructure et à d’autres systèmes) et au niveau des tests d’acceptation (fonctionnels et non-fonctionnels, ainsi que des tests d’acceptation utilisateur et des tests d’acceptation opérationnelle). Voir la section 2.2 pour une description des niveaux de test et la section 2.3 pour une description des types de test.

En outre, les modèles de cycle de vie du développement logiciel eux-mêmes peuvent être combinés. Par exemple, un modèle en V peut être utilisé pour le développement et le test des systèmes back-end et de leurs intégrations, tandis qu’un modèle de développement Agile peut être utilisé pour développer et tester l’interface utilisateur front-end (IHM) et les fonctionnalités. Le prototypage peut être utilisé au début d’un projet, avec un modèle de développement incrémental adopté une fois la phase expérimentale terminée.

Les systèmes Internet des Objets (IoT – Internet of Things), qui se composent de nombreux objets différents, tels que des équipements, des produits et des services, appliquent généralement des modèles de cycle de développement logiciel distincts pour chaque objet. Cela représente un défi particulier pour le développement de versions du système global IoT. De plus, le cycle de développement logiciel de ces objets met davantage l’accent sur les phases ultérieures du cycle de vie du développement logiciel après leur mise en service (p. ex. phases d’exploitation, de mise à jour et de dé-commissionnement).

2.2  Niveaux de test

Les niveaux de test sont des groupes d’activités de test qui sont organisées et gérées ensemble. Chaque niveau de test est une instance du processus de test, constitué des activités décrites à la section 1.4, réalisées en relation avec le logiciel à un niveau de développement donné, depuis les unités ou  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 de vie du développement logiciel. Les niveaux de    test utilisés dans ce syllabus sont les suivants :

• Test de composants
• Test d’intégration
• Test système
• Test d’acceptation

Les niveaux de test sont caractérisés par les éléments suivants :

• Objectifs spécifiques
• Bases de test, référencées pour en dériver des cas de test
• Objet de test (c.-à-d. ce qui est testé)
• Défauts et défaillances types
• Approches et responsabilités spécifiques

Pour chaque niveau de test, un environnement de test approprié est requis. Dans les tests d’acceptation, par exemple, un environnement de test représentatif de la production est idéal, tandis que dans les tests  de composants, les développeurs utilisent généralement leur propre environnement de développement.

2.2.1  Test de composants (K2)

Objectifs des tests de composants

Les tests de composants (également connus sous le nom de tests unitaires ou de modules) se concentrent sur des composants qui peuvent être testés séparément. Les objectifs des tests de composants sont les suivants :

• Réduire le risque
• Vérifier si les comportements fonctionnels et non-fonctionnels du composant sont tels qu’ils ont été conçus et spécifiés
• Renforcer la confiance dans la qualité du composant
• Trouver des défauts dans le composant
• Empêcher les défauts de passer à des niveaux de test plus élevés

Dans certains cas, particulièrement dans les modèles de développement incrémentaux et itératifs (p. ex. Agile) où les changements de code sont continus, les tests de régression automatisés jouent un rôle clé dans l’établissement de la confiance que les changements n’ont pas endommagés les composants existants.

Les tests de composants sont souvent effectués indépendamment du reste du système, en fonction du modèle de cycle de développement logiciel et du système, ce qui peut nécessiter de mettre en place des objets fictifs, une virtualisation des services, des harnais de test, des bouchons et des pilotes. Les tests   de composants peuvent porter sur des caractéristiques fonctionnelles (p. ex., exactitude des calculs), non-fonctionnelles (p. ex. recherche de fuites mémoire) et les propriétés structurelles (p. ex., tests des décisions).

Bases de test

Voici des exemples de produits d’activités qui peuvent être utilisés comme bases de test pour les tests de composants :

• Conception détaillée
• Code
• Modèle de données
• Spécifications des composants

Objets de test

Les objets de test habituels pour les tests de composants sont les suivants :

• Composants, unités ou modules
• Code et structures de données
• Classes
• Modules de bases de données

Défauts et défaillances courants

Voici des exemples de défauts et de défaillances courants pour les tests de composants :

• Fonctionnalité incorrecte (par exemple, non conforme aux spécifications de conception)
• Problèmes de flux de données
• Code et logique incorrects

Les défauts sont généralement corrigés dès qu’ils sont détectés, souvent sans gestion formelle des défauts. Cependant, lorsque les développeurs rapportent vraiment des défauts, cela donne des informations importantes pour l’analyse des causes racines et l’amélioration des processus.

Approches spécifiques et responsabilités

Les tests de composants sont généralement effectués par le développeur qui a écrit le code, mais il nécessite au minimum l’accès au code testé. Les développeurs peuvent alterner le développement des composants avec la recherche et la correction de défauts. Les développeurs vont souvent écrire et exécuter des tests après avoir écrit le code d’un composant. Cependant, dans le développement Agile en particulier, l’écriture de cas de test de composants automatisés peut précéder l’écriture du code de l’application.

Considérons par exemple le développement piloté par les tests (TDD : Test Driven Development). Le développement piloté par les tests est fortement itératif et basé sur des cycles de développement de cas de tests automatisés, puis la construction et l’intégration de petits morceaux de code, suivi de l’exécution des tests des composants, la correction de tout problème et le refactoring du code. Ce processus se poursuit jusqu’à ce que le composant soit complètement achevé et que tous les tests de composants réussissent. Le développement piloté par les tests est un exemple de l’approche dite « test-first » – tester en premier. Le développement piloté par les tests a commencé avec l’Extreme Programming (XP) et il s’est étendu à d’autres formes de développement Agile et aussi à des cycles de vie séquentiels (cf. syllabus Testeur Certifié – Extension Niveau Fondation Testeur Agile CFTL / ISTQB).

2.2.2 Test d’intégration (K2)

Objectifs des tests d’intégration

Les tests d’intégration se concentrent sur les interactions entre les composants ou les systèmes. Les objectifs des tests d’intégration comprennent :

• Réduire les risques
• Vérifier si les comportements fonctionnels et non-fonctionnels des interfaces sont tels qu’ils ont été conçus et spécifiés
• Renforcer la confiance dans la qualité des interfaces
• Trouver des défauts (qui peuvent se trouver dans les interfaces elles-mêmes ou dans les composants ou systèmes)
• Empêcher les défauts de passer à des niveaux de test plus élevés

Comme pour les tests de composants, dans certains cas, les tests d’intégration automatisés utilisés en tests de régression donnent l’assurance que les changements n’ont pas altéré les interfaces, composants ou systèmes existants.

Il y a deux niveaux différents de tests d’intégration décrits dans ce syllabus, qui peuvent être effectués sur des objets de test de taille variable comme suit :

• Les tests d’intégration de composants se concentrent sur les interactions et les interfaces entre composants intégrés. Les tests d’intégration de composants sont effectués après les tests de composants et sont généralement automatisés. Dans le développement itératif et incrémental, les tests d’intégration des composants font généralement partie du processus d’intégration
• Les tests d’intégration de systèmes se concentrent sur les interactions et les interfaces entre systèmes, progiciels et micro-services. Les tests d’intégration de systèmes peuvent également couvrir les interactions avec des entités externes (p. ex. services Web) et les interfaces fournies par celles-ci. Dans ce cas, l’organisation qui développe ne contrôle pas  les  interfaces  externes, ce qui peut créer  divers problèmes pour les  tests (p. ex. s’assurer  que des défauts bloquants  pour  les tests dans  le code de l’entité externe sont résolus,  organiser  des environnements de test, etc.). Les tests d’intégration de systèmes peuvent être effectués après les tests systèmes ou en parallèle d’activités de tests systèmes en cours (à la fois en développement séquentiel et en développement itératif et incrémental).

Bases de test

Voici des exemples de produits d’activités qui peuvent servir de bases de test pour les tests d’intégration :

• Conception du logiciel et du système
• Diagrammes de séquence
• Spécifications des protocoles d’interface et de communication
• Cas d’utilisation
• Architecture au niveau du composant ou du système
• Workflows
• Définitions des interfaces externes

Objets de test

Les objets de test habituels pour les tests d’intégration comprennent :

• Sous-systèmes
• Bases de données
• Infrastructure
• Interfaces
• APIs
• Micro-services

Défauts et défaillances courants

Voici des exemples de défauts et de défaillances habituels pour les tests d’intégration de composants :

• Données incorrectes, données manquantes ou encodage incorrect des données
• Mauvais séquencement ou synchronisation des appels d’interfaces
• Décalages au niveau des interfaces
• Défaillances dans la communication entre les composants
• Défaillances de communication non gérées ou mal gérées entre les composants
• Hypothèses incorrectes sur la signification, les unités ou les limites des données transmises entre les composants

Voici des exemples de défauts et de défaillances habituels pour les tests d’intégration de systèmes :

• Structures de message incohérentes entre les systèmes
• Données incorrectes, données manquantes ou encodage incorrect des données
• Décalages au niveau des interfaces
• Défaillances dans la communication entre les systèmes
• Défaillances de communication non gérées ou mal gérées entre les systèmes
• Hypothèses incorrectes sur la signification, les unités ou les limites des données transmises entre les systèmes
• Non-respect des règles de sécurité requises

Approches spécifiques et responsabilités

Les tests d’intégration de composants et les tests d’intégration de systèmes doivent se concentrer sur l’intégration elle-même. Par exemple, pour l’intégration du module A avec le module B, les tests devraient  se concentrer sur la communication entre les modules, et non sur la fonctionnalité des modules    individuels, car cela aurait dû être couvert pendant les tests de composants. Pour l’intégration du système  X au système Y, les tests devraient se concentrer sur la communication entre les systèmes, et non sur la fonctionnalité des systèmes individuels, car cela aurait dû être couvert pendant les tests du système. Les types de tests fonctionnels, non-fonctionnels et structurels sont concernés.

Les tests d’intégration de composants sont souvent la responsabilité des développeurs. Les tests d’intégration de systèmes relèvent généralement de la responsabilité des testeurs. Idéalement, les testeurs qui effectuent des tests d’intégration de systèmes devraient comprendre l’architecture du système et devraient avoir contribué à la planification de l’intégration.

Si les tests d’intégration et la stratégie d’intégration sont planifiés avant le développement des  composants ou des systèmes, ces composants ou systèmes peuvent être construits dans l’ordre requis pour des tests plus efficaces. Les stratégies d’intégration systématique peuvent être fondées sur l’architecture du système (p. ex. de haut en bas et de bas en haut), les tâches fonctionnelles, les séquences de traitement des transactions ou d’autres aspects du système ou des composantes. Afin de simplifier l’isolation des défauts et de détecter tôt les défauts, l’intégration devrait normalement être incrémentale (c’est-à-dire un petit nombre de composants ou de systèmes supplémentaires à la fois)  plutôt que “big bang” (c’est-à-dire l’intégration de tous les composants ou systèmes en une seule étape). Une analyse de risque des interfaces les plus complexes peut aider à focaliser les tests d’intégration.

Plus la portée de l’intégration est grande, plus il devient difficile de localiser les défauts d’un composant  ou d’un système spécifique, ce qui peut entraîner un risque accru et du temps supplémentaire pour la correction des problèmes rencontrés. C’est l’une des raisons pour lesquelles l’intégration continue, où le logiciel est intégré composant par composant (c’est-à-dire l’intégration fonctionnelle), est devenue une pratique courante. Une telle intégration continue inclut souvent des tests de régression automatisés, idéalement à plusieurs niveaux de test.

2.2.3  Test système (K2)

Objectifs des tests système

Les tests système se concentrent sur le comportement et les capacités d’un système ou d’un produit  entier, en considérant souvent les tâches de bout en bout que le système peut exécuter et les comportements non-fonctionnels qu’il présente pendant l’exécution de ces tâches. Les objectifs des tests système comprennent :

• Réduire les risques
• Vérifier si les comportements fonctionnels et non-fonctionnels du système sont tels qu’ils ont été conçus et spécifiés
• Valider que le système est complet et fonctionnera comme prévu
• Renforcer la confiance dans la qualité du système dans son ensemble
• Trouver des défauts
• Empêcher les défauts de passer à des niveaux de test plus élevés ou en production

Pour certains systèmes, la vérification de la qualité des données peut être un objectif. Comme pour les tests de composants et les tests d’intégration, dans certains cas, les tests de régression automatisés au niveau système donnent l’assurance que les changements n’ont pas altéré les caractéristiques existantes ou les capacités de bout en bout. Le test système produit souvent de l’information qui est utilisée par les intervenants pour prendre des  décisions de livraison. Les tests systèmes peuvent également satisfaire   aux exigences ou aux normes légales ou réglementaires.

L’environnement de test devrait idéalement correspondre à la cible finale ou à l’environnement de production.

Bases de test

Voici des exemples de produits d’activités qui peuvent être utilisés comme bases de test pour les tests système :

• Spécifications des exigences système et logicielles (fonctionnelles et non-fonctionnelles)
• Rapports d’analyse des risques
• Cas d’utilisation
• Epics et User Stories
• Modèles de comportement du système
• Diagrammes d’états
• Manuels système et manuels d’utilisation

Objets de test

Les objets de test habituels pour les tests système comprennent :

• Applications
• Systèmes Matériel/Logiciel
• Systèmes d’exploitation
• Système sous test (SUT – System Under Test)
• Configuration du système et données de configuration

Défauts et défaillances courants

Voici des exemples de défauts et de défaillances habituels pour les tests système :

• Calculs incorrects
• Comportement fonctionnel ou non-fonctionnel du système incorrect ou inattendu
• Flux de contrôle et/ou de données incorrects au sein du système
• Réalisation incorrecte et incomplète des tâches fonctionnelles de bout en bout
• Incapacité du système à fonctionner correctement dans le ou les environnements de production
• Incapacité du système à fonctionner selon la description faite dans les manuels système et utilisateur

Approches spécifiques et responsabilités

Les tests système devraient se concentrer sur le comportement global de bout en bout du système dans son ensemble, à la fois fonctionnel et non-fonctionnel. Les tests système doivent utiliser les techniques   de test les plus appropriées (voir chapitre 4) pour l’(les) aspect(s) du système à tester. Par exemple, une table de décision peut être créée pour vérifier si le comportement fonctionnel est tel que décrit dans les règles métier.

Des testeurs indépendants procèdent en général aux tests système. Des défauts dans les spécifications (par exemple, des User Stories manquantes, des exigences métier mal énoncées, etc.) peuvent conduire   à un manque de compréhension ou à des désaccords sur le comportement attendu du système. De telles situations peuvent causer des faux positifs et des faux négatifs, ce qui fait perdre du temps et réduit l’efficacité de la détection des défauts. L’implication en amont des testeurs dans l’affinement des User Stories ou dans les activités de tests statiques, comme les revues, aide à réduire l’incidence de telles situations.

2.2.4  Test d’acceptation (K2)

Objectifs des tests d’acceptation

Les tests d’acceptation, comme les tests système, se concentrent généralement sur le comportement et les capacités d’un système ou d’un produit entier. Les objectifs des tests d’acceptation comprennent :

• Établir la confiance dans la qualité du système dans son ensemble
• Valider que le système est complet et qu’il fonctionnera comme attendu
• Vérifier que les comportements fonctionnels et non-fonctionnels du système sont tels que spécifiés

Les tests d’acceptation peuvent produire des informations permettant  d’évaluer  la  disponibilité  du système pour le déploiement et l’utilisation par le client (utilisateur final). Des défauts peuvent être trouvés pendant les tests d’acceptation, mais la découverte de défauts ne constitue en général pas un objectif, et   la découverte d’un nombre significatif de défauts pendant les tests d’acceptation peut dans certains cas  être considérée comme un risque majeur du projet. Les tests d’acceptation peuvent également satisfaire aux exigences ou aux normes légales ou réglementaires.

Les formes communes de tests d’acceptation comprennent :

• Tests d’acceptation utilisateur
• Tests d’acceptation opérationnelle
• Tests d’acceptation contractuelle et réglementaire
• Tests alpha et bêta

Chacune est décrite dans les quatre sous-sections suivantes.

Tests d’acceptation utilisateur (UAT – User Acceptance Testing)

Les tests d’acceptation du système par les utilisateurs sont généralement axés sur la validation de son aptitude à l’usage par les utilisateurs prévus dans un environnement opérationnel réel ou simulé.

L’objectif principal est de renforcer la confiance dans l’usage du système pour répondre aux besoins des utilisateurs, satisfaire les exigences et exécuter les processus métier avec un minimum de difficultés, de coûts et de risques.

Tests d’acceptation opérationnelle (OAT – Operational Acceptance Testing)

Les tests d’acceptation du système par le service d’exploitation ou le service d’administration du système sont généralement effectués dans un environnement de production (simulé). Les tests se concentrent sur les aspects opérationnels et peuvent inclure les éléments suivants :

• Tests de sauvegarde et de restauration
• Installation, désinstallation et mise à jour
• Reprise après sinistre
• Gestion des utilisateurs
• Tâches de maintenance
• Tâches de chargement et de migration des données
• Vérification des vulnérabilités de sécurité
• Tests de performance

L’objectif principal des tests d’acceptation opérationnelle est de renforcer la confiance dans le fait que les opérateurs ou les administrateurs système peuvent maintenir le système en bon état de fonctionnement pour les utilisateurs dans l’environnement opérationnel, même dans des conditions exceptionnelles ou difficiles.

Tests d’acceptation contractuelle et réglementaire

Les tests d’acceptation contractuelle sont effectués en fonction des critères d’acceptation d’un contrat pour la production de logiciels sur mesure. Les critères d’acceptation devraient être définis lorsque les parties conviennent du contrat. Les tests d’acceptation contractuelle sont souvent effectués par les utilisateurs ou par des testeurs indépendants.

Les tests d’acceptation réglementaire sont effectués par rapport à tous les règlements qui doivent être respectés, comme les règlements gouvernementaux, légaux ou de sécurité. Les tests d’acceptation réglementaire sont souvent effectués par les utilisateurs ou par des testeurs indépendants, les résultats étant parfois observés ou vérifiés par des organismes de réglementation.

L’objectif principal des tests d’acceptation contractuelle et réglementaire est de renforcer la confiance dans l’atteinte de la conformité contractuelle ou réglementaire.

Tests alpha et bêta

Les tests alpha et bêta sont généralement utilisés par les développeurs de logiciels commerciaux sur étagère (COTS) qui souhaitent obtenir une évaluation des utilisateurs, clients et/ou opérateurs potentiels  ou existants avant que le produit logiciel ne soit mis sur le marché. Les tests alpha sont effectués sur le   site de l’organisation qui développe, non pas par l’équipe de développement, mais par des clients  potentiels ou existants, et/ou des opérateurs ou une équipe de test indépendante. Les tests bêta sont effectués par des clients potentiels ou existants, et/ou des opérateurs sur leurs propres sites. Le test bêta peut venir après le test alpha, ou peut se produire sans qu’aucun test alpha précédent n’ait eu lieu.

L’un des objectifs des tests alpha et bêta est de renforcer la confiance des clients potentiels ou existants et/ou des opérateurs dans l’utilisation du système dans des conditions normales et quotidiennes et dans l’environnement opérationnel pour atteindre leurs objectifs avec un minimum de difficulté, de coût et de risque. Un autre objectif peut être la détection des défauts liés aux conditions et aux environnements   dans lesquels le système sera utilisé, en particulier lorsque ces conditions et environnements sont  difficiles à reproduire par l’équipe de développement.

Bases de test

Voici des exemples de produits d’activités qui peuvent être utilisés comme base de test pour toute forme de test d’acceptation :

• Processus métier
• Exigences utilisateur ou métier
• Réglementations, contrats légaux et normes
• Cas d’utilisation
• Exigences système
• Documentation système ou utilisateur
• Procédures d’installation
• Rapports d’analyse des risques

En outre, comme base de test pour dériver des cas de test pour les tests d’acceptation opérationnelle, un ou plusieurs des produits d’activités suivants peuvent être utilisés :

• Procédures de sauvegarde et de restauration
• Procédures de reprise après sinistre
• Exigences non-fonctionnelles
• Documentation d’exploitation
• Instructions de déploiement et d’installation
• Objectifs de performance
• Ensembles de base de données
• Normes ou règlements de sécurité

Objets de test habituels

Les objets de test habituels pour toute forme de test d’acceptation sont les suivants :

• Systèmes sous test
• Configuration du système et données de configuration
• Processus métier pour un système entièrement intégré
• Systèmes de récupération et sites sensibles (pour les tests de continuité d’activité et de reprise après sinistre)
• Processus d’exploitation et de maintenance
• Formulaires
• Rapports
• Données de production existantes et modifiées

Défauts et défaillances courants

Voici des exemples de défauts courants pour toute forme de test d’acceptation :

• Les workflows du système ne répondent pas aux exigences métier ou utilisateurs
• Les règles métier ne sont pas correctement implémentées
• Le système ne satisfait pas aux exigences contractuelles ou réglementaires
• Les défaillances non-fonctionnelles telles que les vulnérabilités de sécurité, le manque de performance en cas de charges élevées, ou le mauvais fonctionnement sur une plate-forme supportée

Approches et responsabilités spécifiques

Les tests d’acceptation relèvent souvent de la responsabilité des clients, des utilisateurs métier, des Product Owners ou des exploitants d’un système, et d’autres parties prenantes pouvant également être impliquées.

Le test d’acceptation est souvent considéré comme le dernier niveau de test dans un cycle de vie de développement séquentiel, mais il peut aussi se produire à d’autres moments, par exemple :

• Les tests d’acceptation d’un produit logiciel COTS peuvent se produire lorsqu’il est installé ou intégré
• Le test d’acceptation d’une nouvelle amélioration fonctionnelle peut avoir lieu avant le test système

Dans le développement itératif, les équipes de projet peuvent employer diverses formes de tests d’acceptation pendant et à la fin de chaque itération, telles que celles qui visent à vérifier une nouvelle fonctionnalité par rapport à ses critères d’acceptation et celles qui visent à valider qu’une nouvelle fonctionnalité satisfait les besoins des utilisateurs. De plus, des tests alpha et bêta peuvent être réalisés, soit à la fin de chaque itération, après l’achèvement de chaque itération, soit après une série d’itérations. Les tests d’acceptation utilisateur, les tests d’acceptation opérationnelle, les tests d’acceptation réglementaire et les tests d’acceptation contractuelle peuvent également avoir lieu, soit à la clôture de chaque itération, après l’achèvement de chaque itération, soit après une série d’itérations.

2.3  Types de test

Un type de test est un groupe d’activités de test visant à tester des caractéristiques spécifiques d’un système logiciel ou d’une partie d’un système, sur la base d’objectifs de test spécifiques. Ces objectifs peuvent inclure :

• Évaluer des caractéristiques de qualité fonctionnelle, telles que la complétude, l’exactitude et la pertinence
• Évaluer des caractéristiques de qualité non-fonctionnelles, telles que la fiabilité, la performance, la sécurité, la compatibilité et la facilité d’utilisation
• Évaluer si la structure ou l’architecture du composant ou du système est correcte, complète et conforme aux spécifications
• Évaluer les effets des changements, tels que la confirmation de la correction de défauts (tests de confirmation) et la recherche de changements non désirés résultant de changements dans le logiciel ou l’environnement (tests de régression).

2.3.1 Tests fonctionnels (K2)

Les tests fonctionnels d’un système impliquent des tests qui évaluent les fonctionnalités que le système devrait réaliser. Les exigences fonctionnelles peuvent être décrites dans des produits d’activités tels que  les spécifications des exigences métier, les épics, les User Stories, les cas d’utilisation ou les   spécifications fonctionnelles, ou elles peuvent ne pas être documentées. Les fonctionnalités sont “ce que”  le système doit faire.

Les tests fonctionnels devraient être effectués à tous les niveaux de test (par exemple, les tests de composants peuvent être basés sur une spécification de composant), bien que la focalisation soit différente à chaque niveau (voir section 2.2).

Les tests fonctionnels prennent en compte le comportement du logiciel, de sorte que des techniques boîte-noire peuvent être utilisées pour dériver des conditions de test et des cas de test pour la fonctionnalité du composant ou du système (voir section 4.2).

La complétude des tests fonctionnels peut être mesurée par la couverture fonctionnelle. La couverture fonctionnelle est la mesure selon laquelle un  certain type d’élément  fonctionnel a été exercé par des   tests. Elle est exprimée en pourcentage du ou des types d’éléments couverts. Par exemple, en utilisant la traçabilité entre les tests et les exigences fonctionnelles, le pourcentage de ces exigences qui sont couvertes par les tests peut être calculé, identifiant potentiellement des lacunes de couverture.

La conception et l’exécution des tests fonctionnels peuvent nécessiter des compétences ou des connaissances particulières, comme la connaissance du problème métier particulier que le logiciel résout (par exemple, un logiciel de modélisation géologique pour les industries pétrolière et gazière) ou le rôle particulier que joue le logiciel (par exemple, un logiciel de jeux vidéo qui fournit des loisirs interactifs).

2.3.2  Tests non-fonctionnels (K1)

Les tests non-fonctionnels d’un système évaluent les caractéristiques des systèmes et des logiciels comme l’utilisabilité, la performance ou la sécurité. Il convient de se reporter à la norme ISO (ISO/CEI 25010) pour une classification des caractéristiques de qualité des produits logiciels. Le test non- fonctionnel est le test de “comment” le système se comporte.

Contrairement aux idées fausses courantes, les tests non-fonctionnels peuvent et devraient souvent être effectués à tous les niveaux de test, et ce, le plus tôt possible. La découverte tardive de défauts non- fonctionnels peut être extrêmement préjudiciable à la réussite d’un projet.

Des techniques de boîte-noire (voir section 4.2) peuvent être utilisées pour dériver des conditions de test  et des cas de test pour les tests non-fonctionnels. Par exemple, l’analyse des valeurs limites peut être utilisée pour définir les conditions de sollicitation pour les tests de performance.

La complétude des tests non-fonctionnels peut être mesurée par une couverture non-fonctionnelle. La couverture non-fonctionnelle est la mesure selon laquelle un certain type d’élément non-fonctionnel a été exercé par des tests et est exprimée en pourcentage du ou des types d’éléments couverts. Par exemple, en utilisant la traçabilité entre les tests et les appareils pris en charge pour une application mobile, le pourcentage d’appareils qui font l’objet de tests de compatibilité peut être calculé, identifiant potentiellement les lacunes de couverture.

La conception et l’exécution de tests non-fonctionnels peuvent impliquer des compétences ou des connaissances spécifiques, telles que la connaissance des faiblesses inhérentes à une conception ou à une technologie (par exemple, les vulnérabilités de sécurité associées à des langages de programmation particuliers) ou la spécificité des utilisateurs (p. ex. les types d’utilisateurs des systèmes de gestion des établissements de santé).

Se référer aux syllabus CFTL / ISTQB Testeur Certifié de Niveau Avancé : Analyste de Test, Analyste Technique de Test, Testeur de Sécurité, et d’autres modules spécialisés du CFTL / ISTQB pour plus de détails concernant les tests des caractéristiques de qualité non-fonctionnelles.

2.3.3 Tests boîte-blanche (K2)

Les tests boîte-blanche sont des tests basés sur la structure ou l’implémentation interne du système. La structure interne peut comprendre le code, l’architecture, les flux de travail et/ou les flux de données au sein du système (voir section 4.3).

La complétude des tests boîte-blanche peut être mesurée par la couverture structurelle. La couverture structurelle est la mesure dans laquelle un certain type d’élément structurel a été exercé par des tests et est exprimée en pourcentage du type d’élément couvert.

Au niveau du test des composants, la couverture du code est basée sur le pourcentage de code du composant qui a été testé, et peut être mesurée sur différents aspects du code (éléments de couverture) tels que le pourcentage d’instructions exécutables testées dans le composant, ou le pourcentage de résultats de décision testés. Ces types de couverture sont collectivement appelés couverture de code. Au niveau des tests d’intégration des composants, les tests de boîte-blanche peuvent être basés sur l’architecture du système, comme les interfaces entre composants, et la couverture structurelle peut être mesurée en terme de pourcentage d’interfaces exercées par les tests.

La conception et l’exécution de tests boîte-blanche peuvent nécessiter des compétences ou des connaissances particulières, comme la façon dont le code est construit (p. ex. utiliser des outils de couverture de code), la façon dont les données sont stockées (p. ex. évaluer les requêtes possibles dans les bases de données) et la façon d’utiliser les outils de couverture et d’interpréter correctement leurs résultats.

2.3.4 Tests liés aux changements

Lorsque des modifications sont apportées à un système, que ce soit pour corriger un défaut ou en raison d’une fonctionnalité nouvelle ou modifiée, des tests devraient être effectués pour confirmer que les modifications ont corrigé le défaut ou implémenté la fonctionnalité correctement, et n’ont pas causé de conséquences préjudiciables inattendues.

• Test de confirmation : Après la correction d’un défaut, le logiciel peut être testé avec tous les cas de test qui ont échoué en raison du défaut, qui doivent être ré-exécutés sur la nouvelle version du logiciel. Le logiciel peut également être testé avec de nouveaux tests si, par exemple, le défaut  était une fonctionnalité manquante. A minima, les étapes pour reproduire le(s) défaut(s) causé(s) par le défaut doivent être ré-exécutées sur la nouvelle version du logiciel. Le but d’un test de confirmation est de confirmer que le défaut d’origine a été réparé avec succès.
• Tests de régression : Il est possible qu’une modification apportée à une partie du code, qu’il s’agisse d’une correction ou d’un autre type de modification, puisse accidentellement affecter le comportement d’autres parties du code, que ce soit au sein du même composant, dans d’autres composants du même système ou même dans d’autres systèmes. Les changements peuvent inclure des changements de l’environnement, comme une nouvelle version d’un système d’exploitation ou d’un système de gestion de base de données. De tels effets de bord involontaires sont appelés régressions. Les tests de régression sont des tests visant à détecter de tels effets de bord involontaires.

Des tests de confirmation et de régression sont effectués à tous les niveaux de test.

En particulier dans les cycles de vie de développement itératif et incrémental (p. ex. en Agile), les   nouvelles caractéristiques, les modifications apportées aux caractéristiques existantes et le refactoring du code entraînent des changements fréquents du code, ce qui nécessite également des tests liés aux changements. En raison de la nature évolutive  du système,  les  tests de confirmation et  de régression sont très importants. Ceci est particulièrement important pour les systèmes Internet des objets où les   objets individuels (p. ex. des appareils) sont fréquemment mis à jour ou remplacés.

Les suites de tests de régression sont exécutées plusieurs fois et évoluent généralement lentement, raison pour laquelle les tests de régression sont de bons candidats pour l’automatisation. L’automatisation de ces tests devrait commencer tôt dans le projet (voir chapitre 6).

2.3.5  Types de test et niveaux de test

Il est possible d’effectuer n’importe quel type de test mentionné ci-dessus à n’importe quel niveau de test. Pour illustrer, des exemples de tests fonctionnels, non-fonctionnels, boîte blanche et liés au changement seront donnés pour tous les niveaux de test, pour une application bancaire, en commençant par des tests fonctionnels :

• Pour les tests de composants, les tests sont conçus en fonction de la façon dont un composant doit calculer les intérêts composés.
• Pour les tests d’intégration de composants, les tests sont conçus en fonction de la façon dont les informations saisies au niveau de l’interface utilisateur sont transmises à la couche métier.
• Pour les tests système, les tests sont conçus en fonction de la façon dont les titulaires de comptes peuvent demander une ligne de crédit sur leurs comptes chèques.
• Pour les tests d’intégration au niveau système, les tests sont conçus en fonction de la façon dont le système utilise un micro-service externe pour vérifier le taux de crédit d’un titulaire de compte.
• Pour les tests d’acceptation, les tests sont conçus en fonction de la façon dont le banquier gère l’approbation ou le refus d’une demande de crédit.

Voici des exemples de tests non-fonctionnels :

• Pour les tests de composants, les tests de performance sont conçus pour évaluer le nombre de cycles CPU nécessaires pour effectuer un calcul d’intérêt total complexe.
• Pour les tests d’intégration de composants, les tests de sécurité sont conçus pour les vulnérabilités de débordement de la mémoire tampon dues aux données transmises de l’interface utilisateur à la couche métier.
• Pour les tests système, les tests de portabilité sont conçus pour vérifier si la couche de présentation fonctionne sur tous les navigateurs et appareils mobiles supportés.
• Pour les tests d’intégration de système, les tests de fiabilité sont conçus pour évaluer la robustesse du système lorsque le micro-service de calcul du taux de crédit ne répond pas.
• Pour les tests d’acceptation, les tests d’utilisabilité sont conçus pour évaluer l’accessibilité de l’interface de traitement du crédit du banquier pour les personnes handicapées.

Voici des exemples de tests boîte-blanche :

• Pour les tests de composants, les tests sont conçus pour obtenir une couverture complète des instructions et des décisions (voir section 4.3) pour tous les composants qui effectuent des calculs financiers.
• Pour les tests d’intégration de composants, les tests sont conçus pour vérifier comment chaque écran de l’interface du navigateur transmet les données à l’écran suivant et à la couche métier.
• Pour les tests système, les tests sont conçus pour couvrir les séquences de pages Web qui peuvent se succéder pendant une demande de ligne de crédit.
• Pour les tests d’intégration de système, les tests sont conçus pour exercer tous les types de requête possibles envoyés au micro-service de calcul du taux de crédit.
• Pour les tests d’acceptation, les tests sont conçus pour couvrir toutes les structures de fichiers de données financières prises en charge et les plages de valeurs pour les transferts de banque à banque.

Enfin, voici des exemples de tests liés aux changements :

• Pour les tests de composants, des tests de régression automatisés sont construits pour chaque composant et inclus dans le framework d’intégration continue.
• Pour les tests d’intégration de composants, les tests sont conçus pour confirmer les corrections des défauts liés à l’interface au fur et à mesure que ces corrections sont intégrées dans le référentiel de code.
• Pour les tests système, tous les tests d’un workflow donné sont ré-exécutés si un écran de ce workflow change.
• Pour les tests d’intégration système, les tests de l’application interagissant avec le micro-service de calcul du taux de crédit sont ré-exécutés quotidiennement dans le cadre du déploiement continu de ce micro-service.
• Pour les tests d’acceptation, tous les tests échoués précédemment sont ré-exécutés après la correction d’un défaut constaté lors des tests d’acceptation.

Bien que cette section donne des exemples de chaque type de test à tous les niveaux, il n’est pas nécessaire, pour tous les logiciels, que chaque type de test soit représenté à tous les niveaux. Toutefois,   il est important d’exécuter les types de test applicables à chaque niveau, en particulier au niveau le plus précoce où le type de test se trouve.

2.4  Tests de maintenance

Une fois déployés dans les environnements de production, les logiciels et les systèmes doivent être maintenus. Des changements de diverses sortes sont presque inévitables dans les logiciels et les systèmes livrés, soit pour corriger des défauts découverts lors de l’utilisation opérationnelle, soit pour ajouter de nouvelles fonctionnalités, soit pour supprimer ou modifier des fonctionnalités déjà livrées. La maintenance est également nécessaire pour préserver ou améliorer les caractéristiques de qualité non- fonctionnelles du composant ou du système pendant toute sa durée de vie, en particulier la performance,  la compatibilité, la fiabilité, la sécurité et la portabilité.

Lorsque des modifications sont apportées dans le cadre de la maintenance, des tests de maintenance devraient être effectués, à la fois pour évaluer le succès avec lequel les modifications ont été apportées  et pour vérifier les effets secondaires possibles (p. ex. régressions) dans les parties du système qui demeurent inchangées (ce qui est habituellement la plus grande partie du système). Les tests de maintenance se concentrent sur le test des changements apportés au système, ainsi que sur le test des parties inchangées qui auraient pu être affectées par les changements. La maintenance peut impliquer des versions planifiées et des versions non planifiées (corrections à chaud).

Une version de maintenance peut nécessiter des tests de maintenance à plusieurs niveaux de test, en utilisant différents types de test, en fonction de sa portée. L’étendue des tests de maintenance dépend des éléments suivants :

• Le degré de risque du changement, par exemple, la mesure dans laquelle le périmètre modifié du logiciel communique avec d’autres composants ou systèmes
• La taille du système existant
• La taille du changement

2.4.1 Facteurs déclencheurs pour la maintenance (K2)

Il y a plusieurs raisons pour lesquelles la maintenance logicielle, et donc les tests de maintenance, ont lieu, à la fois pour les changements planifiés et non planifiés.

Nous pouvons classer les facteurs déclencheurs de la maintenance comme suit :

• Modification, comme des améliorations planifiées (p. ex., basées sur les versions), des changements correctifs et d’urgence, des changements de l’environnement opérationnel (comme des mises à niveau planifiées du système d’exploitation ou de la base de données), des mises à niveau de logiciels sur étagère (COTS) et des correctifs pour les défauts et les vulnérabilités
• Migration, par exemple d’une plate-forme à une autre, qui peut nécessiter des tests opérationnels du nouvel environnement ainsi que du logiciel modifié, ou des tests de conversion de données lorsque les données d’une autre application seront migrées dans le système en cours de maintenance
• Déclassement, par exemple lorsqu’une application arrive en fin de vie

Lorsqu’une application ou un système est mis hors service, il peut être nécessaire de tester la migration ou l’archivage des données si de longues périodes de conservation des données sont nécessaires. Il  peut également être nécessaire de tester les procédures de restauration/récupération après l’archivage pour de longues périodes de conservation. En outre, des tests de régression peuvent être nécessaires pour s’assurer que toute fonctionnalité qui reste en service fonctionne toujours.

Pour les systèmes Internet des objets, les tests de maintenance peuvent être déclenchés par l’introduction d’objets complètement nouveaux ou modifiés, tels que des dispositifs matériels et des services logiciels, dans l’ensemble du système. Les tests de maintenance de ces systèmes mettent particulièrement l’accent sur les tests d’intégration à différents niveaux (par exemple, niveau réseau, niveau application) et sur les aspects de sécurité, en particulier ceux relatifs aux données personnelles.

2.4.2 Analyse d’impact pour la maintenance (K2)

L’analyse d’impact évalue les changements qui ont été apportés pour une version de maintenance afin d’identifier les conséquences prévues ainsi que des effets secondaires attendus et possibles d’un changement, et d’identifier les zones du système qui seront affectées par le changement. L’analyse d’impact peut également aider à identifier l’impact d’un changement sur les tests existants. Les effets secondaires et les zones affectées dans le système doivent être testés pour les régressions, éventuellement après la mise à jour des tests existants affectés par le changement.

L’analyse d’impact  peut être effectuée avant  qu’un changement  ne soit apporté, pour aider  à déterminer si le changement devrait être apporté en fonction des conséquences potentielles dans d’autres parties du système.

L’analyse d’impact peut être difficile si :

• Les spécifications (p. ex., exigences métier, User Stories, architecture) sont obsolètes ou manquantes
• Les cas de test ne sont pas documentés ou sont obsolètes
• La traçabilité bidirectionnelle entre les tests et les bases de test n’a pas été maintenue
• Le support de l’outillage est faible ou inexistant
• Les personnes impliquées n’ont pas de connaissance du domaine et/ou du système
• Une attention insuffisante a été accordée à la maintenabilité du logiciel au cours du développement