Le test de réception est le test final avec le déploiement du logiciel. L'objectif du test de réception est de vérifier que le logiciel est prêt et qu'il peut être utilisé pour exécuter les fonctions et tâches pour lesquelles il a été conçu. Le test de réception peut être mis en oeuvre à travers trois stratégies communes. A savoir :

La stratégie que vous sélectionnez dépend souvent des exigences contractuelles, des normes de l'organisation et de l'entreprise, et du domaine d'application.

Test de réception formel To top of page

Le test de réception formel est un processus très encadré et constitue souvent une extension du test de système. Les tests sont planifiés et conçus aussi soigneusement que pour le test de système, avec le même niveau de détail. Les cas de test choisis doivent être un sous-ensemble de ceux exécutés dans le test de système. Il est important de ne pas s'écarter de quelque façon que ce soit des cas de test choisis. Dans de nombreuses organisations, le test de réception formelle est entièrement automatisé.

Les activités et artefacts sont les mêmes que pour le test de système. Dans certaines organisations, c'est l'organisation de développement (ou son groupe de test indépendant) qui réalise le test de réception conjointement avec les représentants de l'organisation d'utilisateurs finaux. Dans d'autres organisations, le test de réception est entièrement réalisé par l'organisation d'utilisateurs finaux ou un groupe de personnes objectives choisi par l'organisation d'utilisateurs finaux.

Les avantages de cette forme de test sont les suivants :

  • Les fonctions et options à tester sont connues.
  • Les détails des tests sont connus et peuvent être mesurés.
  • Les tests peuvent être automatisés, ce qui permet d'effectuer des tests de régression.
  • L'évolution des tests peut être mesurée et contrôlée.
  • Les critères d'acceptabilité sont connus.

Ses désavantages sont les suivants :

  • Beaucoup de ressources et un travail de planification important sont nécessaires.
  • Les tests peuvent être de nouvelles implémentations des tests de système.
  • Les tests peuvent ne pas mettre à jour des anomalies subjectives dans le logiciel, étant donné que vous ne recherchez que les anomalies que vous vous attendez de trouver.

Test de réception informel Haut de la page

Dans le test de réception informel, les procédures de test pour l'exécution du test ne sont pas rigoureusement définies que pour le test de réception formelle. Les fonctions et tâches métier à explorer sont identifiées et documentées, mais il n'y a pas de cas de test particulier à suivre. Chaque testeur détermine la marche à suivre. Cette approche du test de réception n'est pas contrôlée comme le test formel et est davantage subjective que le test formel.

Le test de réception informel est plus fréquemment réalisé par l'organisation d'utilisateurs finaux.

Les avantages de cette forme de test sont les suivants :

  • Les fonctions et options à tester sont connues.
  • L'évolution des tests peut être mesurée et contrôlée.
  • Les critères d'acceptabilité sont connus.
  • Vous mettrez à jours des anomalies plus subjectives qu'avec le test de réception formel.

Ses désavantages sont les suivants :

  • Ce test demandes des ressources, un travail de planification et une gestion des ressources.
  • Vous devez contrôler quels cas de test sont utilisés.
  • Les utilisateurs finaux peuvent se conformer à la façon dont fonctionne le système et ne pas voir les anomalies.
  • Les utilisateurs finaux peuvent passer leur temps à comparer le nouveau système avec le système en vigueur plutôt que de rechercher les anomalies.
  • Les ressources du test de réception ne sont pas sous le contrôle du projet et peuvent être limitées.

Test bêta To top of page

Le test bêta est le moins contrôlé des trois stratégies de test de réception. Dans le test bêta, le niveau de détail, les données et l'approche adoptée dépendent entièrement de chaque testeur. Chacun est responsable de la création de son propre environnement de test, de la sélection des données, et de la détermination des fonctions, options ou tâches à explorer. Chaque testeur est responsable de l'identification de ses propres critères d'acceptation du système dans son état actuel ou non.

Le test bêta est mis en oeuvre par les utilisateurs finaux, souvent avec peu ou pas de gestion de la part de l'organisation de développement (ou autre non utilisateur final). Le test bêta est la plus subjective de toutes les stratégies de test de réception.

Les avantages de cette forme de test sont les suivants :

  • Le test est mis en oeuvre par les utilisateurs finaux.
  • Les ressources de test potentielles sont énormes.
  • Le niveau de satisfaction du client est supérieur parmi les participants.
  • Vous mettez à jours des anomalies plus subjectives qu'avec le test de réception formel ou informel.

Ses désavantages sont les suivants :

  • Vous pouvez ne pas tester toutes les fonctions ou options.
  • L'évolution du test est difficile à mesurer.
  • Les utilisateurs finaux peuvent se conformer à la façon dont fonctionne le système et ne pas voir ou signaler les anomalies.
  • Les utilisateurs finaux peuvent passer leur temps à comparer le nouveau système avec le système en vigueur plutôt que de rechercher les anomalies.
  • Les ressources du test de réception ne sont pas sous le contrôle du projet et peuvent être limitées.
  • Les critères d'acceptabilité sont inconnus.
  • Vous avez besoins de plus de ressources de soutien pour gérer les testeurs bêta.


RUP (Rational Unified Process)   2003.06.15