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.
|
|