AMDE (Analyse des Modes de Défaillance et de leurs Effets)

Technique d'analyse de risques systématique utilisée pour identifier les modes de défaillance potentiels d'un système, leurs effets et leur criticité, particulièrement obligatoire dans les domaines critiques pour la sécurité. Elle permet d'orienter les efforts de test vers les zones à risque élevé.

Dans le secteur médical, des sessions d'AMDE sont menées pour identifier les défaillances potentielles du logiciel de surveillance avant de définir les cas de test prioritaires.

Analyse de points de fonction

Technique d'estimation de l'effort de test basée sur la mesure fonctionnelle du logiciel, souvent combinée avec l'analyse de points de test pour produire des estimations détaillées et objectives. Elle est particulièrement adaptée lorsque les spécifications sont disponibles mais que le développement n'est pas encore terminé.

En attendant la livraison du système de réservation externalisé, le responsable des tests utilise l'analyse de points de fonction combinée aux points de test pour estimer le budget de validation.

Critères d'entrée

Conditions préalables devant être satisfaites avant qu'une phase de test puisse démarrer, servant de porte qualité objective pour contrôler la transition entre niveaux de test. Ils garantissent que les ressources ne sont pas gaspillées à tester un livrable insuffisamment préparé.

Le plan de test d'intégration système spécifie comme critère d'entrée un pourcentage minimum de couverture de décision atteint lors des tests unitaires.

Critères de sortie

Conditions mesurables devant être atteintes pour qu'une phase de test soit considérée comme terminée et qu'une décision de libération puisse être prise. Ils comprennent typiquement des métriques de couverture, de densité de défauts et de tendance des défauts.

Dans le projet médical, le comité décide de reconsidérer les critères de sortie en réduisant le périmètre des exigences afin de permettre une livraison partielle avec les tests manuels validés.

DO-178B

Norme avionique internationale prescrivant les exigences de cycle de vie logiciel, de vérification, de couverture structurelle et d'indépendance directement liées aux niveaux d'assurance de conception (DAL) pour l'acceptation réglementaire des logiciels embarqués aéronautiques critiques pour la sécurité.

Lors d'une mission de certification avionique, le responsable des tests vérifie la conformité à DO-178B en s'assurant que les niveaux de couverture structurelle requis par le DAL applicable sont atteints.

IEEE 1044

Norme internationale définissant le processus de classification des incidents logiciels, incluant l'assignation obligatoire de la priorité et de la sévérité à chaque anomalie signalée. Elle structure le cycle de vie complet d'un incident depuis sa détection jusqu'à sa clôture.

Suite à un audit de la procédure de gestion des incidents, la recommandation principale formulée selon IEEE 1044 est d'ajouter l'assignation systématique de priorité et de sévérité à chaque fiche d'incident.

IEEE 829

Norme internationale définissant les modèles et le contenu des documents de test, incluant le plan de test, les spécifications de cas de test et les rapports de test. Elle est utilisée comme référence pour évaluer la qualité des livrables de test dans les appels d'offres.

Le responsable des tests vérifie que le plan du soumissionnaire indique que ses livrables seront développés en utilisant la norme IEEE 829 comme guide.

ISO 9126

Norme internationale d'ingénierie logicielle définissant un modèle de qualité du produit logiciel articulé autour de caractéristiques telles que la fonctionnalité, la fiabilité, l'utilisabilité, l'efficacité, la maintenabilité et la portabilité. Elle fournit une base pour définir des critères de qualité mesurables.

Le responsable des tests s'appuie sur ISO 9126 pour définir les attributs qualité non fonctionnels à couvrir dans la stratégie de test du nouveau produit.

Niveau d'indépendance des tests

Degré de séparation organisationnelle et hiérarchique entre les testeurs et les développeurs du système testé, allant du développeur testant son propre code jusqu'à l'externalisation complète vers un prestataire tiers. Un niveau d'indépendance plus élevé réduit les biais mais peut créer des goulots d'étranglement.

L'équipe compare plusieurs niveaux d'indépendance et conclut que l'externalisation des tests offre la séparation organisationnelle la plus forte, suivie des spécialistes externes pour les tests non fonctionnels.

NPR (Numéro de Priorité de Risque)

Indicateur calculé en multipliant la probabilité d'occurrence, la gravité de l'impact et la détectabilité d'un risque, utilisé pour classer et prioriser les éléments de risque dans une analyse AMDE. Il permet d'allouer l'effort de test proportionnellement aux risques les plus critiques.

Pour l'élément de risque numéro 2, le NPR calculé est de 63, ce qui le positionne en priorité haute dans la liste des risques à couvrir en priorité lors des tests système.

Plan de test de phase

Document de planification opérationnel spécifique à un niveau de test donné, détaillant le calendrier précis des activités, les ressources nommées et les estimations de coûts propres à cette phase. Il se distingue du plan directeur de test par sa granularité et son périmètre restreint.

Le plan de test de phase d'intégration système liste nommément les testeurs affectés et fournit un calendrier détaillé semaine par semaine des activités d'exécution.

Plan directeur de test (Master Test Plan)

Document stratégique de gouvernance au niveau du projet ou du programme définissant l'approche de test globale, la portée, les livrables, les coûts estimés et les déviations par rapport à la stratégie de test. Il couvre tous les niveaux de test sans entrer dans le détail opérationnel de chaque phase.

Le plan directeur de test du projet bancaire décrit l'approche des tests de régression applicable à l'ensemble des cycles et liste les livrables de développement qui feront l'objet de tests.

