Tâche: Obtenir un engagement de testabilité
Cette tâche concerne la définition, la hiérarchisation et la promotion des besoins et des avantages de la testabilité.
Disciplines: Test
Objet

L'objectif de cette tâche est de :

  • Promouvoir la création de logiciels pouvant être testés et prenant en charge les besoins de l'effort de test
  • Promouvoir et prendre en charge l'utilisation de techniques et d'outils d'automatisation appropriés
Relations
Etapes
Examiner les besoins en testabilité
Objectif :  Acquérir une bonne compréhension des besoins d'implémentation de test et d'évaluation, qui doivent être traités par le processus d'ingénierie logicielle ou d'architecture et de conception logicielle. 

Etudiez l'architecture d'automatisation des tests et les caractéristiques de l'interface de test pour comprendre les besoins en termes d'implémentation des tests et d'évaluation. Il est particulièrement important de comprendre les contraintes que ces besoins imposent au processus d'ingénierie logicielle ou à l'architecture et à la conception logicielle.

Evaluer l'impact et hiérarchiser
Objectif :  Identifier les besoins en testabilité ayant le plus d'importance pour l'effort de test et préconiser leur résolution avant les besoins moins importants. 

Etudiez les besoins en testabilité et effectuer des analyses d'impact génériques sur l'effort de test requis si le besoin n'est pas satisfait. Envisagez aussi une analyse de base de l'effort potentiel requis par l'équipe de développement afin d'étudier le besoin et d'y trouver une solution. Pour chaque besoin, identifiez des solutions de remplacement potentielles qui auraient moins d'impact sur les équipes de développement.

En utilisant ces informations, élaborez une liste hiérarchisée qui met l'accent sur les besoins qui, lorsqu'ils ne sont pas satisfaits, ont un impact important sur les efforts de test, mais n'ont pas de solution de remplacement. L'objectif est d'éviter de gâcher des ressources de développement de valeur sur des besoins de testabilité moins essentiels, et de conserver ces ressources pour les besoins les plus importants.

Définir les avantages de la testabilité
Objectif :  Pouvoir convaincre les parties prenantes de la valeur des besoins de testabilité en termes de simple coût-rendement. 

En demandant à l'équipe de développement de développer des logiciels conçus pour gérer l'effort de test, vous ajouterez des exigences et des contraintes supplémentaires à l'effort de développement ; cela signifie essentiellement plus de travail et plus de risque et de complexité pour l'équipe de développement. Certaines équipes de développement considéreront que la prise en compte de la testabilité dans la conception ne dépend pas de leur responsabilité. Dans d'autres cas, les besoins en testabilité seront en compétition avec les besoins et les exigences des clients, qui sont généralement considérés comme prioritaires. Ainsi, vous devez "vendre" les avantages de la testabilité au responsable de projet, à l'architecte logiciel et aux autres parties prenantes de l'équipe de développement.

Elaborez une analyse des avantages de chaque besoin en testabilité pour lequel vous souhaitez un engagement. Cherchez des articles et des études appuyant la valeur de votre besoin en testabilité, et utilisez des statistiques sur le retour sur investissement, si vous en avez. Formulez les avantages en termes de valeur fournie à l'équipe de développement ; quelles informations d'évaluation utiles pourrez-vous leur fournir qu'ils n'auraient pas obtenues si ce besoin n'avait pas été satisfait ? Dans quelle mesure cela vous permettra-t-il de fournir plus facilement ou de manière plus efficace un retour rapide, exact, utile ou détaillé à l'équipe de développement pendant chaque cycle de construction ? Ce besoin fournit-il à l'équipe de développement une fonction utile pouvant être utilisée dans leur propre effort de test ou lors de diagnostics futurs de défaillance des logiciels ? Lorsque ce besoin est en compétition avec les besoins des clients, montrez que lorsque l'on répond de manière précoce au besoin en testabilité, cela permet de mieux répondre aux exigences du client lors des cycles de construction ultérieurs.

Identifier et convaincre des spécialistes de la testabilité
Objectif :  Former des alliances avec des parties prenantes importantes qui superviseront la construction de logiciels pouvant être testés et prendront en charge les besoins de l'équipe de test à cet égard. 

