CUESTIONARIO 01 – ISTQB FOUNDATION LEVEL 4.0

¿Por qué?

Un objetivo válido de las pruebas de software (según ISTQB y buenas prácticas) es:

👉 Reducir el riesgo y aumentar la confianza en el nivel de calidad del sistema.

Ahora veamos por qué las otras opciones no son correctas:

a) Demostrar que no hay defectos sin corregir
❌ Incorrecto. Las pruebas no pueden demostrar la ausencia total de defectos, solo pueden mostrar que existen defectos si se encuentran.

b) Demostrar que no habrá fallos en producción
❌ Incorrecto. Es imposible garantizar que un sistema no fallará nunca en producción, ya que siempre existen escenarios no previstos.

d) Verificar que no hay combinaciones de entradas no probadas
❌ Incorrecto. Probar todas las combinaciones posibles suele ser inviable (pruebas exhaustivas no son posibles en la mayoría de los sistemas).

¿Por qué?

Las actividades de prueba que contribuyen al éxito son aquellas que:

Se realizan de forma temprana.

Involucran a los probadores a lo largo de todo el SDLC.

Ayudan a prevenir y detectar defectos en productos de trabajo (requisitos, diseño, código, etc.).

La opción a) refleja exactamente esto:
👉 Involucrar a los probadores durante varias actividades del SDLC permite detectar defectos antes, cuando son más baratos y fáciles de corregir.

Por qué las otras opciones NO son correctas

b) No molestar a los desarrolladores mientras codifican
❌ Incorrecto. La colaboración entre roles es clave; evitar la comunicación no mejora la calidad, la empeora.

c) Colaborar con usuarios finales para mejorar informes de defectos en integración y sistema
❌ Incorrecto. Los usuarios finales normalmente no participan en la mejora de informes de defectos en estos niveles de prueba; eso corresponde al equipo de pruebas.

d) Los probadores certificados diseñan mejores casos que los no certificados
❌ Incorrecto. La certificación no garantiza mejor calidad; la experiencia y el contexto son igual o más importantes.

¿Por qué?

Usamos Partición de Equivalencia (PE), cuyo objetivo es:
👉 cubrir cada clase de equivalencia válida al menos una vez, con el mínimo número de casos de prueba.

1. Identificación de clases de equivalencia
Piso (3 clases válidas)

Planta baja

Primer piso

Segundo piso o superior

Tipo de jardín (3 clases válidas)

Sin jardín

Jardín pequeño

Jardín grande

⚠️ Restricción importante:
👉 Solo la planta baja puede tener jardín
El sistema no permite combinaciones inválidas, así que solo consideramos combinaciones válidas.

2. Construcción de casos mínimos válidos

Necesitamos cubrir:

Los 3 tipos de piso

Los 3 tipos de jardín

Casos de prueba mínimos

Planta baja + jardín pequeño
✔ Cubre: planta baja, jardín pequeño

Planta baja + jardín grande
✔ Cubre: jardín grande

Primer piso + sin jardín
✔ Cubre: primer piso, sin jardín

Segundo piso o superior + sin jardín
✔ Cubre: segundo piso o superior

👉 Con estos 4 casos:

Todos los pisos están cubiertos

Todos los tipos de jardín están cubiertos

Todas las combinaciones son válidas

3. Por qué no menos de 4

Con 3 casos, no es posible cubrir las 3 clases de piso y las 3 de jardín respetando la restricción.

5 o 6 serían válidos, pero no mínimos.

¿Por qué?

Las técnicas de prueba basadas en la experiencia (como exploratory testing, error guessing y checklists) se caracterizan porque:

👉 dependen en gran medida del conocimiento, la intuición y la experiencia del probador, tanto sobre el software como sobre el dominio del negocio.

Esto es exactamente lo que describe la opción c).

Por qué las otras opciones NO son correctas

a) Casos de prueba basados en información detallada de diseño
❌ Describe técnicas basadas en especificación, no en experiencia.

b) Medir cobertura usando elementos de código de la interfaz
❌ Corresponde a técnicas basadas en la estructura (caja blanca).

d) Identificar desviaciones de los requisitos
❌ Describe el objetivo de técnicas basadas en especificación, no las basadas en experiencia.

¿Por qué?

Según ISTQB, los factores que contribuyen al éxito de las revisiones están relacionados con:

La organización y preparación de la revisión.

El tamaño y complejidad del producto de trabajo.

La actitud objetiva hacia los defectos, no hacia las personas.

Analicemos cada opción:

a) Los participantes deben dedicar tiempo adecuado a la revisión.

