ISTQB Foundation (CTFL v4.0) Examen de práctica #5 — 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 define MEJOR un defecto (bug, falta)?
Una imperfección que puede causar que no realice su función requerida.
Correcto — la definición de un defecto.
Un comportamiento incorrecto observable durante la ejecución.
Eso describe un fallo.
Una acción humana que produce un resultado incorrecto.
Eso describe un error humano.
Una condición que debe cumplirse antes de iniciar las pruebas.
Eso describe un criterio de entrada.
Un defecto es una imperfección que puede causar que un componente o sistema no realice su función requerida.
¿Cuál explica MEJOR el principio 'los defectos se agrupan'?
Un pequeño número de módulos contiene la mayoría de los defectos.
Correcto — es la agrupación de defectos.
Los defectos se distribuyen uniformemente.
Contradice la agrupación.
Las pruebas repetidas dejan de hallar defectos.
Es la paradoja del pesticida.
Las pruebas dependen del contexto.
Válido, pero no es agrupación.
Un pequeño número de módulos suele contener la mayoría de los defectos.
¿Cuál describe MEJOR la relación entre las pruebas y el aseguramiento de la calidad (QA)?
El QA está orientado al proceso; las pruebas son control de calidad que contribuye al QA.
Correcto — las pruebas apoyan el QA.
Las pruebas y el QA son lo mismo.
Están relacionadas pero son distintas.
El QA se realiza solo tras las pruebas.
El QA es trabajo continuo.
Las pruebas reemplazan el QA.
Las pruebas son una entrada, no un reemplazo.
El QA está orientado al proceso; las pruebas son control de calidad orientado al producto que contribuye al QA.
Un caso especifica precondiciones, entradas, resultados esperados y postcondiciones. ¿De qué es un ejemplo el 'resultado esperado'?
La salida prevista derivada de la base de prueba.
Correcto — provienen de un oráculo/base de prueba.
El comportamiento realmente observado.
Es el resultado real.
El hardware necesario para ejecutar la prueba.
Es parte del entorno.
El informe de defecto generado tras la prueba.
Una salida cuando difieren los resultados.
El resultado esperado es la salida prevista derivada de la base de prueba (oráculo).
¿Qué afirmación sobre 'las pruebas dependen del contexto' es CORRECTA?
El software crítico se prueba distinto y más rigurosamente que un sitio simple.
Correcto — el contexto determina cómo se prueba.
Todo software debe probarse igual.
Contradice la dependencia del contexto.
El contexto solo afecta el lenguaje.
Afecta todo el enfoque.
La dependencia del contexto permite omitir pruebas.
No justifica omitirlas.
Las pruebas varían según el contexto: el software crítico se prueba más rigurosamente.
¿Qué actividad produce casos de prueba y requisitos transformando las condiciones de prueba?
Diseño de pruebas
Correcto — convierte condiciones en casos.
Análisis de pruebas
El análisis identifica condiciones.
Ejecución de pruebas
La ejecución corre las pruebas diseñadas.
Seguimiento de pruebas
El seguimiento rastrea el progreso.
El diseño transforma condiciones en casos de prueba y otro testware.
¿Cuáles DOS son habilidades genéricas esenciales de un buen tester? (Elija dos.)
Pensamiento analítico y crítico con atención al detalle.
Correcto — habilidades centrales.
Buenas habilidades de comunicación, incluido el reporte constructivo.
Correcto — la comunicación es esencial.
La capacidad de escribir todo el código de producción.
No es una habilidad genérica.
Autoridad para aprobar el presupuesto.
Una responsabilidad de gestión.
Los buenos testers necesitan pensamiento analítico/crítico y buena comunicación.
¿Cuál es un objetivo típico de las actividades de finalización de pruebas?
Archivar el testware y capturar lecciones aprendidas.
Correcto — una actividad clave de finalización.
Diseñar los primeros casos del proyecto.
Es diseño, mucho antes.
Redactar los requisitos del sistema.
No es una actividad de prueba.
Preparar el entorno por primera vez.
Pertenece a la implementación.
La finalización incluye archivar el testware e identificar lecciones aprendidas.
En un ciclo iterativo-incremental (ágil), ¿por qué cobra importancia la regresión?
Los cambios frecuentes arriesgan romper lo que funcionaba.
Correcto — el cambio incremental impulsa la regresión.
Porque no se añaden funciones tras la primera iteración.
Se añaden continuamente.
Porque la regresión reemplaza los demás niveles.
La regresión complementa.
Porque los ciclos iterativos nunca usan automatización.
Dependen mucho de la automatización.
La funcionalidad crece y el código cambia con frecuencia, con alto riesgo de romper lo que funcionaba.
La aceptación de un producto COTS por clientes en su propio entorno se describe MEJOR como qué forma?
Prueba beta (de campo)
Correcto — por clientes en sus ubicaciones.
Prueba alfa
Es en el sitio del desarrollador.
Prueba de aceptación contractual
Verifica contra el contrato.
Prueba de aceptación operativa
Se centra en aspectos operativos.
La prueba beta (de campo) la realizan clientes en sus ubicaciones; la alfa es en el sitio del desarrollador.
¿Cuál es el enfoque PRINCIPAL de la integración de componentes frente a la prueba de componente?
Las interfaces e interacciones entre componentes.
Correcto — apunta a las interfaces.
La lógica interna de un componente aislado.
Es el enfoque de la prueba de componente.
Los procesos de negocio de extremo a extremo.
Se alinea con sistema o aceptación.
Si el sistema satisface las necesidades de negocio.
Es validación en aceptación.
La integración se centra en interfaces entre componentes; la de componente, en cada uno aislado.
Un banco debe añadir una regla fiscal por un cambio legislativo, sin otro cambio funcional. ¿Qué desencadenante de mantenimiento representa?
Una modificación por un cambio en las regulaciones.
Correcto — un desencadenante reconocido.
Mantenimiento correctivo para arreglar un fallo.
No se arregla un fallo.
Migración a una nueva plataforma.
La plataforma no cambia.
Retiro de la aplicación.
La aplicación se actualiza.
Una modificación para cumplir nuevas regulaciones es un desencadenante por cambio de reglas/entorno.
¿Cuál es el MEJOR ejemplo de una característica no funcional que se prueba?
Comprobar que usuarios no autorizados no acceden a datos protegidos.
Correcto — la seguridad es no funcional.
Verificar que el total del carrito se calcula bien.
Una prueba funcional.
Comprobar que una búsqueda devuelve resultados correctos.
Prueba funcional.
Confirmar que una corrección resolvió un defecto.
Es prueba de confirmación.
La seguridad es no funcional; comprobar que usuarios no autorizados no acceden es una prueba de seguridad.
Un sistema en operación debe modificarse y el equipo tiene que decidir cuánta prueba de mantenimiento, incluida la regresión, se requiere. ¿Qué DOS factores determinan principalmente el alcance de esa prueba? (Elija dos.)
El riesgo asociado al cambio, por ejemplo si afecta a funcionalidad crítica de negocio o a interfaces con otros sistemas.
Correcto — el riesgo es un impulsor principal: cuanto mayor sea el riesgo de las áreas cambiadas y afectadas, más prueba de mantenimiento y regresión se justifica.
El tamaño del sistema existente y el tamaño del propio cambio, según establece el análisis de impacto.
Correcto — un cambio pequeño en un sistema grande y muy acoplado puede afectar a muchas áreas; el análisis de impacto muestra qué partes y qué pruebas existentes se ven afectadas.
Si el cambio fue solicitado por el cliente o propuesto por el equipo de desarrollo.
El origen de la solicitud no altera el riesgo técnico ni las áreas afectadas. Dos cambios idénticos requieren la misma prueba, sea quien sea el solicitante.
El número de testers que estuvieron disponibles durante el proyecto de desarrollo original.
La dotación histórica no es un factor del alcance de la prueba de mantenimiento. Lo que importa es el impacto actual del cambio, determinado por el análisis de impacto y el riesgo.
El alcance de la prueba de mantenimiento depende del riesgo del cambio, del tamaño del sistema existente y del tamaño del cambio; el análisis de impacto identifica las áreas afectadas y las consecuencias para el testware existente.
¿Cuál describe MEJOR un beneficio de involucrar a los interesados en revisiones tempranas?
Construye entendimiento compartido y detecta malentendidos temprano.
Correcto — un beneficio clave.
Elimina la necesidad de pruebas dinámicas.
Las dinámicas siguen siendo necesarias.
Garantiza que los requisitos nunca cambiarán.
No congelan los requisitos.
Transfiere toda la responsabilidad a los revisores.
La responsabilidad sigue compartida.
Las revisiones tempranas crean entendimiento compartido y detectan malentendidos pronto.
¿Qué rol en una revisión formal asegura un proceso eficaz, media y programa la reunión?
El facilitador (moderador)
Correcto — conduce la revisión y media.
El autor
El autor es dueño del producto.
El revisor
Los revisores hallan defectos.
El secretario
El secretario registra hallazgos.
El facilitador (moderador) asegura la eficacia, media y suele organizarla.
Una organización debe verificar que un diseño crítico cumple estrictamente una norma, con métricas y proceso formal. ¿Qué tipo de revisión es la MÁS apropiada?
Inspección
Correcto — la más formal, con métricas.
Revisión informal
Demasiado ligera.
Recorrido (walkthrough)
Dirigido por el autor, menos formal.
Revisión ad hoc
Sin proceso ni métricas definidos.
La inspección, la más formal, sigue un proceso riguroso con roles, reglas, listas y métricas.
¿Cuál es el MEJOR ejemplo de un defecto que las herramientas de análisis estático detectan automáticamente?
Una variable usada antes de asignarle un valor.
Correcto — un hallazgo clásico.
Un tiempo de respuesta lento con 500 usuarios.
El rendimiento requiere ejecución.
Un total equivocado tras un flujo complejo.
Requiere ejecutar el sistema.
Una caída solo con un servicio externo caído.
Un fallo de ejecución/entorno.
El análisis estático detecta, p. ej., una variable usada antes de inicializarse, sin ejecutar el código.
Para la máquina de estados del ciclo de pedido siguiente, ¿cuántos casos se requieren para la cobertura 0-switch (cada transición individual válida una vez)?

