dernière modification : 15 février 2020

document – Plan de Test du Logiciel

Introduction

Généralités

Décrire l’utilité du document.
Ce document contient le plan de tests du logiciel XXX. Il s’applique au dispositif médical XXX.

Référence (lorsque nécessaire)

Références utiles pour le document.

Documents

Identifiant Révision Titre
PRO.CVL x.x Procédure cycle de vie du logiciel

Normes / guides / standards

Les normes et guides utilisés pour le développement, hors aspects DM.
titre Révision Utilisation

Abréviations

SOUP ;

Phases de test

Décrire ici les phases de tests, renvoyer vers le PDL si les phases sont déjà décrites dans celui-ci.

Tests d’intégration

Décrire comment les phases de tests d’intégration sont gérées, revues, documentées … Cette partie peut avoir été décrite succinctement dans le PDL. Elle est décrite de façon plus détaillée ici. Il est admis que la phase « tests d’intégration » ne soit pas séparée de la phase « tests de vérification ».

Phases de tests d’intégration

Décrire les phases de tests d’intégration.

Pour mémoire, les essais d’intégration et de vérification visent à vérifier :

  • L’intégration des composants logiciels entre eux,
  • L’intégration matérielle et logicielle,
  • La conformité du logiciel aux exigences logicielles définies dans la SEL.
Les tests d’intégration sont planifiés à la livraison du module développé par la société sous-traitante xxx :
  • Point d’intégration 1 : à la réception du module version alpha,
  • Point d’intégration 2 : à la réception du module version beta,
  • Point d’intégration finale : à la réception du module version finale.
Les fonctions du logiciel demandent à ce que le logiciel soit intégré pour pouvoir être testées. Par conséquent, les tests d’intégration sont effectués simultanément avec les tests de vérification.

Tests de vérification

Décrire les phases des tests de vérification de façon globale, sans rentrer dans le détail qui est donné dans le plan de tests.
Les tests sont découpés en 7 phases :
Phase Contenu Critère de succès
Dry-Run 1 V0.2. Test des modules xxx et yyy uniquement Les testeurs sont l’équipe de qualification/acceptance (QA) logicielle. Le logiciel est installé sur une plateforme de test et d’intégration. bugs bloquants corrigés
Dry-Run 2 V0.3. Test des modules xxx, yyy, zzz et ttt uniquement. Les testeurs sont l’équipe de qualification/acceptance (QA) logicielle. Le logiciel est installé sur une plateforme de test et d’intégration. bugs bloquants corrigés
Alpha 1 V0.4. Les testeurs sont l’équipe de qualification/acceptance (QA) logicielle. Tous les tests fonctionnels sont exécutés Le logiciel est installé sur une plateforme de test et d’intégration. bugs bloquants corrigés
Alpha 2 V0.5. Les testeurs sont l’équipe de qualification/acceptance (QA) logicielle. Le logiciel est installé sur une plateforme de test et d’intégration. Tous les tests fonctionnels, tests aux limites, tests de performances sont exécutés bugs bloquants corrigés et ; 70% bugs majeurs corrigés
Beta 1 V0.8. Les testeurs sont des utilisateurs sélectionnés des sites pilotes. Le logiciel est installé sur les sites pilotes. Tous les tests fonctionnels et tests de performances sont exécutés. bugs bloquants corrigés et ; 80% bugs majeurs corrigés
Beta 2 V0.9. Les testeurs sont des utilisateurs des sites pilotes. Le logiciel est installé sur les sites pilotes. Tous les tests fonctionnels et tests de performances sont exécutés. bugs bloquants corrigés et ; 90% bugs majeurs corrigés
Version finale V1.0. Les testeurs sont des utilisateurs des sites pilotes. Le logiciel est installé sur les sites pilotes. Tests libres de la version. bugs bloquants corrigés et ; bugs majeurs corrigés et ; 90% bugs mineurs corrigés

Critères de fin de phase de tests

Décrire les critères qui permettent de déterminer qu’une phase de tests est terminée. Attention : le fait qu’une phase de test soit terminée n’implique pas que tous les tests sont OK. Cf Sanction des tests plus bas.
  • Simple : Les tests sont réputés terminés quand tous les tests de la SEL ont été exécutés. Une dérogation peut être accordée, selon le cas, si certains tests n’ont pas été exécutés.
  • En différenciant intégration et vérification : Les tests d’intégration sont réputés terminés selon les critères ci-dessous :
    • Point d’intégration 1 : les tests des exigences d’intégration du module version alpha sont exécutés,
    • Point d’intégration 2 : les tests des exigences d’intégration du module version beta sont exécutés,
    • Point d’intégration finale : les tests des exigences d’intégration du module version finale sont exécutés.

    Les tests de vérification sont réputés terminés selon les critères ci-dessous :

    • Dry-run 1 : Tests des modules xxx et yyy ont tous été exécutés,
    • Dry-run 2 : Tests des modules xxx, yyy, zzz, et ttt ont tous été exécutés,
    • Alpha 1, alpha 2, beta 1 et beta 2 : Tous les tests ont été exécutés,
    • Version finale : tests libres, la phase est bornée à 2 mois.

Reprise des tests en cas d’échec en fin de phase

Décrire comment est gérée un échec de sortie phase de tests (au moins un test pas ok sans dérogation possible) et la reprise des tests.
Lorsque qu’un moins un test n’est pas OK en fin de phase de tests et qu’une dérogation n’est pas accordée (logiciel non-conforme), la phase de tests doit être ré-exécutée avec une nouvelle version du produit logiciel qui corrige les anomalies.

Il est admis de ne ré-exécuter qu’une partie des tests, à condition qu’une justification soit donnée sur les tests ne nécessitant pas d’être repassés.


Ce contenu est réservé aux abonnés.