✔ Sí es un factor de éxito
La falta de tiempo es una causa común de revisiones ineficaces.

b) Dividir productos grandes en partes más pequeñas.

✔ Sí es un factor de éxito
Reduce la carga cognitiva y aumenta la eficacia de la revisión.

c) Evitar comportamientos que indiquen aburrimiento, irritación u hostilidad.

❌ NO es un factor de éxito según ISTQB, sino una regla de conducta o recomendación de comportamiento.
No se considera un factor clave del proceso, sino una norma social deseable.

d) Reconocer y tratar los defectos de manera objetiva.

✔ Sí es un factor de éxito
ISTQB indica explícitamente que los defectos deben ser reconocidos, apreciados y tratados objetivamente.

¿Por qué?

Analicemos las características dadas y veamos con qué tipo de revisión ISTQB encajan mejor:

Características clave del escenario

✔ Existe un escriba

✔ El propósito principal es evaluar la calidad

✔ La reunión es dirigida por el autor

✔ Hay preparación individual

✔ Se produce un informe de revisión

Por qué NO las otras opciones

a) Revisión informal ❌
No suele tener roles formales, preparación ni informe.

c) Revisión técnica ❌
Normalmente es dirigida por un moderador, no por el autor.

d) Inspección ❌
Es la más formal y siempre la dirige un moderador, nunca el autor.

¿Por qué?

La retroalimentación temprana y frecuente permite detectar problemas cuanto antes, especialmente malentendidos en los requisitos, cuando aún son fáciles y baratos de corregir.

La opción d) lo expresa directamente:

✔ Ayuda a evitar malentendidos en los requisitos.

Análisis de las otras opciones

a) Mejora el proceso de prueba para proyectos futuros
❌ Esto es más propio de retrospectivas y mejora continua, no del beneficio principal de la retroalimentación temprana.

b) Obliga a los clientes a priorizar requisitos según riesgos
❌ La retroalimentación no obliga; la priorización es una actividad de gestión.

c) Es la única forma de medir la calidad de los cambios
❌ Incorrecto. No es la única forma de medir calidad.

¿Por qué?

Las pruebas estáticas (revisiones, inspecciones, análisis estático) tienen como objetivo detectar defectos lo antes posible, lo que reduce costos, no lo contrario.

La opción a) dice:

“facilidad de detectar defectos más tarde en el SDLC”

❌ Esto es incorrecto y contradice el beneficio principal de las pruebas estáticas, que es detectar defectos temprano, no tarde.
Por eso NO es un beneficio de las pruebas estáticas.

Análisis de las otras opciones

b) Corregir defectos encontrados durante pruebas estáticas es menos costoso
✔ Correcto. Detectar defectos temprano suele ser mucho más barato que hacerlo durante pruebas dinámicas o en producción.

c) Encontrar defectos de codificación no detectados por pruebas dinámicas
✔ Correcto. El análisis estático puede detectar problemas como código muerto, violaciones de estándares o complejidad excesiva.

d) Detectar lagunas e inconsistencias en los requisitos
✔ Correcto. Las revisiones estáticas son muy eficaces para encontrar problemas en requisitos antes de que se escriba código.

¿Por qué?

Veamos qué ejecuciones corresponden a pruebas de regresión, según ISTQB:

1. CP2 en la Ejecución 2 (5)

✔ Prueba de regresión
CP2 pasó en la Ejecución 1 (2) y se vuelve a ejecutar en la Ejecución 2 para verificar que los cambios realizados no hayan introducido nuevos defectos en una funcionalidad que ya funcionaba.

2. CP1 en la Ejecución 3 (7)

✔ Prueba de regresión
CP1 pasó en la Ejecución 2 (4) y se vuelve a ejecutar en la Ejecución 3 para confirmar que las correcciones aplicadas no rompieron el criterio de aceptación ya validado.

¿Por qué?

Veamos cada tipo de falla y el nivel de prueba donde mejor se detecta según ISTQB:

1. Fallas en el comportamiento del sistema respecto a las necesidades comerciales

✔ Pruebas de aceptación (D)
Estas pruebas validan que el sistema cumple con las necesidades del negocio y del usuario final.

2. Fallas en la comunicación entre componentes

✔ Pruebas de integración de componentes (B)
Este nivel se centra en verificar interfaces, intercambio de datos y comunicación entre componentes.

3. Fallas en la lógica en un módulo

✔ Pruebas de componentes (A)
Las pruebas de componente detectan errores internos, como lógica incorrecta dentro de un módulo individual.

4. Fallas en la implementación incorrecta de reglas comerciales

