Web-ntic MOE MOA

Du concept au projet informatique - De la maîtrise d’oeuvre à la maîtrise d’ouvrage

Web-ntic > Tests et recette > Procéssus de test selon l’ISTQB

Procéssus de test selon l’ISTQB

vendredi 25 mai 2012, par km

ISTQB
L’ISTQB donne un cadre de réflexion pour mettre en place un processus de test. Si l’on ne connait des activités de ce processus de test que la conception et l’exécution, il faut aller plus loin en ajoutant deux autres activités.

Le processus de test se décompose en différentes activités

  • Planification et contrôle
  • Analyse et conception
  • Implémentation et exécution
  • Evaluation des critères de sortie et reporting
  • Activités de clôture

Certaines de ces activités de test peuvent être menées en parallèle (2 et 3), d’autres en séquence (4 et 5)

Modèle de processus de test

En tant que modèle, un modèle de processus de test n’est qu’une abstraction de la réalité et peut apporter une aide pour la comprendre
exemple de modèles de processus :

  • Practical Software Testing – Test Maturity Model de Ilene Burnstein
  • Critical Testing Processes de Rex Black
  • Systematic Test and Evaluation Process (STEP)

Planification et contrôle

La planification consiste à identifier toutes les activités et ressources nécessaires pour mener à bien l’objectif de test décrit dans la stratégie de test
L’approche de test basés sur les risques va permettre de mettre en phase, via le planning, les activités de tests afin de réduire les risques produits identifiés. De même cette approche va permettre de prioriser les activités.
Le contrôle du planning est une activité permanente qui consiste à comparer les progrès réalisés avec l’avancement prévu et de réviser la planification des activités si besoin.
Les métriques liés à cette activités peuvent inclure

  • Couverture des risques par les tests
  • Découverte d’anomalies
  • temps passé / planifié à développer le testware et exécuter les cas de test

Analyse et conception des tests

Cette activité consiste à identifier les conditions de test, créer les cas de tests en regard des conditions.
Durant cette activité de conception et la suivante (implémentation et exécution), la priorisation des critères identifiés durant la phase d’analyse de risque et de planification des tests doit être appliquée.

Implémentation et exécution

Implémentation des tests consiste à :

  • organiser les cas de tests en procédures, en scénarios de test
  • finaliser les données de test et les environnements
  • formaliser un planning d’exécution des cas de test
  • vérifier les critères d’entrée

Cette implémentation doit prendre en compte les objectifs définis dans la stratégie de test, notamment en termes de priorité de test vis à vis par exemple de la criticité des exigences.
Concernant les données de test, c’est durant cette activité que les données peuvent être chargées en base de données, voire crées via des scripts si besoin.

Exécution des tests

Cette activité démarre lorsque l’objet du test est livré et que les critères d’entrée sont satisfaits.
Les tests manuels doivent être exécutés selon les procédures de test avec un degré de liberté pour permettre la couverture de scénarios intéressants - chaque anomalie devra alors être suffisamment décrite pour pouvoir être reproduite.
Les test automatisés doivent être exécuté comme prévus.

Les métriques de cette activité peuvent être :

  • Pourcentage d’environnement de test configurés
  • Pourcentage de données de test chargés en base
  • Pourcentage de conditions de test et de cas de tests exécutés
  • Pourcentage de cas de test automatisés.

Evaluation des critères de sortie

Du point de vue de la procédure de tests, le suivi d’avancement des tests implique la collecte d’informations. Les métriques vont prendre en compte les critères de sorties, tels que validés durant la planification.

Cela peut être :

  • nombre de cas de test planifiés, exécutés, dont en anomalie et passés.
  • nombre d’anomalies réparties par gravité, et priorité pour celles qui sont corrigée et en cours.
  • nombre d’évolution atteints, pris en compte et testés.
  • Pour le reporting au niveau des tests, l’IEEE 829 préconise un Rapport résumé, constitué de :
  • Identifiant du rapport
  • résumé
  • Ecarts
  • Evaluation complète
  • Résumé des résultats
  • Résumé des activités
  • Approbations
  • Evaluation
  • Le reporting des tests peut être produit à la fin des différents niveau de test (tests unitaires, tests d’intégration, tests système)

Activités de clôture des tests

Ces activités peuvent être regroupées en 4 ensembles.

  • s’assurer que chaque activités de test est menée à terme, c’est à dire que les tests planifiés ont été exécutés, ou ajournés ; les anomalies ont été corrigées, recyclées, remises à plus tard ou déclarées contournables.
  • donner des taches aux bons profils en attribuant des anomalies typées (régression, performance, fonctionnelle) à ceux qui ont la compétence requise.
  • participer à des retour d’expérience avec rédaction de documentation sur les leçons apprises à la fois sur le projet de test et sur le cycle de vie du logiciel.
  • archiver les résultats et les documents
  • Les métriques de suivi des activités de clôture des tests peuvent inclure
  • Pourcentage de cas de test exécutés
  • Pourcentage de cas de test identifiés comme réutilisable dans le répertoire des cas de tests
  • Pourcentage de cas de test identifié comme test de non régression.
  • ratio de cas de test automatisés, manuels

Un message, un commentaire ?

modération a priori

Ce forum est modéré a priori : votre contribution n’apparaîtra qu’après avoir été validée par un administrateur du site.

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document