Test ISTQB en ligne, niveau Fondation

1. Le débogage est l'activité de développement qui consiste à trouver, analyser et corriger les défauts.
2. Le débogage est l'activité de développement qui consiste à vérifier qu'un défaut a bien été corrigé, c'est-à-dire qu'il ne provoque plus de défaillances.
3. Le débogage est l'activité de test qui consiste à rechercher les défaillances et à les compiler dans un outil de test dédié.
4. Le débogage est l'activité de test qui consiste à trier les anomalies des faux positifs.

2 - Lors de la phase de conception des spécifications, quelle pratique est la plus adéquate ?

1. Le testeur n’est pas impliqué dans cette phase
2. Le testeur effectue une revue des spécifications afin de détecter au plus tôt les points à éclaircir ou à corriger
3. Le testeur rédige une partie des spécifications
4. Le testeur rédige l’intégralité des spécifications

3 - Un test automatisé est en erreur, pourtant l’application fonctionne correctement. Comment cela s’appelle-t-il ?

1. Un faux positif
2. Un test non-fonctionnel
3. Un faux négatif
4. Un test automatisé n’est en erreur que si l’application présente une anomalie. En revanche, l’anomalie décelée par le test automatisé n’est pas toujours celle qui était anticipée au moment de son implémentation.

1. Trouver certains défauts du logiciels sans exécuter celui-ci
2. Se prémunir contre les régressions des fonctionnalités entre deux versions du produit
3. Evaluer automatiquement l'utilisabilité d'une application
4. Mesurer automatiquement les performances d’une application

5 - Lors de l’exécution d’une campagne de test, les cas de test fournissent une ligne directrice qu'il faut suivre à la lettre.

1. Vrai. Les cas de test ont été créé de manière à assurer la meilleure couverture des tests possible, il est essentiel de les suivre attentivement.
2. Faux. S'éloigner des cas de tests permet de couvrir des cas non prévus et ainsi d'améliorer la couverture des tests.
3. Vrai. Les cas de test couvrent les fonctionnalités indiquées dans la spécification ; il n'est pas nécessaire de rechercher des anomalies en-dehors de ce périmètre.
4. Faux. Les cas de test sont utilisés non pas lors des campagnes de test, mais lors des tests de confirmation.

1. Risque = Impacts en cas d’occurrence / Bénéfices en cas de non-occurrence
2. Risque = Somme de la gravité des impacts possibles
3. Risque = Probabilité d’occurrence x Impact en cas d’occurrence
4. Il n’est pas recommandé de calculer les risques, car le résultat du calcul est susceptible de créer des biais et d’induire l’équipe de test en erreur.

1. Un comportement similaire pouvant être observés au sein de deux versions différentes d’un même applicatif.
2. Une plage de données qui, lorsqu’elles sont utilisées dans un même test, doivent générer le même comportement.
3. La somme de tous les comportements possibles permettant d’effectuer une même action au sein d’un applicatif donné.
4. Un recueil de règles de nommages applicable au développement d’un applicatif donné.

8 - Une borne d’achat de tickets de bus interdit le paiement en espèce, sauf si l’utilisateur lui présente une carte d’abonné activée et non périmée. Quel outil est tout indiqué pour analyser les différents comportements possibles de l’application ?

1. Un outil de test management
2. Un graphe d’appel
3. Un diagramme d’états et de transitions
4. Une table de décisions

9 - Un test unitaire exécute la fonction suivante avec l’argument $soldes = true.

10 - L’indépendance de l’équipe de test vis-à-vis de l’équipe de développement favorise l’impartialité des tests. Mais elle présente aussi des risques. Lequel n’en fait pas directement partie ?

1. Risque de voir les développeurs perdre le sens de leur responsabilité vis-à-vis de la qualité
2. Risque pour l’équipe de test de ne pas être au courant de certains changements
3. Risque pour l’équipe de test de manquer de légitimité auprès du client
4. Risque de créer un goulet d’étranglement au niveau de l’équipe de test

11 - Tout projet de test est soumis à deux grandes familles de risques. Lesquels ?

1. Les risques techniques et les risques fonctionnels
2. Les risques quantitatifs et les risques qualitatifs
3. Les risques contextuels et les risques permanents
4. Les risques projet et les risques produit

12 - Parmi les activités suivantes, lesquelles peuvent être réalisées de manière informelle ?

1. Une exigence laissée de côté suite à un arbitrage de l’équipe de test
2. Une exigence contredite par d’autres exigences
3. Une exigence ne se rapportant pas aux fonctionnalités
4. Une exigence qui n’impacte pas l’expérience utilisateur

14 - L’équipe de développement vient de finaliser le développement d’un site contenant beaucoup d’animations (carrousel d’images, popups…) Le client souhaite s’assurer que ce grand nombre d’animation ne ralentit pas trop le chargement du site. Quel type de test est tout indiqué dans ce cas-là ?

1. le taux de conformité aux standards en vigueur de la réalisation spécifique d'un composant, système ou processus
2. la mesure relative à la satisfaction exprimée par les clients ou utilisateurs à l'issue de la conception d'un composant, système ou processus
3. le ratio entre la part des composants, systèmes ou processus exempt d'anomalies et la totalités de ces objets
4. le degré par lequel un composant, système ou processus atteint des exigences spécifiées et/ou des besoins ou attentes des clients ou utilisateurs

1. Un développeur introduit une anomalie dans son code. Cette anomalie est susceptible de générer une erreur du système.
2. Un développeur introduit un défaut dans son code. Ce défaut est susceptible de générer une anomalie du système.
3. Un développeur introduit un bug dans son code. Ce bug est susceptible de générer une défaillance du système.
4. Un développeur introduit une erreur dans son code. Cette erreur est susceptible de générer un bug du système.

17 - Les rapports d'incidents peuvent avoir plusieurs objectifs. Lequel n'en fait pas partie ?

1. Fournir aux développeurs et aux autres parties un retour sur le problème concerné pour en permettre l'identification, la localisation et la correction nécessaires
2. Fournir aux responsables du test le moyen de suivre la qualité d'un système sous test et l'avancement du test
3. Fournir aux chefs de projet des métriques de performance relatives à chaque développeur
4. Fournir des idées pour l'amélioration du processus de test

18 - Dans quel ordre se déroulent en principe les différents niveaux de tests ?

1. Tests de composants, tests d'intégration, tests système, tests d'acceptation
2. Tests de composants, tests système, tests d'acceptation, tests d'intégration
3. Tests de composants, tests d'acceptation, tests système, tests d'intégration
4. Tests de composants, tests d'acceptation, tests d'intégration, tests système

1. Non. L'agilité s'oppose au test manuel mais met l'accent sur les tests automatisés.
2. Non. L'agilité favorise une exécution fréquente des tests afin d'éviter les régressions d'une itération à l'autre.
3. Non. Une démarche agile se doit de rechercher constamment à améliorer les processus de développement, donc de tester différentes solutions.
4. Non. C'est l'inverse : ce sont les standards du test qui s'opposent à l'agilité, qui délaisse la qualité au profit de la rapidité.

1. Dès que le code est suffisamment stable. Le risque, en commençant les tests trop tôt, est de confondre ce qui est en cours et ce qui contient réellement des défauts.
2. Dès qu'il existe un brouillon de spécification. Des bugs peuvent déjà exister dans la documentation.
3. Dès le début du développement. C'est ce qu'on appelle le TDD (test driven development).
4. Dès qu'une version alpha du projet est disponible. Il ne faut pas attendre la version bêta, car elle est directement déployée chez le client.

Test ISTQB Foundation en ligne