ISTQB Foundation (CTFL v4.0) Examen de práctica #11 — Preguntas y respuestas
Todas las preguntas de este examen de práctica, con la respuesta correcta marcada y una justificación escrita para cada opción a continuación — para leer y repasar, no una prueba cronometrada.
En un sistema grande, el responsable de pruebas observa que cerca del 80% de los fallos provienen de 3 de los 20 módulos y concentra más pruebas ahí. ¿Qué principio de prueba aplica?
Agrupación de defectos
Unos pocos módulos suelen contener la mayoría de los defectos.
Paradoja del pesticida
Trata de pruebas repetidas que pierden eficacia, no de dónde se agrupan.
Las pruebas exhaustivas son imposibles
Cierto, pero no se relaciona con enfocarse en módulos con más defectos.
Las pruebas dependen del contexto
Un principio distinto sobre adaptarse al contexto.
Los defectos tienden a agruparse en pocos módulos; concentrar el esfuerzo ahí es la agrupación de defectos.
¿Qué afirmación distingue mejor las pruebas del aseguramiento de la calidad (QA)?
Las pruebas evalúan el producto para hallar defectos; el QA mejora procesos para prevenirlos.
Distinción estándar producto vs. proceso.
Las pruebas y el QA son exactamente lo mismo.
Están relacionados pero son distintos.
El QA se realiza solo después del lanzamiento.
El QA es continuo y orientado al proceso.
Las pruebas mejoran procesos, el QA halla defectos.
Invertido: las pruebas hallan defectos, el QA mejora procesos.
Las pruebas son orientadas al producto; el QA es orientado al proceso.
¿Cuáles DOS de los siguientes están entre los siete principios de prueba?
Las pruebas muestran la presencia de defectos, no su ausencia
Uno de los siete principios.
Paradoja del pesticida
Repetir las mismas pruebas deja de encontrar defectos nuevos.
Las pruebas garantizan un producto sin defectos
Ningún principio afirma esto; es imposible.
Las pruebas exhaustivas siempre son viables
Lo contrario es un principio: son imposibles.
'Las pruebas muestran presencia, no ausencia de defectos' y la 'paradoja del pesticida' son principios; los otros dos son falsos.
¿En qué actividad de prueba un equipo identifica principalmente las condiciones de prueba (qué debe probarse) a partir de la base de prueba?
Análisis de prueba
El análisis deriva las condiciones de prueba de la base de prueba.
Implementación de pruebas
Construye procedimientos/datos tras el diseño.
Ejecución de pruebas
Ejecuta las pruebas, mucho después.
Finalización de pruebas
Cierra tras terminar la ejecución.
Identificar qué probar (condiciones de prueba) ocurre durante el análisis de prueba.
¿Por qué es valioso mantener la trazabilidad entre la base de prueba y los casos de prueba?
Permite evaluar la cobertura y el impacto de los cambios en los requisitos
La trazabilidad vincula requisitos y pruebas para cobertura e impacto.
Corrige automáticamente las pruebas que fallan
La trazabilidad no corrige nada.
Elimina la necesidad de una base de prueba
La base de prueba es a lo que se traza.
Garantiza el 100% de detección de defectos
Ninguna técnica lo garantiza.
La trazabilidad permite evaluar la cobertura y el impacto de los cambios.
Una prueba pasa en el entorno de prueba pero el mismo escenario falla en producción. Además de un defecto de código, ¿qué causa del fallo es plausible?
Diferencias de entorno (configuración, datos, integraciones) entre ambos
Los fallos pueden venir de condiciones del entorno, no solo del código.
Los fallos solo pueden deberse a defectos de código
También pueden surgir del entorno, datos o uso.
El entorno de prueba es irrelevante para los resultados
El entorno influye mucho en los resultados.
Pasar en pruebas garantiza pasar en producción
Entornos distintos pueden comportarse distinto.
Los fallos pueden deberse a condiciones del entorno o datos, no solo a defectos de código.
¿Qué DOS afirmaciones sobre la responsabilidad de la calidad y las pruebas son correctas en CTFL v4.0?
La calidad es responsabilidad de todo el equipo
La práctica moderna comparte la calidad en el equipo.
Las pruebas independientes hallan defectos que el autor puede pasar por alto
La independencia reduce el sesgo del autor.
Solo el equipo de pruebas es responsable de la calidad
La calidad es compartida, no solo de los testers.
Los desarrolladores nunca deben probar su propio código
Pueden y deben; las pruebas independientes lo complementan.
La calidad es responsabilidad de todo el equipo y las pruebas independientes pueden revelar defectos distintos a los del autor.
Cada actividad del proceso de prueba genera su propio testware. ¿Cuál de los siguientes elementos es un resultado típico de la monitorización y control de pruebas y no de otra actividad?
Informes de progreso de las pruebas
Correcto — la monitorización recoge información sobre progreso y calidad y la informa, para poder tomar decisiones de control durante el esfuerzo de prueba.
El plan de pruebas
El plan de pruebas es el resultado principal de la planificación. La monitorización y control compara la realidad con ese plan, no lo produce.
Procedimientos de prueba y datos de prueba
Se crean durante la implementación de pruebas, cuando se organizan las pruebas y se prepara lo necesario para la ejecución.
El informe de finalización de pruebas
Ese informe lo produce la finalización al terminar un nivel o proyecto y resume todo el esfuerzo, no el progreso en curso.
La monitorización y control produce informes de progreso de pruebas (y directivas de control). El plan proviene de la planificación, los procedimientos y datos de la implementación, y el informe de finalización de la finalización.
¿En qué enfoque de desarrollo las pruebas se integran típicamente de forma continua en iteraciones cortas y repetidas con retroalimentación frecuente?
Desarrollo ágil/iterativo
Las pruebas son continuas en cada iteración corta.
Desarrollo secuencial (cascada)
Las pruebas se concentran en una fase tardía, no continuas.
Integración big-bang
Es una estrategia de integración, no un ciclo de vida.
Ningún modelo integra las pruebas de forma continua
Agile hace exactamente eso.
Los enfoques iterativos/ágiles integran las pruebas continuamente en iteraciones cortas.
¿Qué comprueba principalmente la prueba de componentes (unitaria)?
Componentes o unidades individuales de forma aislada
Es el alcance de la prueba de componentes.
Flujos de negocio de extremo a extremo
Eso es prueba de sistema o aceptación.
Interfaces entre componentes integrados
Eso es prueba de integración.
Satisfacción del usuario en producción
Se relaciona con aceptación/operación.
La prueba de componentes comprueba módulos/unidades de forma aislada.
Verificar que una aplicación web es operable por usuarios que usan un lector de pantalla es principalmente ¿qué tipo de prueba?
Prueba no funcional (accesibilidad/usabilidad)
La accesibilidad es una característica no funcional.
Prueba funcional
Comprueban qué hace el sistema, no su usabilidad.
Prueba de caja blanca
Se basa en la estructura interna.
Prueba de confirmación
Revisa un defecto ya corregido.
La accesibilidad/usabilidad es una característica de calidad no funcional.
¿Qué desencadena típicamente las pruebas de mantenimiento?
Una modificación, migración o retirada de un sistema ya operativo
Son los desencadenantes estándar.
Escribir la primera línea de código
Es desarrollo inicial, no mantenimiento.
Redactar los requisitos iniciales
Precede a cualquier operación.
Diseñar los primeros casos de prueba
El diseño es parte del desarrollo normal.
Las pruebas de mantenimiento se desencadenan por modificación, migración o retirada de un sistema operativo.
¿Cuáles DOS de los siguientes son tipos de prueba NO FUNCIONALES?
Prueba de rendimiento (carga)
Evalúa cuán bien funciona el sistema.
Prueba de usabilidad
Evalúa la facilidad de uso, característica no funcional.
Prueba de integración
Es un nivel de prueba, no un tipo no funcional.
Prueba de humo
Una comprobación funcional superficial de estabilidad.
Rendimiento y usabilidad son no funcionales; integración es un nivel y humo es un conjunto (funcional).
Tras un cambio en un sistema operativo, ¿cómo se determina mejor el alcance de la regresión necesaria?
Mediante análisis de impacto del cambio para identificar áreas afectadas
El análisis de impacto delimita la regresión racionalmente.
Volviendo a ejecutar todas las pruebas sin importar el cambio
A menudo inviable; el análisis enfoca el esfuerzo.
No ejecutando nunca regresión tras cambios
Los cambios arriesgan regresiones; hace falta probar.
Eligiendo pruebas al azar
El azar ignora el riesgo y el impacto reales.
El análisis de impacto identifica qué áreas pueden verse afectadas y necesitan regresión.
¿Qué tipo de problema puede detectar una herramienta de análisis estático SIN ejecutar el código?
Violaciones de estándares y código inalcanzable
El análisis inspecciona la estructura sin ejecutar.
Tiempo de respuesta real bajo carga alta
Eso requiere ejecución dinámica.
Fugas de memoria observadas en ejecución
El comportamiento en ejecución requiere ejecutar.
Puntuaciones de satisfacción del usuario
Vienen del feedback del usuario, no del análisis.
El análisis estático halla violaciones de estándares, código inalcanzable, variables no definidas, etc.
En el proceso genérico de revisión, ¿qué actividad va PRIMERO?
Planificación
Primero se define el alcance y qué productos revisar.
Comunicación y análisis de problemas
Ocurre tras la reunión de revisión.
Revisión individual
Sigue a la iniciación.
Corrección y reporte
Es casi al final.
El proceso genérico de revisión comienza con la planificación.
¿Cuáles DOS son beneficios reales de las revisiones (pruebas estáticas)?
Detección temprana de defectos en productos de trabajo
Las revisiones hallan defectos antes de ejecutar.
Compartir conocimiento entre los participantes
Las revisiones difunden el conocimiento.
Medir el tiempo de respuesta bajo carga
Requiere pruebas dinámicas de rendimiento.
Garantizar un producto sin defectos
Ninguna actividad garantiza cero defectos.
Las revisiones permiten detección temprana y compartir conocimiento; no miden rendimiento ni garantizan cero defectos.
La prueba estática comprende tanto revisiones como análisis estático. ¿Qué afirmación describe correctamente lo que distingue al análisis estático de una revisión?
El análisis estático lo realizan normalmente herramientas que comprueban código u otros artefactos formales frente a reglas y estándares, mientras que una revisión es un examen humano de un producto de trabajo.
Correcto — la diferencia esencial es quién o qué realiza el examen: herramientas frente a personas.
El análisis estático ejecuta el código con entradas predefinidas, mientras que una revisión no ejecuta nada.
Ninguno ejecuta el objeto de prueba. En cuanto se ejecuta código, la actividad es prueba dinámica, no estática.
El análisis estático solo puede aplicarse después de compilar el código y desplegarlo en un entorno de prueba.
Las herramientas de análisis estático trabajan directamente sobre el código fuente o modelos y no necesitan despliegue ni sistema en ejecución; esa es una de sus ventajas.
Una revisión está totalmente automatizada por herramientas, mientras que el análisis estático siempre debe hacerse manualmente.
Los papeles están invertidos. El análisis estático es la parte apoyada en herramientas; las revisiones dependen del juicio humano, aunque las herramientas puedan ayudar en su gestión.
El análisis estático se basa en herramientas: examinan código, modelos u otros artefactos formales frente a estándares y reglas. Una revisión es un examen humano de un producto de trabajo. Ninguno ejecuta el objeto de prueba.
Un sistema de calificación asigna una banda por nota entera: 0-39 suspenso, 40-59 aprobado, 60-79 notable, 80-100 sobresaliente. Con partición de equivalencia solo sobre notas VÁLIDAS, ¿cuál es el mínimo de casos para cubrir cada banda válida una vez?
4
Un valor representativo por cada una de las cuatro bandas válidas.
3
Hay cuatro bandas válidas, no tres.
2
Dos casos no cubren cuatro particiones.
8
Eso contaría los límites, no las particiones.
Hay cuatro bandas válidas, así que cuatro casos (un representante cada una).
Un campo acepta enteros de 10 a 50 inclusive; los valores fuera se rechazan. Con el análisis de valores límite de 2 valores (cada límite más su vecino más cercano), ¿qué conjunto prueba AMBOS límites?
{9, 10, 50, 51}
Límite más su vecino exterior en cada extremo.
{10, 50}
Solo límites, omiten vecinos.
{9, 10, 11, 49, 50, 51}
Ese es el enfoque de 3 valores (seis valores).
{10, 11, 49, 50}
Usa vecinos interiores en vez de exteriores.
Cada límite (10, 50) más su vecino exterior (9, 51): {9,10,50,51}.
Para el mismo campo (enteros 10 a 50 inclusive), ¿cuántos valores distintos requiere el enfoque de 3 valores para cubrir AMBOS límites?
6
Tres valores por límite, dos límites, sin solapamiento.
4
Ese es el enfoque de 2 valores.
8
Cuenta de más; tres por límite bastan.
3
Tres valores cubren solo un límite.
Inferior {9,10,11} y superior {49,50,51} = seis valores distintos.
Use la tabla de decisión siguiente. Un conductor de 22 años (menor de 25) contrata seguro premium y tiene un historial limpio. ¿Qué regla aplica y cuál es el resultado?
Regla R5 - Aprobar con recargo de conductor joven
Edad N, Premium S, limpio S es exactamente R5.
Regla R1 - Aprobar, sin recargo
R1 requiere Edad>=25 = S.
Regla R6 - Aprobar + joven + recargo de riesgo
R6 requiere historial limpio = N.
Regla R8 - Rechazar
R8 requiere Premium = N y limpio = N.
Edad>=25 = N, Premium = S, limpio = S coincide con R5: Aprobar + recargo de conductor joven.
En la tabla de decisión siguiente, las dos reglas de Rechazar (R4 y R8) tienen Premium = N y limpio = N, y solo difieren en la condición de edad. Con simplificación 'don't-care', ¿cuántas columnas se fusionan en una sola regla?
2 (R4 y R8 se fusionan en una regla)
Ambas rechazan con Premium = N y limpio = N; la edad es 'don't-care'.
4
Solo las dos columnas de Rechazar comparten la misma acción.
8
Solo dos columnas se fusionan, no las ocho.
1
Una columna no puede 'fusionarse'; dos se fusionan en una.
R4 y R8 comparten la acción y solo difieren en una condición 'don't-care', así que 2 se fusionan en 1.
¿Para qué situación es la prueba de transición de estados la técnica MÁS adecuada?
Un pedido cuyas acciones permitidas dependen de su estado (p. ej. pagado, enviado)
El comportamiento depende del estado y eventos - ideal.
Un único campo numérico con un rango permitido
Eso encaja con el análisis de valores límite.
Una regla de negocio con varias condiciones independientes
Eso encaja con la tabla de decisión.
Medir la cobertura de código de una función
Eso es prueba estructural (caja blanca).
La prueba de transición de estados encaja con sistemas cuyo comportamiento depende del estado y de los eventos.
Usando la máquina de estados del ciclo de pedido siguiente, ¿qué secuencia de eventos es un camino VÁLIDO de Created a Delivered?
Created -> pay -> Paid -> pack -> Packed -> ship -> Shipped -> deliver -> Delivered
Cada transición existe en ese orden.
Created -> pack -> ship -> deliver
No se puede empacar antes de pagar; no hay Created->Packed.
Created -> pay -> Paid -> ship -> deliver
No hay Paid->Shipped; hay que empacar primero.
Created -> pay -> Paid -> cancel -> Delivered
Cancel lleva a Cancelled, no a Delivered.
El camino válido es pay, pack, ship, deliver.
Considere esta rutina con cinco sentencias ejecutables: (1) INPUT n; (2) total = 0; (3) IF n > 0; (4) total = n * 2; (5) PRINT total. La sentencia 4 se ejecuta solo si el IF es verdadero. Una prueba se ejecuta con n = 0. ¿Qué cobertura de sentencias logra?
80%
Se ejecutan 1, 2, 3 y 5; se omite la 4: 4/5.
100%
La sentencia 4 no se alcanza con n = 0.
60%
Se ejecutan cuatro de cinco, no tres.
40%
Solo se omite una; se ejecutan cuatro.
Con n = 0 el IF es falso, así que se ejecutan 4 de 5 sentencias = 80%.
¿Cuáles DOS de los siguientes son técnicas de prueba de caja blanca (basadas en estructura)?
Prueba de sentencias
Se basa en ejecutar sentencias del código.
Prueba de ramas
Se basa en cubrir los resultados de decisión.
Partición de equivalencia
Una técnica de caja negra basada en especificación.
Prueba de tabla de decisión
Una técnica de caja negra basada en especificación.
Las pruebas de sentencias y ramas son de caja blanca; partición de equivalencia y tablas de decisión son de caja negra.
Un tester, basado en su experiencia, lista entradas probablemente problemáticas (campos vacíos, cero, números muy grandes, caracteres especiales) y las prueba. ¿Qué técnica es?
Conjetura de errores
Una técnica basada en experiencia que anticipa defectos.
Partición de equivalencia
Una técnica sistemática, no basada en experiencia.
Análisis de valores límite
Sistemática, centrada en los bordes.
Prueba de transición de estados
Basada en estados y eventos, no en conjeturas.
Anticipar entradas propensas a errores desde la experiencia es la conjetura de errores.
¿Cuáles DOS de las siguientes son técnicas de prueba de caja blanca (basadas en la estructura)? (Elija dos.)
Prueba de sentencias.
Se basa en la ejecución de las sentencias del código — una técnica de caja blanca.
Prueba de ramas.
Se basa en ejercitar los resultados de las decisiones del código — una técnica de caja blanca.
Partición de equivalencia.
Una técnica de caja negra (basada en la especificación).
Prueba de casos de uso.
Una técnica de caja negra (basada en la especificación).
Las técnicas de caja blanca se basan en la estructura interna del código, p. ej., la prueba de sentencias y la prueba de ramas. La partición de equivalencia y la prueba de casos de uso son de caja negra.
Un enfoque de prueba en el que el diseño y la ejecución comienzan solo tras la entrega del software, reaccionando al sistema tal como se ha construido, se describe mejor como:
Un enfoque de prueba reactivo.
Correcto — las pruebas se diseñan y ejecutan en reacción al sistema entregado.
Un enfoque de prueba preventivo.
Los enfoques preventivos diseñan pruebas pronto, antes de construir el código.
Un enfoque de prueba de caja blanca.
Caja blanca se refiere a usar la estructura interna, no al momento del diseño de pruebas.
Un enfoque de prueba de confirmación.
La confirmación reprueba tras una corrección; no es un enfoque global definido por el momento.
Un enfoque reactivo diseña y ejecuta pruebas en respuesta al software entregado (p. ej., pruebas exploratorias). Un enfoque preventivo diseña pruebas pronto, antes de que el software exista.
¿Cuál de los siguientes es un ejemplo de criterio de SALIDA de un nivel de prueba?
Se ha logrado la cobertura planificada y no quedan defectos de alta severidad abiertos
Los criterios de salida definen cuándo parar.
Se ha preparado el entorno de prueba
Es un criterio de entrada.
Los requisitos se han fijado como línea base
Una condición de entrada, no de salida.
Se ha comprado una herramienta
Sin relación con los criterios de salida.
Cobertura planificada lograda sin defectos abiertos de alta severidad es un criterio de salida típico.
En el análisis de riesgos, ¿a qué se refiere el 'impacto' de un riesgo?
La consecuencia o el daño si el riesgo se materializa
El impacto mide cuán grave sería el resultado.
La probabilidad de que el riesgo ocurra
Eso es la probabilidad, no el impacto.
El número de testers asignados
Sin relación con el impacto.
El coste de la herramienta
Sin relación con el impacto.
El impacto es la magnitud del daño si el riesgo se materializa.
Durante un ciclo, el responsable reprioriza y reasigna pruebas porque un área de alto riesgo falla mucho. ¿Qué actividad es?
Control de pruebas
El control toma acciones correctivas según el monitoreo.
Monitoreo de pruebas
El monitoreo recopila info; actuar es control.
Planificación
Ocurre antes de ejecutar, no como reacción.
Finalización
Cierra tras terminar la ejecución.
Tomar acciones correctivas con base en el monitoreo es el control de pruebas.
¿Qué DOS elementos pertenecen típicamente a un informe de finalización de pruebas?
Un resumen de las pruebas realizadas y los resultados
Contenido central del informe.
Riesgos residuales y lecciones aprendidas
Ayuda a decidir y mejorar.
El código fuente completo del sistema
No es parte del informe.
El salario de cada desarrollador
Irrelevante e inapropiado.
Un resumen de las pruebas/resultados y los riesgos residuales/lecciones aprendidas pertenecen al informe.
Una errata puramente cosmética en la página de inicio se corrige con urgencia porque mañana hay un gran lanzamiento. ¿Qué ilustra esto?
Severidad y prioridad son independientes - baja severidad puede ser alta prioridad
El contexto de negocio puede elevar la prioridad.
La severidad y la prioridad siempre coinciden
Son atributos distintos y pueden diferir.
Los defectos cosméticos nunca deben corregirse
A veces importan mucho (p. ej. un lanzamiento).
La prioridad la fijan solo los desarrolladores
Suele ser decisión del negocio/partes interesadas.
Severidad y prioridad son distintas: un defecto de baja severidad puede tener alta prioridad.
Con estimación de tres puntos: optimista = 2 días, más probable = 5 días, pesimista = 14 días, ¿cuál es la duración esperada por (a + 4m + b) / 6?
6 días
(2 + 4*5 + 14)/6 = 36/6 = 6.
5 días
5 es el valor más probable, no la estimación ponderada.
7 días
No coincide con el resultado de la fórmula, que es 6.
8 días
Error aritmético; el valor correcto es 6.
(2 + 20 + 14) / 6 = 36 / 6 = 6 días.
¿Qué DOS factores influyen típicamente en una estimación del esfuerzo de prueba?
El tamaño y la complejidad del producto
Productos mayores y complejos requieren más pruebas.
El nivel de calidad requerido y el riesgo del producto
Más calidad/riesgo requiere más pruebas.
El color favorito de los testers
Irrelevante para el esfuerzo.
El número de salas de reunión del edificio
Irrelevante para el esfuerzo.
El tamaño/complejidad del producto y el nivel de calidad/riesgo determinan el esfuerzo.
¿En qué se diferencia una estrategia de prueba de un plan de pruebas?
Una estrategia describe un enfoque general a nivel de organización/programa, mientras que un plan es específico de un proyecto o nivel
La estrategia es genérica; el plan la aplica.
Son documentos idénticos con distinto nombre
Operan en niveles de abstracción distintos.
Un plan es siempre más genérico que una estrategia
Invertido: la estrategia es la más genérica.
Una estrategia enumera los casos exactos a ejecutar
Ese detalle pertenece al diseño, no a la estrategia.
Una estrategia es un enfoque general a nivel de organización/programa; un plan es específico de proyecto/nivel.
¿Qué tipo de herramienta revisa el código en busca de violaciones de estándares y construcciones sospechosas SIN ejecutarlo?
Herramienta de análisis estático
Examina la estructura sin ejecutar.
Herramienta de pruebas de rendimiento
Ejecuta el sistema bajo carga.
Herramienta de gestión de pruebas
Gestiona pruebas y trazabilidad, no analiza código.
Herramienta de ejecución (automatización)
Ejecuta scripts dinámicamente.
Una herramienta de análisis estático inspecciona el código sin ejecutarlo.
¿Cuáles DOS son consideraciones sensatas al seleccionar una herramienta de prueba para una organización?
Compatibilidad con herramientas y procesos existentes
La integración evita fricción y retrabajo.
Evaluación del soporte del proveedor y el mantenimiento
El soporte a largo plazo afecta coste y riesgo.
Lo pegadizo del eslogan de marketing
Irrelevante para la eficacia.
Una garantía del proveedor de producto sin defectos
Ninguna herramienta garantiza cero defectos.
La compatibilidad con herramientas/procesos existentes y el soporte/mantenimiento del proveedor son criterios sensatos.