✔ Pruebas de sistema (C)
En este nivel se verifica el sistema completo frente a los requisitos funcionales y reglas de negocio, pero aún desde una perspectiva técnica (no de aceptación del usuario).

¿Por qué?

El propósito principal de las retrospectivas es inspeccionar y adaptar el proceso, identificando qué funcionó bien, qué no y qué se puede mejorar en el siguiente ciclo.

La opción c) lo expresa claramente:

👉 Las debilidades del proceso identificadas durante la retrospectiva pueden ser analizadas y servir como una lista de tareas pendientes para el programa de mejora continua de la organización.

Este es exactamente el valor práctico y organizacional que un gerente espera escuchar.

Por qué las otras opciones NO son adecuadas

a) Son populares y los clientes lo apreciarían
❌ Argumento débil y subjetivo; la popularidad no justifica un cambio de proceso.

b) Ahorrarán dinero porque los usuarios finales no dan retroalimentación inmediata
❌ Incorrecto y confuso; las retrospectivas no sustituyen la retroalimentación de usuarios.

d) Abarcan valores como coraje y respeto
❌ Aunque es cierto en marcos ágiles (como Scrum), no es un argumento convincente para la gerencia desde el punto de vista del negocio.

¿Por qué?

El enfoque “shift left” (desplazamiento hacia la izquierda) consiste en realizar actividades de prueba lo antes posible dentro del SDLC, especialmente antes de que el software esté completamente implementado, con el objetivo de detectar defectos tempranamente.

Análisis de cada opción

a) Revisar los requisitos del usuario antes de que sean formalmente aceptados
✅ Sí es shift left.
Revisar requisitos de forma temprana es un ejemplo clásico de desplazamiento a la izquierda.

b) Escribir una prueba de componente antes de escribir el código
✅ Sí es shift left.
Esto es un ejemplo claro de TDD, que es una práctica típica de shift left.

c) Ejecutar una prueba de eficiencia de rendimiento para un componente durante las pruebas de componentes
✅ También es shift left.
Las pruebas no funcionales (como rendimiento) realizadas antes de niveles tardíos son un ejemplo de desplazamiento a la izquierda.

d) Escribir un guión de prueba antes de establecer el proceso de gestión de configuración
❌ NO es shift left.
Esto no adelanta actividades de prueba dentro del SDLC, sino que describe una mala secuencia organizativa sin relación con la detección temprana de defectos.

¿Por qué?

El ATDD (Acceptance Test-Driven Development) se caracteriza porque:

👉 las pruebas de aceptación se definen antes del desarrollo y se usan para guiar la implementación del software.

Eso es exactamente lo que describe la opción c):

“En ATDD, se crean pruebas basadas en criterios de aceptación para guiar el desarrollo del software relacionado.”

Esta definición coincide directamente con la de ISTQB.

Por qué las otras opciones NO son la mejor respuesta

a) Uso del formato Given/When/Then
❌ No es exclusivo de ATDD.
Ese formato es típico de BDD, no un requisito de ATDD.

b) Casos de prueba a nivel de componentes y orientados al código
❌ Describe más bien TDD, no ATDD.
ATDD se centra en el nivel de aceptación, no en componentes.

d) Pruebas basadas en el comportamiento deseado y fáciles de entender
❌ Esto también describe BDD.
Aunque ATDD puede tener este efecto, no es su definición principal.

¿Por qué?

La regla:

“Para cada actividad del ciclo de vida del desarrollo de software (SDLC) existe una actividad de prueba correspondiente”

es un principio fundamental de ISTQB y se aplica a todos los modelos de SDLC, independientemente de cómo estén organizados.

Explicación por modelo de SDLC

Modelos secuenciales (ej. cascada, V-Model)
✔ Claramente visible: cada fase de desarrollo tiene una fase de prueba correspondiente (requisitos ↔ pruebas de aceptación, diseño ↔ pruebas de sistema, etc.).

Modelos iterativos
✔ En cada iteración se realizan actividades de desarrollo y actividades de prueba correspondientes.

Modelos incrementales
✔ Cada incremento desarrollado se verifica y valida mediante pruebas.

Aunque en modelos ágiles estas actividades no estén separadas formalmente, siguen existiendo.

Por qué las otras opciones son incorrectas

a), b), c) ❌
Limitan la regla a ciertos modelos, cuando en realidad es universal.

¿Por qué?

El enfoque de equipo completo (Whole Team Approach) promueve la colaboración estrecha entre todos los roles: negocio, desarrollo y pruebas, con el objetivo común de asegurar la calidad.

En particular, la interacción entre probadores y representantes del negocio se refleja en que:

👉 Los probadores ayudan al negocio a crear pruebas de aceptación claras, correctas y comprobables, asegurando que los requisitos sean entendidos y verificables.

Esto es típico en enfoques ágiles, por ejemplo mediante criterios de aceptación, BDD o ejemplos concretos (example mapping).

Por qué las otras opciones NO son correctas

a) Los representantes del negocio deciden sobre automatización de pruebas
❌ La automatización es una decisión técnica, no del negocio.

b) Los probadores ayudan a definir la estrategia de pruebas
❌ Aunque los probadores contribuyen, la estrategia de pruebas es principalmente responsabilidad de la gestión de pruebas, no del negocio.

c) El negocio no forma parte del enfoque de equipo completo
❌ Justamente lo contrario: el negocio sí forma parte del enfoque de equipo completo.

¿Por qué?

Según ISTQB, las habilidades más importantes de un probador combinan conocimiento, colaboración y pensamiento analítico. Analicemos cada punto:

Análisis de las habilidades

i. Tener conocimiento del dominio
✅ Importante. Permite entender el contexto del negocio, identificar riesgos relevantes y diseñar mejores pruebas.

ii. Crear una visión del producto
❌ No es una habilidad clave del probador. Esto corresponde principalmente a roles como Product Owner o negocio.

iii. Ser un buen jugador de equipo
✅ Muy importante. ISTQB enfatiza la colaboración y el whole team approach.

iv. Planificar y organizar el trabajo del equipo
❌ Propio de roles de gestión (Test Manager, Team Lead), no del probador.

v. Pensamiento crítico
✅ Fundamental. Es una de las habilidades centrales del probador para analizar requisitos, detectar riesgos y encontrar defectos.

¿Por qué?

Según ISTQB, el rol de probador se centra en actividades relacionadas con la preparación, ejecución y seguimiento de las pruebas, incluyendo el entorno y el reporte del estado de las pruebas.

Análisis de cada opción

a. Configurar entornos de prueba
✅ Correcta. El probador es responsable de preparar y verificar que los entornos de prueba sean adecuados para ejecutar las pruebas.

b. Mantener la pila (backlog) del producto
❌ Incorrecta. Es responsabilidad del Product Owner.

c. Diseñar soluciones para nuevos requisitos
❌ Incorrecta. Corresponde principalmente a desarrolladores y arquitectos.

d. Crear el plan de pruebas
❌ Incorrecta. Es una tarea de gestión de pruebas (Test Manager / Test Lead).

e. Informar sobre la cobertura alcanzada
✅ Correcta. El probador realiza el seguimiento y reporta la cobertura de pruebas (requisitos, riesgos, etc.).

¿Por qué?

El proceso de prueba está fuertemente influenciado por factores que afectan cómo, cuándo, qué y con qué profundidad se prueba. Analicemos cada factor:

Análisis de cada factor

i. El ciclo de vida del desarrollo de software (SDLC)
✔ Influencia significativa
El modelo de desarrollo (ágil, en cascada, incremental, DevOps, etc.) determina cuándo se prueban los artefactos, el nivel de formalidad y el tipo de actividades de prueba.

ii. El número de defectos detectados en proyectos anteriores
❌ No tiene una influencia directa significativa en el proceso de prueba actual.
Es información histórica útil, pero no define el proceso de prueba.

iii. Los riesgos de producto identificados
✔ Influencia significativa
El enfoque de pruebas basado en riesgos determina qué se prueba primero, con más profundidad o con más técnicas.

iv. Nuevos requisitos regulatorios obligatorios
✔ Influencia significativa
Pueden requerir pruebas adicionales, mayor documentación, trazabilidad y tipos específicos de pruebas.

v. El número de probadores certificados en la organización
❌ No influye directamente en el proceso de prueba. La certificación no determina el proceso, sino las competencias individuales.

¿Por qué?

El análisis de pruebas se centra en:

Analizar la base de pruebas (requisitos, historias de usuario, criterios de aceptación).

Identificar qué se debe probar.

Detectar condiciones de prueba y riesgos.

La opción b) encaja exactamente con esto:

👉 “Decidir que el equipo debe probar si es posible compartir adecuadamente el pago entre varios usuarios”
Esto implica analizar la funcionalidad de pago, interpretar los requisitos y definir una condición de prueba relevante.

Por qué las otras opciones NO corresponden al análisis de pruebas

a) Estimar que probar la integración llevará 8 días-persona
❌ Esto es planificación de pruebas, no análisis.

c) Utilizar BVA para derivar datos de prueba
❌ Esto pertenece al diseño de pruebas, ya que se están creando datos y casos de prueba.

