ISTQB Foundation : fiche pratique

Cette page présente un ensemble d'éléments importants, à connaître absolument pour postuler à la certification ISTQB niveau Foundation. Attention : cette liste de choses à connaître n'est pas exhaustive !

Documents importants pour la préparation

Types de tests

Tester (trouver des erreurs) est différent de déboguer (corriger les erreurs).

Par ?

  • test-statique : réalisés sans que le code soit exécuté (revue de code, de spécifications, de documents de design)
  • test-dynamique : exécution du code pour s'assurer du fonctionnement correct, sur un sous-ensemble fini de données possibles

Par niveau d'accessibilité

  • test-boite-noire
  • test-boite-grise
  • test-boite-blanche : tests réalisés en ayant accès aux détails de réalisation du logiciel (code notamment), synonyme de test structurel. Critère de couverture :
    • toutes-les-instructions : chaque instruction du programme est exercée au moins une fois.
    • tous-les-chemins : tous les jeux de valeurs sont testés (impraticable).
    • tous-les-i-chemins : variante de tous les chemins sur la manière de traiter les boucles (de 0 à i itérations).
    • toutes-les-branches-decisions : tous les résultats possibles de chaque condition doivent être exercés. Exemple : pour la condition (A or B), on s'arrangera pour avoir un résultat Vrai et un résultat Faux.
    • toutes-les-conditions : toutes les valeurs possibles de chaque condition doivent être exercées .Exemple : pour la condition (A or B), on choisira des cas de test avec A=Vrai, A=Faux, B=Vrai et B=Faux.
    • toutes-les-conditions-decisions : tous les résultats possibles et les valeurs possibles de chaque condition doivent être exercées .Exemple : pour la condition (A or B), on s'arrangera pour avoir un résultat Vrai et un résultat Faux, et on choisira des cas de test avec A=Vrai, A=Faux, B=Vrai et B=Faux.
    • toutes-les-conditions-multiples : impraticable
    • toutes-les-conditions-decisions-modifiees (MC/DC) : on ne fait varier une valeur de condition que si cette variation influe sur le résultat de la décision, indépendamment des autres conditions.

Par niveau d'application

  • test-unitaire
  • test-integration : test réalisé pour découvrir des défauts dans les interfaces et dans les interactions entre les composants intégrés.
    • test-big-bang : tous les éléments sont combinés en une seule fois en un système complet.
    • test-de-haut-en-bas : approche incrémentale, où on intègre d'abord les composants de plus haut niveau. On détecte bien les défaut structurels, mais il faut utiliser des bouchons pour simuler le comportement de composants de plus bas niveau pas encore développés.
    • test-de-bas-en-haut : approche incrémentale, où le niveau le plus bas des composants sont testés d'abord, et ensuite utilisés pour faciliter les tests des composants de plus haut niveau. Utilisation de pilotes.
  • test-systeme

Par objet de test

  • test-fonctionnel
  • test-non-fonctionnel : test d'attributs d'un composant ou système qui ne sont pas liés aux fonctionnalités (rendement, maintenabilité, fiabilité, utilisabilité…).
  • test-non-regression : après une modification, pour voir si aucun nouveau bug a été introduit ou dévoilé. Ne pas confondre avec les tests de confirmation ou retest, qui sont exécutés pour vérifier que les corrections ont bien réglé les problèmes.

Autres types de tests

  • test-exploratoire : un test exploratoire est un test où le testeur contrôle activement la conception des tests en même temps que ces tests sont exécutés, et utilise l'information obtenue pendant les tests pour concevoir de nouveaux tests.

Couverture de test

  • Estimation de la couverture en boite blanche : on se base que les résultats de décision, les conditions ou conditions multiples exercées et les instructions exécutées.
  • Condition de test : c'est quelque chose qui peut être testé par un ou plusieurs cas de test (par exemple une fonction, une transaction…).
  • partition-equivalence : portion d'un domaine pour laquelle le comportement d'un composant ou système est supposé être le même, basé sur ses spécifications.

table-de-decision : Une table de décision montre la combinaison des entrées/stimuli (causes) et leurs sorties/actions (effets) associées, qui peut être utilisé pour concevoir des cas de test. Les colonnes correspondent aux combinaisons de valeurs possibles, et les lignes au nombre de variables + le nombre d'actions possibles. Sans optimisation, il y a donc a*b*... où a, b, etc. sont les nombres de valeurs respectives que peuvent prendre chaque variable.

Gestion des risques

  • risque-produit : risque directement lié à l'objet du test
  • risque-projet : risque lié à la gestion et au contrôle du projet de test (manque d'encadrement, deadlines irréalistes…)

Déroulement des tests

  1. Planification et contrôle
  2. Analyse et conception
  3. Implémentation et exécution
  4. Évaluation des critères de sortie et information
  5. Activités de clôture des tests

Rapport d'incident

Il doit comporter un résumé, ainsi que les étapes pour reproduire l'erreur.

Outils support aux tests

Bénéfices

  • Répétitivité et cohérence accrues
  • Évaluation objective
  • Facilité d’accès aux informations au sujet des tests ou de leur exécution
  • Réduction du travail répétitif

Risques

  • Confiance excessive dans l’outil
  • Attentes irréalistes placées dans l’outil
  • Sous-estimation de l’effort requis pour maintenir les acquis générés par l’outil

Outils utilisés principalement par les développeurs

  • Outils d’analyse statique
  • Outils de modélisation
  • Outils d’analyse dynamique