ISTQB Foundation (CTFL v4.0) Examen de práctica #7 — 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.
Un equipo de pruebas informa: «Todas las pruebas planificadas pasaron.» Un gerente concluye que el software no tiene defectos. ¿Qué principio de prueba demuestra que esta conclusión es errónea?
Las pruebas muestran la presencia de defectos, no su ausencia.
Correcto — las pruebas superadas no pueden probar la ausencia de todos los defectos.
Las pruebas exhaustivas son imposibles.
Cierto como principio, pero trata el esfuerzo de prueba, no la conclusión falsa de 'sin defectos'.
Las pruebas se desgastan (paradoja del pesticida).
Se refiere a repetir las mismas pruebas, no a probar la ausencia de defectos.
Los defectos se agrupan.
Describe la distribución desigual de defectos, no los límites de las pruebas superadas.
Las pruebas pueden mostrar la presencia de defectos pero no pueden probar su ausencia; las pruebas superadas reducen el riesgo pero no garantizan un producto sin defectos.
Un desarrollador interpreta mal un requisito y programa la fórmula de descuento incorrecta. El código se publica; un usuario ve luego un total incorrecto en pantalla. En términos ISTQB, ¿qué es el total incorrecto que ve el usuario?
Un fallo.
Correcto — un fallo es la manifestación de un defecto durante la ejecución.
Un error (equivocación).
El error fue la mala interpretación del requisito, no el resultado en pantalla.
Un defecto.
El defecto es la fórmula incorrecta en el código; el total incorrecto visible es su efecto.
Una causa raíz.
La causa raíz es la razón subyacente del error, no el resultado visible.
La equivocación es un error; la fórmula incorrecta en el código es un defecto; el total incorrecto visible durante la ejecución es un fallo.
¿Cuál de los siguientes es un objetivo típico de las pruebas?
Proporcionar información a las partes interesadas para apoyar decisiones.
Correcto — un objetivo central de las pruebas es informar decisiones sobre calidad y riesgo.
Garantizar que el producto esté completamente libre de defectos.
Imposible — las pruebas no pueden probar la ausencia de defectos.
Eliminar la necesidad de revisiones de requisitos.
Las pruebas dinámicas complementan, pero no reemplazan, las revisiones estáticas.
Atribuir la culpa de los defectos a los desarrolladores.
Las pruebas no buscan culpables; la psicología de las pruebas favorece la comunicación constructiva.
Los objetivos típicos incluyen prevenir defectos, encontrar defectos, generar confianza, proporcionar información para decisiones y verificar/validar contra los requisitos.
En un proyecto, el 80% de los defectos se encuentran en dos de diez módulos. El jefe de pruebas decide concentrar pruebas adicionales en esos dos módulos. ¿Qué principio de prueba respalda esta decisión?
Los defectos se agrupan.
Correcto — la mayoría de los defectos se concentran en pocos módulos.
Las pruebas tempranas ahorran tiempo y dinero.
Principio válido, pero trata del momento, no de dónde se concentran los defectos.
Las pruebas dependen del contexto.
Relevante en general, pero no explica el enfoque en módulos con muchos defectos.
Falacia de la ausencia de defectos.
Advierte que un sistema sin defectos aún puede no cumplir necesidades; no trata la agrupación.
Agrupación de defectos: un pequeño número de módulos suele contener la mayoría de los defectos, por lo que concentrar el esfuerzo allí es eficaz.
¿Cuáles DOS de los siguientes forman parte de la actividad del proceso de prueba «análisis de prueba»? (Seleccione DOS.)
Analizar la base de prueba para identificar características comprobables.
Correcto — parte central del análisis de prueba.
Definir y priorizar las condiciones de prueba.
Correcto — las condiciones de prueba son un resultado del análisis de prueba.
Diseñar y priorizar casos de prueba concretos.
Eso pertenece al diseño de prueba, no al análisis.
Ejecutar casos de prueba y registrar resultados.
Eso es la ejecución de prueba, una actividad posterior.
Preparar el entorno de prueba y los datos de prueba.
Eso es parte de la implementación de prueba.
El análisis de prueba determina 'qué probar' analizando la base de prueba para identificar características comprobables y definir/priorizar condiciones de prueba.
¿Qué afirmación describe MEJOR la diferencia entre pruebas y aseguramiento de la calidad (QA)?
El QA está orientado al proceso (prevenir defectos); las pruebas al producto (encontrar defectos).
Correcto — refleja la distinción estándar.
Pruebas y QA son sinónimos intercambiables.
Están relacionados pero son disciplinas distintas.
Las pruebas están orientadas al proceso; el QA solo encuentra defectos en el código.
Esto invierte las definiciones correctas.
El QA solo se hace tras el lanzamiento; las pruebas solo antes.
Ambos ocurren a lo largo del ciclo de vida.
El QA está orientado al proceso y se centra en prevenir defectos mejorando procesos; las pruebas están orientadas al producto y se centran en encontrar defectos en los productos de trabajo.
Un tester y un desarrollador discrepan sobre si un comportamiento reportado es un defecto. Aplicando la psicología de las pruebas, ¿cuál es el enfoque MÁS constructivo?
Comunicar los hallazgos de forma neutral y objetiva, centrándose en hechos y en el resultado esperado frente al real.
Correcto — la comunicación neutral y basada en hechos reduce el conflicto.
Escalar de inmediato a la gerencia para asignar responsabilidad.
Escalar prematuramente daña la colaboración; primero discutir los hechos.
Cerrar el reporte como 'no es un defecto' para evitar conflicto.
Suprimir información válida daña la calidad del producto.
Insistir en que el desarrollador se equivoca porque los testers son dueños de la calidad.
La calidad es responsabilidad compartida; una postura adversarial es contraproducente.
La información sobre defectos debe comunicarse de forma neutral y objetiva para evitar fricciones y mantener el foco en mejorar el producto, no en culpar.
Un equipo prueba la versión 3.2 de un componente de pagos y utiliza la especificación de requisitos para derivar las pruebas. En terminología ISTQB, ¿cómo se denomina el propio componente de pagos de la versión 3.2?
El objeto de prueba
Correcto — el objeto de prueba es el componente, sistema u otro producto de trabajo que se prueba.
La base de prueba
La base de prueba es el conjunto de información usado para el análisis y diseño de pruebas. Aquí ese papel lo cumple la especificación de requisitos, no el componente.
La condición de prueba
Una condición de prueba es un aspecto comprobable del objeto de prueba derivado de la base de prueba, por ejemplo «rechaza un importe negativo». Describe un aspecto, no el objeto.
El entorno de prueba
El entorno de prueba es el hardware, software, configuración y datos en los que se ejecuta el objeto de prueba. Lo rodea, pero no es el objeto.
El objeto de prueba es el producto de trabajo que se va a probar, aquí el componente de pagos 3.2. La especificación de requisitos es la base de prueba con la que se derivan las pruebas.
Un equipo sigue un ciclo de vida secuencial (modelo en V). Según el principio de pruebas tempranas, ¿qué debería ocurrir con las pruebas de aceptación de un requisito?
Pueden diseñarse en cuanto los requisitos estén disponibles.
Correcto — el diseño temprano ayuda a encontrar defectos de requisitos antes.
Deben esperar hasta que todo el código esté integrado.
Esperar contradice las pruebas tempranas; el diseño puede empezar con los requisitos.
Son innecesarias en un modelo en V.
La prueba de aceptación es un nivel explícito del modelo en V.
Deben ser escritas solo por desarrolladores.
Las pruebas de aceptación suelen involucrar a usuarios/negocio, no solo a desarrolladores.
En el modelo en V, cada nivel de desarrollo tiene un nivel de prueba correspondiente; el diseño de pruebas (p. ej. de aceptación) comienza en cuanto la base correspondiente (requisitos) está disponible.
Se realiza un cambio en el módulo de cálculo de impuestos. El equipo vuelve a ejecutar las pruebas de impuestos existentes que antes pasaban, para asegurarse de que el cambio no las rompió. ¿Qué tipo de prueba es esta?
Prueba de regresión.
Correcto — reejecutar pruebas superadas tras un cambio es prueba de regresión.
Prueba de confirmación.
La prueba de confirmación verifica la corrección de un defecto concreto, no áreas sin cambios.
Prueba de humo.
La prueba de humo es una comprobación superficial de la funcionalidad básica, no regresión dirigida.
Prueba de aceptación.
La prueba de aceptación valida la idoneidad de uso, no reejecuta pruebas de impuestos.
La prueba de regresión reejecuta pruebas que antes pasaban tras un cambio para detectar efectos secundarios no deseados; la prueba de confirmación verifica que un defecto corregido concreto ya no está.
¿Qué nivel de prueba se centra en las interfaces e interacciones entre componentes o sistemas integrados?
Prueba de integración.
Correcto — se centra en interfaces e interacciones entre partes integradas.
Prueba de componente.
La prueba de componente verifica un solo componente de forma aislada.
Prueba de sistema.
La prueba de sistema evalúa el comportamiento del sistema completo, no específicamente las interfaces.
Prueba de aceptación.
La prueba de aceptación genera confianza y disposición de uso, no foco en interfaces.
La prueba de integración se centra en interfaces e interacciones; la integración de componentes prueba interacciones entre componentes y la de sistemas entre sistemas.
¿Cuáles DOS de los siguientes son formas comunes de prueba de aceptación? (Seleccione DOS.)
Prueba de aceptación operativa (OAT).
Correcto — la OAT verifica aspectos operativos como copia/restauración y mantenimiento.
Prueba beta.
Correcto — la prueba beta es una forma de aceptación realizada por usuarios reales en su entorno.
Prueba de cobertura de ramas.
La cobertura de ramas es una medida de caja blanca, no una forma de aceptación.
Prueba de integración de componentes.
Es un nivel de integración, no una prueba de aceptación.
Prueba de cobertura de sentencias.
La cobertura de sentencias es una medida estructural, no una forma de aceptación.
Las formas comunes de prueba de aceptación incluyen la de usuario (UAT), la operativa (OAT), la contractual/regulatoria y las pruebas alfa/beta.
Un banco añade una nueva función de «pago instantáneo» y debe verificar que cumple las normativas nacionales de pago antes del lanzamiento. ¿Qué tipo de prueba se aborda MÁS directamente?
Prueba funcional.
Correcto — verificar que la función hace lo que exige la norma es prueba funcional.
Prueba de eficiencia de rendimiento.
Es una característica no funcional sobre velocidad/recursos, no la corrección regulatoria.
Prueba de portabilidad.
La portabilidad trata mover software entre entornos, no aplica aquí.
Prueba de mantenibilidad.
La mantenibilidad trata la facilidad de modificación, no el comportamiento regulatorio.
La prueba funcional verifica el 'qué' del sistema frente a requisitos funcionales; el cumplimiento de normas sobre lo que la función debe hacer se verifica de forma funcional.
En un enfoque shift-left, ¿qué acción ilustra MEJOR el concepto?
Revisar requisitos y escribir pruebas antes de desarrollar el código.
Correcto — adelantar las actividades de prueba es la esencia de shift left.
Ejecutar todas las pruebas solo tras construir el sistema por completo.
Eso es lo contrario de shift left.
Añadir más testers a la fase final de aceptación.
Añadir esfuerzo tarde no adelanta las actividades.
Posponer el diseño de pruebas hasta después del despliegue.
Posponer es una actividad shift-right/tardía, no shift left.
Shift left significa realizar actividades de prueba antes, p. ej. revisar requisitos, escribir pruebas antes del código (TDD) e involucrar a los testers desde el inicio.
¿Cuál de los siguientes es un beneficio clave de las pruebas estáticas frente a las dinámicas?
Puede encontrar defectos antes y en productos de trabajo no ejecutables.
Correcto — las pruebas estáticas detectan defectos en requisitos/diseño antes de que exista código.
Mide el rendimiento real bajo carga.
El rendimiento bajo carga requiere ejecución dinámica.
Confirma que el sistema se comporta correctamente en tiempo de ejecución.
El comportamiento en ejecución solo se observa con pruebas dinámicas.
Siempre elimina la necesidad de pruebas dinámicas.
Las pruebas estáticas y dinámicas son complementarias, no sustitutas.
Las pruebas estáticas examinan productos de trabajo sin ejecutar código, por lo que pueden encontrar defectos (incluso en requisitos/diseño) antes y en artefactos no ejecutables.
Durante una revisión, el moderador planifica y dirige la reunión, mientras otro participante se centra en detectar defectos usando listas de verificación. ¿Qué rol desempeña el segundo participante?
Revisor.
Correcto — los revisores examinan el producto e identifican defectos.
Escriba.
El escriba registra las incidencias; no las encuentra principalmente.
Autor.
El autor creó el producto bajo revisión.
Facilitador (moderador).
Ese es el primer participante, que dirige la reunión.
En una revisión formal, el autor posee el producto, el moderador dirige la revisión, el escriba registra incidencias, los revisores encuentran defectos y el líder de revisión asume la responsabilidad general.
¿Cuáles DOS de los siguientes se encuentran típicamente de forma MÁS efectiva mediante pruebas estáticas que dinámicas? (Seleccione DOS.)
Ambigüedades y contradicciones en los requisitos.
Correcto — las revisiones detectan defectos de requisitos antes de que exista código.
Código inalcanzable (muerto).
Correcto — el análisis estático detecta código que nunca se ejecuta.
Degradación del tiempo de respuesta bajo carga alta.
El rendimiento bajo carga requiere ejecución dinámica.
Fugas de memoria que solo aparecen en ejecución.
El comportamiento de memoria en ejecución se observa dinámicamente.
Resultados incorrectos producidos por un cálculo en ejecución.
Observar una salida calculada errónea requiere ejecutar el código.
Las pruebas estáticas encuentran eficazmente defectos de requisitos y diseño, desviaciones de estándares, problemas de mantenibilidad y código muerto/inalcanzable que las dinámicas pueden pasar por alto.
¿Qué tipo de revisión se caracteriza por ser la MÁS formal, dirigida por un moderador capacitado, con criterios de entrada/salida definidos, preparación individual y métricas?
Inspección.
Correcto — la inspección es el tipo de revisión más formal.
Revisión informal.
Una revisión informal no tiene proceso formal ni resultados documentados.
Recorrido (walkthrough).
Un recorrido lo dirige el autor y es menos formal que una inspección.
Revisión técnica.
Una revisión técnica es formal pero suele ser menos rigurosa y métrica que una inspección.
Una inspección es el tipo de revisión más formal, con moderador capacitado, proceso formal, criterios de entrada/salida, roles definidos, preparación individual y recogida de métricas.
Para la máquina de estados del ticket de soporte siguiente, ¿cuántos casos se requieren para la cobertura 0-switch (cada transición individual válida una vez)?
6
New->Open, Open->InProgress, InProgress->Resolved, Resolved->Closed, Resolved->InProgress, Closed->Open.
4
Omite reject/reopen y Closed->Open.
5
Cuenta una transición de menos.
7
Cuenta de más; hay exactamente seis.
Hay seis transiciones: triage, assign, resolve, close, reject/reopen (Resolved->InProgress), reopen (Closed->Open).
Un campo de entrada 'edad' acepta valores enteros de 18 a 65 inclusive como válidos; los valores fuera de ese rango son inválidos. Usando particiones de equivalencia, ¿qué conjunto de valores representa una partición válida y las dos inválidas con un representante cada una?
10, 40, 80
Correcto — 10 (inválido bajo), 40 (válido), 80 (inválido alto): uno por partición.
20, 40, 60
Los tres están en la partición válida; no se cubren las inválidas.
17, 18, 65
Son valores límite (BVA), no representantes únicos de tres particiones.
5, 12, 16
Los tres están en la partición inválida baja; faltan válida e inválida alta.
La partición de equivalencia agrupa entradas en válidas (18–65) e inválidas (≤17 y ≥66); basta un representante por partición.
Un sistema de fidelización otorga puntos según el gasto anual de un cliente. Las reglas: gasto de 0 a 999 da Bronce; de 1000 a 4999 da Plata; de 5000 o más da Oro. El gasto es un número entero de euros. Usando análisis de valores límite (BVA) de dos valores sobre el gasto, ¿cuántos valores límite distintos deben probarse para cubrir las fronteras entre las tres categorías?
4 (999, 1000, 4999, 5000)
Correcto — dos fronteras internas, cada una con dos valores.
2 (1000, 5000)
La BVA de dos valores también prueba el valor justo por debajo (999 y 4999).
6 (0, 999, 1000, 4999, 5000, 9999)
0 y un valor alto arbitrario no son fronteras internas entre las tres categorías.
3 (999, 1000, 5000)
Omite 4999, el lado inferior de la segunda frontera.
La BVA de dos valores prueba cada frontera y el valor justo al otro lado. Las fronteras entre categorías están en 999/1000 y 4999/5000. Eso da los valores 999, 1000, 4999, 5000 — cuatro valores límite distintos.
Una aseguradora de autos aplica reglas de descuento según la siguiente tabla de decisión. Un conductor de 40 años sin siniestros en los últimos 5 años tiene una sola póliza con la aseguradora (multi-póliza = Falso). ¿Qué regla aplica y cuál es la acción resultante?
R7 — aplicar el 10% de descuento.
Correcto — T, T, F corresponde a R7, cuya acción es el 10% de descuento.
R8 — aplicar el 10% de descuento.
R8 requiere multi-póliza = T; aquí es F.
R5 — aplicar nivel premium.
R5 requiere sin siniestros = F; aquí es T.
R3 — aplicar nivel premium.
R3 requiere Age>=25 = F; aquí el conductor tiene 40 (T).
Edad 40 → Age>=25 = T; sin siniestros en 5 años = T; una sola póliza → Multi-policy = F. La columna con T, T, F es R7, cuya acción es '10% de descuento' (no se aplica nivel premium).
La máquina de estados de abajo modela una pantalla de inicio de sesión. Tras 3 intentos inválidos la cuenta queda bloqueada (Locked); vuelve a Idle solo tras un reinicio de 30 minutos. Usando el diagrama, ¿cuál es el número mínimo de casos de prueba para lograr el 100% de cobertura de transiciones válidas (0-switch), donde cada caso es un camino que empieza en el estado inicial?
2
Correcto — dos caminos desde el inicio cubren las cinco transiciones válidas.
1
Un solo camino no puede incluir 'valid login' (termina en LoggedIn) y 'reset' (necesita Locked).
4
Cuatro es más del mínimo; dos caminos bien elegidos ya cubren todas las transiciones.
5
Cinco es el número de transiciones, pero un caso cubre varias transiciones en un camino.
Hay 5 transiciones: enterCredentials, el autobucle inválido, 3rd invalid, valid login y reset. Un camino (Idle→Entering, invalid, invalid, 3rd invalid→Locked, reset→Idle) cubre cuatro; un segundo camino (Idle→Entering, valid login→LoggedIn) cubre valid login. Así que bastan 2 casos.
¿Cuál es la diferencia entre la cobertura 0-switch (todas las transiciones) y la cobertura 1-switch en pruebas de transición de estados?
0-switch cubre transiciones individuales; 1-switch cubre cada secuencia válida de dos transiciones consecutivas.
Correcto — 1-switch cubre pares de transiciones, aumentando la exhaustividad.
0-switch cubre solo estados válidos; 1-switch solo inválidos.
La cobertura switch trata transiciones/secuencias, no estados válidos vs inválidos.
0-switch cubre todos los estados una vez; 1-switch dos veces.
La cobertura switch cuenta transiciones, no visitas a estados.
No hay diferencia; los términos son sinónimos.
Definen niveles de cobertura distintos.
La cobertura 0-switch ejercita cada transición válida individual una vez; la 1-switch ejercita cada par válido de transiciones consecutivas (secuencias de dos transiciones).
¿Qué DOS afirmaciones sobre la prueba de tabla de decisión son correctas? (Seleccione DOS.)
La cobertura completa requiere al menos un caso por cada regla (columna) alcanzable.
Correcto — cada regla factible debe ejercitarse al menos una vez.
Las tablas de decisión son útiles cuando varias condiciones se combinan para determinar un resultado.
Correcto — capturan sistemáticamente condiciones y acciones que interactúan.
Una tabla de decisión solo puede contener una única condición.
Las tablas de decisión manejan múltiples condiciones.
La prueba de tabla de decisión garantiza el 100% de cobertura de ramas del código.
Es una técnica de caja negra y no garantiza cobertura estructural del código.
Las tablas de decisión son una técnica de caja blanca basada en la estructura del código.
Son una técnica de caja negra basada en especificaciones, no en código.
Las tablas de decisión modelan combinaciones de condiciones y sus acciones resultantes; la cobertura completa requiere al menos un caso por regla (columna) alcanzable. Son adecuadas para reglas de negocio con condiciones que interactúan.
Un equipo quiere verificar si un usuario experimentado puede completar un flujo complejo usando su propio conocimiento e intuición, sin casos de prueba predefinidos, explorando la aplicación y aprendiendo sobre la marcha. ¿Qué enfoque se describe?
Pruebas exploratorias.
Correcto — diseño, ejecución y aprendizaje ocurren juntos, sin scripts predefinidos.
Análisis de valores límite.
El BVA es una técnica basada en especificaciones con valores límite predefinidos.
Prueba de sentencias.
La prueba de sentencias es una técnica de caja blanca basada en cobertura de código.
Pruebas basadas en listas de verificación.
Siguen una lista predefinida de comprobaciones, a diferencia de la exploración libre.
Las pruebas exploratorias son un enfoque basado en la experiencia donde el tester diseña, ejecuta y aprende a la vez, a menudo sin scripts predefinidos.
Considere este pseudocódigo: línea 1 read x; línea 2 if x > 0 then línea 3 y = x * 2; línea 4 end if; línea 5 print y. Se ejecuta una sola prueba con x = 5. ¿Qué cobertura de sentencias logra esta única prueba (contando las sentencias ejecutables de las líneas 1, 3 y 5, más la decisión de la línea 2)?
100% de cobertura de sentencias (pero solo 50% de ramas).
Correcto — se ejecutan todas las sentencias, pero solo la rama verdadera.
50% de cobertura de sentencias.
Se ejecutan las tres sentencias ejecutables, así que es 100%, no 50%.
100% de cobertura de sentencias y 100% de ramas.
La rama falsa (x ≤ 0) nunca se toma, así que la cobertura de ramas no es del 100%.
75% de cobertura de sentencias.
No hay sentencia parcial; cada sentencia ejecutable corre, dando 100%.
Con x = 5 la decisión es verdadera, por lo que se ejecutan todas las sentencias ejecutables (read x, y = x*2, print y). Eso es 100% de cobertura de sentencias. Pero la rama falsa de la decisión no se toma, así que la cobertura de ramas/decisión es solo del 50%.
¿Qué afirmación sobre la relación entre cobertura de sentencias y cobertura de ramas (decisión) es correcta?
El 100% de cobertura de ramas implica el 100% de sentencias, pero no al revés.
Correcto — la cobertura de ramas subsume la de sentencias.
El 100% de cobertura de sentencias implica el 100% de ramas.
Las sentencias pueden ejecutarse sin ejercitar cada resultado de rama.
Siempre son iguales para cualquier programa.
Difieren cuando una decisión tiene un resultado no tomado.
Ninguna implica a la otra.
La cobertura de ramas sí implica la de sentencias; la relación es unidireccional.
Lograr el 100% de cobertura de ramas garantiza el 100% de cobertura de sentencias, pero no al revés; la cobertura de ramas es más fuerte porque también exige ejercitar cada resultado de decisión.
Una función contiene exactamente dos decisiones simples independientes (dos sentencias if separadas, cada una con resultado verdadero y falso, sin anidamiento). ¿Cuál es el número mínimo de casos de prueba para lograr el 100% de cobertura de ramas (decisión)?
2
Correcto — (V,V) y (F,F) cubren ambos resultados de ambas decisiones.
4
Cuatro solo se necesitarían para la combinación completa (p. ej. cobertura de condiciones múltiples), no para ramas básica.
1
Una prueba no puede tomar el resultado verdadero y falso de una decisión.
3
Tres es más de lo necesario; dos ejecuciones ya cubren los cuatro resultados.
Cada decisión simple necesita cubrir su resultado verdadero y falso. Dos decisiones independientes se combinan en las mismas ejecuciones: la prueba 1 toma (verdadero, verdadero) y la prueba 2 (falso, falso), cubriendo los cuatro resultados. Así que bastan 2 casos.
¿Cuál de los siguientes se documenta normalmente en un plan de pruebas?
El alcance, objetivos, enfoque, cronograma y criterios de entrada/salida.
Correcto — son contenidos centrales de un plan de pruebas.
El código fuente completo del sistema bajo prueba.
El código fuente pertenece al repositorio, no al plan de pruebas.
El presupuesto de marketing para el lanzamiento.
Los presupuestos de marketing no se relacionan con la planificación de pruebas.
Las evaluaciones de desempeño de los desarrolladores.
Las evaluaciones de personal no forman parte de un plan de pruebas.
Un plan de pruebas describe el alcance, objetivos, enfoque, recursos, cronograma y criterios de entrada/salida; es el puente entre la estrategia de prueba y el trabajo a realizar.
Un líder de pruebas estima el esfuerzo para probar una función con la técnica de tres puntos (PERT). La estimación optimista es de 4 días, la más probable de 10 días y la pesimista de 22 días. Usando la fórmula E = (a + 4m + b) / 6, ¿cuál es el esfuerzo estimado?
11 días
Correcto — (4 + 40 + 22) / 6 = 66 / 6 = 11.
12 días
Es el promedio simple de 4, 10 y 22; PERT pondera el valor más probable por 4.
10 días
10 es solo el valor más probable, no la estimación PERT ponderada.
13 días
Recalcular: (4 + 40 + 22)/6 = 11, no 13.
E = (4 + 4*10 + 22) / 6 = (4 + 40 + 22) / 6 = 66 / 6 = 11 días.
Un jefe de proyecto teme que un entorno de prueba clave no sea entregado a tiempo por el proveedor. En términos de pruebas basadas en riesgo, ¿cómo se clasifica este riesgo?
Un riesgo de proyecto.
Correcto — el retraso del entorno trata del control del proyecto, un riesgo de proyecto.
Un riesgo de producto.
El riesgo de producto trata de no cumplir necesidades, no de retrasos del proveedor.
Un defecto residual.
Un defecto residual es un defecto conocido que queda tras la prueba, no un riesgo de entrega.
Un fallo.
Un fallo es un comportamiento incorrecto observado en ejecución, no un riesgo de planificación.
Un riesgo de proyecto se refiere a la gestión y control del proyecto (p. ej. recursos, entornos, cronogramas, proveedores). Un riesgo de producto se refiere a que el producto no satisfaga las necesidades.
¿Cuáles DOS de los siguientes son ejemplos de riesgos de PROYECTO? (Seleccione DOS.)
Escasez de testers con las habilidades requeridas.
Correcto — los problemas de personal/habilidades son riesgos de proyecto.
Un retraso del proveedor en entregar un componente crítico.
Correcto — los retrasos del proveedor amenazan la entrega, un riesgo de proyecto.
El módulo de pago podría calcular totales incorrectamente.
Es un riesgo de producto — trata de la corrección del producto.
La aplicación podría responder muy lento bajo carga pico.
Es un riesgo de producto sobre rendimiento, no un riesgo de proyecto.
Datos sensibles podrían exponerse por un fallo de seguridad.
Es un riesgo de producto (calidad) sobre seguridad, no de proyecto.
Los riesgos de proyecto afectan la capacidad de entrega: escasez de personal/habilidades, problemas organizativos, retrasos de proveedores, disponibilidad de entornos. Los de producto son sobre el producto (cálculos erróneos, mal rendimiento, fallos de seguridad).
Un equipo tiene cuatro riesgos de producto con estos niveles (probabilidad × impacto): R1 = bajo × alto, R2 = alto × alto, R3 = alto × bajo, R4 = bajo × bajo. Solo hay tiempo para probar a fondo dos de estas áreas primero. Según las pruebas basadas en riesgo, ¿qué dos áreas deberían recibir las pruebas más profundas y tempranas?
R2 y R3 (las dos con un factor 'alto' y el mayor riesgo global), antes que R1 y R4.
Correcto — R2 es el mayor; R3 (alto×bajo) sigue como riesgo combinado, con R4 (bajo×bajo) claramente última.
R1 y R4, porque son más fáciles de probar.
La facilidad de prueba no es la base de la priorización por riesgo; R4 es el menor riesgo.
R3 y R4, porque ambos tienen alta probabilidad.
R4 tiene baja probabilidad y bajo impacto — es el menor riesgo, no prioridad.
Las cuatro por igual, ignorando los niveles de riesgo.
Tratar todos los riesgos por igual contradice el propósito de las pruebas basadas en riesgo.
Las pruebas basadas en riesgo priorizan el mayor riesgo combinado (probabilidad × impacto). R2 (alto × alto) es claramente el mayor. R1 (bajo × alto) y R3 (alto × bajo) superan a R4 (bajo × bajo). Primero van las dos de mayor riesgo; R4 es claramente la última.
¿Cuál de los siguientes es el MEJOR ejemplo de un criterio de salida (para detener las pruebas) de un nivel de prueba?
Todas las pruebas planificadas se ejecutaron y no quedan defectos de alta prioridad abiertos.
Correcto — define cuándo se considera completa la prueba.
El entorno de prueba está listo y el build instalado.
Es un criterio de entrada (precondición para iniciar), no de salida.
Los requisitos han sido revisados y aprobados.
Es un criterio de entrada típico, no de detención.
Hay datos de prueba disponibles para iniciar la ejecución.
La disponibilidad de datos es una condición de entrada para iniciar.
Los criterios de salida (finalización) definen cuándo puede detenerse una actividad de prueba, p. ej. metas de cobertura alcanzadas, sin defectos de alta prioridad abiertos, pruebas planificadas ejecutadas. Los de entrada definen precondiciones para iniciar.
¿Cuál de las siguientes informaciones es ESENCIAL en un buen informe de defectos para que sea reproducible?
Pasos claros para reproducir, con resultado esperado y real.
Correcto — los pasos más esperado vs real son esenciales para la reproducibilidad.
El nombre del desarrollador a quien culpar.
Atribuir culpa es contraproducente y no es parte de un buen informe.
El número total de casos de prueba del proyecto.
Los recuentos globales no ayudan a reproducir un defecto concreto.
La fecha de lanzamiento comercial del producto.
Las fechas de lanzamiento no se relacionan con reproducir un defecto.
Un informe útil incluye pasos para reproducir, resultado esperado vs real, entorno/configuración y severidad/prioridad — lo suficiente para que otra persona reproduzca y evalúe el defecto.
El progreso de las pruebas va con retraso. ¿Cuáles DOS de las siguientes son acciones de control de prueba apropiadas? (Seleccione DOS.)
Repriorizar las pruebas restantes para cubrir primero las áreas de mayor riesgo.
Correcto — repriorizar por riesgo es una acción de control estándar.
Reasignar recursos o ajustar el cronograma e informar el impacto a las partes interesadas.
Correcto — ajustar recursos/cronograma e informar es control válido.
Dejar de registrar defectos para que las métricas se vean mejor.
Suprimir datos de defectos es deshonesto y daña las decisiones de calidad.
Marcar todos los defectos abiertos como 'corregidos' sin verificar.
Falsificar el estado de defectos no es ético y socava la integridad de la prueba.
Dejar de informar el estado a la gerencia hasta terminar las pruebas.
Ocultar el estado elimina la visibilidad necesaria para decisiones de control.
El control de prueba reorienta las pruebas hacia los objetivos, p. ej. repriorizar por riesgo, reasignar recursos, ajustar el cronograma o ajustar criterios de entrada/salida. Ocultar defectos u omitir informes no son acciones válidas.
¿Por qué es importante la gestión de la configuración para las pruebas?
Asegura que los elementos de prueba y el testware estén identificados y versionados, de modo que los resultados sean reproducibles.
Correcto — elementos trazables y versionados hacen los resultados reproducibles y confiables.
Garantiza que el software no contiene defectos.
La gestión de configuración controla versiones; no elimina defectos.
Elimina la necesidad de un plan de pruebas.
La gestión de configuración complementa, no reemplaza, la planificación.
Ejecuta automáticamente todas las pruebas de regresión.
La ejecución la hacen personas o herramientas de ejecución, no la gestión de configuración.
La gestión de configuración asegura que todos los elementos de prueba (testware, versiones de software, entornos, datos) estén identificados, versionados y sean trazables, de modo que los resultados sean reproducibles y refieran a versiones conocidas.
Un equipo planea introducir una herramienta de automatización de pruebas. ¿Cuál de los siguientes es un RIESGO realista (no un beneficio) de adoptar dicha herramienta?
El esfuerzo de mantener los scripts automatizados puede subestimarse.
Correcto — el esfuerzo de mantenimiento es un riesgo conocido de la automatización.
Se puede reducir el trabajo manual repetitivo.
Eso es un beneficio del soporte de herramientas, no un riesgo.
Se hace posible una evaluación más objetiva (p. ej. medir cobertura).
Eso es un beneficio, no un riesgo.
Acceso más fácil a información sobre pruebas y el proceso de prueba.
El mejor acceso a la información es un beneficio del soporte de herramientas.
Los riesgos de adoptar una herramienta incluyen expectativas poco realistas, subestimar el esfuerzo de mantener los scripts, dependencia excesiva de la herramienta y el coste de introducción y mantenimiento. Los beneficios incluyen menos trabajo repetitivo y evaluación más objetiva.
¿Cuáles DOS de los siguientes son ejemplos de herramientas que apoyan la ejecución y el registro de pruebas o la gestión de pruebas? (Seleccione DOS.)
Un framework de pruebas unitarias/automatización que ejecuta pruebas y registra resultados.
Correcto — es una herramienta de ejecución y registro de pruebas.
Una herramienta de gestión de pruebas que almacena casos, ejecuciones y trazabilidad a requisitos.
Correcto — una herramienta de gestión de pruebas apoya organizar y rastrear las pruebas.
Un procesador de texto de propósito general.
Un procesador de texto no es una herramienta de prueba dedicada.
Un compilador de lenguaje usado para construir la aplicación.
Un compilador construye software; no es una herramienta de prueba.
Una hoja de cálculo para presupuesto personal.
Una hoja de presupuesto personal no participa en la ejecución ni gestión de pruebas.
Las categorías incluyen herramientas de gestión de pruebas, análisis estático, ejecución de pruebas (p. ej. frameworks de pruebas unitarias/automatización), pruebas de rendimiento y gestión de defectos. Un compilador y un procesador de texto son herramientas de propósito general, no de prueba.