Observation des récapitulatifs d'évaluation des tests les plus courants
Objet :
|
Comprendre l'évaluation actuelle récapitulative des problèmes de qualité produit que les membres de
l'équipe de test ont identifié.
|
Commencez par examiner les récapitulatifs d'évaluation des tests préparés par l'équipe de test. Comparez les
informations d'évaluation au plan de test de l'itération, pour comprendre le récapitulatif dans le contexte du travail
prévu. Soulevez toute ambiguïté et préoccupation auprès de l'équipe de test qui a élaboré le récapitulatif et résolvez
ces problèmes.
Pour cette étape et les suivantes qui réunissent des informations et évaluent la qualité du logiciel, tentez d'obtenir
une vue équilibrée intégrant des mesures objectives et subjectives. Souvenez-vous que les mesures objectives ne
décrivent qu'une partie de la situation et qu'elles doivent être expliquées par le climat actuel du projet. A
l'inverse, ne vous fiez pas strictement aux rumeurs et aux spéculations subjectives au sujet de la qualité des
logiciels : recherchez plutôt des preuves objectives. Nous vous recommandons de compléter vos données objectives par
des discussions avec les responsables d'équipes ou éventuellement avec les membres de l'équipe, afin de collecter des
évaluations subjectives. Ainsi, vous pourrez jauger le niveau de confiance à avoir par rapport aux données objectives.
|
Pour connaître le contexte, examinez les résultats des tests sélectionnés
Objet :
|
Mieux comprendre les résultats de tests qui accompagnent les synthèses de qualité des produits.
|
Pour obtenir plus de contexte, observez les résultats des tests basés sur les récapitulatifs d'évaluation des tests.
Examinez les résultats en profondeur pour confirmer que vous comprenez bien les questions clés qui ont été identifiées
dans les récapitulatifs d'évaluation des tests.
Revoyez également les données et repérez les tendances évidentes importantes qui peuvent avoir été oubliées dans les
résultats des tests. Il est en général plus important d'identifier ce qu'indiquent les tendances relatives des données
plutôt que d'observer les nombres absolus. Soyez attentifs aux indications telles que les échecs dans une zone liés à
des échecs dans d'autres zones.
|
Examinez les principales demandes de changements
Objet :
|
Se familiariser avec le contexte et être ainsi capable de discuter efficacement des questions les plus
exceptionnelles et de leurs solutions éventuelles.
|
Nous vous recommandons de limiter cet exercice aux questions les plus urgentes et aux demandes de changements qui leur
sont liées. Vous pourrez consacrer davantage d'énergie à un plus petit nombre de questions, qui sont le plus souvent
susceptibles d'avoir une incidence sur la qualité des produits. Si vous disposez d'une liste de questions clés plus
longue, nous vous recommandons d'y consacrer l'énergie qui convient par rapport au caractère prioritaire très relatif
de ces questions : ne gaspillez pas vos ressources en vous investissant à fond dans des questions secondaires.
Néanmoins, notez qu'un nombre significatif de demandes de changements de très basse priorité peut rendre une
instruction aussi significative en termes de qualité des produits, qu'une poignée de changements de priorité élevée.
Essayez de réunir les demandes de changements de basse priorité dans les caractéristiques logiques de la qualité,
fondées sur les risques qui lui sont liés. Cela vous aidera à structurer et à mettre plus clairement en valeur leurs
effets combinés sur la qualité.
Identifiez les tendances évidentes associées aux demandes de changements générales. Il est en général plus important
d'identifier ce qu'indiquent les tendances relatives des données plutôt que d'observer les nombres absolus. Observez
les signes positifs tels qu'un débit stable et continu en termes de résolution d'incidents, ou encore un débit de
résolution évoluant graduellement puis régressant dans le temps. Surveillez les pics et creux en termes de débit de
résolution indiquant que l'équipe de développement est susceptible de rencontrer des problèmes sur le plan des
processus, de l'environnement, sur le plan politique ou tout autre problème réduisant leur productivité.
Remarque : vous serez peut-être tenté d'améliorer la clarté des demandes de changements, en éliminant les aspects
ambigus et délicats liés au langage et au raisonnement. Si vous apportez ces changements vous-mêmes, discutez-en avec
les personnes qui ont créé ces produits afin qu'ils puissent comprendre l'importance de ces améliorations.
|
Identifiez les écarts de qualité et estimez leur incidence et les risques qui leur sont liés
Objet :
|
Formuler votre compréhension des questions clés, sur le plan des risques clés susceptibles d'affecter la
qualité du produit et la réussite du projet de développement logiciel.
|
Identifiez chaque écart de qualité et évaluez l'incidence et le risque associés à chaque point ayant généré l'écart.
Envisagez des stratégies de limitation et de secours, formulez vos idées initiales et discutez-en avec les autres
membres de l'équipe.
Tenez compte du fait que la qualité "parfaite" est un concept illusoire. Veillez à utiliser une référence réaliste et
atteignable lorsque vous évaluez la qualité et identifiez les écarts de qualité. Voir Technique: Qualité produit
|
Identifiez les actions essentielles qui permettent de traiter les écarts de qualité
Objet :
|
Produire une liste minimum et réaliste des actions imposées pour négocier une résolution satisfaisante des
questions clés.
|
Envisagez pour chaque écart majeur de qualité, des stratégies de limitation et de secours. Formulez vos idées initiales
et discutez-en de manière informelle avec les autres membres de l'équipe. Cela vous éclairera sur vos raisonnements et
vous permettra de les valider. Concernant les solutions, il est bon d'avoir des options : elles vous permettent de
sonder les compromis et de choisir la meilleure solution pour un contexte donné.
Elaborez des solutions et des suggestions potentiellement utiles qui aideront l'équipe du projet à traiter chaque écart
de qualité de la manière la mieux adaptée. Cette étape est essentielle car elle permettra à l'effort de test de
contribuer efficacement à la résolution des problèmes, et de ne pas se limiter à rendre compte des problèmes. Cela
représente un aspect important dans la reconnaissance de la valeur de l'équipe de test ; ainsi, vous bénéficierez du
respect et de la collaboration des autres membres de l'équipe.
|
Identifiez et associez-vous avec des personnes compétentes concernant les questions majeures
Objet :
|
Optimiser la résolution des questions clés de manière informelle et identifier les propositions
susceptibles d'être acceptées.
|
Soutenir une cause perdue n'est pas agréable. Une approche plus efficace consiste à identifier les solutions aux
problèmes les plus susceptibles d'être soutenues, acceptées et concrétisées par l'équipe du projet. Gardez une relation
étroite avec les principaux décideurs et commencez par exposer clairement les questions clés de manière informelle dans
des discussions individuelles. Cette démarche permet souvent d'obtenir un soutien et de trouver des solutions
réalistes.
Il arrive que l'on n'ait pas le choix et que l'on soit contraint de défendre une solution qui est mal vue par l'équipe
de développement. Lorsque c'est probable, il est encore plus important d'identifier les personnes censées vous apporter
leur soutien et de savoir comment vendre la solution, en présentant clairement sa valeur et en exposant précisément les
conséquences liées à l'absence de résolution du problème.
|
Négocier les tâches prioritaires
Objet :
|
Défendre une solution adaptée qui sera développée dans un délai acceptable, sans aucune incidence
défavorable sur la qualité exigée.
|
Le point crucial dans le choix de la qualité est la capacité à négocier une solution adaptée, qui apaise l'équipe de
développement sans réduire la qualité du produit de manière considérable. Rappelez-vous que l'équipe de tests joue très
souvent le rôle de conseiller qualité ; prenez donc garder à ne pas exiger qu'une résolution donnée soit exécutée.
Cependant, il est essentiel que l'équipe de test accomplisse un bon travail d'appui de la qualité ; il faut parfois
apporter des nouvelles dont l'équipe du projet ne souhaite absolument pas prendre connaissance. C'est pourquoi les
bonnes équipes de test apportent à l'effort de développement autant d'éclaircissements que possible sur le problème
rencontré, sur ses solutions possibles et sur la compréhension des différents choix. Vous devez agir dans une certaine
mesure comme un agent vis-à-vis des clients potentiels du produit et contribuer à négocier des solutions qui leur
seront profitables.
|
Surveillez la progression du travail
Objet :
|
Soutenir et rester impliqué au sujet de l'évolution de la résolution du problème.
|
Il arrive que certains incidents et autres demandes de modification se perdent dans les méandres du développement du
produit et de l'accroissement des fonctionnalités. En effet, il est plus intéressant pour les développeurs de
travailler sur des questions nouvelles que de résoudre d'anciennes questions ; par ailleurs, il est plus facile de
placer de la valeur dans l'ajout d'un élément nouveau que dans la résolution d'un incident. En tant que partisans de la
qualité, l'équipe de test doit contribuer à la résolution des anomalies majeures du projet, durant sa réalisation.
Les bonnes équipes logicielles trouvent un bon équilibre entre l'amélioration progressive de la qualité obtenue par la
résolution des incidents et l'augmentation graduelle des fonctions. L'équipe de test peut aider l'équipe de projet en
encourageant l'amélioration de la qualité plutôt qu'en endossant le rôle (moins utile et plus controversé) de gendarme
qualité.
|
Confirmez la résolution appropriée des questions clés
Objet :
|
Confirmer que la résolution des points clés règle le problème de manière efficace, sans entraîner d'effet
secondaire négatif.
|
Quelle que soit la solution adoptée par l'équipe de développement pour résoudre un incident lié à la qualité, cette
résolution doit apporter des améliorations en termes de qualité. Prenez le temps nécessaire pour évaluer ces
améliorations. Assurez-vous aussi que la résolution apporte bien une solution au problème d'origine et n'entraîne pas
de conséquence négative.
Concernant les solutions comportant des risques notables, il pourrait s'avérer utile de réaliser des tests sur les
premières versions du produit, avant que trop de temps et d'efforts ne soient consacrés au suivi de la phase de
résolution jusqu'à sa conclusion.
|
Evaluez et vérifiez vos résultats
Objet :
|
Vérifier que la tâche a été correctement réalisée et que les produits qui en résultent sont
acceptables.
|
Maintenant que vous avez achevé le travail, il serait utile de vérifier qu'il 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 bien achevé pour les membres de l'équipe qui en feront un usage ultérieur comme entrée pour leur
propre travail. A chaque fois que cela est possible, utilisez les listes de contrôle fournies dans RUP pour vérifier
que la qualité et l'achèvement sont suffisamment bons.
Faites en sorte que les personnes qui effectuent des tâches en aval et qui se basent sur votre travail comme 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 artefacts 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 itératif de livraison et que, dans la plupart des cas, les
produits évoluent avec le temps. A ce titre, il n'est pas habituellement 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. Cela vient du fait 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 un nouveau travail et une perte d'efforts. 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 comme livrable de projet, vous pouvez envisager d'utiliser
une ressource d'administration pour réaliser les tâches de présentation.
|
|