I. Les responsabilités du directeur des tests?
❖ Développer ou examiner une politique et une stratégie de tests pour
l'organisation.
❖ Planifier les activités de test en tenant compte du contexte, en comprenant les
objectifs et les risques.
❖ Coordonner les plans de test avec les chefs de projet, les propriétaires de
produits et d'autres acteurs.
❖ Partager les perspectives de test avec d'autres activités du projet, telles que
la planification de l'intégration.
❖ Initier l'analyse, la conception, la mise en œuvre et l'exécution des tests,
surveiller l'avancement des tests et les résultats, et vérifier le statut des
critères de sortie.
❖ Préparer et présenter des rapports d'avancement des tests et des rapports de
synthèse des tests basés sur les informations recueillies.
❖ Soutenir la mise en place du système de gestion des anomalies et la
configuration adéquate de la gestion des éléments de test.
❖ Introduire des indicateurs appropriés pour mesurer l'avancement des tests et
évaluer la qualité des tests et du produit.
❖ Soutenir la sélection et la mise en œuvre d'outils pour soutenir le processus
de test.
❖ Décider de la mise en place de l'environnement de test.
❖ Développer les compétences et les carrières des testeurs (par le biais de
plans de formation, d'évaluations de performance, de coaching, etc.).
II. Quelle est votre approche si vous constatez que les testeurs de votre
organisation effectuent un test sur le produit produit, même après
que des défauts significatifs ont été identifiés?
Je rédige un rapport de défaut typique qui comprend :
➔ Un identifiant unique.
➔ Un titre et un bref résumé du défaut signalé (date du rapport de défaut, organisation
émettrice et auteur).
➔ Identification de l'élément de test (élément de configuration testé) et de
l'environnement.
➔ Les phases du cycle de vie du développement au cours desquelles le défaut a été
observé.
➔ Une description du défaut permettant sa reproduction et sa résolution, y compris des
journaux, des extractions de base de données, des captures d'écran ou des
enregistrements (trouvés lors de l'exécution des tests).
➔ Les résultats attendus et réels.
➔ La portée ou le degré d'impact (gravité) du défaut sur les intérêts des parties
prenantes.
➔ Urgence/priorité de la correction.
➔ État du rapport de défaut (ouvert, reporté, doublon, en attente de correction, en attente
de tests de confirmation, ré-ouvert, clos).
➔ Conclusion, recommandations et approbations.
➔ Problèmes globaux, tels que d'autres domaines pouvant être affectés par un
changement résultant du défaut.
➔ Historique des changements, tels que la séquence des actions prises par les membres
de l'équipe du projet concernant le défaut pour l'isoler, le réparer et le confirmer
comme résolu.
➔ Références, y compris le cas de test qui a révélé le problème.
Si vous découvriez que votre équipe effectuait un test sur le livrable
après l'identification d'un défaut important, votre première action serait
d'arrêter le test immédiatement. Sinon, cela pourrait entraîner un travail
inutile et de peu de valeur, car de nouveaux tests doivent être effectués
après la correction du défaut. Vous devriez ensuite évaluer la situation
pour déterminer la meilleure marche à suivre. Probablement, vous
devriez coopérer avec les développeurs pour vous assurer qu'ils
corrigent le défaut avant que votre équipe puisse poursuivre le
processus de test. Vous devriez également communiquer avec le chef
de projet et les autres parties prenantes pour les tenir informés de la
situation.
III. Comment choisiriez-vous un outil de test pour votre projet?
Lors de la phase Planification des tests, ses objectifs et ses activités permettront de choisir
l’outil de test adéquat :
➔ Détermination de la portée et des risques, et identification des objectifs des tests.
➔ Définition de l'approche globale des tests.
➔ Intégration et coordination des activités de test dans le cycle de vie du logiciel.
➔ Prise de décisions sur ce qu'il convient de tester.
➔ Planification des activités de test, affectation des ressources aux activités.
➔ Affectation des ressources pour les différentes activités définies.
➔ Sélection de métriques pour la surveillance et le contrôle.
➔ Définition des critères d'entrée et de sortie.
IV. Quels sont les principaux défis d'un projet de test?
Les principaux défis consistent en la gestion des risques du projet. les risques peuvent être
des risques liés au projet, et des risques liés au produit.
1) Les risques liés au projet:
a) Problèmes de projet :
Les retards, la satisfaction des critères de sortie, des estimations inexactes, une réaffectation
des fonds à des projets de plus haute priorité, un financement insuffisant…
Des changements tardifs peuvent entraîner une refonte substantielle.
b) Problèmes organisationnels :
Les compétences et la formation du personnel , les conflits générés par le personnel, la
disponibilité des utilisateurs ou des experts, les priorités commerciales conflictuelles.
c) Problèmes politiques :
communication de résultats de test, les problèmes de communication entre testeurs et
développeurs, attitude inappropriée et attentes irréalistes.
d) Problèmes techniques :
mal définition des exigences, exigences non satisfaites, indisponibilité de l'environnement de
test, la conversion de données, le retard de la planification de la migration , mauvaise gestion
des défauts et leur accumulation…
e) Problèmes liés aux fournisseurs :
Les problèmes contractuels.
2) Les risques liés au produit:
Les risques liés au produit impliquent la possibilité qu'un produit de travail ne
parvienne pas à satisfaire les besoins de ses utilisateurs et/ou parties prenantes.
Lorsque les risques liés au produit sont associés à des caractéristiques spécifiques de la
qualité d'un produit (par exemple, la pertinence fonctionnelle, la fiabilité, l'efficacité des
performances, la convivialité, la sécurité, la compatibilité, la maintenabilité et la portabilité),
on les appelle aussi des risques liés à la qualité.
Voici des exemples de risques liés au produit :
● Le logiciel pourrait ne pas exécuter ses fonctions prévues conformément à la
spécification.
● Le logiciel pourrait ne pas exécuter ses fonctions conformément aux besoins des
utilisateurs, des clients et/ou des parties prenantes.
● L'architecture d'un système peut ne pas prendre en charge de manière adéquate
certaines exigences non fonctionnelles.
● Un calcul particulier peut être effectué de manière incorrecte dans certaines
circonstances.
● Mauvaise intégrité et qualité des données.
● Les temps de réponse peuvent être inadéquats pour un système de traitement de
transactions à haute performance.