6
Created->Paid, Paid->Packed, Packed->Shipped, Shipped->Delivered, Created->Cancelled, Paid->Cancelled.
4
Omite las dos transiciones de cancelación.
5
Cuenta una transición de menos.
7
Cuenta de más; hay exactamente seis.
Hay seis transiciones: pay, pack, ship, deliver, cancel (desde Created), cancel (desde Paid).
Una tienda aplica reglas según la tabla de decisión. Un cliente NO es miembro, tiene un pedido de $120 (por lo que 'Pedido >= $100' es verdadero) e introduce un código promocional válido. ¿Qué regla aplica y qué acciones resultan?

Regla R5: Envío gratis y 10% de descuento.
Correcto — F, T, T corresponde a R5.
Regla R1: Envío gratis y 10% de descuento.
R1 requiere Miembro = T.
Regla R7: solo 10% de descuento.
R7 requiere Pedido >= $100 = F.
Regla R8: ninguna acción.
R8 requiere todas falsas.
Miembro = F, Pedido >= $100 = T, Código válido = T corresponde a la regla R5: Envío gratis Y 10% de descuento.
En el grafo hay dos decisiones (nodo 2 y nodo 4). ¿Cuál es el mínimo de casos para 100% de cobertura de ramas?

3
Correcto — tres caminos cubren los cuatro resultados.
2
Dos caminos no bastan.
4
Aquí bastan 3.
1
Un camino no cubre los cuatro resultados.
Hay cuatro resultados de rama. El camino 2-falso (1-2-6-7) cubre nodo 2 falso. Para el nodo 4 se necesita nodo 2 verdadero; un camino 4 verdadero y otro 4 falso. Por tanto 3 casos.
Un retiro acepta un importe (múltiplo de 10) desde 20 hasta 500 inclusive. Con AVL en los límites (20 y 500), ¿qué par representa los dos valores límite válidos?
20 y 500
Correcto — los valores límite mínimo y máximo.
10 y 510
Justo fuera — vecinos inválidos.
0 y 1000
Muy fuera del rango.
250 y 260
Valores medios, no límites.
Los límites son el mínimo 20 y el máximo 500; el AVL prueba estos valores.
Un login bloquea la cuenta tras 3 intentos fallidos. Estados: Activo, 1Fallo, 2Fallos, Bloqueado. La contraseña correcta vuelve a Activo; la incorrecta incrementa el contador; el 3er fallo pasa a Bloqueado. ¿Cuántos casos para cobertura 0-switch?
5
Correcto — cinco transiciones válidas.
3
Cuenta solo las de fallo.
4
Omite una transición.
6
Solo hay 5 transiciones.
Transiciones válidas: Activo→1Fallo, 1Fallo→2Fallos, 2Fallos→Bloqueado, más retorno desde 1Fallo y 2Fallos = 5, por tanto 5 casos.
¿Qué comprueba típicamente un caso de 'transición inválida' en la prueba de transición de estados?
Que el sistema maneja correctamente un evento no válido en el estado actual.
Correcto — prueba el manejo robusto.
Que cada transición válida se toma una vez.
Eso es cobertura 0-switch.
Que el código logra 100% de cobertura de sentencias.
Un criterio de caja blanca.
Que se prueban valores límite en cada estado.
Es otra técnica.
La prueba negativa comprueba que el sistema maneja correctamente eventos no válidos en el estado actual.
¿Por qué elegir un diseño colaborativo (p. ej. los tres amigos) al escribir criterios de aceptación?
Para crear entendimiento compartido y criterios claros y comprobables.
Correcto — reduce ambigüedad y mejora la comprobabilidad.
Para que el tester escriba el código de producción.
Busca entendimiento compartido.
Para evitar tener que probar la historia.
Mejora las pruebas, no las elimina.
Para garantizar que la historia no tiene defectos.
Ninguna técnica lo garantiza.
Los enfoques colaborativos crean entendimiento compartido y criterios más claros y comprobables.
Un tester usa su conocimiento de defectos previos para diseñar pruebas en áreas propensas a errores (p. ej. división por cero). ¿Qué técnica se usa?
Conjetura de errores
Correcto — una técnica basada en experiencia.
Partición de equivalencia
Una técnica sistemática de caja negra.
Prueba de sentencias
Una técnica de caja blanca.
Prueba de tabla de decisión
Una técnica sistemática para combinaciones.
La conjetura de errores es una técnica basada en la experiencia que anticipa defectos probables.
Una escala asigna 0–100: A = 90–100, B = 80–89, C = 70–79, F = 0–69. Con AVL de dos valores, ¿cuántos valores límite distintos deben probarse en todo el rango (incluyendo 0 y 100)?
8
Correcto — 0, 69, 70, 79, 80, 89, 90, 100.
6
Omite 0 y 100.
4
Solo un lado de cada límite.
12
Cuenta de más; son 8.
Límites internos 69/70, 79/80, 89/90 más 0 y 100: 0, 69, 70, 79, 80, 89, 90, 100 = 8 valores.
¿Cuáles DOS afirmaciones sobre partición de equivalencia y AVL son CORRECTAS? (Elija dos.)
El AVL es una extensión de la partición centrada en los bordes.
Correcto — refina la partición.
Ambas son técnicas de caja negra (basadas en especificación).
Correcto — no requieren conocer el código.
El AVL aplica a conjuntos no ordenados como colores.
Requiere particiones ordenadas con límites.
La partición de equivalencia es de caja blanca.
La partición es de caja negra.
El AVL es una extensión de la partición centrada en los bordes; ambas son de caja negra.
¿Cuál es el propósito PRINCIPAL de medir la cobertura con técnicas de caja blanca?
Medir objetivamente cuán a fondo se ha ejercitado la estructura del código.
Correcto — indica minuciosidad y vacíos.
Demostrar que el software no tiene defectos.
El 100% de cobertura no lo demuestra.
Medir cuán rápido responde el sistema.
Eso es prueba de rendimiento.
Reemplazar las técnicas de caja negra.
Complementa la caja negra.
Mide objetivamente la minuciosidad respecto a la estructura del código.
R2 (nivel de riesgo 16)
4 × 4 = 16 es el mayor nivel de riesgo calculado, así que R2 se atiende primero.
R1 (nivel de riesgo 10)
2 × 5 = 10, inferior al 16 de R2.
R3 (nivel de riesgo 10)
5 × 2 = 10, también por debajo del 16 de R2.
R4 (nivel de riesgo 9)
3 × 3 = 9 es el más bajo, así que no es la primera prioridad.
Niveles de riesgo: R1=10, R2=16, R3=10, R4=9. R2 tiene el producto más alto (16) y se prioriza primero.
¿Cuál describe MEJOR un enfoque de prueba (estrategia) dentro de un plan de pruebas?
Cómo se realizarán las pruebas: niveles, tipos, técnicas y manejo de riesgos.
Correcto — el enfoque define el cómo.
El código fuente completo del sistema.
El código no es parte del enfoque.
Una lista de cada defecto hallado.
Son datos de defectos.
El plan de marketing del producto.
Ajeno a las pruebas.
El enfoque describe cómo se realizarán las pruebas: niveles, tipos, técnicas, criterios y manejo de riesgos.
Un jefe de pruebas estima con (a + 4m + b) / 6. Módulo X: a=2, m=5, b=14. ¿Cuál es la estimación para el Módulo X?
6 días
Correcto — 36 / 6 = 6.
7 días
Es el promedio simple.
5 días
5 es el valor más probable.
8 días
No coincide con 6.
(2 + 4×5 + 14) / 6 = 36 / 6 = 6 días.
¿Qué técnica de estimación se basa en el juicio y la experiencia de quienes harán el trabajo o de expertos?
Estimación basada en expertos (p. ej. Wideband Delphi, tres puntos).
Correcto — se apoya en el juicio experto.
Cobertura de sentencias
Un criterio de cobertura.
Análisis de valores límite
Una técnica de diseño.
Pruebas exploratorias
Una técnica de prueba, no estimación.
Las técnicas basadas en expertos se apoyan en la experiencia; p. ej. Wideband Delphi y tres puntos.
Se halló un defecto en producción. La causa raíz es un requisito ambiguo que nunca se revisó. ¿Cuál es la MEJOR acción de mejora?
Introducir o reforzar las revisiones de requisitos.
Correcto — aborda la causa raíz.
Culpar al desarrollador.
Culpar no mejora el proceso.
Dejar de publicar a producción.
No es una acción realista.
Añadir más casos para módulos no relacionados.
No aborda la causa raíz.
Introducir o reforzar las revisiones de requisitos aborda la causa raíz y evita recurrencias.
¿Cuál es un contenido típico de un informe de defecto que indica el grado en que el defecto afecta al sistema?
Severidad
Correcto — refleja el impacto en el sistema.
El número total de testers del proyecto.
Irrelevante para el impacto.
El presupuesto de marketing.
Ajeno al informe.
La versión del lenguaje de programación.
Un detalle de entorno, no el grado de impacto.
La severidad indica el grado de impacto, independiente de la urgencia (prioridad).
Un gráfico de burndown y el número de casos aprobados/fallidos por día son ejemplos de información de qué artefacto de gestión?
Un informe de progreso (o panel).
Correcto — el estado continuo aparece allí.
La especificación de requisitos.
Los requisitos son entrada.
Una especificación de un caso individual.
Describe una prueba única.
El manual de usuario.
Un documento de producto.
Los informes de progreso (y paneles) presentan información continua como estado, aprobado/fallido y burndown.
Al analizar riesgos de producto, ¿qué par de factores se usa para evaluar el nivel de cada riesgo?
Probabilidad e impacto.
Correcto — definen el nivel de riesgo.
Costo y color.
El color es irrelevante.
Tamaño del equipo y ubicación.
No definen el nivel de riesgo.
Número de casos y líneas de código.
Son métricas de tamaño.
El nivel se evalúa por su probabilidad y su impacto.
¿Cuál es la MEJOR razón para priorizar el orden de ejecución de los casos?
Para que las pruebas más importantes se ejecuten primero.
Correcto — maximiza el valor.
Para que todas las pruebas duren lo mismo.
No es el objetivo.
Para evitar diseñar casos.
Ordena pruebas ya diseñadas.
Para que el informe parezca más largo.
No es una razón válida.
Priorizar asegura que las pruebas más valiosas se ejecuten primero y se hallen defectos importantes temprano.
¿Cuál describe MEJOR una limitación al confiar en resultados de pruebas automatizadas?
Las pruebas automatizadas solo verifican lo programado y pueden omitir otros defectos.
Correcto — falsa confianza fuera de su alcance.
Siempre encuentran todos los defectos.
Ningún enfoque los encuentra todos.
Nunca requieren mantenimiento.
Requieren mantenimiento continuo.
Pueden reemplazar el juicio humano en todos los casos.
El juicio humano sigue siendo esencial.
Las pruebas automatizadas solo comprueban lo programado; la excesiva dependencia deja comportamientos sin probar.
¿Qué categoría de herramienta apoyaría MEJOR la generación de grandes volúmenes de datos de entrada realistas?
Una herramienta de preparación de datos de prueba.
Correcto — genera/manipula datos.
Una herramienta de análisis estático.
Analiza código.
Una herramienta de gestión de pruebas.
Gestiona el proceso.
Una herramienta de medición de cobertura.
Mide la cobertura.
Las herramientas de preparación de datos generan o manipulan grandes volúmenes de datos realistas.