Activité: Vérifier l'approche de test
Cette activité montre que les différentes techniques décrites brièvement dans l'approche de test faciliteront l'effort de test prévu. Le but est de vérifier par démonstration que l'approche va fonctionner, produire des résultats corrects et qu'elle est adaptée aux ressources disponibles.
DescriptionStructure de répartition du travailAffectation d'équipeUtilisation du produit
Relations
Activités parentes
Description

L'objectif est de comprendre les contraintes et les limitations de chaque technique par rapport au contexte du projet donné, et de :

  • trouver une solution d'implémentation appropriée pour chaque technique
  • trouver des techniques alternatives pouvant être utilisées.

Cela aide à limiter le risque de découvrir trop tard dans le cycle de vie du projet que l'approche de test ne peut pas être utilisée.
Pour chaque itération, le travail se focalise principalement sur :

  • Vérifier tôt dans le projet que la stratégie de test prévue va fonctionner et produire des résultats de valeur
  • Etablir l'infrastructure de base pour permettre la stratégie de test et la prendre en charge
  • Obtenir un engagement de l'équipe de développement de développer le logiciel pour répondre aux exigences de testabilité nécessaires pour atteindre la stratégie de test, et fournir une prise en charge continue de ces exigences de testabilité.
  • Identifier la portée, les frontières, les limitations et les contraintes de chaque technique
Propriétés
Commandé par les événements
Plusieurs occurrences
En cours
Facultatif
PlanifiéYes
Réitérable
Affectation du personnel

Bien que la majorité des rôles impliqués dans la discipline de test jouent un rôle dans ce travail, l'effort se concentre principalement autour des rôles de concepteur de test et de testeur. Le domaine de compétence le plus important requis pour ce travail comporte l'architecture logicielle, la conception logicielle et la résolution de problèmes.

Ce rôle nécessite généralement plus de ressources dans les itérations allant de la fin de la phase de création au début de la phase de construction, et demande souvent des ressources minimales à la fin de la phase de construction et dans la phase de transition. Cependant, soyez conscient du fait qu'au fur et à mesure de la progression du projet, de nouveaux objectifs ou livrables peuvent avoir été identifiés nécessitant de nouvelles stratégies de test à définir et à vérifier.

Pour donner une heuristique de l'utilisation relative des ressources par phase, les pourcentages d'utilisation des ressources de test pour cette activité sont : création - 30%, élaboration - 20%, construction - 10% et transition - 05%.

Utilisation
Conseils d'utilisation

Cette activité commence tôt dans chaque itération, dès qu'un accord satisfaisant est trouvé sur la mission de l'itération, et continue selon les besoins pendant l'itération. Traité plus fréquemment dans les premières phases de création, d'élaboration et au début de la construction, et allant généralement en diminuant à la fin de la construction et dans la transition.

Cette activité est considérée comme optionnelle lorsque l'approche de test est connue, et que son applicabilité au contexte actuel est bien établie.

Ce travail est relativement indépendant des cycles de test, et comporte souvent la vérification de techniques qui ne seront pas utilisées avant les itérations ultérieures. Ce travail commence normalement après que la mission d'évaluation ait été définie pour l'itération actuelle, bien qu'il puisse débuter plus tôt. Dans certains cas, il peut falloir de nombreuses itérations pour trouver la meilleure approche d'implémentation pour une technique.

Les activités d'implémentation et d'exécution de test faisant partie de ce travail sont effectuées dans le but d'obtenir une preuve démontrable que les techniques vérifiées peuvent véritablement fonctionner. Ainsi, nous vous conseillons de limiter votre sélection de test à un petit sous-ensemble représentatif ; en vous focalisant généralement sur des domaines possédant des risques élevés en terme de qualité. Essayez d'inclure une sélection de tests qui, selon vous, vont échouer afin de confirmer que la technique détectera bien ces échecs.

Bien que les échecs des éléments de test ciblés soient identifiés et les incidents enregistrés en conséquence, l'identification des échecs n'est pas l'intérêt central de ce travail ni son objectif principal. L'objectif est encore une fois de vérifier que l'approche est appropriée (elle produit des résultats qui complètent les objectifs de l'itération), qu'elle peut être atteinte (elle peut être implémentée avec des contraintes données en terme de ressources), et qu'elle fonctionnera.

Pour que ce travail produise des résultats rapides, il est souvent nécessaire d'utiliser des constructions incomplètes "officieuses" ou bien d'effectuer ce travail en dehors d'une configuration reconnue d'environnement de test. Bien que ces compromis soient appropriés, soyez conscient des contraintes, des suppositions et des risques qui existent lorsque vous vérifiez votre approche dans de telles conditions.

Au fur et à mesure que le cycle de vie progresse d'une phase à l'autre, l'intérêt central de l'effort de test change généralement. Cela peut nécessiter potentiellement des approches nouvelles ou supplémentaires, demandant l'introduction de nouveaux types de tests ou de nouvelles techniques pour prendre en charge l'effort de test.

Dans les situations où la combinaison de domaine, l'environnement de test et d'autres aspects cruciaux de la stratégie n'ont pas de précédent, consacrez plus de temps et d'effort pour effectuer ce travail. Dans certains cas - en particulier lorsque l'automatisation est une exigence- il peut être plus économique d'obtenir l'utilisation de ressources possédant des compétences spécialisées et une expérience prouvée dans les aspects de la stratégie n'ayant pas de précédent, pendant une période réduite (comme des ressources contractuelles) afin de définir et de vérifier les besoins techniques fondamentaux de la stratégie de test.

Plus d'informations