ISTQB Foundation (CTFL v4.0) Examen de práctica #9 — 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 desarrollador escribe código que calcula una fecha de entrega. El desarrollador teclea por error '-' en lugar de '+' en una fórmula. Como resultado, cuando un cliente compra un viernes, el sistema muestra una fecha de entrega en el pasado y el cliente se queja. Asocie estas tres observaciones con los términos ISTQB error, defecto y fallo.
Error = el desarrollador teclea mal; defecto = el operador incorrecto en el código; fallo = la fecha de entrega en el pasado mostrada al cliente.
Asociación correcta: el desliz humano es el error, el código defectuoso es el defecto, la salida incorrecta observada es el fallo.
Error = la fecha en el pasado; defecto = la queja del cliente; fallo = el tecleo erróneo.
Invertido: la fecha y la queja son consecuencias (fallo), no el error; el tecleo es el error.
Error = el operador incorrecto en el código; defecto = el tecleo erróneo; fallo = la queja del cliente.
El operador incorrecto es el defecto, no el error; el tecleo es el error.
Los tres términos describen el mismo único evento y son intercambiables.
ISTQB separa deliberadamente la acción humana, el defecto estático y la manifestación dinámica — no son intercambiables.
Un error es una acción humana que produce un resultado incorrecto; el defecto es el fallo resultante en el código; el fallo es el comportamiento incorrecto observado externamente.
¿Qué afirmación describe mejor una razón clave por la que las pruebas son necesarias en el desarrollo de software?
Las pruebas reducen el riesgo de que ocurran fallos en operación y aportan información sobre la calidad.
Justificación central: las pruebas reducen el riesgo operativo e informan sobre la calidad.
Las pruebas garantizan que el software está completamente libre de defectos.
Las pruebas nunca pueden demostrar la ausencia de defectos; es una falacia conocida.
Las pruebas eliminan la necesidad de requisitos y diseño.
Las pruebas complementan, no sustituyen, las actividades de requisitos y diseño.
Las pruebas solo son necesarias cuando el cliente reporta un problema.
Esperar a los reportes del cliente contradice la detección temprana de defectos.
Las pruebas reducen el riesgo de fallos en operación y ayudan a verificar que se cumplen los requisitos.
¿Qué afirmación refleja correctamente el principio de prueba conocido como 'paradoja del pesticida'?
Si se repiten las mismas pruebas muchas veces, terminan por no encontrar defectos nuevos, por lo que hay que revisar los casos de prueba con regularidad.
Justo la paradoja del pesticida: los conjuntos estáticos pierden eficacia y deben actualizarse.
Los defectos tienden a agruparse en un número reducido de módulos.
Eso describe el 'agrupamiento de defectos', un principio distinto.
Las pruebas exhaustivas de todas las entradas son alcanzables con suficientes recursos.
Contradice 'las pruebas exhaustivas son imposibles'.
Probar pronto ahorra tiempo y dinero.
Cierto, pero ese es el principio de 'pruebas tempranas', no la paradoja del pesticida.
Repetir las mismas pruebas deja de encontrar defectos nuevos; las pruebas deben revisarse y modificarse con el tiempo.
¿Cuáles DOS de las siguientes son objetivos válidos de las pruebas según el temario ISTQB? (Elija dos.)
Evaluar la calidad y generar confianza en el nivel de calidad.
Un objetivo de prueba reconocido en el temario.
Encontrar defectos y fallos, reduciendo así el riesgo.
Detectar defectos para reducir el riesgo de calidad inadecuada es un objetivo central.
Demostrar que el software no contiene defectos.
Imposible — las pruebas no pueden demostrar la ausencia de defectos.
Corregir los defectos encontrados.
Corregir es trabajo de depuración/desarrollo, no un objetivo de prueba.
Las pruebas encuentran defectos y generan confianza en el nivel de calidad; no pueden demostrar la ausencia de defectos.
Durante el proceso de prueba, el equipo transforma objetivos generales en condiciones de prueba concretas y luego en casos de prueba. ¿Qué actividad de prueba se ocupa principalmente de identificar QUÉ probar (las condiciones de prueba) analizando la base de prueba?
Análisis de prueba
El análisis de prueba examina la base de prueba para determinar características probables y definir condiciones (qué probar).
Diseño de prueba
El diseño elabora las condiciones en casos concretos (el cómo), después de que el análisis define el qué.
Implementación de prueba
La implementación organiza los casos en procedimientos/suites y prepara el entorno, tras el diseño.
Ejecución de prueba
La ejecución corre las pruebas y compara resultados reales con esperados — mucho más tarde.
El análisis de prueba identifica qué probar (condiciones); el diseño de prueba determina cómo, generando casos de prueba.
¿Por qué cierto grado de independencia suele ser útil al probar software?
Los testers independientes tienden a reconocer defectos distintos que el autor por sesgos y suposiciones diferentes.
La independencia reduce el sesgo del autor y revela defectos pasados por alto.
Los autores no pueden probar su propio código bajo ninguna circunstancia.
Los autores sí prueban su trabajo (p. ej. pruebas unitarias); la independencia es gradual, no una prohibición absoluta.
Los testers independientes siempre encuentran más defectos que los desarrolladores.
No está garantizado — la independencia ayuda pero no siempre rinde más defectos.
La independencia elimina por completo la necesidad de que los desarrolladores prueben.
Las pruebas de los desarrolladores siguen siendo valiosas; la independencia las complementa.
Los testers independientes tienden a reconocer tipos distintos de defectos debido a suposiciones y sesgos diferentes.
Un jefe de proyecto afirma: 'Ejecutamos todas las pruebas planificadas y casi todas pasaron, así que el sistema está listo para lanzarse y los usuarios estarán satisfechos.' ¿Qué principio advierte contra este razonamiento?
La falacia de ausencia de errores.
Encontrar y corregir defectos no sirve si el sistema es inusable o no cumple las necesidades del usuario.
Las pruebas muestran la presencia de defectos, no su ausencia.
Es un principio real, pero trata lo que demuestran las pruebas, no la brecha de aptitud de uso planteada.
Agrupamiento de defectos.
Trata la distribución de defectos entre módulos, ajeno a la satisfacción del usuario.
Las pruebas dependen del contexto.
Cierto en general, pero no advierte específicamente sobre equiparar pocos defectos con satisfacción.
La falacia de ausencia de errores: un sistema puede tener pocos defectos y aun así no cumplir las necesidades y expectativas de los usuarios.
Un tester toma varios casos de prueba relacionados, los pone en el orden en que deben ejecutarse, añade los pasos de preparación necesarios antes del primero y guarda el resultado. En terminología ISTQB, ¿qué ha creado el tester?
Un procedimiento de prueba
Correcto — un procedimiento de prueba es una secuencia de casos en orden de ejecución junto con las precondiciones y acciones preparatorias necesarias.
Un caso de prueba
Un caso de prueba especifica precondiciones, entradas, resultados esperados y postcondiciones de una sola prueba. Aquí se secuenciaron varios casos existentes, algo por encima del nivel de un caso.
Una suite de pruebas
Una suite es un conjunto de casos o procedimientos seleccionados para ejecutarse juntos, por ejemplo en un ciclo. Agrupa pruebas, pero no prescribe el orden interno ni los pasos de preparación propios de un procedimiento.
Una condición de prueba
Una condición de prueba indica qué debe probarse, por ejemplo una funcionalidad o característica de calidad. No contiene pasos de ejecución ni orden alguno.
Un procedimiento de prueba especifica una secuencia de acciones para la ejecución, incluidos los casos de prueba en su orden de ejecución y las precondiciones o pasos preparatorios. Se crea durante la implementación de pruebas.
Un equipo adopta un enfoque 'shift-left'. ¿Cuál de las siguientes ilustra MEJOR el shift-left testing en la práctica?
Los testers revisan los requisitos y definen pruebas de aceptación en la fase de análisis, antes de escribir código.
La revisión y el diseño temprano de pruebas es la esencia del shift-left.
Todas las pruebas se posponen hasta una fase dedicada tras finalizar el desarrollo.
Eso es lo contrario del shift-left — desplaza las pruebas a la derecha.
Las pruebas se realizan solo en producción mediante monitoreo.
El monitoreo en producción es 'shift-right'; no adelanta las pruebas.
Se reduce el número de testers y los desarrolladores hacen menos pruebas unitarias.
Reducir las pruebas tempranas contradice el shift-left.
Shift-left adelanta las actividades de prueba, p. ej. revisar requisitos y escribir pruebas antes de terminar el código.
¿Cuál es el propósito principal de las pruebas de integración como nivel de prueba?
Probar las interfaces e interacciones entre componentes o sistemas integrados.
La integración de componentes busca defectos en las interfaces e interacciones entre componentes.
Probar cada componente individual de forma aislada.
Eso es la prueba de componentes (unitaria), otro nivel.
Validar el sistema completo frente a los requisitos de negocio con usuarios finales.
Eso describe las pruebas de aceptación, no la integración.
Verificar el comportamiento del sistema integrado completo de extremo a extremo.
Probar el sistema completo de extremo a extremo es la prueba de sistema.
Las pruebas de integración se centran en las interacciones e interfaces entre componentes o sistemas.
Un equipo de prueba mide la rapidez con que responde la aplicación bajo una carga de 500 usuarios concurrentes. ¿Qué tipo de prueba es y por qué?
Prueba no funcional, porque evalúa una característica de calidad (eficiencia de rendimiento) y no una función.
El tiempo de respuesta bajo carga es una característica de eficiencia de rendimiento (no funcional).
Prueba funcional, porque la aplicación realiza sus cálculos.
El foco está en la rapidez, no en si el resultado es correcto — eso la hace no funcional.
Prueba de caja blanca, porque se basa en la estructura interna del código.
Medir el tiempo de respuesta no requiere conocer la estructura interna.
Prueba de confirmación, porque vuelve a ejecutar una prueba anterior.
La confirmación reprueba un defecto corregido; esto es una nueva medición de rendimiento.
Medir el tiempo de respuesta bajo carga es una prueba no funcional (rendimiento/eficiencia) — prueba cómo de bien se comporta el sistema, no qué hace.
Una aplicación que lleva dos años en operación debe actualizarse porque se actualiza el sistema operativo en el que se ejecuta. La funcionalidad no cambia. ¿Qué tipo de prueba se desencadena principalmente y cómo se llama el desencadenante?
Prueba de mantenimiento, desencadenada por un cambio del entorno (actualización del sistema operativo).
Las modificaciones del entorno operativo son un desencadenante reconocido del mantenimiento.
Prueba de aceptación, desencadenada por un nuevo requisito de negocio.
No hay un nuevo requisito de negocio; la funcionalidad no cambia.
Prueba de componentes, desencadenada por código nuevo escrito desde cero.
No se escribe código de funcionalidad nuevo; el sistema se migra.
Prueba de humo, desencadenada por la compilación diaria.
La compilación diaria no es el desencadenante; lo es la actualización del SO.
Es una prueba de mantenimiento desencadenada por un cambio en el entorno (un desencadenante operativo/de migración).
¿Cuáles DOS afirmaciones distinguen correctamente las pruebas de confirmación de las de regresión? (Elija dos.)
La confirmación reejecuta las pruebas que antes fallaron, para verificar la corrección.
Correcto — la confirmación verifica que el defecto original se resolvió.
La regresión verifica que el cambio no haya introducido o revelado defectos en partes no modificadas.
Correcto — la regresión busca efectos secundarios no deseados de un cambio.
La confirmación siempre está totalmente automatizada y la regresión nunca.
Ambas pueden ser manuales o automatizadas; la automatización no las distingue.
La regresión solo se hace tras desplegar el software en producción.
La regresión se hace ante cualquier cambio de software o entorno, en cualquier nivel.
La confirmación verifica que un defecto corregido ha desaparecido; la regresión verifica que el cambio no ha roto nada más.
En un entorno DevOps con integración continua (CI), ¿cuál es un beneficio clave para las pruebas?
Las pruebas automatizadas se ejecutan en cada integración, dando retroalimentación rápida y detección temprana.
La retroalimentación rápida y automatizada en cada commit es un beneficio clave de CI/DevOps.
La CI elimina la necesidad de pruebas de regresión automatizadas.
La CI depende mucho de las pruebas de regresión automatizadas; no las elimina.
La CI garantiza que ningún defecto llegue a producción.
La CI reduce el riesgo pero no puede garantizar versiones sin defectos.
La CI implica probar solo manualmente al final del sprint.
La CI enfatiza pruebas automatizadas continuas, no pruebas manuales al final del sprint.
La CI da retroalimentación rápida mediante pipelines automatizados de construcción y prueba, detectando defectos poco después de cada commit.
¿Qué afirmación contrasta correctamente las pruebas estáticas con las dinámicas?
Las pruebas estáticas encuentran defectos sin ejecutar el código, mientras que las dinámicas requieren ejecutar el software.
Correcto — es la distinción fundamental entre ambas.
Las pruebas estáticas requieren ejecutar el código y las dinámicas no.
Esto invierte las definiciones.
Tanto las estáticas como las dinámicas requieren siempre ejecutar el software.
Las pruebas estáticas precisamente no ejecutan el software.
Ni las estáticas ni las dinámicas pueden encontrar defectos.
Ambas encuentran defectos; difieren en cómo.
Las pruebas estáticas encuentran defectos directamente en los productos de trabajo sin ejecutar código; las dinámicas ejecutan el software y observan fallos.
¿Cuál de los siguientes es un beneficio que ofrece la prueba estática y que la prueba dinámica normalmente no puede ofrecer?
Detectar defectos directamente en requisitos o diseño antes de ejecutar código.
La prueba estática examina productos de trabajo sin ejecución, hallando defectos antes y en su origen.
Medir el tiempo de respuesta real del sistema en ejecución.
Medir el comportamiento en ejecución requiere ejecutar — eso es prueba dinámica.
Observar fallos por fugas de memoria durante la ejecución.
Observar fallos en ejecución necesita ejecutar y es prueba dinámica.
Confirmar que un defecto corregido ya no causa un fallo en ejecución.
Eso es prueba de confirmación, que requiere ejecutar el software.
La prueba estática puede encontrar defectos en productos de trabajo sin ejecutar código, p. ej. directamente en los requisitos, incluso antes de que exista código.
Un equipo necesita un tipo de revisión que sea el más formal, siga un proceso definido con criterios de entrada/salida documentados, use métricas y esté dirigido por un moderador capacitado. ¿Qué tipo de revisión encaja mejor?
Inspección
La inspección es la revisión más formal: proceso definido, moderador capacitado, roles, métricas y criterios de salida.
Recorrido (walkthrough)
El recorrido lo dirige el autor y es menos formal, a menudo sin criterios estrictos ni métricas.
Revisión informal
La revisión informal no tiene proceso definido y genera poca o ninguna documentación.
Revisión técnica
La revisión técnica es bastante formal y dirigida por pares, pero la inspección es la más formal de las listadas.
La inspección es el tipo de revisión más formal, con proceso definido, roles, criterios de entrada/salida y métricas.
Durante una reunión de revisión formal, ¿qué rol es responsable de registrar los defectos, decisiones y nuevos asuntos planteados durante la discusión?
El escriba (registrador).
El escriba recopila y documenta las anomalías, decisiones y nuevos hallazgos durante la reunión.
El moderador (facilitador).
El moderador dirige y facilita la reunión; registrar es tarea del escriba.
El autor.
El autor creó el producto y responde preguntas, pero no registra la revisión.
El líder de revisión / gerente.
El gerente puede decidir la ejecución de revisiones, pero registrar en la reunión es del escriba.
El escriba (registrador) documenta los defectos, decisiones y asuntos planteados durante la revisión.
Un formulario web acepta un campo 'cantidad' para un pedido en línea. La especificación dice: la cantidad debe ser un entero entre 1 y 50 inclusive. Las cantidades de 0 o menos se rechazan como 'cantidad inválida'; las de 51 o más como 'excede el máximo'. Usando partición de equivalencia, ¿cuántas particiones existen para el campo cantidad y cuál es el número mínimo de casos para cubrir cada partición una vez?
3 particiones; 3 casos.
Válida 1–50, inválida ≤0, inválida ≥51 = tres particiones; cada una una vez = tres casos.
2 particiones; 2 casos.
Ignora que hay dos particiones inválidas distintas con manejo diferente.
4 particiones; 4 casos.
Solo hay una partición válida (1–50), no dos; el total es tres, no cuatro.
50 particiones; 50 casos.
La partición de equivalencia agrupa valores tratados igual; no prueba cada entero.
Hay tres particiones (una válida: 1–50; dos inválidas: ≤0 y ≥51), se necesitan mínimo tres casos.
Para el mismo campo 'cantidad' (rango entero válido de 1 a 50 inclusive), aplica el análisis de valores límite (BVA) de 2 valores. El enfoque de 2 valores prueba, en cada límite, el valor límite y su vecino más cercano del otro lado. ¿Qué conjunto de valores representa exactamente los valores de prueba BVA de 2 valores para este campo?
0, 1, 50, 51
Límite inferior 1 con vecino 0; límite superior 50 con vecino 51 — cuatro valores.
1, 50
Son solo los límites; el enfoque de 2 valores también necesita los vecinos 0 y 51.
0, 1, 2, 49, 50, 51
Ese es el enfoque de 3 valores (límite y ambos vecinos), no el de 2 valores.
1, 25, 50
25 es un valor medio (típico de EP), no un valor límite para BVA, y faltan 0/51.
Los límites son 1 y 50; el enfoque de 2 valores usa {0, 1, 50, 51}.
Un motor de descuentos asigna un nivel de fidelidad según el gasto anual S (euros enteros): Bronce para 0–999, Plata para 1000–4999, Oro para 5000 o más. Usando el enfoque de 3 valores del análisis de valores límite (cada límite probado con el valor anterior, el del límite y el posterior), ¿cuántos valores de prueba distintos se requieren para cubrir todos los límites internos entre niveles? Considere solo los dos límites internos (Bronce/Plata y Plata/Oro).
6 valores de prueba distintos.
Cada límite interno aporta tres valores; los conjuntos {999,1000,1001} y {4999,5000,5001} no se solapan — 6.
4 valores de prueba distintos.
Ese sería el enfoque de 2 valores (dos por límite), no el de 3 valores.
3 valores de prueba distintos.
Tres valores cubren solo un límite; aquí hay dos límites internos.
9 valores de prueba distintos.
Nueve supondría tres límites; solo se consideran dos límites internos.
Límite 1000 → {999,1000,1001}; límite 5000 → {4999,5000,5001}; sin solapamiento, 6 valores distintos.
La siguiente tabla de decisión especifica las reglas de descuento y envío gratis en la caja de una tienda en línea. 'Member (loyalty)' = el cliente tiene cuenta de fidelidad, 'Cart total ≥ 100' = pedido de 100 euros o más, 'Coupon valid' = se introdujo un cupón válido. '–' significa 'no importa'.
Un cliente de fidelidad hace un pedido de 120 euros y NO introduce cupón. Según la tabla, ¿qué regla aplica y cuáles son las acciones resultantes?
Regla R6: 10% de descuento y envío gratis.
Member T, carrito ≥ 100 T, cupón F es exactamente R6 — 10% y envío gratis.
Regla R7: 20% de descuento y envío gratis.
R7 requiere un cupón válido (Coupon=T); aquí no se introdujo cupón.
Regla R4: 5% de descuento y sin envío gratis.
R4 requiere carrito ≥ 100 = F; aquí es 120 (≥100 = T).
Regla R1: 0% de descuento y sin envío gratis.
R1 es para no miembros con carrito menor a 100; este cliente es miembro con 120.
Member=T, Cart≥100=T, Coupon=F coincide con R6 → 10% de descuento, envío gratis = Sí.
Observe de nuevo la tabla de decisión de descuentos de la caja de la tienda en línea.
¿Por qué la regla R1 usa un valor 'no importa' (–) para la condición 'Coupon valid', y qué efecto práctico tiene en el número de columnas?
Como el resultado es idéntico con o sin cupón válido, las dos columnas correspondientes se fusionan en la única regla R1, reduciendo el tamaño de la tabla.
Un 'no importa' combina combinaciones con las mismas acciones, reduciendo la tabla sin perder cobertura.
Porque la condición de cupón es una entrada inválida que nunca debería probarse.
La condición de cupón es válida y se prueba en otras reglas; '–' solo indica irrelevancia para esta regla.
Porque un valor faltante significa que la regla es inviable y puede eliminarse.
R1 es una regla válida y viable; '–' es un 'no importa' deliberado, no un valor faltante.
Porque duplica el número de columnas a probar.
Un 'no importa' reduce, no aumenta, el número de columnas/reglas.
Cuando un no miembro tiene un carrito menor a 100, el resultado es el mismo sin importar el cupón, por lo que dos columnas se combinan en una (R1).
El siguiente diagrama de transición de estados modela una máquina expendedora simple. La máquina inicia en 'Idle'. Insertar una moneda la lleva a 'HasCredit'; más monedas añaden crédito (autotransición). Desde 'HasCredit', seleccionar un producto con crédito suficiente va a 'Dispensing'; seleccionar con crédito insuficiente va a 'Refunding'. Tras dispensar o reembolsar, vuelve a 'Idle'. 'cancel' desde 'HasCredit' reembolsa y vuelve a 'Idle'.
¿Cuál de las siguientes secuencias de eventos es un camino VÁLIDO por el diagrama (es decir, cada transición existe)?
insertCoin, insertCoin, select [credit ≥ price], dispensed.
Idle→HasCredit, autotransición con la segunda moneda, →Dispensing con crédito suficiente, →Idle al dispensar. Todas las transiciones existen.
select [credit ≥ price], insertCoin, dispensed.
Desde Idle no existe transición 'select'; el primer evento es inválido.
insertCoin, dispensed.
No hay transición 'dispensed' directa desde HasCredit; primero debe dispensar.
insertCoin, select [credit < price], dispensed.
Crédito insuficiente lleva a Refunding, desde donde no ocurre 'dispensed' (sino 'refunded').
insertCoin → insertCoin → select(suficiente) → dispensed es válido: Idle→HasCredit→HasCredit→Dispensing→Idle.
¿Qué afirmación describe mejor cuándo una tabla de decisión es una técnica de diseño de pruebas especialmente adecuada?
Cuando distintas combinaciones de condiciones de entrada conducen a distintas acciones o salidas.
Las tablas de decisión capturan sistemáticamente combinaciones de condiciones y sus acciones.
Cuando el sistema tiene un único rango numérico de entrada y nada más.
Un único rango se trata mejor con partición de equivalencia y análisis de valores límite.
Cuando el comportamiento depende de la secuencia de eventos en el tiempo.
El comportamiento secuencial se modela con pruebas de transición de estados, no tablas de decisión.
Cuando hay que ejercitar la estructura interna del código para cobertura.
La cobertura estructural es caja blanca; las tablas de decisión son técnica de caja negra.
Las tablas de decisión son adecuadas cuando el comportamiento depende de combinaciones de condiciones que producen acciones distintas.
Considere esta rutina (con números de línea). 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: if x > 100 then. Línea 6: y = 100. Línea 7: end if. Línea 8: print y. Las sentencias ejecutables son las líneas 1, 2, 3, 5, 6, 8. Un único test se ejecuta con x = 50.
¿Qué cobertura de sentencias logra el único test x = 50?
Cerca del 83% (5 de las 6 sentencias).
x=50 cumple x>0 (línea 3 se ejecuta) pero no x>100 (línea 6 omitida): 5/6 ≈ 83%.
100%.
La línea 6 (y = 100) nunca se alcanza con x = 50, así que no puede ser 100%.
50%.
Se ejecutan bastante más de la mitad; solo se omite una de seis.
67%.
67% serían 4 de 6 sentencias; aquí se ejecutan 5 de 6.
Con x=50 se ejecutan las líneas 1,2,3,5,8 (5 de 6 sentencias); la línea 6 se omite → ~83%.
Una función contiene una única decisión: if (a AND b) then doX() else doY(). 'a' y 'b' son entradas booleanas independientes. Quiere lograr 100% de cobertura de decisiones (ramas) — deben ejercitarse tanto el resultado verdadero como el falso de la decisión.
¿Cuál es el número mínimo de casos de prueba para 100% de cobertura de ramas de esta decisión?
2 casos de prueba.
Un caso hace (a AND b) verdadero (a=T,b=T → doX), otro falso (p. ej. a=F → doY); ambas ramas cubiertas.
1 caso de prueba.
Un caso ejercita solo un resultado de la decisión; la cobertura de ramas necesita ambos.
3 casos de prueba.
Tres no son necesarios para la cobertura de ramas simple de una decisión; dos bastan.
4 casos de prueba.
Cuatro cubrirían todas las combinaciones de a y b, más de lo que exige la cobertura de ramas.
La cobertura de ramas exige que la decisión sea verdadera y falsa → 2 casos (p. ej. a=T,b=T y a=F).
¿Cuáles DOS de las siguientes son características de las técnicas de caja negra (basadas en especificación)? (Elija dos.)
Los casos se derivan de la especificación u otra descripción externa del comportamiento.
Las técnicas de caja negra usan descripciones externas, no la estructura interna del código.
La partición de equivalencia y el análisis de valores límite son ejemplos.
Ambas son técnicas clásicas de caja negra (basadas en especificación).
Miden la cobertura de sentencias y ramas del código fuente.
La cobertura de la estructura del código es una característica de caja blanca.
Requieren acceso y análisis del código fuente interno.
Necesitar el código interno es caja blanca, no caja negra.
Las técnicas de caja negra derivan pruebas de las especificaciones sin referirse a la estructura interna; ejemplos: EP, BVA y tablas de decisión.
Un tester experimentado, sin usar una técnica formal, enumera entradas que probablemente causen problemas (campos vacíos, cero, números negativos, cadenas muy largas, caracteres especiales) según defectos pasados. ¿Qué técnica basada en la experiencia es esta?
Conjetura de errores (error guessing).
La conjetura de errores usa la experiencia del tester para anticipar defectos probables.
Análisis de valores límite.
BVA es una técnica formal basada en especificación, no en la experiencia.
Prueba de sentencias.
La prueba de sentencias es una técnica estructural de caja blanca.
Pruebas basadas en listas de verificación.
Estas siguen una lista documentada; aquí el tester improvisa desde la experiencia sin una.
Anticipar errores probables a partir de la experiencia es la conjetura de errores (error guessing).
Un equipo usa pruebas basadas en riesgos. Cada riesgo de producto se puntúa como nivel de riesgo = probabilidad × impacto, ambos de 1 (bajo) a 5 (alto). Cuatro riesgos: R1 probabilidad 2, impacto 5; R2 probabilidad 4, impacto 4; R3 probabilidad 5, impacto 2; R4 probabilidad 3, impacto 3. El equipo probará primero el de MAYOR nivel de riesgo. ¿Cuál se prueba primero y cuál es su nivel de riesgo?
R2, con un nivel de riesgo de 16.
2×5=10, 4×4=16, 5×2=10, 3×3=9 → R2 (16) es el mayor y se prueba primero.
R1, con un nivel de riesgo de 10.
R1 obtiene 10, no es el mayor; R2 obtiene 16.
R3, porque tiene la mayor probabilidad.
La mayor probabilidad por sí sola no maximiza el nivel; R3 obtiene solo 10.
R1, porque tiene el mayor impacto.
El mayor impacto por sí solo no maximiza el nivel; R1 obtiene 10, por debajo de R2 con 16.
R1=10, R2=16, R3=10, R4=9; el mayor es R2 con 16.
¿Cuáles DOS de los siguientes son ejemplos de riesgos de PRODUCTO (en lugar de riesgos de proyecto)? (Elija dos.)
El software podría calcular mal los intereses y mostrar saldos incorrectos.
Un defecto en el software entregado que afecta la calidad es un riesgo de producto.
Bajo carga alta el sistema podría responder demasiado lento para los usuarios.
El mal rendimiento del producto es un riesgo de producto relacionado con la calidad.
Testers clave podrían dejar el equipo antes de terminar la fase de prueba.
El personal/disponibilidad es un riesgo de proyecto, no de producto.
El entorno de prueba podría no ser entregado a tiempo por el proveedor.
Los retrasos de un proveedor que afectan el calendario son un riesgo de proyecto.
Los riesgos de producto se refieren a la calidad del producto; los de proyecto, a la gestión del proyecto (plazos, personal, etc.).
Un líder de pruebas estima el esfuerzo de ejecutar una suite con la técnica de tres puntos (PERT): Estimación = (Optimista + 4 × Más probable + Pesimista) / 6. Optimista 4 días, más probable 7 días, pesimista 16 días. ¿Cuál es la estimación de tres puntos?
8 días.
(4 + 28 + 16) / 6 = 48 / 6 = 8 días.
9 días.
9 resultaría de un error aritmético; la media ponderada correcta es 8.
7 días.
7 es solo el valor más probable, no la estimación ponderada de tres puntos.
9,5 días.
9,5 es un promedio simple mal calculado; la fórmula PERT pondera el valor más probable por 4.
(4 + 4×7 + 16) / 6 = (4 + 28 + 16) / 6 = 48 / 6 = 8 días.
¿Cuál es el propósito principal del monitoreo y control de pruebas durante la ejecución?
Recopilar información sobre el progreso y usarla para guiar acciones correctivas hacia los objetivos.
El monitoreo recopila métricas; el control actúa sobre ellas — juntos mantienen las pruebas en rumbo.
Escribir el código fuente que corrige los defectos encontrados.
Corregir código es desarrollo/depuración, no monitoreo y control de pruebas.
Garantizar que el proyecto terminará en la fecha planificada.
El monitoreo informa decisiones pero no puede garantizar el calendario.
Eliminar la necesidad de un plan de pruebas.
El monitoreo y control complementan el plan; no lo sustituyen.
El monitoreo recopila información del progreso; el control la usa para tomar acciones correctivas y cumplir objetivos.
¿Cuáles DOS de los siguientes se documentarían normalmente en un plan de pruebas? (Elija dos.)
Los objetivos, el alcance y el enfoque de prueba a utilizar.
Alcance, objetivos y enfoque son contenidos centrales de un plan.
Criterios de entrada y salida para las actividades de prueba.
Los criterios de entrada/salida son elementos estándar de un plan.
El código fuente completo de la aplicación bajo prueba.
El código fuente no forma parte del plan de pruebas.
La descripción detallada paso a paso de cada defecto encontrado.
Los informes de defectos individuales son productos aparte, no el plan.
Un plan de pruebas documenta alcance, objetivos, enfoque, calendario, recursos y criterios de entrada/salida — no los informes de defectos reales ni el código fuente.
En un equipo ágil, la 'definición de terminado' de una historia incluye 'todas las pruebas de aceptación pasan y no quedan defectos de severidad alta abiertos'. ¿A qué concepto de gestión de pruebas corresponde MÁS directamente la definición de terminado?
Criterios de salida.
La definición de terminado especifica las condiciones para considerar el trabajo completo — es decir, criterios de salida.
Criterios de entrada.
Los criterios de entrada (definición de listo) deciden cuándo puede empezar el trabajo, no cuándo termina.
Datos de prueba.
Los datos de prueba son entradas para ejecutar pruebas, ajenos a las condiciones de finalización.
Un test charter.
Un test charter guía una sesión exploratoria; no es el criterio de finalización de una historia.
Una definición de terminado actúa como criterios de salida — condiciones a cumplir antes de considerar el trabajo completo.
¿Qué DOS datos son esenciales en un buen informe de defecto para hacerlo accionable? (Elija dos.)
Pasos claros para reproducir el problema.
Los pasos de reproducción permiten a los desarrolladores observar y diagnosticar el fallo.
El resultado esperado y el resultado real (observado).
Esperado vs real define con precisión qué está mal.
El nombre del desarrollador culpable del defecto.
Culpar es contraproducente y no forma parte de un buen informe.
La suposición del tester sobre la línea exacta de código que causa el defecto.
Localizar la línea es diagnóstico del desarrollador, no un campo obligatorio.
Un buen informe incluye los pasos para reproducir y los resultados esperado y real; culpar a alguien y la causa supuesta no son esenciales.
¿Cómo apoya la gestión de la configuración a las actividades de prueba?
Identifica y versiona de forma única los ítems y productos de prueba para que las pruebas sean reproducibles y trazables.
Saber qué versiones se probaron hace los resultados fiables y reproducibles.
Escribe automáticamente los casos de prueba a partir de los requisitos.
La gestión de configuración controla versiones; no genera casos.
Garantiza que el software no tiene defectos de configuración.
Gestiona versiones pero no puede garantizar la ausencia de defectos.
Elimina la necesidad de saber en qué compilación se encontró un defecto.
Al contrario, es justo lo que permite rastrear la compilación/versión de cada defecto.
La gestión de la configuración asegura que los productos y objetos de prueba estén identificados, versionados y trazables para que los resultados sean reproducibles.
Un gerente de pruebas decide cómo se realizarán las pruebas: qué técnicas, niveles y tipos usar, cuánto automatizar y cómo asignar el esfuerzo frente a los riesgos. ¿Cómo se llama este conjunto de decisiones?
El enfoque de prueba.
El enfoque de prueba define cómo se adaptan e implementan las pruebas según el contexto y los riesgos.
La condición de prueba.
Una condición de prueba es un aspecto concreto a probar, no el enfoque global.
El caso de prueba.
Un caso de prueba es un conjunto de entradas/resultados esperados, no la estrategia.
El registro de prueba.
Un registro recoge lo ocurrido durante la ejecución, no cómo se planifica.
Es el enfoque de prueba (estrategia de prueba) — cómo se implementan las pruebas según el contexto y los riesgos.
¿Cuáles DOS de los siguientes son ejemplos de herramientas que apoyan la ejecución y el registro de pruebas? (Elija dos.)
Una herramienta de ejecución que reproduce pruebas con scripts y registra resultados.
Las herramientas de ejecución corren scripts automatizados y registran los resultados.
Un framework de pruebas unitarias que ejecuta pruebas de desarrollo e informa resultados.
Los frameworks unitarios ejecutan pruebas y capturan/reportan los registros de resultados.
Una herramienta de gestión de requisitos para almacenar y trazar requisitos.
La gestión de requisitos apoya la gestión/trazabilidad, no la ejecución y el registro.
Una herramienta de análisis estático que inspecciona el código sin ejecutarlo.
El análisis estático apoya la prueba estática, no la ejecución dinámica y el registro.
La ejecución y el registro de pruebas se apoyan en herramientas que ejecutan pruebas con scripts y capturan resultados, p. ej. herramientas de ejecución y frameworks de pruebas unitarias.
¿Qué afirmación describe, en conjunto, un beneficio realista Y un riesgo realista de la automatización de pruebas?
Beneficio: menos esfuerzo manual repetitivo y retroalimentación más rápida; Riesgo: los scripts requieren mantenimiento y las expectativas pueden ser demasiado altas.
La automatización ahorra esfuerzo repetitivo pero añade costo de mantenimiento y riesgo de dependencia excesiva — visión equilibrada.
Beneficio: encuentra más tipos de defectos que cualquier humano; Riesgo: ninguno, una vez configurada.
La automatización no encuentra inherentemente más tipos de defectos y siempre conlleva riesgos de mantenimiento.
Beneficio: elimina la necesidad de diseño de pruebas; Riesgo: es más lenta que las pruebas manuales.
La automatización sigue necesitando buen diseño y suele ser más rápida, no más lenta, en ejecuciones repetidas.
Beneficio: garantiza una versión sin defectos; Riesgo: es demasiado barata para valer la pena.
Ninguna técnica garantiza una versión sin defectos, y el bajo costo no es un riesgo.
La automatización puede reducir el esfuerzo manual repetitivo (beneficio) pero conlleva costos de mantenimiento y puede generar dependencia excesiva (riesgo).