Dans la mesure où vous allez imposer un surcroît de risque ou de travail potentiel à l'équipe de développement, vous devez identifier et convaincre les parties prenantes influentes qui peuvent approuver ou rendre obligatoire la prise en charge de la testabilité. Faites-le le plus tôt possible, avant de promouvoir activement les besoins en testabilité qui doivent être pris en charge.

Les trois parties prenantes les plus importantes sont l'architecte logiciel, le responsable de projet et le représentant du client. Passez du temps avec l'architecte logiciel et défendez l'intérêt d'une architecture logicielle prenant en charge la testabilité. Passez du temps avec le responsable de projet et soulignez les avantages de la testabilité en termes de productivité de l'équipe de test et de la transmission rapide des informations d'évaluation. Encouragez le client à accorder de la valeur à la livraison d'un produit de qualité.

Promouvoir les besoins et les avantages de la testabilité
Objectif :  Informer les parties prenantes appropriées des principaux besoins en testabilité de l'effort de test, et obtenir leur soutien pour la testabilité. 

Il est important de promouvoir les besoins en testabilité d'une manière adéquate. Chaque combinaison de responsable de projet, équipe de développement et parties prenantes client possède une dynamique et une culture sociale différente, et il faut prendre ce fait en compte au moment de promouvoir les besoins en testabilité. D'une manière générale, ne lancez pas une "campagne" de testabilité formelle si l'équipe est relativement détendue et informelle ; et n'utilisez pas non plus une approche informelle pour un projet très procédurier.

Dans certains cas, une session collaborative de "brainstorming" est un format de présentation utile, où le besoin est exposé à l'équipe de développement comme un défi, et ils sont encouragés à identifier des solutions créatives pour répondre au(x) besoin(s) de testabilité. Ceci les encourage à prendre la responsabilité de la solution et crée un sentiment de partenariat dans l'effort.

Le choix du moment est aussi important dans cette étape. En règle générale, vous devez essayer d'identifier et de promouvoir les problèmes de testabilité les plus importants le plus tôt possible, généralement pendant la phase d'élaboration et si possible dans la phase de création. Lorsque les problèmes de testabilité sont soulevés dans les premières étapes du projet, l'équipe est généralement plus réduite et plus réceptive au changement. Il est aussi plus facile d'inclure ces besoins dans la conception en évolution car les remaniements à effectuer sont généralement limités.

Une bonne façon d'identifier les besoins en testabilité et de les présenter de manière positive et moins "officielle" consiste à demander à l'équipe de test d'évaluer les activités de justification de la conception et d'examiner la sélection des composants tiers à utiliser dans l'effort de développement. En particulier, l'implication des équipes de test lors de la sélection des composants de la base de données, du contrôle de l'interface utilisateur ou de la sélection des composants middleware, etc., signifie que les problèmes de testabilité peuvent être utilisés comme un aspect des critères de sélection des composants. Par exemple, les équipes de développement n'ont généralement pas de préférence quant à la bibliothèque d'objets fenêtre à utiliser ; si une bibliothèque est plus facile à tester qu'une autre, l'équipe de développement ne verra aucun inconvénient à l'utiliser.

Si l'identification ou la persuasion des spécialistes de la testabilité vous posent problème, vous devrez peut-être envisager une approche qui intègre les changements de façon plus progressive en créant des blocs d'efforts plus petits et moins risqués, ou bien remonter les besoins de testabilité les plus importants comme problèmes fondamentaux du projet compromettant la réussite de l'effort de test. Dans ce dernier cas, nous vous recommandons d'envisager avec soin toutes les autres options avant de vous lancer dans cette voie.

Obtenir un engagement de prise en charge et de maintenance de la testabilité
Objectif :  Obtenir un accord attestant que l'équipe de développement continuera à prendre en charge et à assurer la maintenance des fonctionnalités de testabilité. 

Il est important de s'assurer que les besoins en testabilité sont considérés de la même façon que toute autre exigence ou contrainte imposée à l'effort de développement. Vous devez être certain que les fonctionnalités de testabilité disponibles aujourd'hui ne seront pas abandonnées demain.

