Certified Tester Foundation Level - ISTQB Foundation Sample Quiz 3

n/a

n/a

Le "fallacie de l'absence de défauts" concerne l'idée que garantir la conformité aux exigences (c'est-à-dire, vérifier l'absence de défauts d'implémentation) ne garantit pas la satisfaction de l'utilisateur avec le système. Pour résoudre ce problème, il est également nécessaire de valider que le système répond aux besoins et aux attentes des utilisateurs, remplit les objectifs commerciaux et surpasse les systèmes concurrents.

Étant donné la description suivante de l'analyse de test :
Pour identifier les fonctionnalités qui nécessitent des tests, la base de test est analysée et définie comme des conditions de test, qui sont ensuite priorisées avec les risques associés. L'identification systématique des conditions de test en tant qu'éléments de couverture implique souvent l'utilisation de techniques de test à la fois pendant l'analyse de test et dans le cadre de l'activité de conception de test.
De la description ci-dessus, il peut être vu que les techniques de test sont souvent utilisées dans les activités d'analyse de test et de conception de test. L'analyse de valeur limite et le partitionnement d'équivalence sont des techniques de test.

En considérant chacune des activités de test listées et leur output de testware :
A. Analyse de test - conditions de test priorisées (4) (par exemple, critères d'acceptation), et rapports de défauts pour les défauts identifiés dans la base de test
B. Conception de test - cas de test priorisés, chartes de test, éléments de couverture (1), exigences de données de test, et exigences d'environnement de test
C. Mise en œuvre du test - procédures de test, scripts de test automatisés, suites de test, données de test, planning d'exécution de test (3), et éléments d'environnement de test tels que les stubs, les pilotes, les simulateurs, et les virtualisations de service
D. Achèvement du test - rapport d'achèvement du test, leçons apprises documentées, points d'action pour l'amélioration, et demandes de changement (2) (comme éléments de backlog de produit)

n/a

n/a

n/a

n/a

Lequel des suivants est un exemple d'une approche de développement basée sur les tests en premier ?

n/a

n/a

n/a

n/a

En considérant chacun des défauts d'exemple listés :
i. Deux parties différentes de la spécification de conception sont en désaccord en raison de la complexité de la conception - c'est un exemple de défaut de spécification, qui comprend des incohérences, des ambiguïtés, des contradictions, des omissions, des inexactitudes et des duplications, qui peuvent être le plus facilement trouvées par des tests statiques
ii. Un temps de réponse est trop long et fait donc perdre patience aux utilisateurs - c'est un exemple de défaut de temps de réponse, qui ne peut être détecté en pratique qu'en exécutant le programme et en mesurant le temps de réponse, qui peut être le plus facilement trouvé par des tests dynamiques
iii. Un chemin dans le code ne peut pas être atteint pendant l'exécution - c'est un exemple de défaut de codage, qui comprend des variables avec des valeurs non définies, des variables non déclarées, du code dupliqué ou inaccessible, et une complexité de code excessive, qui peut être le plus facilement trouvé par des tests statiques
iv. Une variable est déclarée mais jamais utilisée par la suite dans le programme - c'est un exemple de défaut de codage, qui comprend des variables avec des valeurs non définies, des variables non déclarées, du code dupliqué ou inaccessible, et une complexité de code excessive, qui peut être le plus facilement trouvé par des tests statiques
v. La quantité de mémoire nécessaire au programme pour générer un rapport est trop élevée - c'est un exemple de défaut de performance, qui ne peut être détecté en pratique qu'en exécutant le programme et en mesurant la mémoire utilisée, qui peut être le plus facilement trouvé par des tests dynamiques.

n/a

En considérant chacun des types de revue listés :
1. Revue technique - Ce type de revue est effectué par des examinateurs techniquement qualifiés et dirigé par un modérateur. Les objectifs sont d'obtenir un consensus et de prendre des décisions sur des problèmes techniques tout en évaluant la qualité et en renforçant la confiance dans le produit de travail, en générant de nouvelles idées, en motivant et en permettant aux auteurs de s'améliorer, et en détectant des anomalies.
2. Revue informelle - L'objectif principal est de détecter des anomalies. Le processus n'est pas défini et ne nécessite pas de sortie documentée formelle.
3. Inspection - Il s'agit du type de revue le plus formel, et il suit le processus de revue générique complet. L'objectif principal est de trouver le plus d'anomalies, et d'autres objectifs incluent l'évaluation de la qualité et le renforcement de la confiance dans le produit de travail, la motivation et la capacité des auteurs à s'améliorer, et la collecte de mesures qui peuvent être utilisées pour améliorer le cycle de vie du développement logiciel (SDLC), y compris le processus d'inspection. L'auteur ne peut pas agir en tant que leader de la revue ou scribe.
4. Walkthrough - Dirigé par l'auteur, ce type de revue sert divers objectifs tels que l'évaluation de la qualité et le renforcement de la confiance dans le produit de travail, l'éducation des examinateurs, l'obtention d'un consensus, la génération de nouvelles idées, la motivation et la capacité des auteurs à s'améliorer, et la détection d'anomalies. Les examinateurs peuvent effectuer une revue individuelle avant le walkthrough, mais ce n'est pas obligatoire.

A. Inclut des objectifs tels que l'obtention d'un consensus, la génération de nouvelles idées et la motivation des auteurs à s'améliorer (A)
B. L'objectif principal est de détecter les défauts potentiels et il ne génère aucune sortie documentée formelle (D)
C. L'objectif principal est de détecter les défauts potentiels et il nécessite la collecte de mesures pour soutenir l'amélioration du processus (C)
D. Inclut des objectifs tels que l'éducation des examinateurs, l'obtention d'un consensus, la génération de nouvelles idées et la détection de défauts potentiels (B)

n/a

n/a

The equivalence partitions are: {…, 99, 100}, {101, 102, …, 198, 199}, {200, 201, …}.
Thus, there are 4 boundary values, which are: 100, 101, 199 and 200.

In 2-value BVA, for each boundary value there are two coverage items (the boundary value and its closest neighbor belonging to the adjacent partition). As the closest neighbors are also boundary values in the adjacent partition, then there are just four coverage items.

The following three transitions:

“REQUESTING -> CONFIRMED”
“WAITING LIST -> CONFIRMED”
“WAITING LIST -> END”

cannot appear in the same test case, which suggests that at least three test cases are required. All the other transitions can appear in combination with one or more of these three transitions, so we need a minimum of three test cases. In fact, only three sequences are possible:
TC1: START (Room request)  REQUESTING (Available)  CONFIRMED (Pay) => END
TC2: START (Room request)  REQUESTING (Not available)  WAITING LIST (Available) => CONFIRMED (Pay)  END
TC3: START (Room request)  REQUESTING (Not available)  WAITING LIST (Cancel) => END

In branch testing the coverage items are branches, which are represented by the edges of a control flow graph. There are 8 edges in the control flow graph.

How many coverage items do you need to test?

From the graph we have:
A(4)=6 and A(3)=8 (the last two gray boxes).
From the formula we obtain:
E(5) = (3*A(4) + A(3)) / 4 = (3*6+8) / 4 = 26 / 4 = 6.5 person-days

We want to run test cases according to their priorities, but we also need to consider the dependencies.
If we only consider priorities, we want to first run TC 5 and TC 7 (highest priority), then TC 1, TC 3, and TC 4, and finally TC 2 and TC 6 (lowest priority).
However, in order to run TC 7, we need to first run TC 4.
In order to run TC 5, we need to run TC 4 and TC 2, but TC 2 is blocked by TC 1, which should be run prior to TC 2.
So, in order to run priority 1 test cases as early as possible, the first five test cases should be: TC 4 - TC 7 - TC 1 - TC 2 - TC 5.
Next, we need to run TC 3, because it has higher priority than TC 6.
Thus the full schedule will be TC 4 – TC 7 – TC 1 – TC 2 – TC 5 – TC 3 – TC 6.
So, the sixth test case will be TC 3.