Certified Tester Foundation Level - ISTQB Foundation Sample Quiz 3

n/a

n/a

La 'falacia de ausencia de defectos' se refiere a la idea de que garantizar la corrección de acuerdo con los requisitos (es decir, verificar la ausencia de defectos de implementación) no garantiza la satisfacción del usuario con el sistema. Para abordar esto, también es necesario validar que el sistema cumple con las necesidades y expectativas de los usuarios, cumple con los objetivos comerciales y supera a los sistemas competidores.

Dada la siguiente descripción del análisis de pruebas:
Para identificar las características que requieren pruebas, se analiza y define la base de la prueba como condiciones de prueba, que luego se priorizan junto con los riesgos relacionados. La identificación sistemática de las condiciones de prueba como elementos de cobertura a menudo implica el uso de técnicas de prueba tanto durante el análisis de prueba como parte de la actividad de diseño de prueba.
De la descripción anterior, se puede ver que las técnicas de prueba a menudo se utilizan en las actividades de análisis y diseño de pruebas. El análisis de valores límite y la partición de equivalencia son técnicas de prueba.

Considerando cada una de las actividades de prueba enumeradas y su software de prueba de salida:
A. Análisis de prueba - condiciones de prueba priorizadas (4) (por ejemplo, criterios de aceptación), e informes de defectos para defectos identificados en la base de la prueba
B. Diseño de prueba - casos de prueba priorizados, cartas de prueba, elementos de cobertura (1), requisitos de datos de prueba y requisitos de entorno de prueba
C. Implementación de la prueba - procedimientos de prueba, scripts de prueba automatizados, suites de prueba, datos de prueba, horario de ejecución de la prueba (3) y elementos del entorno de prueba como stubs, controladores, simuladores y virtualizaciones de servicio
D. Finalización de la prueba - informe de finalización de la prueba, lecciones aprendidas documentadas, elementos de acción para la mejora y solicitudes de cambio (2) (como elementos del backlog del producto)

n/a

n/a

n/a

n/a

¿Cuál de las siguientes es un ejemplo de un enfoque de desarrollo basado en pruebas primero?

n/a

n/a

n/a

n/a

Considerando cada uno de los defectos de ejemplo enumerados:
i. Dos partes diferentes de la especificación de diseño no concuerdan debido a la complejidad del diseño: este es un ejemplo de un defecto de especificación, que incluye inconsistencias, ambigüedades, contradicciones, omisiones, inexactitudes y duplicaciones, que se pueden encontrar más fácilmente mediante pruebas estáticas.
ii. El tiempo de respuesta es demasiado largo y hace que los usuarios pierdan la paciencia: este es un ejemplo de un defecto de tiempo de respuesta, que solo se puede detectar en la práctica ejecutando el programa y midiendo el tiempo de respuesta, que se puede encontrar más fácilmente mediante pruebas dinámicas.
iii. Un camino en el código no se puede alcanzar durante la ejecución: este es un ejemplo de un defecto de codificación, que incluye variables con valores indefinidos, variables no declaradas, código duplicado o inalcanzable, y excesiva complejidad del código, que se puede encontrar más fácilmente mediante pruebas estáticas.
iv. Se declara una variable pero nunca se usa posteriormente en el programa: este es un ejemplo de un defecto de codificación, que incluye variables con valores indefinidos, variables no declaradas, código duplicado o inalcanzable, y excesiva complejidad del código, que se puede encontrar más fácilmente mediante pruebas estáticas.
v. La cantidad de memoria necesaria para que el programa genere un informe es demasiado alta: este es un ejemplo de un defecto de rendimiento, que solo se puede detectar en la práctica ejecutando el programa y midiendo la memoria utilizada, que se puede encontrar más fácilmente mediante pruebas dinámicas.

n/a

Considerando cada uno de los tipos de revisión enumerados:
1. Revisión técnica - Este tipo de revisión es realizada por revisores técnicamente calificados y dirigida por un moderador. Los objetivos son alcanzar consenso y tomar decisiones sobre problemas técnicos, al mismo tiempo que se evalúa la calidad y se genera confianza en el producto de trabajo, se generan nuevas ideas, se motiva y se permite a los autores mejorar, y se detectan anomalías.
2. Revisión informal - El objetivo principal es detectar anomalías. El proceso no está definido y no requiere una salida documentada formal.
3. Inspección - Este es el tipo de revisión más formal, y sigue el proceso de revisión genérico completo. El objetivo principal es encontrar la mayoría de las anomalías, y otros objetivos incluyen evaluar la calidad y generar confianza en el producto de trabajo, motivar y permitir a los autores mejorar, y recopilar métricas que se pueden utilizar para mejorar el ciclo de vida del desarrollo de software (SDLC), incluido el proceso de inspección. El autor no puede actuar como líder de la revisión o escriba.
4. Walkthrough - Dirigido por el autor, este tipo de revisión sirve a varios objetivos como evaluar la calidad y generar confianza en el producto de trabajo, educar a los revisores, alcanzar consenso, generar nuevas ideas, motivar y permitir a los autores mejorar, y detectar anomalías. Los revisores podrían realizar una revisión individual antes del walkthrough, pero esto no es obligatorio.

A. Incluye objetivos como alcanzar consenso, generar nuevas ideas y motivar a los autores a mejorar (A)
B. El objetivo principal es detectar posibles defectos y no genera una salida documentada formal (D)
C. El objetivo principal es detectar posibles defectos y requiere la recopilación de métricas para apoyar la mejora del proceso (C)
D. Incluye objetivos como educar a los revisores, alcanzar consenso, generar nuevas ideas y detectar posibles defectos (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.