Dans certains cas, lorsqu'on tente d'obtenir cet engagement, on peut se heurter à un refus de l'équipe de développement de créer ou de prendre en charge les fonctions de testabilité. Cela peut être décourageant, mais il vaut mieux être conscient de cette situation et faire face à cette réalité le plus tôt possible ; il serait bien pire de gaspiller votre temps et vos efforts à développer une implémentation de test que l'équipe de développement cessera ensuite de prendre en charge, faute d'implication.

Préconiser la résolution des problèmes de testabilité
Objectif :  Contrôler et favoriser la résolution de problèmes de testabilité. 

Même si l'équipe de développement accepte d'assurer la prise en charge nécessaire des besoins en testabilité pour l'effort de test, il est important de jouer un rôle actif dans la conception, l'implémentation et la bonne exécution de ce travail. Ne cessez pas de vous intéresser à la testabilité une fois que l'équipe de développement a accepté de traiter les besoins en testabilité ou a commencé à travailler sur une solution ; vous devez vous assurer qu'une solution appropriée est développée rapidement.

Soyez, ainsi que le reste de l'équipe de test, disponible pour répondre à toutes les questions de l'équipe de développement, et proposez d'évaluer les prototypes dès qu'ils seront construits. Donnez un retour constructif et montrez de l'enthousiasme pour les efforts fournis par l'équipe de développement pour aider à répondre à vos besoins. Suggérez que vos ressources principales participent ou animent des ateliers de conception pour les besoins en testabilité les plus complexes, mais veillez à ce que votre équipe ne soit pas trop autoritaire et qu'elle laisse aux développeurs une marge de manoeuvre suffisante pour le processus de conception.

Lorsque des problèmes se posent et que vous avez l'impression qu'on ne leur porte pas l'attention appropriée ou qu'ils ne sont pas traités avec assez de rapidité, faites part de votre inquiétude à l'architecte logiciel et au responsable de projet. Si nécessaire, demandez au responsable de projet de consigner le problème dans la liste des problèmes du projet.

Evaluer et vérifier vos résultats
Objectif :  Vérifier que la tâche a été correctement réalisée et que les produits en résultant sont acceptables. 

Maintenant que vous avez achevé le travail, il serait utile de vérifier que ce travail a suffisamment de valeur et que vous n'avez pas simplement consommé de grandes quantités de papier. Vous devez évaluer si votre travail est d'une qualité correcte et qu'il est assez complet pour être utile aux membres de l'équipe qui en feront un usage ultérieur comme donnée d'entrée pour leur propre travail. Si possible, utilisez les listes de contrôle fournies dans RUP pour vérifier que la qualité et l'exhaustivité sont "satisfaisantes".

Faites en sorte que les personnes qui effectuent les tâches en aval, et qui se basent sur votre travail comme donnée d'entrée, prennent part à la revue de votre travail intermédiaire. Effectuez cette revue pendant que vous avez encore du temps disponible pour prendre les mesures qui répondent à leurs préoccupations. Vous devez également évaluer votre travail par rapport aux produits d'entrée clés pour vous assurer que vous les avez précisément et suffisamment représentés. Il peut être utile que l'auteur du produit d'entrée revoie votre travail sur cette base.

Essayez de vous rappeler que le RUP est un processus de livraison itératif et que dans de nombreux cas, les produits évoluent au fil du temps. A ce titre, il n'est généralement pas nécessaire - et c'est même souvent contre-productif - de former complètement un produit qui ne sera que partiellement utilisé ou ne sera pas du tout utilisé dans l'immédiat. Ceci parce qu'il y a une grande probabilité pour que la situation qui entoure le produit change - et que les hypothèses émises lors de la création du produit s'avèrent incorrectes - avant même l'utilisation du produit, occasionnant ainsi une perte d'efforts et un remaniement coûteux. Evitez également le piège consistant à utiliser trop de cycles pour la présentation au détriment de la valeur du contenu. Dans les environnements de projet où la présentation a une importance et une valeur économique en tant que résultat d'un projet, vous pouvez envisager d'utiliser une ressource administrative pour réaliser les tâches de présentation.