Menu

Exemple de modèle de rapport de test d'acceptation avec des exemples

sample template acceptance test report with examples

Essayez Notre Instrument Pour Éliminer Les Problèmes

Vue d'ensemble du rapport d'essai d'acceptation (partie III):

Tutoriel précédent | Tutoriel SUIVANT

Dans notre précédent tutoriel sur ' Documentation des tests d'acceptation avec des scénarios en temps réel ”Nous avons discuté du plan de test d'acceptation.

Dans ce didacticiel, nous examinerons en profondeur la création de rapports sur l'état du test d'acceptation, le résumé du test d'acceptation et la signature.

Certains modèles génériques sont inclus dans ce didacticiel pour améliorer votre compréhension d'une meilleure manière. Nous passerons également en revue le concept des tests d'acceptation dans le développement agile et piloté par les tests d'acceptation.

En bref, ce didacticiel vous expliquera le rapport d'état et le rapport récapitulatif des tests d'acceptation, ainsi que des modèles génériques pour une compréhension claire, ainsi que le concept de test d'acceptation dans le développement Agile et piloté par les tests d'une manière facilement compréhensible.

Modèle de test d

Ce que vous apprendrez:

Rapport d'état du test d'acceptation

Le rapport de test d'acceptation doit toujours résumer les tests d'acceptation qui sont effectués avec leurs résultats. Il doit être adressé à toutes les parties prenantes identifiées qui font partie de la phase de test d'acceptation. Une fois que l'exécution des tests d'acceptation a commencé, les progrès doivent être signalés au jour le jour.

Modèle générique pour le rapport d'état du test d'acceptation:

Date :Date du rapport d'état du test d'acceptation

Détails de l'exécution des tests d'acceptation d'aujourd'hui:

  • Nombre de tests réussis
  • Nombre de tests échoués
  • Nombre de tests en cours

Détails de l'exécution des tests d'acceptation jusqu'à la date:

  • Nombre total de tests
  • Nombre de tests réussis
  • Nombre de tests échoués
  • Nombre de tests en cours
  • Nombre de tests en attente

Détails des défauts:

outil de piratage en ligne
  • Nombre d'anomalies enregistrées
  • Chaque défaut doit avoir les détails ci-dessous:
    • ID, résumé, composant, gravité
  • Le nombre total de défauts enregistrés jusqu'à présent (en phase de test d'acceptation).

Ce rapport doit être revu quotidiennement pour s'assurer que l'exécution est sur la bonne voie et qu'il n'y a pas d'écart par rapport aux calendriers prévus.

Rapport de synthèse du test d'acceptation

Il s'agit du rapport qui résume l'état de l'ensemble de la phase de test d'acceptation. Cela implique des détails tels que les activités de test menées, les références aux critères remplis, les spécifications des exigences, les règles métier, les résultats d'exécution, les calendriers prévus, les écarts, etc.

Modèle générique de rapport récapitulatif des tests d'acceptation:

Résumé

Les écarts

Les écarts

Résultats

Rapports

Évaluation

Recommandation

gravité des défauts , et le taux de réussite a un impact sur la recommandation de lancement du produit sur le marché.>

Efforts

Efforts

Rapport d'approbation

Une fois que le produit a passé les tests d'acceptation, il sera recommandé de passer en direct. Avant d'être lancé en production, il doit être officiellement signé.

Modèle générique pour le rapport d'approbation:

Nom du produit, version, numéro de build

Dernier rapport

Révisé le

Revu par

Examiner les commentaires

Date de signature

Signature par

Commentaires de signature

En général, tous les rapports ci-dessus doivent être examinés par les principales parties prenantes pour son modèle et doivent être convenus de ce qui doit figurer dans les informations.

Tous les détails qui sont remplis dans le rapport doivent être vérifiés avant de le partager avec les parties prenantes. Toute divergence dans le rapport aura un impact important sur la décision commerciale et pourrait entraîner une défaillance du produit sur le marché.

Par conséquent, les rapports doivent toujours être gérés par des spécialistes ou des membres seniors de l'équipe.

Test d'acceptation en Agile

Dans Agile , Les critères d'acceptation de chaque user story sont ciblés pour les tests d'acceptation, c'est-à-dire que les tests d'acceptation sont dérivés des critères d'acceptation d'une user story. Chaque critère d'acceptation peut avoir un ou plusieurs tests d'acceptation pour couvrir le scénario.

Les tests d'acceptation sont généralement conçus par un AQ qui est l'expertise en la matière dans le domaine. Les tests d'acceptation dans Agile commencent bien tôt par rapport aux autres approches, généralement dans les sprints eux-mêmes.

Il est effectué très fréquemment car chaque sprint aura de nouvelles histoires d'utilisateurs à venir ainsi que des améliorations / continuations des histoires précédentes.

