ISTQB Foundation (CTFL v4.0) Examen de práctica #8 — 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 de los siguientes NO es uno de los siete principios de prueba definidos en el programa ISTQB Foundation?
Las pruebas exhaustivas garantizan un producto sin defectos
Opción correcta: esto NO es un principio. El principio real dice lo contrario — las pruebas exhaustivas son imposibles salvo en casos triviales.
Las pruebas muestran la presencia, no la ausencia, de defectos
Es un principio real de ISTQB, por lo que no es la respuesta.
Los defectos se agrupan
Es un principio real (agrupación de defectos), por lo que no es la respuesta.
Las pruebas dependen del contexto
Es un principio real, por lo que no es la respuesta.
Un equipo ejecuta pruebas principalmente para generar confianza en la calidad de una versión antes de entregarla. ¿Qué objetivo de prueba ilustra MEJOR esto?
Generar confianza en el nivel de calidad del objeto de prueba
Correcto: ganar confianza en la calidad es un objetivo de prueba explícitamente indicado.
Demostrar que el software no contiene defectos
Incorrecto: las pruebas nunca pueden probar la ausencia de defectos.
Eliminar la necesidad de revisar los requisitos
Incorrecto: las pruebas dinámicas no sustituyen las revisiones estáticas de requisitos.
Garantizar el cronograma del proyecto
Incorrecto: las pruebas informan decisiones pero no garantizan cronogramas.
Un desarrollador comete un error de escritura en una condición. El código defectuoso se ejecuta después y el programa muestra un resultado incorrecto al usuario. En la terminología ISTQB, ¿cómo se llama el resultado incorrecto mostrado al usuario?
Un fallo
Correcto: el comportamiento incorrecto observado externamente es un fallo.
Un error (humano)
Incorrecto: el error fue la acción humana (el tipeo), no el resultado visible.
Un defecto
Incorrecto: el defecto es la falla en el propio código, no su efecto observado.
Una causa raíz
Incorrecto: la causa raíz es la razón subyacente, no el resultado visible.
¿Qué afirmación distingue MEJOR las pruebas de la depuración?
Las pruebas pueden provocar fallos causados por defectos; la depuración localiza, analiza y corrige esos defectos
Correcto: las pruebas revelan fallos, la depuración localiza y elimina el defecto subyacente.
Pruebas y depuración son dos nombres de la misma actividad
Incorrecto: son actividades distintas con objetivos diferentes.
La depuración la realizan solo los testers, nunca los desarrolladores
Incorrecto: la depuración suele ser una actividad de los desarrolladores.
Las pruebas corrigen defectos mientras la depuración solo los reporta
Incorrecto: esto invierte los roles de ambas actividades.
¿Por qué son necesarias las pruebas? Seleccione DOS afirmaciones que describan correctamente una contribución de las pruebas.
Las pruebas reducen el riesgo de que ocurran fallos en operación
Correcto: una razón central de las pruebas es reducir el riesgo del producto en operación.
Las pruebas pueden ayudar a cumplir requisitos contractuales o legales y normas
Correcto: el cumplimiento de contratos, leyes y normas es una razón reconocida para probar.
Las pruebas demuestran que el software es completamente correcto
Incorrecto: las pruebas no pueden probar la corrección total.
Las pruebas eliminan la necesidad de procesos de aseguramiento de la calidad
Incorrecto: las pruebas son parte del control de calidad y complementan, no reemplazan, el aseguramiento.
Un conjunto de pruebas que hace un año encontraba muchos defectos ahora rara vez encuentra nuevos, aunque el producto sigue cambiando. ¿Qué principio lo explica y cuál es la respuesta recomendada?
La paradoja del pesticida — revisar y actualizar las pruebas, y añadir nuevas
Correcto: repetir las mismas pruebas deja de encontrar defectos nuevos; deben revisarse y actualizarse.
Agrupación de defectos — dejar de probar las áreas modificadas
Incorrecto: la agrupación no justificaría dejar de probar las áreas modificadas.
Pruebas exhaustivas — ejecutar todas las pruebas posibles
Incorrecto: las pruebas exhaustivas son imposibles y no son la explicación.
Las pruebas dependen del contexto — cambiar el entorno de prueba
Incorrecto: la dependencia del contexto no se relaciona con la pérdida de eficacia con el tiempo.
Un sistema pasa todas sus pruebas y contiene muy pocos defectos, pero los usuarios lo rechazan porque no satisface sus necesidades reales. ¿Qué principio ilustra esta situación?
La falacia de ausencia de errores
Correcto: un sistema casi sin defectos puede aun así no satisfacer las necesidades de los usuarios.
Probar pronto ahorra tiempo y dinero
Incorrecto: este principio trata de cuándo empezar a probar, no de la idoneidad para el usuario.
Los defectos se agrupan
Incorrecto: la agrupación describe la distribución de defectos, no la idoneidad de uso.
Las pruebas dependen del contexto
Incorrecto: la dependencia del contexto no explica el rechazo de un sistema sin defectos.
Durante el análisis y el diseño de pruebas, un equipo define atributos medibles del objeto de prueba que deben ejercitarse, para poder informar después de la cobertura como porcentaje. En terminología ISTQB, ¿cómo se llaman esos atributos?
Elementos de cobertura
Correcto — los elementos de cobertura son los atributos medibles derivados de las condiciones de prueba y la base para expresar la cobertura en porcentaje.
Condiciones de prueba
Las condiciones de prueba indican qué aspectos del objeto deben probarse. Los elementos de cobertura se derivan de ellas y son lo que realmente se cuenta y mide.
Criterios de salida
Los criterios de salida son las condiciones para decidir si la prueba puede terminar. Un objetivo de cobertura puede formar parte de ellos, pero no son los atributos medibles del objeto.
Datos de prueba
Los datos de prueba son los valores que necesita un caso al ejecutarse. Apoyan las pruebas, pero no expresan cuánto del objeto se ha ejercitado.
Los elementos de cobertura son los atributos medibles derivados de las condiciones de prueba; la cobertura se expresa como el porcentaje de elementos de cobertura ejercitados por las pruebas ejecutadas.
En un ciclo de vida secuencial (modelo en V), ¿qué nivel de prueba está más estrechamente asociado con la especificación de requisitos del sistema?
Pruebas de sistema
Correcto: en el modelo en V, las pruebas de sistema se derivan de y verifican la especificación de requisitos del sistema.
Pruebas de componente
Incorrecto: las pruebas de componente se relacionan con el diseño detallado, no con los requisitos del sistema.
Pruebas de integración de componentes
Incorrecto: este nivel se relaciona con el diseño técnico/arquitectónico.
Pruebas de aceptación
Incorrecto: la aceptación se asocia con requisitos de negocio y necesidades del usuario, no con la especificación de requisitos del sistema.
Un tester comprueba si una nueva función de informes devuelve totales correctos para varios conjuntos de datos de entrada. ¿Qué tipo de prueba se realiza?
Pruebas funcionales
Correcto: verificar lo que hace el sistema (totales correctos) frente a requisitos funcionales es prueba funcional.
Pruebas no funcionales
Incorrecto: las pruebas no funcionales cubren cómo de bien funciona el sistema (p. ej., rendimiento), no la corrección de los resultados.
Pruebas de caja blanca
Incorrecto: esto describe una base de prueba (estructura del código), no el objetivo de verificar totales calculados.
Pruebas de confirmación
Incorrecto: la prueba de confirmación vuelve a ejecutar pruebas tras una corrección, lo cual no se describe aquí.
Después de entregar la corrección de un defecto, un tester primero vuelve a ejecutar exactamente la prueba que falló, y luego ejecuta un conjunto de pruebas que antes pasaban alrededor del área modificada. ¿Cuáles son estas dos actividades, en orden?
Prueba de confirmación, luego prueba de regresión
Correcto: la confirmación verifica la corrección; la regresión comprueba que no se introdujeron defectos en otra parte.
Prueba de regresión, luego prueba de confirmación
Incorrecto: el orden está invertido; primero se confirma la corrección.
Reprueba, luego prueba de mantenimiento
Incorrecto: 'reprueba' es sinónimo de confirmación, pero la segunda actividad es regresión, no prueba de mantenimiento.
Prueba de humo, luego prueba de confirmación
Incorrecto: una prueba de humo es una verificación amplia, no la reejecución dirigida de la prueba fallida.
¿Qué situación desencadenaría típicamente una prueba de mantenimiento?
Migrar un sistema en producción a una nueva plataforma operativa
Correcto: la migración de un sistema en operación es un desencadenante reconocido de la prueba de mantenimiento.
Escribir pruebas unitarias para un componente nuevo durante el desarrollo inicial
Incorrecto: esto es prueba de componente durante el desarrollo, no mantenimiento.
Definir criterios de aceptación antes de empezar a programar
Incorrecto: es una actividad de prueba temprana, sin relación con el mantenimiento de un sistema existente.
Revisar el documento de requisitos en busca de ambigüedades
Incorrecto: esto es prueba estática, no prueba de mantenimiento.
¿Qué DOS afirmaciones describen características de las pruebas en un enfoque de desarrollo ágil/iterativo?
Las actividades de prueba ocurren en cada iteración, integradas con el desarrollo
Correcto: en enfoques iterativos las pruebas son continuas e integradas, no una fase final.
Las pruebas de regresión automatizadas son importantes para seguir el ritmo de los cambios frecuentes
Correcto: las iteraciones frecuentes hacen valiosas las pruebas de regresión automatizadas para gestionar el cambio.
Todas las pruebas se posponen hasta después de la iteración final
Incorrecto: posponer todas las pruebas contradice la naturaleza iterativa y continua de ágil.
La documentación de pruebas debe ser siempre más formal que en los modelos secuenciales
Incorrecto: ágil suele usar documentación más ligera, no más formal.
Un equipo adopta un enfoque de 'shift-left' en las pruebas. ¿Qué significa esto principalmente?
Realizar las actividades de prueba antes en el ciclo de vida
Correcto: shift-left significa adelantar las actividades de prueba, p. ej., revisar requisitos y escribir pruebas antes de terminar el código.
Mover todas las pruebas a un equipo dedicado después del lanzamiento
Incorrecto: esto es lo contrario de shift-left.
Reducir el número total de pruebas para ahorrar tiempo
Incorrecto: shift-left se refiere al momento de probar, no a reducir la cantidad de pruebas.
Probar solo los módulos del lado izquierdo de la arquitectura
Incorrecto: shift-left no tiene que ver con la disposición espacial de los módulos.
¿Cuáles DOS de los siguientes son beneficios de las pruebas estáticas? (Elija dos.)
Detectar y corregir defectos antes y de forma más económica.
Encontrar defectos en productos de trabajo tempranos reduce el coste de corregirlos.
Encontrar defectos difíciles de exponer mediante pruebas dinámicas.
Las revisiones pueden detectar requisitos ambiguos o código inalcanzable que la ejecución puede pasar por alto.
Medir el tiempo de respuesta real del sistema en ejecución.
Medir el comportamiento en ejecución requiere pruebas dinámicas.
Demostrar que el software no tiene defectos pendientes.
Ninguna técnica puede probar la ausencia de defectos.
Las pruebas estáticas detectan defectos pronto (más baratos de corregir) y pueden encontrar defectos difíciles de revelar con pruebas dinámicas, como código inalcanzable o requisitos inconsistentes.
¿Cuál es un beneficio clave de las pruebas estáticas frente a las dinámicas?
Los defectos pueden encontrarse pronto, antes de ejecutar el código
Correcto: las pruebas estáticas examinan productos de trabajo sin ejecución, permitiendo detección muy temprana.
Mide el rendimiento del sistema en tiempo de ejecución
Incorrecto: el rendimiento en ejecución requiere pruebas dinámicas.
Solo puede aplicarse al código fuente
Incorrecto: las pruebas estáticas se aplican a muchos productos de trabajo, no solo al código.
Garantiza que no puedan ocurrir defectos de integración
Incorrecto: las pruebas estáticas no pueden garantizar la ausencia de defectos de integración.
Una revisión se realiza siguiendo un procedimiento documentado, con roles definidos, un moderador capacitado, preparación individual con listas de verificación y métricas formales de defectos encontrados. ¿Qué tipo de revisión es?
Inspección
Correcto: un proceso formal con roles, moderador capacitado, preparación y métricas es característico de una inspección.
Revisión informal
Incorrecto: una revisión informal no tiene proceso, roles ni métricas definidos.
Recorrido (walkthrough)
Incorrecto: un walkthrough lo dirige el autor y es menos formal, sin métricas obligatorias ni moderación capacitada.
Revisión ad hoc
Incorrecto: la revisión ad hoc no tiene preparación, procedimiento ni roles.
En una revisión formal, ¿quién es responsable de dirigirla, planificarla y asegurar que se siga el procedimiento?
El facilitador (moderador)
Correcto: el facilitador/moderador dirige la revisión, la planifica y asegura que se siga el proceso.
El autor
Incorrecto: el autor crea y corrige el producto de trabajo, pero no dirige la revisión.
El secretario (scribe)
Incorrecto: el secretario registra los hallazgos, no dirige la revisión.
El revisor
Incorrecto: los revisores identifican problemas, pero no dirigen ni planifican la revisión.
Un no socio realiza un pedido de 40 $ y selecciona envío urgente. Según la tabla de decisión siguiente, ¿qué tarifa de envío aplica el sistema?
15 $
No socio, pedido menor de 50 $, envío urgente: coincide con la regla R7, cuya acción es 15 $.
10 $
10 $ es la regla R3 o R5, que requieren socio o pedido >= 50 $.
8 $
8 $ es la regla R8, que solo aplica sin envío urgente.
5 $
5 $ corresponde a reglas sin envío urgente (R4/R6), no a esta combinación.
Member? = No, Order >= $50? = No (40 $), Express shipping? = Sí → regla R7 → 15 $.
Submitted → Screening → Interview → Offer → Hired (4 transiciones)
Es la única ruta que llega a Hired y usa cuatro transiciones.
Submitted → Screening → Offer → Hired (3 transiciones)
No existe transición directa Screening → Offer; no se puede omitir Interview.
Submitted → Interview → Offer → Hired (3 transiciones)
Submitted va primero solo a Screening; no hay transición Submitted → Interview.
Submitted → Screening → Interview → Offer → Declined → Hired (5 transiciones)
Declined es un estado final sin transición saliente, así que no puede llevar a Hired.
El único camino a Hired es Submitted →(review) Screening →(pass) Interview →(pass) Offer →(accept) Hired = 4 transiciones.
En la máquina de estados del reproductor, el estado actual es Playing. ¿Qué evento sería una transición INVÁLIDA (no definida) desde Playing?
play
Correcto — no hay transición 'play' saliendo de Playing.
pause
Incorrecto — 'pause' es una transición válida Playing→Paused.
stop
Incorrecto — 'stop' es una transición válida Playing→Stopped.
Tanto pause como stop
Incorrecto — ambos son transiciones válidas desde Playing.
Desde Playing solo están definidos 'pause' (→Paused) y 'stop' (→Stopped). 'play' no tiene transición desde Playing, es inválida.
Un formulario web acepta un campo 'cantidad' para un pedido en línea. La especificación dice: la cantidad debe ser un entero de 1 a 99; los valores de 0 o menos se rechazan con el mensaje 'el mínimo es 1'; los valores de 100 o más con 'el máximo es 99'; las entradas no enteras se rechazan como inválidas. Usando partición de equivalencia, ¿cuántas particiones de equivalencia existen para el campo cantidad y cuál es el número MÍNIMO de casos de prueba para cubrir cada partición una vez?
4 particiones, 4 casos de prueba
Correcto: enteros válidos 1–99, enteros ≤0, enteros ≥100 y no enteros = 4 particiones; cubrir cada una una vez requiere 4 casos.
3 particiones, 3 casos de prueba
Incorrecto: omite la partición separada de no enteros (inválidos).
2 particiones, 2 casos de prueba
Incorrecto: solo cuenta 'válido' e 'inválido' sin separar los distintos comportamientos inválidos.
4 particiones, 8 casos de prueba
Incorrecto: cubrir cada partición una vez requiere un caso por partición, es decir 4, no 8.
Un campo acepta un porcentaje entero válido de 0 a 100 inclusive. El equipo aplica análisis de valores límite de dos valores (probando cada valor límite y el valor justo fuera de él). Considerando los límites inferior y superior, ¿qué conjunto de valores de entrada debe seleccionarse?
-1, 0, 100, 101
Correcto: la BVA de dos valores prueba cada límite (0 y 100) más el valor adyacente fuera (-1 y 101).
0, 50, 100
Incorrecto: 50 es un valor medio de la partición y faltan los valores justo fuera del límite.
-1, 1, 99, 101
Incorrecto: se omiten los valores límite reales 0 y 100; 1 y 99 no son los límites.
-1, 0, 1, 99, 100, 101
Incorrecto: esto es BVA de tres valores; la BVA de dos valores no incluye 1 y 99.
La tabla de decisión siguiente especifica un motor de preaprobación de préstamos (T = condición verdadera, F = falsa, – = indiferente, X = acción ejecutada). Examine la tabla y responda: un solicitante tiene 25 años, una puntuación crediticia de 720, un ingreso mensual de 4000 y un préstamo existente. ¿Qué regla aplica y cuál es la acción resultante?
Regla R4 — Rechazar
Correcto: las cuatro condiciones verdaderas (edad, puntuación, ingreso) con préstamo existente = R4, acción Rechazar.
Regla R5 — Aprobar tasa estándar
Incorrecto: R5 requiere NO tener préstamo existente (C4 = F); aquí C4 = T.
Regla R6 — Aprobar tasa premium
Incorrecto: R6 también requiere no tener préstamo existente; el préstamo existente la descarta.
Regla R3 — Rechazar
Incorrecto: R3 requiere ingreso menor a 3000 (C3 = F); aquí el ingreso es 4000, así que C3 = T.
Lectura de la tabla: C1 (edad ≥ 18) = T, C2 (puntuación ≥ 700) = T, C3 (ingreso ≥ 3000) = T, C4 (préstamo existente) = T. Coincide con la regla R4, cuya acción es 'Rechazar'.
¿Qué técnica de prueba de caja negra es MÁS apropiada cuando el comportamiento de un sistema depende de combinaciones de varias condiciones de entrada independientes, cada una verdadera o falsa?
Prueba de tabla de decisión
Correcto: las tablas de decisión capturan sistemáticamente combinaciones de condiciones y sus acciones.
Análisis de valores límite
Incorrecto: la BVA se centra en los bordes de rangos ordenados, no en combinaciones de condiciones booleanas.
Prueba de transición de estados
Incorrecto: la prueba de transición de estados modela eventos y estados en el tiempo, no combinaciones estáticas de condiciones.
Prueba de sentencias
Incorrecto: la prueba de sentencias es una técnica de caja blanca basada en el código, no en combinaciones de condiciones.
¿Qué afirmación sobre las técnicas de prueba de caja blanca (basadas en la estructura) es correcta?
La cobertura mide en qué medida la estructura del código ha sido ejercitada por las pruebas
Correcto: la cobertura estructural (p. ej., sentencias, ramas) cuantifica cuánto código se ejecutó.
El 100% de cobertura de ramas garantiza la ausencia de todos los defectos
Incorrecto: una alta cobertura reduce el riesgo pero nunca garantiza un producto sin defectos.
Las técnicas de caja blanca no requieren conocimiento del código
Incorrecto: las técnicas de caja blanca se basan en la estructura interna del código.
Lograr 100% de cobertura de sentencias siempre implica 100% de cobertura de ramas
Incorrecto: la cobertura de ramas es más fuerte; la cobertura total de sentencias puede dejar ramas sin cubrir.
Un tester experimentado, basándose en el conocimiento de defectos que suelen ocurrir en aplicaciones similares, introduce deliberadamente campos vacíos, cadenas muy largas y caracteres especiales para provocar fallos. ¿Qué técnica basada en la experiencia es esta?
Conjetura de errores
Correcto: anticipar errores probables y diseñar entradas para exponerlos es conjetura de errores.
Análisis de valores límite
Incorrecto: la BVA es una técnica sistemática de caja negra basada en bordes, no en la experiencia.
Prueba de tabla de decisión
Incorrecto: las tablas de decisión modelan combinaciones de condiciones, no conjeturas intuitivas.
Prueba de sentencias
Incorrecto: la prueba de sentencias es una técnica de caja blanca basada en la cobertura de código.
¿Qué descripción caracteriza MEJOR las pruebas exploratorias?
El diseño, la ejecución y el aprendizaje ocurren simultáneamente, a menudo guiados por un acta de prueba
Correcto: las pruebas exploratorias entrelazan aprendizaje, diseño y ejecución, a menudo con tiempo limitado y un acta.
Todos los casos de prueba están totalmente guionizados y documentados antes de ejecutar
Incorrecto: eso describe las pruebas guionizadas, lo opuesto a las exploratorias.
Es una técnica basada en la estructura que requiere acceso al código fuente
Incorrecto: las pruebas exploratorias se basan en la experiencia, no en la estructura.
Solo pueden realizarlo herramientas automatizadas
Incorrecto: las pruebas exploratorias son ante todo una actividad humana basada en habilidad.
¿Qué base de prueba se utiliza MÁS directamente para derivar pruebas con la técnica de prueba de casos de uso?
Casos de uso que describen interacciones actor-sistema, incluyendo flujos principal y alternativos
Correcto: la prueba de casos de uso deriva pruebas del flujo básico y de los flujos alternativos/excepción.
El grafo de flujo de control del código fuente
Incorrecto: esa es la base de las técnicas de caja blanca, no de la prueba de casos de uso.
Una lista de particiones de equivalencia para un solo campo de entrada
Incorrecto: eso apoya la partición de equivalencia, no la prueba de casos de uso.
Un diagrama de transición de estados de modos internos
Incorrecto: esa es la base de la prueba de transición de estados.
¿Cuál de los siguientes se documenta típicamente en un plan de pruebas?
Los objetivos, el alcance, el enfoque y los criterios de entrada/salida de las pruebas
Correcto: un plan de pruebas describe objetivos, alcance, enfoque, cronograma, recursos y criterios de entrada/salida.
El código fuente exacto de cada corrección
Incorrecto: el código fuente no forma parte de un plan de pruebas.
El presupuesto de marketing para el lanzamiento
Incorrecto: los presupuestos de marketing no se relacionan con un plan de pruebas.
Las evaluaciones de desempeño personal de los testers
Incorrecto: las evaluaciones de desempeño de RR. HH. no forman parte de un plan de pruebas.
Un equipo acuerda que las pruebas de sistema no pueden empezar hasta que el build se despliegue en el entorno de prueba y pase una prueba de humo. ¿Cómo se clasifican MEJOR estas condiciones?
Criterios de entrada
Correcto: las condiciones que deben cumplirse antes de iniciar una actividad de prueba son criterios de entrada.
Criterios de salida
Incorrecto: los criterios de salida definen cuándo puede detenerse la prueba, no cuándo empezar.
Condiciones de prueba
Incorrecto: una condición de prueba es un elemento a verificar, no una precondición para iniciar.
Requisitos de datos de prueba
Incorrecto: son puertas de entorno/calidad, no requisitos de datos.
Un jefe de pruebas estima el esfuerzo para probar una función con la técnica de tres puntos (PERT). La estimación más optimista es 5 días, la más probable 8 días y la más pesimista 17 días. Usando la fórmula E = (a + 4m + b) / 6, ¿cuál es el esfuerzo estimado?
9 días
Correcto: (5 + 4×8 + 17) / 6 = (5 + 32 + 17) / 6 = 54 / 6 = 9 días.
10 días
Incorrecto: es el promedio simple (5+8+17)/3 = 10, no la estimación PERT ponderada.
8 días
Incorrecto: 8 es solo el valor más probable, sin la ponderación optimista y pesimista.
11 días
Incorrecto: 54/6 = 9, no 11; recalcule la suma ponderada.
¿Cuál de los siguientes es un riesgo de PRODUCTO y no un riesgo de proyecto?
El módulo de pago podría calcular mal el impuesto en ciertas condiciones
Correcto: un posible fallo del software para cumplir una necesidad de calidad es un riesgo de producto.
Un tester clave podría dejar el equipo a mitad del proyecto
Incorrecto: los problemas de personal son un riesgo de proyecto, no de producto.
La entrega del entorno de prueba podría retrasarse
Incorrecto: un retraso de entrega es un riesgo de proyecto.
El presupuesto para herramientas podría recortarse
Incorrecto: un recorte de presupuesto es un riesgo de proyecto (gestión).
Un equipo usa pruebas basadas en riesgos. Cuatro riesgos de producto se calificaron por probabilidad (L) e impacto (I), cada uno en escala 1–5, con nivel de riesgo = L × I: – R1: L=2, I=5 – R2: L=4, I=4 – R3: L=5, I=2 – R4: L=3, I=3 Con tiempo limitado, ¿a qué riesgo se debe dedicar primero el MAYOR esfuerzo de prueba?
R2 (nivel de riesgo 16)
Correcto: R2 = 4×4 = 16, el más alto frente a R1=10, R3=10, R4=9, por lo que se prioriza primero.
R1 (nivel de riesgo 10)
Incorrecto: R1 = 2×5 = 10, menor que el 16 de R2.
R3 (nivel de riesgo 10)
Incorrecto: R3 = 5×2 = 10, igual que R1 pero por debajo de R2.
R4 (nivel de riesgo 9)
Incorrecto: R4 = 3×3 = 9, el nivel de riesgo más bajo de los cuatro.
¿Qué información es ESENCIAL en un informe de defecto bien redactado para que el desarrollador pueda reproducir el problema?
Pasos para reproducir, más los resultados esperado y real
Correcto: los pasos de reproducción con resultado esperado vs real son esenciales para diagnosticar y corregir.
La opinión del tester sobre quién tiene la culpa
Incorrecto: asignar culpas no es útil ni parte de un buen informe de defecto.
Una conjetura de la línea exacta de código que está mal
Incorrecto: una línea de código especulativa no es necesaria y puede confundir; importan los detalles de reproducción.
El número total de defectos encontrados ese día
Incorrecto: los totales diarios son una métrica, no información para reproducir un defecto concreto.
¿Cuáles DOS de los siguientes son métricas de monitoreo de pruebas de uso común?
Porcentaje de casos de prueba planificados ejecutados
Correcto: el progreso de ejecución de casos de prueba es una métrica de monitoreo estándar.
Número de defectos encontrados, corregidos y aún abiertos
Correcto: el conteo y estado de defectos se usan ampliamente para monitorear el progreso y la calidad.
El número de escritorios en la sala del equipo de pruebas
Incorrecto: esto es irrelevante para el monitoreo de pruebas.
Los pasatiempos personales de los desarrolladores
Incorrecto: los pasatiempos de los desarrolladores no son una métrica de prueba.
¿Por qué es importante la gestión de la configuración para apoyar las pruebas?
Garantiza que el testware y los objetos de prueba estén identificados de forma única, versionados y sean trazables
Correcto: la gestión de configuración controla la identidad y versiones de los elementos de prueba y testware, haciendo reproducibles los resultados.
Corrige automáticamente todos los defectos encontrados
Incorrecto: la gestión de configuración no corrige defectos.
Elimina la necesidad de un plan de pruebas
Incorrecto: la gestión de configuración complementa, no reemplaza, la planificación.
Garantiza una cobertura de prueba del 100%
Incorrecto: la gestión de configuración no influye en los niveles de cobertura.
¿Qué DOS afirmaciones describen correctamente el valor y la limitación de las pruebas independientes?
Los testers independientes pueden reconocer fallos distintos a los del autor por partir de otras suposiciones
Correcto: la independencia aporta una perspectiva fresca que ayuda a revelar defectos que el autor podría pasar por alto.
La independencia puede causar barreras de comunicación y aislamiento del equipo de desarrollo
Correcto: un inconveniente reconocido es la menor colaboración y una posible dinámica de 'nosotros contra ellos'.
Las pruebas independientes garantizan que no queden defectos en el producto
Incorrecto: ninguna forma de prueba puede garantizar un producto sin defectos.
Los desarrolladores son incapaces de encontrar defectos en su propio trabajo
Incorrecto: los desarrolladores sí encuentran defectos en su trabajo; la independencia es complementaria, no un reemplazo.
Un equipo quiere una herramienta que ejecute automáticamente scripts de prueba pregrabados contra la aplicación y compare las salidas reales con los resultados esperados. ¿Qué categoría de herramienta es esta?
Herramienta de ejecución de pruebas
Correcto: las herramientas de ejecución ejecutan pruebas guionizadas y comparan resultados reales con esperados.
Herramienta de análisis estático
Incorrecto: el análisis estático examina el código sin ejecutarlo.
Herramienta de gestión de pruebas
Incorrecto: las herramientas de gestión organizan artefactos e informes, no la ejecución y comparación de scripts.
Herramienta de pruebas de rendimiento
Incorrecto: las herramientas de rendimiento generan carga y miden la respuesta, no comparan salidas funcionales de scripts.
¿Cuáles DOS son riesgos o costes reales de introducir la automatización de pruebas que los equipos deben prever?
Se requiere esfuerzo continuo para mantener los scripts automatizados a medida que cambia la aplicación
Correcto: el mantenimiento de las pruebas automatizadas es un coste real y recurrente, fácil de subestimar.
Las expectativas sobre los beneficios pueden ser poco realistas, y la configuración inicial exige tiempo y habilidades
Correcto: las expectativas demasiado optimistas y la inversión inicial en habilidades y configuración son riesgos reconocidos.
La automatización siempre elimina la necesidad de testers humanos
Incorrecto: la automatización apoya a los testers pero no elimina la necesidad de pruebas y criterio humanos.
Las pruebas automatizadas garantizan encontrar más defectos que las manuales en todos los casos
Incorrecto: la automatización destaca en la repetición pero no garantiza encontrar más defectos que pruebas manuales hábiles.