d) Analizar discrepancias tras ejecutar un caso y reportar un defecto
❌ Esto es parte de la ejecución de pruebas y gestión de defectos, no del análisis.

¿Por qué?

El principio de “las pruebas se desgastan” establece que:

👉 Si se ejecutan los mismos casos de prueba repetidamente, con el tiempo dejan de encontrar nuevos defectos, incluso aunque el sistema siga cambiando.

En tu escenario:

El sistema evoluciona de forma incremental.

Los casos de prueba de regresión no se han actualizado durante varias iteraciones.

No aparecen nuevos defectos de regresión.

Esto genera una falsa sensación de seguridad, lo que explica tu escepticismo.

Por lo tanto, es necesario revisar, actualizar y añadir nuevos casos de prueba para seguir siendo efectivos.

Por qué las otras opciones no aplican

b) Falacia de la ausencia de errores
❌ Se refiere a que un sistema sin defectos detectados puede no satisfacer las necesidades del usuario. No es el foco del problema aquí.

c) Los defectos se agrupan
❌ Indica que la mayoría de los defectos se concentran en pocas áreas, lo cual no explica la falta de nuevos defectos encontrados.

d) Las pruebas exhaustivas son imposibles
❌ Es un principio general, pero no explica directamente el problema de casos de prueba obsoletos.

Un riesgo clásico de la automatización es que:

• Los scripts requieren mantenimiento continuo

• Si no se asigna tiempo, personas o presupuesto, el conjunto de pruebas:

  • Se vuelve obsoleto

  • Falla con frecuencia

  • Pierde valor

Esto está explícitamente reconocido por ISTQB como un riesgo clave.

Por qué las otras opciones NO son correctas

a) Puede introducir regresiones desconocidas en producción
❌ Eso es un riesgo del software, no específico de la automatización de pruebas.

c) Las herramientas de prueba y el conjunto de pruebas asociado pueden no ser suficientemente confiables
❌ Las herramientas pueden fallar, pero no es el riesgo principal identificado por ISTQB; el problema real suele ser el mantenimiento.

d) Puede reducir el tiempo asignado para las pruebas manuales
❌ Esto es normalmente un beneficio, no un riesgo.

🧠 Regla para el examen

Cuando preguntan por riesgos de automatización, piensa primero en:
coste, mantenimiento, esfuerzo y sostenibilidad

Una herramienta de preparación de datos se usa para crear, seleccionar, anonimizar o cargar datos de prueba antes y durante la ejecución de las pruebas.

Eso la vincula directamente con la fase en la que las pruebas se ponen en marcha.

Análisis de opciones

a) Monitoreo y control de pruebas
❌ Se centra en métricas, progreso y seguimiento, no en datos.

b) Análisis y diseño de pruebas
❌ Aquí se definen condiciones y casos, no se preparan datos reales.

c) Implementación y ejecución de pruebas
✅ Correcta.
La preparación de datos:

• Es parte de la implementación (crear y configurar datos)

• Apoya la ejecución de los casos de prueba

d) Finalización de pruebas
❌ Se trata de cierre y reportes.

Analicemos las opciones:

a) Resultado esperado y resultado real
❌ Ya están incluidos:

• Resultado real: la aplicación se bloquea

• Resultado esperado: debería aceptar la entrada y crear el usuario

b) Referencias y estado del defecto
❌ Hay referencias (TC-1305, REQ-0012) y estado (“Rechazado”).

c) Entorno de prueba e ítem de prueba
✅ Correcta.
Falta información como:

• Versión de la aplicación / build

• Sistema operativo

• Navegador / plataforma

• Configuración del entorno

Sin esto, reproducir el problema es difícil o imposible, aunque el defecto sea real.

d) Prioridad y gravedad
❌ La prioridad ya se menciona (“alta prioridad”) y la gravedad no explica problemas de reproducibilidad.

La gestión de configuración se encarga de:

• Controlar versiones de artefactos (incluidos scripts de prueba automatizados)

• Registrar cambios

• Mantener el historial y la integridad en el repositorio de pruebas

Actualizar un script para cumplir un nuevo requisito implica crear una nueva versión, lo cual es exactamente responsabilidad de la gestión de configuración.

Descarte de las otras opciones

• a) Gestión de trazabilidad ❌ → Relaciona requisitos con pruebas, no gestiona versiones.

• b) Pruebas de mantenimiento ❌ → Describe cuándo se prueban cambios, no cómo se versionan los scripts.

• d) Ingeniería de requisitos ❌ → Trata de definir y gestionar requisitos, no scripts de prueba.