RAD (Développement Rapide d'Applications)

Cycle de vie de développement logiciel fondé sur le prototypage itératif, les livraisons fréquentes et l'adaptation continue aux exigences évolutives, favorisant la validation précoce par les utilisateurs finaux. Il pose des défis spécifiques aux tests en raison de la documentation réduite et des exigences instables.

L'adoption d'une approche RAD permet au personnel marketing et aux testeurs de valider des prototypes d'écran précoces avant que le développement complet ne soit engagé.

Rapport de progression des tests

Document périodique destiné à informer les parties prenantes de l'avancement des activités de test, du statut des défauts et du respect des critères de sortie. Son contenu doit être adapté au niveau d'expertise technique et aux besoins décisionnels de chaque audience cible.

Le rapport de progression des tests destiné à la direction générale présente uniquement des métriques synthétiques, tandis que celui adressé au chef de projet spécialiste inclut la liste détaillée des défauts en suspens avec leur priorité et sévérité.

Risque produit

Risque lié à la possibilité qu'un livrable logiciel ne satisfasse pas aux exigences fonctionnelles ou non fonctionnelles attendues, pouvant entraîner des conséquences négatives pour les utilisateurs ou l'organisation. Il détermine l'intensité et les techniques de test à appliquer sur chaque zone du système.

Les préoccupations des utilisateurs relatives à la faible ergonomie de l'interface augmentent la probabilité du risque produit associé, conduisant à rediriger une partie de l'effort de test vers les tests d'utilisabilité.

Stratégie de test

Document de haut niveau définissant l'approche générale des tests pour un projet ou une organisation, incluant les techniques de conception, les critères d'entrée et de sortie, les niveaux de test et la politique de gestion des risques. Elle constitue le cadre de référence à partir duquel les plans de test détaillés sont dérivés.

La stratégie de test publiée pour le nouveau produit prescrit l'utilisation de techniques de conception systématiques et précise que les tests structurels seront focalisés sur les tests de composants.

Tests de confirmation (re-test)

Tests exécutés pour vérifier qu'un défaut précédemment signalé a bien été corrigé sans introduire de nouvelles anomalies, distincts des tests de régression qui visent l'ensemble des fonctionnalités non modifiées. Ils font partie intégrante du calcul du nombre total de tests restant à exécuter dans un cycle.

En supposant que tous les tests de confirmation réussissent et que le taux d'échec initial reste constant, le calcul aboutit à 720 tests restant à effectuer dans le cycle en cours.

Tests exploratoires

Technique de test simultanée combinant l'apprentissage du système, la conception des cas de test et leur exécution en temps réel, sans script prédéfini figé. Elle est particulièrement adaptée aux environnements à exigences évolutives comme le RAD, où la documentation est limitée.

Face à des exigences instables dans le projet RAD, le responsable des tests recommande les tests exploratoires comme technique principale d'atténuation des risques qualité.

Tests statiques

Activités de vérification ne nécessitant pas l'exécution du logiciel, incluant les revues, inspections et analyses de traçabilité, permettant de détecter des défauts dans les documents de spécification, les plans de test et autres artefacts. Ils sont particulièrement efficaces pour identifier les lacunes de couverture entre exigences et cas de test.

Pour traiter le risque que les cas de test ne couvrent pas les exigences clés du système de réservation externalisé, le responsable des tests préconise des tests statiques basés sur l'analyse de traçabilité.

TMMi (Test Maturity Model Integration)

Modèle d'amélioration de la maturité des processus de test structuré en cinq niveaux de maturité par étapes, fortement aligné sur le cadre CMMI. Il fournit un référentiel permettant d'évaluer et d'améliorer progressivement les pratiques de test d'une organisation.

Lors de la comparaison TMMi versus TPI, l'équipe retient que TMMi est un modèle par étapes à cinq niveaux étroitement lié à CMMI, indépendant du cycle de vie logiciel utilisé.

TPI (Test Process Improvement)

Modèle d'amélioration continue des processus de test à progression par points de contrôle indépendants, offrant plus de flexibilité que TMMi pour cibler des améliorations spécifiques sans obligation de franchir des niveaux de maturité globaux. Il est adaptable à différents types de cycles de vie logiciels.

L'organisation choisit TPI plutôt que TMMi pour son approche d'amélioration, car elle souhaite progresser sur des axes spécifiques sans avoir à satisfaire l'ensemble des critères d'un niveau de maturité global.

Traçabilité des exigences

Capacité à relier chaque cas de test aux exigences qu'il couvre et réciproquement, permettant de mesurer la couverture des tests et de démontrer que toutes les exigences ont été vérifiées. Dans les domaines critiques pour la sécurité, elle constitue une preuve réglementaire obligatoire.

Dans le projet de logiciel médical, la traçabilité vers les exigences est imposée comme mesure spécifique du domaine pour prouver l'adéquation des tests lors des audits réglementaires.

WBS (Work Breakdown Structure)

Structure de découpage hiérarchique des travaux décomposant l'ensemble des activités d'un projet de test en tâches élémentaires estimables et assignables, utilisée comme base pour l'élaboration des estimations de coûts et du planning. Elle couvre l'intégralité du périmètre du projet, des activités de planification à la clôture.

La WBS du projet de tests d'acceptation du système de réservation inclut la planification, la préparation des cas de test et l'exécution pour chacun des quatre incréments de livraison.