ISTQB Foundation (CTFL v4.0) Examen de práctica #12 — 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.
Una suite de regresión lleva un año ejecutándose sin cambios y ya casi no encuentra defectos nuevos. ¿Qué principio lo explica y qué debe hacer el equipo?
Paradoja del pesticida - revisar y renovar las pruebas
Las pruebas idénticas repetidas pierden eficacia con el tiempo.
Agrupación de defectos - dejar de probar esos módulos
La agrupación trata de dónde se concentran, no del envejecimiento.
Pruebas exhaustivas - ejecutar aún más de lo mismo
Más pruebas iguales no ayudan; hay que renovarlas.
Las pruebas demuestran que el software ya no tiene defectos
Las pruebas nunca prueban la ausencia de defectos.
La paradoja del pesticida: las pruebas sin cambios dejan de hallar defectos, por lo que hay que revisarlas y actualizarlas.
¿Qué par distingue correctamente verificación de validación?
La verificación comprueba que cumple la especificación; la validación, que cumple las necesidades
Distinción estándar de CTFL.
La verificación comprueba necesidades; la validación la especificación
Definiciones invertidas.
Ambas significan la misma actividad
Son conceptos distintos.
La verificación solo se hace en producción
La verificación ocurre durante todo el desarrollo.
Verificación = construir bien el producto (cumple especificaciones); validación = construir el producto correcto (cumple necesidades).
¿Cuáles DOS de los siguientes son productos de trabajo de prueba?
Casos de prueba
Un producto de trabajo central.
Registros de prueba
Registros de la ejecución, un producto de trabajo.
El compilador
Una herramienta de desarrollo, no un producto de prueba.
El servidor de producción
Infraestructura, no un producto de prueba.
Los casos de prueba y los registros de prueba son testware; un compilador y el servidor de producción no.
¿Por qué un defecto real en el código podría no causar nunca un fallo durante la operación?
El código defectuoso nunca se ejecuta bajo las condiciones que lo activarían
Sin ejecución del camino defectuoso no se observa fallo.
Los defectos siempre causan un fallo cada ejecución
Muchos defectos son latentes y dependen de condiciones.
Un defecto y un fallo son lo mismo
El defecto está en el código; el fallo es comportamiento observado.
Porque las pruebas eliminaron el defecto automáticamente
Las pruebas detectan, no eliminan automáticamente.
Si el código defectuoso nunca se ejecuta (o solo bajo condiciones que no ocurren), no produce fallo.
La gestión de la calidad suele describirse como compuesta por ¿qué dos subáreas?
Aseguramiento (QA) y control (QC) de la calidad
QA es de proceso; QC (incl. pruebas) es de producto.
Marketing y ventas
No forman parte de la gestión de la calidad.
Codificación y despliegue
Son actividades de desarrollo, no subáreas de QM.
Depuración y refactorización
Actividades de desarrollo, no subáreas de QM.
La gestión de la calidad comprende el aseguramiento (QA) y el control de la calidad (QC).
¿Qué principio de prueba afirma que encontrar y corregir defectos antes reduce el coste total?
Probar pronto ahorra tiempo y dinero
Los defectos eliminados pronto evitan retrabajo costoso.
Agrupación de defectos
Trata de la concentración de defectos.
Las pruebas muestran presencia, no ausencia
Principio cierto, pero sobre lo que prueban.
Las pruebas dependen del contexto
Sobre adaptar el enfoque, no el momento del coste.
Probar pronto ahorra tiempo y dinero es uno de los siete principios.
¿Qué DOS afirmaciones sobre los niveles de independencia de las pruebas son correctas?
Las pruebas diseñadas por el autor tienen baja independencia
El autoexamen es el nivel menos independiente.
Un equipo de pruebas independiente es una forma reconocida de independencia
Un equipo dedicado es un nivel mayor de independencia.
Mayor independencia garantiza hallar todos los defectos
Ningún nivel lo garantiza.
La independencia es irrelevante para la detección
La independencia puede mejorar la eficacia.
Las pruebas del propio autor tienen baja independencia; un equipo independiente es una forma mayor; la independencia es un espectro y ningún nivel garantiza hallar todos los defectos.
La forma de llevar a cabo el proceso de prueba depende del contexto del proyecto. ¿Cuáles DOS de los siguientes son factores contextuales que dan forma a cómo se prueba? (Elija dos.)
El ciclo de vida de desarrollo utilizado y las herramientas disponibles para el equipo
Correcto — el SDLC y las herramientas disponibles son factores contextuales explícitos; un ciclo iterativo con pipeline de CI produce un proceso de prueba muy distinto al de uno secuencial.
Restricciones del proyecto como el tiempo y el presupuesto disponibles, junto con las habilidades del equipo
Correcto — las restricciones del proyecto y las habilidades del equipo son factores contextuales: determinan cuánto puede probarse, con qué técnicas y con qué formalidad.
Cuántos de los siete principios de prueba decide aplicar el equipo en este proyecto
Los siete principios son directrices generales válidas en cualquier contexto; no se eligen uno por uno y por tanto no son un factor contextual del proceso.
La exigencia de que todo proceso de prueba alcance el 100 % de cobertura de todas las entradas posibles
No es un factor sino un concepto erróneo: la prueba exhaustiva es imposible salvo en casos triviales, por lo que ningún contexto impone tal exigencia.
Los factores contextuales incluyen las partes interesadas, las habilidades del equipo, el dominio de negocio, factores técnicos, restricciones del proyecto (tiempo, presupuesto), factores organizativos, el ciclo de vida de desarrollo empleado y las herramientas disponibles.
¿Qué significa el enfoque 'shift left' en el contexto de las pruebas?
Realizar actividades de prueba y calidad antes en el ciclo de vida
La participación temprana halla defectos antes y más barato.
Retrasar todas las pruebas hasta después del lanzamiento
Es lo opuesto a shift left.
Mover a los testers a otra oficina
Trata del momento en el ciclo, no del lugar.
Probar solo la mitad izquierda de la interfaz
No tiene que ver con el diseño de la UI.
Shift left significa realizar actividades de prueba (y calidad) antes en el ciclo de vida.
¿Qué evalúa principalmente la prueba de sistema?
El comportamiento del sistema integrado completo frente a sus requisitos
Cubre el comportamiento de extremo a extremo.
Un único módulo de forma aislada
Eso es la prueba de componentes.
Solo las interfaces entre dos componentes
Eso es la prueba de integración.
Si los usuarios finales aceptan el sistema
Eso es la prueba de aceptación.
La prueba de sistema evalúa el comportamiento del sistema integrado completo frente a sus requisitos.
Verificar que una transferencia debita y acredita los importes correctos y calcula el saldo correcto es principalmente ¿qué tipo de prueba?
Prueba funcional
Comprueba qué hace el sistema frente a requisitos funcionales.
Prueba de rendimiento
Mide velocidad/rendimiento, no la corrección de importes.
Prueba de usabilidad
Evalúa la facilidad de uso, no la corrección del cálculo.
Prueba de portabilidad
Trata de ejecutarse en distintos entornos.
Comprobar la corrección de resultados calculados es una prueba funcional.
¿Cuál es el propósito de la prueba de regresión?
Detectar efectos secundarios no deseados de un cambio
La regresión comprueba que lo que funcionaba sigue funcionando.
Verificar que una corrección concreta funcionó
Eso es la prueba de confirmación.
Medir el rendimiento del sistema bajo carga
Eso es la prueba de rendimiento.
Aceptar el sistema en nombre de los usuarios
Eso es la prueba de aceptación.
La prueba de regresión detecta efectos secundarios no deseados introducidos por cambios.
¿Cuáles DOS de los siguientes son NIVELES de prueba?
Prueba de sistema
Un nivel de prueba reconocido.
Prueba de componentes
Un nivel de prueba reconocido.
Prueba de carga
Un tipo no funcional, no un nivel.
Prueba de confirmación
Prueba de cambio, no un nivel.
La prueba de sistema y de componentes son niveles; la de carga es un tipo y la de confirmación es de cambio.
¿Cuál es la base de prueba más típica para la prueba de aceptación?
Requisitos de usuario y negocio, casos de uso y procesos de negocio
La aceptación valida la idoneidad para el uso de negocio.
El diseño de componentes de bajo nivel y el código
Es la base de la prueba de componentes.
Las especificaciones de interfaz entre módulos
Es la base de la prueba de integración.
Los archivos de configuración del pipeline de CI
No es una base típica de aceptación.
La prueba de aceptación se basa típicamente en requisitos de usuario/negocio, casos de uso y procesos de negocio.
¿Qué tipo de revisión es el MENOS formal, a menudo solo una comprobación rápida entre pares sin proceso documentado ni roles definidos?
Revisión informal
El tipo de revisión menos formal.
Inspección
El tipo más formal, con métricas y roles.
Revisión técnica
Una revisión documentada y bastante formal por pares.
Auditoría
Una evaluación formal e independiente frente a estándares.
Una revisión informal no tiene proceso documentado ni roles definidos.
¿Por qué las revisiones son especialmente rentables en un proyecto?
Hallan defectos pronto en productos antes de ejecutar código
La detección temprana evita retrabajo tardío costoso.
Se ejecutan automáticamente sin esfuerzo humano
Las revisiones requieren participación humana.
Garantizan que el producto no tendrá defectos
Ninguna actividad garantiza cero defectos.
Reemplazan todas las pruebas dinámicas
Las revisiones complementan las dinámicas.
Las revisiones hallan defectos pronto, antes de escribir/ejecutar código, reduciendo costes posteriores.
¿Cuáles DOS son roles reconocidos en una revisión formal?
Autor
El dueño del producto de trabajo revisado.
Moderador
Dirige y facilita la revisión.
El compilador
Una herramienta, no un rol.
El cliente final
No es un rol definido en la revisión.
El autor y el moderador son roles de revisión; un compilador y el cliente final no.
Entre los roles definidos para el proceso de revisión, ¿quién decide qué se va a revisar, asigna el tiempo y el presupuesto necesarios y se asegura de que la revisión encaje en el calendario del proyecto?
El gestor
Correcto — decidir qué se revisa y aportar tiempo, presupuesto y recursos es responsabilidad del gestor en el proceso de revisión.
El moderador (facilitador)
El moderador asegura que la reunión se desarrolle eficazmente y media entre participantes, pero no decide el alcance ni asigna presupuesto.
El autor
El autor crea el producto de trabajo revisado y corrige después las anomalías aceptadas. No controla el calendario ni el presupuesto.
El secretario (scribe)
El secretario recopila las anomalías de la revisión individual y registra las decisiones y los nuevos asuntos planteados en la reunión.
El gestor decide qué debe revisarse, asigna tiempo en el calendario y proporciona presupuesto y recursos. El moderador solo hace que la reunión de revisión se desarrolle eficazmente.
Un servicio de paquetería fija el nivel de envío por peso entero en kg: 1-5 pequeño, 6-20 mediano, 21-50 grande. Con partición de equivalencia solo sobre pesos VÁLIDOS, ¿cuál es el mínimo de casos para cubrir cada nivel válido una vez?
3
Un valor representativo por cada nivel válido.
2
Tres niveles válidos no se cubren con dos casos.
4
Aquí solo existen tres niveles válidos.
6
Eso cuenta los límites, no las particiones.
Tres niveles válidos (pequeño, mediano, grande) necesitan tres representantes.
Un campo acepta enteros de 1 a 30 inclusive; los valores fuera se rechazan. Con el análisis de valores límite de 2 valores (límite más vecino más cercano), ¿qué conjunto prueba AMBOS límites?
{0, 1, 30, 31}
Límite más vecino exterior en cada extremo.
{1, 30}
Solo límites, omiten vecinos.
{0, 1, 2, 29, 30, 31}
Ese es el enfoque de 3 valores.
{1, 2, 29, 30}
Usa vecinos interiores en vez de exteriores.
Cada límite (1, 30) más su vecino exterior (0, 31): {0,1,30,31}.
Para el mismo campo (enteros 1 a 30 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 {0,1,2} y superior {29,30,31} = seis valores distintos.
Use la tabla de decisión siguiente. Un miembro del programa de fidelidad que hizo check-in online llega con una maleta de 25 kg (sobre el límite de 23 kg). ¿Qué regla aplica y qué tarifa resulta?
Regla R3 - Tarifa por sobrepeso
Online S, Maleta<=23 N, Miembro S es exactamente R3.
Regla R1 - Sin tarifa
R1 requiere Maleta <= 23 = S.
Regla R4 - Sobrepeso + estándar
R4 requiere Miembro = N.
Regla R7 - Sobrepeso + estándar
R7 requiere check-in online = N.
Online = S, Maleta <= 23 = N, Miembro = S coincide con R3: Tarifa por sobrepeso.
En la tabla de decisión siguiente, las reglas R5 y R6 dan ambas 'Tarifa estándar' cuando check-in online = N y Maleta <= 23 = S, sin importar la membresía. Con simplificación 'don't-care', ¿cuántas columnas se fusionan en una sola regla?
2 (R5 y R6 se fusionan en una regla)
Ambas dan Tarifa estándar con la membresía como 'don't-care'.
4
Solo estas dos columnas comparten la misma acción bajo ese par.
8
Solo dos columnas se fusionan, no las ocho.
1
Una columna no puede 'fusionarse'; dos se fusionan en una.
R5 y R6 comparten la acción y solo difieren en una condición 'don't-care', así que 2 se fusionan en 1.
Una especificación tiene varias condiciones de entrada cuyas combinaciones llevan a distintas acciones del sistema. ¿Qué técnica de diseño cubre sistemáticamente esas combinaciones?
Prueba de tabla de decisión
Diseñada para combinaciones de condiciones con distintas acciones.
Análisis de valores límite
Apunta a los bordes de un solo rango ordenado.
Prueba de sentencias
Una técnica de caja blanca basada en código.
Prueba exploratoria
Sin guion y basada en experiencia, no cobertura sistemática.
La prueba de tabla de decisión cubre sistemáticamente combinaciones de condiciones y acciones.
Usando la máquina de estados del ticket de soporte siguiente, ¿qué secuencia de eventos es un camino VÁLIDO de New a Closed?
New -> triage -> Open -> assign -> InProgress -> resolve -> Resolved -> close -> Closed
Cada transición existe en ese orden.
New -> assign -> InProgress -> close
No hay New->assign; primero triage a Open.
New -> triage -> Open -> resolve -> Closed
Open no va directo a Resolved; hay que asignar primero.
New -> triage -> Open -> assign -> InProgress -> close -> Closed
Cerrar requiere primero el estado Resolved (resolve y luego close).
El camino válido es triage, assign, resolve, close.
Considere esta rutina con seis sentencias ejecutables: (1) INPUT a; (2) INPUT b; (3) sum = a + b; (4) IF sum > 100; (5) PRINT high; (6) PRINT sum. La sentencia 5 se ejecuta solo si el IF es verdadero. Una prueba se ejecuta con a = 10, b = 20. ¿Qué cobertura de sentencias logra?
83% (5 de 6 sentencias)
Se ejecutan 1, 2, 3, 4 y 6; se omite la 5: 5/6 ≈ 83%.
100%
La sentencia 5 (PRINT high) no se alcanza con sum = 30.
67%
Se ejecutan cinco de seis, no cuatro.
50%
Solo se omite una; se ejecutan cinco.
sum = 30, así que el IF es falso; se ejecutan 5 de 6 sentencias = 83%.
¿Cuáles DOS de los siguientes son técnicas de prueba de caja negra (basadas en especificación)?
Análisis de valores límite
Derivado de la especificación (rangos de entrada).
Prueba de tabla de decisión
Basada en combinaciones de condiciones especificadas.
Prueba de sentencias
Una técnica de caja blanca basada en código.
Prueba de ramas
Una técnica de caja blanca basada en decisiones.
El análisis de valores límite y la tabla de decisión son de caja negra; sentencias y ramas son de caja blanca.
Un tester usa una lista estándar de problemas comunes de formularios web (campos obligatorios, longitud máxima, caracteres inválidos, etc.) para guiar las pruebas. ¿Qué técnica es?
Prueba basada en listas de verificación
Guiada por una lista predefinida de elementos.
Prueba exploratoria
Sin guion y guiada por el aprendizaje, no una lista fija.
Análisis de valores límite
Una técnica sistemática sobre rangos de entrada.
Prueba de transición de estados
Basada en estados y eventos.
Usar una lista predefinida para guiar las pruebas es la prueba basada en listas de verificación.
¿Cuáles de las siguientes son técnicas de prueba basadas en la experiencia? (Elija DOS.)
Pruebas exploratorias.
Correcto: se basa en la experiencia del tester.
Conjetura de errores.
Correcto: se basa en anticipar errores probables.
Análisis de valores límite.
Incorrecto: es una técnica de caja negra (basada en especificación).
Pruebas de sentencias.
Incorrecto: es una técnica de caja blanca (basada en estructura).
Las pruebas exploratorias y la conjetura de errores son técnicas basadas en la experiencia.
¿Cuál es el propósito de los criterios de entrada de una actividad de prueba?
Definen las precondiciones que deben cumplirse antes de empezar con sentido
Evitan empezar el trabajo prematuramente.
Definen cuándo se declara terminada la actividad
Eso describe los criterios de salida.
Enumeran los defectos exactos a encontrar
Los defectos no se conocen de antemano.
Fijan los salarios de los testers
Sin relación con los criterios de entrada.
Los criterios de entrada definen las precondiciones que deben cumplirse antes de iniciar eficazmente una actividad.
Un cálculo de impuestos incorrecto en software ya entregado es un ejemplo de ¿qué tipo de riesgo?
Riesgo de producto
Concierne a la calidad del producto entregado.
Riesgo de proyecto
Afectan gestión/entrega, no directamente la calidad.
Riesgo residual
Es lo que queda tras la mitigación.
Nivel de riesgo
Es una medida, no una categoría.
Un defecto en la calidad del producto entregado es un riesgo de producto.
Tras probar las áreas de alto riesgo de un producto, ¿cómo se llama el riesgo que aún queda?
Riesgo residual
Riesgo que queda tras las actividades de reducción.
Riesgo de producto
Es la categoría, no lo que queda.
Riesgo de proyecto
Una categoría sobre la entrega, no el resto.
Probabilidad del riesgo
Es un factor del riesgo, no el resto.
El riesgo que queda tras la mitigación/pruebas es el riesgo residual.
¿Cuáles DOS son campos esenciales de un informe de defectos bien redactado?
Un identificador único y el estado actual
Permite seguir el defecto en su ciclo de vida.
Pasos para reproducir con resultado esperado y real
Permite reproducir y diagnosticar el defecto.
El pedido de almuerzo del tester
Irrelevante para un informe.
Un eslogan de marketing del lanzamiento
Irrelevante para un informe.
Un ID/estado único y los pasos para reproducir con resultado esperado/real son esenciales; los demás irrelevantes.
¿Cuál es un propósito principal del monitoreo de pruebas?
Dar visibilidad del progreso comparando el estado real con el plan
El monitoreo informa decisiones de control.
Escribir el código fuente del sistema
El monitoreo no es desarrollo.
Garantizar que el producto no tiene defectos
Ninguna actividad lo garantiza.
Reemplazar la necesidad de planificar
El monitoreo complementa la planificación.
El monitoreo da visibilidad y compara el progreso real con el plan.
Con estimación de tres puntos: optimista = 4 días, más probable = 8 días, pesimista = 18 días, ¿cuál es la duración esperada por (a + 4m + b) / 6?
9 días
(4 + 4*8 + 18)/6 = 54/6 = 9.
8 días
8 es el valor más probable, no la estimación ponderada.
10 días
No coincide con el resultado de la fórmula, que es 9.
11 días
Error aritmético; el valor correcto es 9.
(4 + 32 + 18) / 6 = 54 / 6 = 9 días.
¿Cuáles DOS de los siguientes son enfoques/estrategias de prueba reconocidos?
Prueba basada en riesgos
Asigna el esfuerzo según el riesgo del producto.
Prueba reactiva (p. ej. exploratoria)
Responde al sistema según se encuentra.
Prueba alfabética
No es un enfoque reconocido.
Prueba basada en salario
No es un enfoque reconocido.
El enfoque basado en riesgos y el reactivo (p. ej. exploratorio) son reconocidos; los otros dos no son estrategias reales.
¿Cuál de los siguientes es una técnica de estimación de pruebas reconocida?
Estimación basada en métricas con datos históricos
Un enfoque de estimación estándar y defendible.
Tomar la fecha que la dirección ya anunció
No es estimación; ignora el esfuerzo real.
Duplicar al azar lo que digan los desarrolladores
Arbitrario, no es una técnica reconocida.
Usar el número de invitaciones a reuniones abiertas
Irrelevante para la estimación.
La estimación basada en métricas (datos históricos) y la basada en expertos son técnicas reconocidas.
¿Por qué es útil gestionar los defectos mediante un ciclo de vida definido con estados como «abierto», «en curso», «corregido» y «cerrado»?
Proporciona visibilidad del estado de cada defecto y facilita la elaboración de informes y el control.
Correcto — los estados definidos hacen que el estado del defecto sea rastreable y reportable.
Garantiza que no se introducirán nuevos defectos.
Un ciclo de vida hace seguimiento de los defectos pero no puede impedir que aparezcan nuevos.
Elimina la necesidad de escribir pasos de reproducción.
Los pasos de reproducción siguen siendo necesarios independientemente del ciclo de vida.
Corrige automáticamente los defectos cuando cambian de estado.
Los cambios de estado registran el estado; no corrigen el código.
Un ciclo de vida de defectos aporta visibilidad y control: muestra el estado actual de cada defecto, facilita la priorización y permite la elaboración de informes y el análisis de tendencias.
¿Qué tipo de herramienta ayuda principalmente a crear y gestionar los datos necesarios para ejecutar pruebas?
Herramienta de preparación de datos de prueba
Crea y gestiona los conjuntos de datos usados.
Herramienta de pruebas de rendimiento
Genera carga y mide rendimiento.
Herramienta de análisis estático
Analiza el código sin ejecutarlo.
Herramienta de revisión (colaboración)
Apoya la revisión, no los datos de prueba.
Una herramienta de preparación de datos de prueba crea y gestiona los datos.
¿Cuáles DOS son beneficios reales de la automatización de pruebas?
Ejecución repetida más eficiente de las pruebas
Las máquinas ejecutan pruebas repetitivas más rápido.
Mayor consistencia y reutilización de los activos de prueba
Las pruebas automatizadas se ejecutan igual cada vez.
Las pruebas automatizadas nunca necesitan mantenimiento
Requieren mantenimiento continuo cuando el sistema cambia.
La automatización elimina la necesidad de análisis
Las pruebas igualmente deben analizarse y diseñarse.
La ejecución repetida más eficiente y la mayor consistencia/reutilización son beneficios reales; la automatización sigue necesitando mantenimiento y análisis.