✅ Respuesta correcta

c) Gestión de configuración

La herramienta que muestra cuánto trabajo se ha completado y cuánto trabajo queda en una iteración es el gráfico de quemado.

Análisis rápido

• a) Criterios de aceptación ❌
  Definen cuándo una historia está “terminada”, no muestran progreso.

• b) Informe de defectos ❌
  Muestra defectos, no el trabajo restante de la iteración.

• c) Informe de finalización de pruebas ❌
  Resume resultados al final, no el progreso continuo.

• d) Gráfico de quemado (Burndown chart) ✅
  Visualiza:

  • Trabajo total

  • Trabajo restante día a día

  • Progreso de la iteración

La mitigación del riesgo consiste en reducir la probabilidad y/o el impacto del riesgo mediante acciones preventivas.

En el escenario dado:

• Se identificó un riesgo de rendimiento (tiempo de respuesta demasiado largo).

• La respuesta propuesta incluye:

  • Pruebas de rendimiento por un equipo independiente.

  • Pruebas de aceptación alfa y beta con usuarios finales antes de la entrega.

Estas acciones están orientadas a detectar y reducir el riesgo antes de que ocurra en producción, lo cual es característico de la mitigación, no de la aceptación, transferencia ni contingencia.

Descarte rápido

• a) Aceptación ❌ → No se toman acciones preventivas.

• b) Plan de contingencia ❌ → Se actuaría después de que el riesgo ocurra.

• d) Transferencia ❌ → No se transfiere el riesgo a un tercero (por ejemplo, seguro o proveedor).

✅ Respuesta correcta

c) Mitigación del riesgo

Según el modelo de Cuadrantes de Pruebas Ágiles (ISTQB), la relación correcta es:

Mapeo correcto

• Pruebas de usabilidad → Q3
  Orientadas al negocio, críticas al producto
  ➜ 1 → C

• Pruebas de componentes → Q1
  Orientadas a la tecnología, apoyan al equipo de desarrollo
  ➜ 2 → A

• Pruebas funcionales → Q2
  Orientadas al negocio, apoyan al equipo de desarrollo
  ➜ 3 → B

• Pruebas de fiabilidad (rendimiento, estabilidad, etc.) → Q4
  Orientadas a la tecnología, críticas al producto
  ➜ 4 → D

✅ Respuesta correcta

a) 1C, 2A, 3B, 4D

Primero hay que respetar las dependencias, y solo después usar la prioridad para decidir el orden.

1️⃣ Analicemos dependencias

• TC001 → no tiene dependencia → debe ejecutarse primero

• TC002 → depende de TC001

• TC003 → depende de TC002

• TC004 → depende de TC002

• TC005 → depende de TC002

2️⃣ Orden posible respetando dependencias y prioridades

Paso 1:
Solo es ejecutable:

• TC001 (prioridad 3)
  👉 1.º TC001

Paso 2:
Ahora es ejecutable:

• TC002 (prioridad 2)
  👉 2.º TC002

Paso 3:
Ahora son ejecutables:

• TC003 (prioridad 1)

• TC004 (prioridad 2)

• TC005 (prioridad 3)

El número más pequeño = mayor prioridad, así que se elige:

👉 TC003

Para la estimación de tres puntos (método PERT, usado por ISTQB), la fórmula es:

Donde:

• O = Optimista = 2

• M = Más probable = 11

• P = Pesimista = 14

Cálculo:

Criterios de salida (exit criteria)

Son condiciones para decidir que las pruebas pueden finalizar, por ejemplo:

• Nivel aceptable de defectos

• Objetivos de prueba alcanzados (cobertura, calidad, etc.)

Análisis de las opciones

a) El entorno de prueba está listo
❌ Criterio de entrada, no de salida.

b) La capacidad de iniciar sesión en el objeto de prueba por parte del probador
❌ También criterio de entrada.

c) Se alcanza la densidad de defectos estimada
✅ Correcto.
Un nivel aceptable de defectos es un criterio clásico de salida.

d) Los requisitos se traducen al formato Given/When/Then
❌ Actividad de refinamiento / preparación, no de salida.

e) Las pruebas de regresión están automatizadas
✅ Aceptable como criterio de salida, ya que indica que se ha alcanzado un objetivo de calidad y estabilidad del sistema antes de finalizar las pruebas (especialmente en contextos ágiles).

La pregunta es típica de ISTQB Agile y pide cómo aportan valor los probadores en la planificación de la iteración y la entrega.

Analicemos las opciones:

