ISTQB Foundation (CTFL v4.0) Examen de práctica #4 — 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.
¿Cuál describe MEJOR por qué son necesarias las pruebas?
Reduce el riesgo de fallos durante la operación.
Correcto — una razón clave.
Garantiza que el software no contiene defectos.
Las pruebas no demuestran la ausencia de defectos.
Sustituye el análisis de requisitos.
Las pruebas complementan el trabajo de requisitos.
Hace innecesaria la depuración.
La depuración sigue siendo necesaria.
Las pruebas reducen el riesgo de fallos en operación y ayudan a determinar si la calidad es aceptable; no garantizan software sin defectos.
Un tester cree que una función funciona y solo diseña pruebas que lo confirman. ¿Con qué sesgo cognitivo se relaciona?
Sesgo de confirmación — favorecer información que confirma creencias.
Correcto — el sesgo del principio de factores humanos.
La paradoja del pesticida.
Trata de pruebas repetidas que pierden eficacia.
Agrupación de defectos.
Trata de dónde se concentran los defectos.
Falacia de ausencia de errores.
Trata de un sistema sin defectos pero inadecuado.
Es el sesgo de confirmación: favorecer la evidencia que confirma expectativas.
Un sistema pasó todas las pruebas y tiene pocos defectos, pero los usuarios lo rechazan porque no satisface sus necesidades. ¿Qué principio ilustra?
Falacia de ausencia de errores.
Correcto — pocos defectos no garantizan satisfacer al usuario.
Las pruebas muestran la presencia de defectos.
Cierto, pero no lo que ilustra el escenario.
Las pruebas exhaustivas son imposibles.
No es el punto aquí.
Las pruebas dependen del contexto.
Válido, pero no describe esta situación.
La 'falacia de ausencia de errores': corregir defectos no sirve si el sistema no satisface al usuario.
Ordene lógicamente: 1) diseño, 2) análisis, 3) implementación, 4) ejecución.
Análisis → Diseño → Implementación → Ejecución
Correcto — el orden lógico.
Diseño → Análisis → Ejecución → Implementación
El análisis precede al diseño.
Implementación → Análisis → Diseño → Ejecución
Análisis y diseño van antes.
Ejecución → Implementación → Diseño → Análisis
Es el orden inverso.
Análisis → diseño → implementación → ejecución.
¿Cuál de los siguientes es una condición de prueba y no un caso de prueba?
"Validación del inicio de sesión con contraseña inválida"
Correcto — aspecto comprobable sin datos concretos.
Entrada 'amy'/'x', esperar 'credenciales inválidas'.
Tiene entradas y resultado — un caso.
Introducir 'amy'/'secret123' y cargar el panel.
Datos concretos — un caso.
Introducir contraseña de 13 caracteres y esperar rechazo.
Valor concreto — un caso.
Una condición es un aspecto comprobable. Un caso añade entradas y resultados esperados.
¿Cuáles DOS forman parte del análisis de pruebas? (Elija dos.)
Identificar condiciones analizando la base de prueba.
Correcto — parte central.
Detectar defectos en la base, como ambigüedades.
Correcto — el análisis suele descubrirlos.
Ejecutar los casos y registrar resultados.
Eso es ejecución.
Preparar el entorno y las herramientas.
Eso es implementación.
El análisis identifica condiciones de prueba y detecta defectos en la base.
¿Por qué es importante la responsabilidad de todo el equipo por la calidad en contextos modernos (ágiles)?
Permite prevenir y detectar defectos antes en todo el equipo.
Correcto — favorece la calidad temprana.
Elimina la necesidad de habilidades de prueba.
Las habilidades siguen siendo necesarias.
Solo los desarrolladores son responsables.
Todo el equipo la comparte.
Garantiza cero defectos en el producto.
Ningún enfoque garantiza cero defectos.
La responsabilidad compartida permite prevenir y detectar defectos antes.
En el proceso de prueba de ISTQB, una actividad define los objetivos de la prueba y selecciona el enfoque que mejor los alcanza dentro de las restricciones dadas, y su resultado principal es el plan de pruebas. ¿De qué actividad se trata?
Planificación de pruebas
Correcto — la planificación de pruebas establece los objetivos y elige el enfoque y los recursos para alcanzarlos; el plan de pruebas es su resultado.
Monitorización y control de pruebas
Esta actividad compara el progreso real con el plan y desencadena acciones correctivas. Usa el plan, no lo crea.
Análisis de pruebas
El análisis de pruebas deriva condiciones de prueba de la base de prueba, es decir, qué probar. No define los objetivos globales ni selecciona el enfoque.
Implementación de pruebas
La implementación crea y organiza el testware necesario para la ejecución (procedimientos, suites, datos, entorno). Ocurre después de haber elegido el enfoque.
La planificación de pruebas define los objetivos de la prueba y selecciona el enfoque (técnicas, niveles, criterios de entrada/salida, recursos, calendario) que mejor los alcanza dentro de las restricciones del proyecto. Su testware principal es el plan de pruebas.
¿Qué caracteriza MEJOR los enfoques 'test-first' como TDD?
Las pruebas se escriben antes del código, que luego las supera.
Correcto — la característica definitoria.
Las pruebas se escriben solo al terminar el sistema.
Es lo contrario de test-first.
No se usan pruebas automatizadas.
TDD depende de pruebas automatizadas.
Solo pruebas de aceptación, nunca unitarias.
TDD se centra en pruebas unitarias.
En TDD se escriben las pruebas antes del código, que luego se escribe para superarlas.
Representantes del cliente prueban si el sistema soporta sus procesos de negocio reales antes de producción. ¿Qué forma de aceptación es?
Prueba de aceptación de usuario (UAT)
Correcto — los usuarios validan contra sus necesidades reales.
Prueba de integración de componentes
Verifica interfaces entre componentes.
Prueba de componente
El nivel más bajo, por desarrolladores.
Prueba de regresión
La regresión busca efectos secundarios.
La prueba de aceptación de usuario valida que el sistema soporta los procesos reales del usuario.
¿Cuál es el MEJOR ejemplo de prueba no funcional de la característica 'fiabilidad'?
Ejecutar el sistema 72 horas seguidas sin fallos ni degradación.
Correcto — la prueba de resistencia aborda la fiabilidad.
Comprobar que una transferencia mueve la cantidad correcta.
Una prueba funcional.
Medir cuán rápido se renderiza la página.
Eficiencia de rendimiento, no fiabilidad.
Comprobar que las etiquetas están traducidas al francés.
Localización/usabilidad.
La fiabilidad concierne a seguir funcionando en el tiempo, p. ej. ejecución prolongada sin fallos.
En el modelo en V, ¿con qué fase se asocia MEJOR el diseño de las pruebas de sistema?
La fase de especificación de requisitos del sistema.
Correcto — las pruebas de sistema verifican los requisitos.
La fase de diseño detallado.
Se empareja con la prueba de componente.
La fase de codificación.
Se empareja con la prueba de componente.
La fase de requisitos de negocio / contrato.
Se empareja con la aceptación.
El diseño de pruebas de sistema se basa en la especificación de requisitos del sistema.
¿Qué tipo de prueba determina el cumplimiento con regulaciones, normas o requisitos contractuales?
Prueba de cumplimiento (conformidad)
Correcto — verifica la adhesión a normas/regulaciones.
Prueba de humo
Verifica la estabilidad básica.
Prueba de usabilidad
Trata la facilidad de uso.
Prueba de confirmación
Verifica que una corrección resolvió un defecto.
La prueba de cumplimiento verifica la adhesión a leyes, normas o contratos.
Poco antes de la puesta en producción, el equipo de operaciones comprueba la copia de seguridad y su restauración, el procedimiento de recuperación ante desastres, la administración de usuarios y los scripts de instalación en un entorno similar al de producción. ¿Qué forma de prueba de aceptación es?
Prueba de aceptación operativa
Correcto — son exactamente las tareas operativas que cubre la OAT, realizadas por el personal de operaciones o administración de sistemas.
Prueba de aceptación de usuario
La prueba de aceptación de usuario la realizan usuarios de negocio y valida que el sistema soporte sus procesos y su idoneidad de uso, no los procedimientos de copia, recuperación y administración.
Prueba alfa
La prueba alfa la realizan usuarios potenciales o existentes en las instalaciones de la organización desarrolladora. El factor distintivo es quién prueba y dónde, no el carácter operativo de las tareas.
Prueba de aceptación regulatoria
La prueba de aceptación regulatoria demuestra el cumplimiento de leyes, normativas y estándares. Copia, recuperación y administración de usuarios son cuestiones operativas, no evidencia regulatoria.
La prueba de aceptación operativa (OAT) la realiza el personal de operaciones o administración de sistemas y cubre tareas como copia/restauración, recuperación ante desastres, gestión de usuarios, instalación y mantenimiento del sistema en su entorno operativo.
¿En qué paso del proceso de revisión los revisores examinan individualmente el producto antes de la reunión?
Revisión individual (preparación individual)
Correcto — examinan el producto por separado primero.
Planificación
Define alcance y participantes.
Corrección e informe
Ocurre tras comunicar hallazgos.
Inicio de la revisión
El inicio distribuye el producto.
El paso de 'revisión individual' es donde los revisores examinan el producto por su cuenta.
¿Qué tipo de revisión es MEJOR cuando el objetivo es lograr consenso, dirigida por el autor?
Recorrido (walkthrough)
Correcto — dirigido por el autor, busca consenso.
Inspección
Dirigida por un moderador, la más formal.
Revisión informal
Sin estructura definida.
Auditoría
Verifica cumplimiento de normas.
El recorrido lo dirige el autor y busca comprensión y consenso.
¿Cuál es un producto típico que puede examinarse mediante pruebas estáticas?
Un documento de especificación de requisitos.
Correcto — los documentos son típicos.
El tiempo de respuesta medido bajo carga.
Un resultado dinámico.
El uso de CPU durante una prueba de estrés.
Métricas en ejecución requieren prueba dinámica.
El registro de ca1da real cuando la app falla.
Surge al ejecutar.
Las pruebas estáticas examinan requisitos, diseño, código, planes, etc.
¿Cuál es la distinción PRINCIPAL entre un defecto hallado por prueba estática y un fallo hallado por prueba dinámica?
La estática halla defectos directamente; la dinámica observa fallos.
Correcto — estática halla el defecto, dinámica ve el síntoma.
La estática siempre halla más defectos.
Ninguna es universalmente superior.
La dinámica no requiere casos de prueba.
Usa casos para ejecutar el sistema.
La estática ejecuta el código de forma controlada.
La estática no ejecuta el código.
La estática halla defectos directamente sin ejecución; la dinámica observa fallos durante la ejecución.
¿Cuáles DOS de las siguientes son técnicas de caja negra (basadas en especificación)? (Elija dos.)
Pruebas con tabla de decisión.
Una técnica basada en especificación (caja negra) para combinaciones de condiciones.
Pruebas de transición de estados.
Una técnica basada en especificación (caja negra) basada en estados y transiciones.
Pruebas de sentencias.
Las pruebas de sentencias son de caja blanca (estructurales).
Pruebas de ramas.
Las pruebas de ramas son de caja blanca (estructurales).
Las técnicas de caja negra incluyen partición de equivalencia, análisis de valores límite, tablas de decisión, transición de estados y casos de uso. Las pruebas de sentencias y de ramas son de caja blanca.
Para la máquina de estados del cajero siguiente, ¿cuántos casos de prueba se requieren para lograr la cobertura 0-switch, es decir, cubrir cada transición individual válida exactamente una vez? (Cuente la autotransición 'PIN incorrecto (<3)' como una transición.)
9
Idle->AwaitPIN, AwaitPIN->Menu, autobucle de AwaitPIN, AwaitPIN->Locked, Menu->Dispensing, Dispensing->Menu, Menu->CardReturned, CardReturned->Idle, Locked->Idle.
6
Cuenta de menos; hay nueve transiciones distintas.
8
Omite una transición, p. ej. el autobucle.
5
Demasiado pocos para la cobertura 0-switch aquí.
Hay nueve transiciones válidas, por lo que la cobertura 0-switch necesita nueve casos.
El diagrama del termostato muestra las transiciones válidas. ¿Qué secuencia de eventos es INVÁLIDA, comenzando en S1 (Apagado)?
turn on, luego temp >= set
Correcto — tras 'turn on' está en Reposo; 'temp >= set' solo válido desde Calentando.
turn on, luego temp < set, luego temp >= set
Válido: Apagado→Reposo→Calentando→Reposo.
turn on, luego turn off
Válido: Apagado→Reposo→Apagado.
turn on, luego temp < set, luego turn off
Válido: Apagado→Reposo→Calentando→Apagado.
Desde S1 (Apagado) solo 'turn on' a S2 es válido. No hay transición de Apagado a Calentando, así que 'turn on' y luego 'temp >= set' es inválido.
Para el grafo de flujo de control, el cuerpo del bucle (nodo 3 → nodo 4) puede ejecutarse cero o más veces. ¿Cuál es el mínimo de casos para 100% de cobertura de ramas de la decisión en el nodo 2?
2
Correcto — uno entra al bucle y otro lo omite.
1
Un test no cubre ambos resultados de rama.
3
Solo una decisión, dos resultados bastan.
4
Demasiados; una decisión necesita solo 2.
La decisión en el nodo 2 tiene dos resultados: entrar al bucle (verdadero) y salir (falso). La cobertura de ramas exige ambos — 2 casos.
¿Cuál es el propósito PRINCIPAL de colapsar una tabla de decisión fusionando columnas redundantes?
Reducir el número de casos manteniendo la cobertura.
Correcto — fusiona don't-care sin perder cobertura.
Añadir más condiciones.
Colapsar reduce, no añade.
Convertir la tabla en un diagrama de transición.
Son técnicas distintas.
Garantizar el 100% de cobertura de ramas del código.
Las tablas de decisión son de caja negra.
Fusiona columnas con condiciones don't-care, reduciendo casos sin perder cobertura.
El costo de envío depende de dos condiciones: 'Miembro' y 'Pedido >= $50'. El comportamiento difiere en las cuatro combinaciones. ¿Cuántos casos para cobertura total?
4
Correcto — 2 × 2 = 4 combinaciones distintas.
2
Dos no cubren las cuatro.
3
Tres dejan una sin probar.
8
8 sería 2^3; aquí solo dos condiciones.
Dos condiciones binarias dan 2 × 2 = 4 combinaciones; todas difieren — 4 casos.
¿Qué criterio de caja blanca se satisface cuando cada sentencia ejecutable se ha ejercitado al menos una vez?
Cobertura de sentencias
Correcto — mide las sentencias ejercitadas.
Cobertura de ramas
Exige cada resultado de decisión.
Cobertura de caminos
Exige todos los caminos independientes.
Cobertura de particiones de equivalencia
Un criterio de caja negra.
La cobertura de sentencias mide el porcentaje de sentencias ejercitadas.
Un cuestionario califica 0–100: 0–39 = Suspenso, 40–69 = Aprobado, 70–100 = Distinción. ¿Qué conjunto elige UN representante de CADA partición válida?
{ 20, 55, 85 }
Correcto — un valor en cada partición.
{ 39, 40, 69, 70 }
Son valores límite.
{ 10, 25, 35 }
Los tres en Suspenso.
{ 55, 60, 65 }
Los tres en Aprobado.
Tres particiones: Suspenso, Aprobado, Distinción. Uno de cada una, p. ej. {20, 55, 85}.
¿Cuándo es la prueba de transición de estados la técnica MÁS apropiada?
Cuando el comportamiento depende del estado actual y los eventos.
Correcto — modela estados, eventos y transiciones.
Cuando las entradas son rangos numéricos independientes sin memoria.
Eso conviene a partición/AVL.
Cuando el objetivo es medir la cobertura de sentencias.
Es un objetivo de caja blanca.
Solo cuando no hay especificación.
Depende de un modelo derivado de la especificación.
Para sistemas cuyo comportamiento depende del estado actual y del historial, donde los eventos disparan transiciones.
¿Cuáles DOS son técnicas de caja blanca? (Elija dos.)
Prueba de sentencias
Correcto — basada en la estructura del código.
Prueba de ramas
Correcto — basada en decisiones del código.
Partición de equivalencia
Una técnica de caja negra.
Prueba de casos de uso
Una técnica de caja negra.
Las pruebas de sentencias y ramas derivan de la estructura. Partición y casos de uso son de caja negra.
Un semáforo recorre Rojo → Verde → Ámbar → Rojo, con una transición válida entre cada par. ¿Cuántos casos para cobertura 0-switch?
3
Correcto — tres transiciones válidas.
1
Uno no ejercita las tres.
6
6 corresponde a 1-switch.
9
Muchos más que tres.
0-switch exige cada transición válida una vez. Tres transiciones — 3 casos.
Cuatro riesgos se valoran 1-5: R1 L=5 I=5; R2 L=2 I=4; R3 L=4 I=3; R4 L=3 I=5. Si nivel de riesgo = Probabilidad x Impacto, ¿cuál se prueba PRIMERO?
R1 (nivel de riesgo 25)
5*5 = 25 es el más alto.
R4 (nivel de riesgo 15)
3*5 = 15 es menor que el 25 de R1.
R3 (nivel de riesgo 12)
4*3 = 12 es menor que el 25 de R1.
R2 (nivel de riesgo 8)
2*4 = 8 es el más bajo.
R1 tiene el producto más alto (25).
¿Qué describe MEJOR la diferencia entre seguimiento y control de pruebas?
El seguimiento recopila información; el control actúa con ella.
Correcto — el control actúa sobre lo que revela el seguimiento.
El seguimiento corrige defectos; el control escribe casos.
Ninguno es correcto.
Son la misma actividad.
Son distintas.
El control recopila métricas; el seguimiento aprueba el presupuesto.
Roles invertidos.
El seguimiento recopila información; el control toma acciones correctivas con ella.
¿Cuál es el MEJOR ejemplo de una entrada basada en riesgo de producto en un plan de pruebas?
"Un cálculo de interés incorrecto podría causar pérdidas — probar a fondo."
Correcto — un riesgo de producto.
"El entorno podría entregarse con dos semanas de retraso."
Un riesgo de proyecto.
"Dos testers podrían dejar el proyecto."
Un riesgo de personal.
"La licencia de la herramienta podría caducar."
Un riesgo de herramienta/proyecto.
Un riesgo de producto se refiere a un fallo que daña a los interesados, p. ej. un cálculo de interés incorrecto.
Un equipo ejecutó 200 casos. 150 pasaron, 30 fallaron y 20 quedaron bloqueados. ¿Qué porcentaje de los ejecutados pasó?
Aproximadamente 83%
Correcto — 150 / 180 ≈ 0,833.
75%
150 / 200 cuenta los bloqueados.
85%
No coincide con 83%.
90%
Sobreestima la tasa.
Ejecutados = 150 + 30 = 180. 150 / 180 ≈ 83%.
¿Cuál es un atributo típico de un informe de defecto para clasificación y análisis?
La severidad y prioridad del defecto.
Correcto — apoyan clasificación y priorización.
La opinión personal del tester sobre el desarrollador.
Los informes deben ser objetivos.
El presupuesto total del proyecto.
Ajeno al informe.
El número de reuniones de la semana.
Irrelevante.
Los informes registran severidad/prioridad, estado, fase y referencias.
¿Cuál es un ejemplo de métrica basada en cobertura para monitorear el progreso?
Porcentaje de requisitos cubiertos por casos ejecutados.
Correcto — métrica de cobertura.
El número de cafés consumidos.
No es una métrica significativa.
La marca de la herramienta.
Un atributo de herramienta.
El esquema de colores del panel.
Cosmético.
Las métricas de cobertura miden la proporción cubierta, p. ej. requisitos cubiertos.
¿Qué distingue MEJOR la severidad de la prioridad de un defecto?
La severidad es el impacto; la prioridad la urgencia.
Correcto — dimensiones independientes.
Siempre tienen el mismo valor.
Pueden diferir.
La severidad la fija la gerencia; la prioridad el compilador.
El compilador no fija la prioridad.
La prioridad es el impacto; la severidad la urgencia.
Invierte las definiciones.
La severidad es el impacto; la prioridad es la urgencia de corregirlo. Pueden diferir.
Al aplicar pruebas basadas en riesgos, ¿qué efecto tiene que una función sea de alto riesgo?
Recibe pruebas más tempranas y exhaustivas.
Correcto — el riesgo orienta la profundidad.
Se excluye de las pruebas.
Se prueban más, no se excluyen.
Se prueba solo después de la entrega.
Los altos riesgos se prueban antes.
Automáticamente tiene cero defectos.
El nivel de riesgo no cambia el número de defectos.
Las áreas de alto riesgo reciben pruebas más tempranas y exhaustivas.
¿Qué práctica de gestión de la configuración es la MÁS importante para que las pruebas sean repetibles y trazables?
Identificar y controlar versiones de los elementos y el testware.
Correcto — el control de versiones sustenta la repetibilidad.
Borrar resultados antiguos para ahorrar espacio.
Borrar socava la trazabilidad.
Dejar copias privadas sin versión a cada tester.
Destruye la repetibilidad.
Evitar toda documentación de versiones.
Sin documentación no hay trazabilidad.
La GC identifica y controla versiones de los elementos y el testware.
¿Cuál es un beneficio de usar una herramienta de ejecución (automatización) para regresión?
Grandes conjuntos de regresión se ejecutan rápida y consistentemente.
Correcto — velocidad y consistencia.
Elimina la necesidad de diseñar casos.
El diseño sigue siendo necesario.
Garantiza que no quedan defectos.
Ninguna herramienta lo garantiza.
Elimina todo esfuerzo de mantenimiento.
Requieren mantenimiento continuo.
Las herramientas ejecutan grandes conjuntos de regresión rápida y repetidamente.
¿Cuál es una consideración clave al SELECCIONAR una herramienta de prueba?
Qué tan bien encaja con los procesos y la madurez, con evaluación costo-beneficio.
Correcto — ajuste y ROI son centrales.
Solo el color de la interfaz.
Cosmético.
Elegir la opción más cara.
El precio no indica idoneidad.
Elegir la herramienta que usa un competidor.
Puede no encajar en tu contexto.
La selección debe considerar madurez, ajuste con procesos, habilidades, soporte y costo-beneficio.