Les tests d'acceptation sont effectués à deux étapes différentes dans Agile:

  • Lorsque la fonctionnalité est créée et dans sa phase initiale - de base.
  • Lorsque la fonctionnalité est intégrée et stabilisée avec les autres fonctionnalités du produit.

Chaque user story ici doit subir un test d'acceptation et doit être passée pour examen. Tout échec dans le test d'acceptation doit être considéré comme une priorité élevée et corrigé immédiatement, cela, à son tour, aura le test d'acceptation pour l'exécuter.

Des points d'histoire sont attribués à chaque user story en fonction du succès des résultats des tests d'acceptation pour chacun des critères d'acceptation. Le test d'acceptation définit également l'achèvement au niveau de la user story, indiquant que les critères d'acceptation de l'histoire sont remplis.

Qui effectue les tests d'acceptation dans Agile?

Habituellement, les chefs de produit, l'expertise en la matière (il peut s'agir de testeurs clients ET / OU bêta) effectuent des tests d'acceptation dans un environnement Agile. Parfois, l'AQ implique également cette activité avec leurs tâches de régression régulières.

Avantages des tests d'acceptation en Agile

Les tests d'acceptation dans Agile présentent plusieurs avantages.

Les avantages sont:

  • Collaboration plus étroite entre le chef de produit et l'équipe.
  • Renforce la confiance au niveau de la User Story.
  • Aidera à dériver plus de scénarios pour couvrir chaque critère d'acceptation.
  • Augmentation de la probabilité d'improviser les solutions du produit grâce aux critères d'acceptation dans les User Stories.

Désavantages

Bien qu'il y ait plusieurs avantages, il y a aussi certains inconvénients.

Les inconvénients comprennent:

  • Toutes les histoires ne peuvent pas être prises en compte pour les tests d'acceptation. Seules les histoires fonctionnelles à couvrir - La couverture au niveau de l'histoire peut diminuer.
  • Tous les critères d'acceptation ne peuvent pas être pris en compte pour les tests d'acceptation. Seuls les critères fonctionnels doivent être couverts - La couverture des critères d'acceptation dans User story peut diminuer.
  • Étant donné que des parties prenantes de différents horizons sont impliquées et que les tests d'acceptation au niveau de l'histoire sont effectués directement, il est assez difficile pour tout le monde d'être sur la même longueur d'onde (essentiellement pour comprendre le niveau de la user story individuelle).
  • Étant donné que la durée de publication est inférieure à celle d'autres approches, il est assez difficile d'intégrer les tests d'acceptation dans les sprints.

Développement piloté par les tests d'acceptation (ATDD)

Il s'agit de l'une des pratiques de développement Agile où toute l'équipe discute en collaboration de chacun des critères d'acceptation de User Story et construit des tests d'acceptation solides autour d'eux.

En effet, des perspectives différentes de chacun des membres de l'équipe donneront une nouvelle façon de penser pour chacun des critères d'acceptation et arriveront avec un bon nombre de tests d'acceptation couvrant plus de scénarios. Quelquefois, ATDD s'appelle aussi Développement piloté par les tests d'histoire (STDD).

En fait, ATDD se produit avant le début du développement. Ainsi, les développeurs, dans cette approche, sauront ce qui est réellement attendu et comment y parvenir. Toute l'équipe partagera une compréhension commune de la fonctionnalité et de ce qui est en cours de construction.

Cela décrit comment le produit est construit et donnera à son tour une idée juste de la façon dont le produit fonctionnera réellement avant qu'il ne soit remis pour test. Par conséquent, il est appelé « Développement piloté par les tests d'acceptation ».

Conclusion

Les tests d'acceptation dans l'une de ses approches ont pour objectif commun de renforcer la confiance et la satisfaction du client sur le produit développé avant sa mise en service. Ceci n'est obtenu que lorsqu'il n'y a pas / moins de défauts de faible gravité dans le produit qui n'entravent aucune des fonctionnalités.

En un mot:

  • Les tests d'acceptation sont réussis.
  • Les défauts sont à des niveaux acceptables.
  • Couverture en flux / scénario réalisée.
  • Le produit et ses solutions sont acceptés.
  • Le client est suffisamment confiant dans le produit.
  • Tous les documents produits sont mis à jour pour correspondre aux dernières fonctions.
  • Résultat de l'effort de l'équipe.
  • C'est bien d'aller de l'avant avec le lancement de la production.

Tutoriel précédent | Tutoriel SUIVANT

J'espère que vous auriez acquis d'immenses connaissances grâce à ces didacticiels de test d'acceptation. N'hésitez pas à partager vos réflexions et à poser vos questions dans la section commentaires ci-dessous.

lecture recommandée

^