a) Los probadores determinan la prioridad de las historias de usuario que se deben desarrollar.
❌ No es responsabilidad del probador; la prioridad la define el Product Owner.

b) Los probadores se centran únicamente en los aspectos funcionales del sistema que se va a probar.
❌ Incorrecto: los probadores también consideran aspectos no funcionales (riesgos, usabilidad, rendimiento, etc.).

c) Los probadores participan en la identificación detallada de riesgos y la evaluación de riesgos de las historias de usuario.
✅ Correcta.
Una contribución clave de los probadores en la planificación es:

• Identificar riesgos

• Evaluar su impacto y probabilidad

• Ayudar a planificar pruebas y esfuerzo en función del riesgo

d) Los probadores aseguran la entrega del software de alta calidad mediante un diseño temprano de pruebas durante la planificación de la entrega.
❌ Está formulada de manera demasiado absoluta (“aseguran”) y mezcla planificación de entrega con ejecución; además, la pregunta se centra en planificación de iteración y entrega, donde el rol distintivo del probador es la gestión del riesgo.

Clave de ATDD

Una prueba ATDD debe:

• Derivarse de los criterios de aceptación

• Validar comportamiento funcional esperado

• No introducir funcionalidades nuevas

Evaluación de opciones

a) probar si el editor puede guardar el documento después de eliminar el contenido de la página
⚠️ No menciona “eliminar contenido” en los criterios, pero sí valida explícitamente:

• que el editor

• puede guardar cambios

➡️ Es una variación válida de un criterio existente.

b) probar si el propietario de contenido puede iniciar sesión y realizar actualizaciones en el contenido
❌ El foco de la historia es el Editor, no el propietario.
La reasignación es secundaria, no el comportamiento principal.

c) probar si el editor puede programar la publicación del contenido editado
❌ Programar publicación no aparece en los criterios.

d) probar si el editor puede reasignar a otro editor para realizar actualizaciones
❌ El criterio habla de reasignar al rol de “propietario de contenido”, no a otro editor.

La pregunta pide la mejor forma de documentar los criterios de aceptación, especialmente en el contexto ágil (historias de usuario).

Análisis de las opciones

a) Realizando retrospectivas…
❌ Las retrospectivas sirven para mejorar el proceso, no para documentar criterios de aceptación.

b) Utilizando el formato Given/When/Then para describir una condición de prueba de ejemplo relacionada con una historia de usuario dada.
✅ Correcta.
Este es el formato típico de criterios de aceptación en enfoques ágiles y BDD:

• Given (contexto)

• When (acción)

• Then (resultado esperado)

c) Utilizando la comunicación verbal…
❌ La comunicación verbal no es documentación y aumenta el riesgo, no lo reduce.

d) Documentando los riesgos… en un plan de pruebas…
❌ Los riesgos no son criterios de aceptación.

La situación describe:

• Aplicación completamente nueva

• Poco tiempo (las pruebas empiezan tarde)

• Requisitos incompletos

• Tester con buen conocimiento del dominio y habilidades analíticas

• Dirección quiere resultados rápidos

Esto encaja exactamente con pruebas exploratorias.

Análisis de las opciones

a) Pruebas basadas en listas de comprobación
❌ Requieren listas previamente definidas (normalmente derivadas de requisitos o experiencia previa estructurada).

b) Predicción de errores
❌ Útil, pero es una técnica puntual; no proporciona de forma integral resultados rápidos y estructurados en ausencia de requisitos.

c) Pruebas exploratorias
✅ La mejor opción.
Según ISTQB:

• Se diseñan y ejecutan simultáneamente

• No dependen de requisitos completos

• Aprovechan el conocimiento del dominio

• Producen resultados tempranos

• Ideales cuando hay presión de tiempo

d) Pruebas de rama
❌ Técnica de caja blanca que requiere código estable y no sirve para mostrar resultados funcionales rápidos.

El concepto de “predicción de errores” (error guessing) en pruebas de software, según ISTQB, se basa en usar la experiencia previa con defectos típicos para anticipar dónde pueden aparecer errores.

Analicemos las opciones:

a) La predicción de errores implica utilizar tu conocimiento y experiencia de los defectos encontrados en el pasado y los errores típicos cometidos por los desarrolladores.
✅ Correcta.
Esta es prácticamente la definición de error guessing: apoyarse en experiencia, listas de defectos comunes y conocimiento del dominio.

b) La predicción de errores implica utilizar tu experiencia personal en el desarrollo y los errores que cometiste como desarrollador.
❌ Demasiado limitada: no se basa solo en errores personales, sino en experiencia colectiva y patrones conocidos.

c) La predicción de errores requiere que imagines que eres el usuario del objeto de prueba y predigas los errores que el usuario podría cometer al interactuar con él.
❌ Esto describe más bien pruebas de usabilidad / pruebas basadas en el usuario, no error guessing.

d) La predicción de errores requiere que dupliques rápidamente la tarea de desarrollo para identificar el tipo de errores que un desarrollador podría cometer.
❌ No forma parte del concepto de error guessing.

a) Durante las pruebas de caja blanca se considera toda la implementación del software.
✅ Verdadero — la caja blanca se basa en la estructura interna.

b) Las métricas de cobertura de caja blanca pueden ayudar a identificar pruebas adicionales para aumentar la cobertura del código.
✅ Verdadero — uso típico de la cobertura.

c) Las técnicas de prueba de caja blanca se pueden utilizar en pruebas estáticas.
✅ Verdadero — mediante walkthroughs, dry run, inspecciones del código, etc., sin ejecutar el programa.

d) Las pruebas de caja blanca pueden ayudar a identificar omisiones en la implementación de los requisitos.
❌ NO es cierto — detectar omisiones de requisitos es propio de pruebas basadas en especificación (caja negra).
La caja blanca verifica cómo está implementado el código, no qué requisitos faltan.

• Por qué las otras son falsas:
  • b) No es cierto; añadir pruebas no asegura automáticamente la cobertura si no son las adecuadas.
  • c) Falso; la cobertura de caminos es una medida mucho más estricta que la de sentencias.
  • d) Falso; esto es cobertura exhaustiva de entradas, imposible en la mayoría de casos. 

Analicemos el diagrama de estados y contemos las transiciones válidas.

🔹 Estados

• INICIO

• MODO DEPURACIÓN

• EN OPERACIÓN

• EN ESPERA

• APAGADO

🔹 Transiciones válidas (7 en total)

1. INICIO → MODO DEPURACIÓN (probar)

2. INICIO → EN OPERACIÓN (ejecutar)

3. MODO DEPURACIÓN → APAGADO

4. EN OPERACIÓN → MODO DEPURACIÓN (error)

5. EN OPERACIÓN → EN ESPERA (pausa)

6. EN ESPERA → EN OPERACIÓN (continuar)

7. EN ESPERA → APAGADO (terminado)

🔹 Objetivo

Cada caso de prueba:

• Debe comenzar en INICIO

• Debe finalizar en APAGADO

• Entre todos, deben cubrir todas las transiciones

🔹 Conjunto mínimo de casos de prueba

TC1
INICIO → MODO DEPURACIÓN → APAGADO
(cubre 1, 3)

TC2
INICIO → EN OPERACIÓN → EN ESPERA → APAGADO
(cubre 2, 5, 7)

TC3
INICIO → EN OPERACIÓN → EN ESPERA → EN OPERACIÓN → MODO DEPURACIÓN → APAGADO
(cubre 2, 5, 6, 4, 3)

👉 No es posible cubrir en un solo camino porque son rutas excluyentes.

Revisión de las opciones

• R2 (Miembro, plazo no vencido, no es 15.º alquiler)
  ✔ Situación perfectamente posible.

• R4 (Miembro, plazo no vencido, 15.º alquiler)
  ✔ Posible (miembro fiel y puntual).

• R6 (No miembro, plazo no vencido, no es 15.º alquiler)
  ✔ Posible (cliente ocasional).

• R8 (No miembro, plazo vencido, 15.º alquiler)
  ❌ Imposible, porque:

  • Un no miembro no puede llegar a su “15.º alquiler”, ya que el conteo de alquileres está ligado al programa de membresía.

• • Frontera 1 (Reprobado/Suficiente): Valores 50 y 51.
  • Frontera 2 (Suficiente/Satisfactorio): Valores 60 y 61.
  • Frontera 3 (Satisfactorio/Bueno): Valores 70 y 71.
  • Frontera 4 (Bueno/Muy Bueno): Valores 80 y 81.
  • Frontera 5 (Muy Bueno/Excelente): Valores 90 y 91.
  • Límites Extremos: Valores 0 (con su adyacente -1) y 100 (con su adyacente 101). 

1. 1. 50 (TC2) - Cubierto
   2. 51 - Faltante
   3. 60 (TC4) - Cubierto
   4. 61 - Faltante
   5. 70 (TC5) - Cubierto
   6. 71 - Faltante
   7. 80 (TC6) - Cubierto
   8. 81 (TC3) - Cubierto
   9. 90 - Faltante
   10. 91 (TC1) - Cubierto
   11. 0 - Faltante
   12. 100 - Faltante