ISTQB Foundation (CTFL v4.0) Examen de práctica #15 — 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 es un objetivo típico de las pruebas?
Evaluar productos de trabajo y encontrar defectos
Encontrar defectos y evaluar la calidad es un objetivo central de las pruebas.
Demostrar que el software no contiene defectos
Es imposible demostrar la ausencia de defectos; las pruebas solo muestran que hay defectos presentes.
Corregir los defectos hallados durante la ejecución
Corregir defectos es depuración, una actividad de desarrollo, no un objetivo de las pruebas.
Garantizar que el sistema es apto para todo uso posible
Las pruebas reducen el riesgo pero no pueden garantizar la aptitud para todos los usos.
Las pruebas tienen varios objetivos, entre ellos encontrar defectos, generar confianza en el nivel de calidad y aportar información para la toma de decisiones. Probar la ausencia de defectos es imposible.
Un equipo ejecuta la misma suite de regresión automatizada sin cambios durante meses y casi no encuentra defectos nuevos. ¿Qué principio de prueba lo explica mejor?
La paradoja del pesticida
Las pruebas idénticas repetidas pierden con el tiempo la capacidad de encontrar defectos nuevos.
Las pruebas muestran la presencia de defectos, no su ausencia
Es un principio válido, pero no explica por qué la repetición deja de hallar defectos.
Los defectos se agrupan
La agrupación de defectos trata de dónde se concentran, no del efecto de repetir pruebas.
Probar temprano ahorra tiempo y dinero
Este principio trata del momento de probar, no de la pérdida de eficacia por repetición.
La paradoja del pesticida indica que repetir las mismas pruebas deja de encontrar defectos nuevos; hay que revisarlas y actualizarlas.
Un desarrollador escribe mal una fórmula en una hoja. La fórmula errónea queda en el código y al generar el informe muestra un total incorrecto. Relacione error, defecto y fallo en orden.
Escribir mal = error; fórmula errónea en el código = defecto; total incorrecto = fallo
Es la cadena causal correcta: error → defecto → fallo.
Escribir mal = defecto; fórmula errónea = fallo; total incorrecto = error
El orden es incorrecto; la equivocación humana es un error, no un defecto.
Escribir mal = fallo; fórmula errónea = error; total incorrecto = defecto
Incorrecto; la salida errónea observable es el fallo, no la equivocación.
Los tres son lo mismo descrito de otra forma
Error, defecto y fallo son conceptos distintos con una relación causal.
Una equivocación humana (error) introduce un defecto en el código que, al ejecutarse, produce un fallo (comportamiento incorrecto observable).
¿Qué afirmación sobre la diferencia entre probar y depurar es correcta?
Probar puede provocar fallos; depurar localiza y corrige los defectos subyacentes
Separa correctamente ambas actividades.
Probar y depurar son dos nombres para la misma actividad
Son actividades distintas con objetivos diferentes.
La depuración siempre precede a las pruebas
Las pruebas suelen revelar fallos primero; la depuración las sigue para corregir.
Solo los testers depuran, nunca los desarrolladores
La depuración suele realizarla el desarrollador, no el tester.
Las pruebas pueden provocar fallos causados por defectos; la depuración es la actividad de desarrollo de localizar, analizar y corregir esos defectos.
Durante una revisión de requisitos, el equipo comprueba según la especificación: «¿Estamos construyendo el producto correctamente?». ¿Qué actividad es?
Verificación
Comprobar la conformidad con la especificación es verificación.
Validación
La validación pregunta si se construye el producto correcto para necesidades reales, no la conformidad con la especificación.
Depuración
La depuración corrige defectos, sin relación con esta comprobación.
Reprueba
La reprueba confirma una corrección; no trata de la conformidad con la especificación.
La verificación comprueba si un producto de trabajo cumple su especificación; la validación comprueba si cumple las necesidades reales de los usuarios.
¿Por qué es valioso el análisis de causa raíz de los defectos?
Apoya la mejora del proceso para prevenir defectos similares
Identificar el origen permite acciones preventivas y reduce defectos futuros.
Garantiza que el defecto actual nunca reaparecerá
El análisis reduce el riesgo de recurrencia pero no lo garantiza.
Elimina la necesidad de ejecutar pruebas
El análisis de causa raíz complementa, no sustituye, la ejecución de pruebas.
Asigna la culpa al desarrollador responsable
El objetivo es mejorar, no culpar.
Analizar la causa subyacente apoya la mejora del proceso para prevenir defectos similares en el futuro.
¿Cuáles DOS son ejemplos de la mentalidad y habilidades que debe tener un buen tester?
Curiosidad y atención al detalle
Ayudan a los testers a notar anomalías y diseñar pruebas exhaustivas.
Buena comunicación y pensamiento crítico
Los testers deben comunicar hallazgos con claridad y cuestionar supuestos.
Autoridad para aprobar presupuestos del proyecto
Aprobar presupuestos es responsabilidad de gestión, no una habilidad del tester.
Escribir siempre el código de producción bajo prueba
Escribir código de producción es tarea de desarrollo, no una habilidad definitoria del tester.
Los testers se benefician de la curiosidad, atención al detalle, buena comunicación y pensamiento crítico. Escribir código de producción o aprobar presupuestos no son habilidades de prueba.
El proceso de prueba de ISTQB se describe como un conjunto de actividades, pero en la práctica no se realizan estrictamente una después de otra. ¿Cuáles DOS afirmaciones describen correctamente su relación en la práctica? (Elija dos.)
Las actividades pueden solaparse, ejecutarse en paralelo o repetirse; por ejemplo, el diseño de pruebas de funcionalidades posteriores continúa mientras ya se ejecutan pruebas anteriores.
Correcto — el proceso no es estrictamente secuencial; la iteración y el solape son normales, sobre todo en ciclos iterativos e incrementales.
La monitorización y control de pruebas acompaña continuamente a las demás actividades, en lugar de ocupar una posición fija entre dos de ellas.
Correcto — la monitorización y control se ejerce durante todo el esfuerzo, realimentando información y ajustando las demás actividades cuando es necesario.
La planificación de pruebas se realiza una sola vez al inicio del proyecto y nunca se revisa después.
Los planes se actualizan cuando la monitorización y control revela desviaciones o cuando cambian riesgos y prioridades; la planificación se retoma durante el proyecto.
El análisis de pruebas debe estar totalmente terminado para todo el sistema antes de poder iniciar el diseño.
Describe una secuencia rígida que el programa no exige. Análisis y diseño suelen avanzar funcionalidad por funcionalidad; el diseño empieza cuando existen las condiciones de prueba correspondientes.
Las actividades pueden solaparse, ejecutarse en paralelo e iterarse, y la monitorización y control es una actividad continua que acompaña todo el esfuerzo de prueba en lugar de ocupar una posición única en una secuencia.
En un ciclo de vida secuencial (modelo en V), ¿cuándo debería comenzar idealmente el análisis y diseño de pruebas para el nivel de prueba de sistema?
En cuanto estén disponibles los requisitos del sistema
El diseño de pruebas puede empezar sobre los requisitos, en paralelo al desarrollo.
Solo después de escribir todo el código
Esperar a que el código esté completo contradice el principio de prueba temprana.
Solo después de que la prueba de componentes pase por completo
El diseño de la prueba de sistema no debe esperar a que termine la de componentes.
Durante la fase de mantenimiento
Es demasiado tarde; el diseño debe alinearse con la fase de requisitos.
En el modelo en V, las actividades de prueba de cada nivel comienzan en cuanto está disponible la base correspondiente (p. ej. requisitos del sistema), en paralelo al desarrollo — una aplicación de las pruebas tempranas.
Un equipo introduce análisis estático y pruebas unitarias durante la codificación y revisa los requisitos antes de empezar a desarrollar. ¿Qué enfoque aplican?
Un enfoque shift-left
Adelantar las actividades de prueba es precisamente la idea de shift-left.
Un enfoque shift-right
Shift-right enfatiza probar en producción/operación, no las actividades tempranas.
Integración big-bang
Es una estrategia de integración, ajena al momento de las actividades de prueba.
Pruebas exploratorias
Las pruebas exploratorias son una técnica basada en la experiencia, no una decisión temporal.
«Shift left» significa realizar las actividades de prueba antes en el ciclo de vida, como revisar requisitos y probar durante la codificación.
Se ejecutan pruebas para verificar que las interfaces e interacciones entre módulos integrados funcionan correctamente, antes de probar todo el sistema. ¿Qué nivel de prueba es?
Prueba de integración
Se dirige específicamente a interfaces e interacciones entre módulos.
Prueba de componentes
La prueba de componentes verifica módulos aislados, no sus interacciones.
Prueba de aceptación
La prueba de aceptación valida la disposición para el uso, normalmente por usuarios, más adelante.
Prueba de regresión
La regresión es un tipo de prueba que se repite tras cambios, no un nivel sobre interfaces.
La prueba de integración se centra en las interacciones entre componentes o sistemas; se sitúa entre la prueba de componentes y la de sistema.
Un tester mide el tiempo de respuesta bajo carga y comprueba que el sistema se mantiene dentro de un umbral acordado. ¿Qué tipo de prueba es?
Prueba no funcional
El rendimiento/tiempo de respuesta es una característica de calidad no funcional.
Prueba funcional
La prueba funcional verifica qué hace el sistema, no cómo de bien rinde.
Prueba de caja blanca
La caja blanca deriva pruebas de la estructura interna, no de un umbral de rendimiento.
Prueba de confirmación
La prueba de confirmación reejecuta una prueba tras una corrección; no trata del rendimiento.
Las pruebas no funcionales evalúan características como eficiencia de rendimiento, usabilidad y fiabilidad. El tiempo de respuesta bajo carga es rendimiento (no funcional).
Un banco despliega un parche de seguridad en un sistema de pagos en producción desde hace años. ¿Qué tipo de prueba se activa principalmente?
Prueba de mantenimiento
Los cambios en un sistema operativo activan pruebas de mantenimiento con análisis de impacto.
Prueba de componentes
La prueba de componentes se dirige a módulos nuevos aislados, no a cambios en un sistema vivo.
Solo prueba de aceptación
Puede haber aceptación, pero el detonante es un cambio en un sistema operativo.
No se necesita ninguna prueba para un parche
Los parches en sistemas vivos requieren pruebas para gestionar el riesgo de regresión.
Las pruebas de mantenimiento se activan por modificaciones a un sistema en operación, como parches, actualizaciones o migraciones, e incluyen análisis de impacto y pruebas de regresión.
Tras corregir un defecto, el equipo quiere (a) confirmar que la corrección funciona y (b) asegurar que nada más se rompió. ¿Cuáles DOS afirmaciones describen correctamente la prueba de confirmación y la de regresión?
La prueba de confirmación reejecuta la prueba que falló antes, tras la corrección
La confirmación verifica que el defecto concreto está resuelto.
La prueba de regresión comprueba que las partes no cambiadas siguen funcionando tras el cambio
La regresión detecta efectos secundarios no intencionados de los cambios.
La prueba de confirmación mide el rendimiento bajo carga pico
Eso describe la prueba de rendimiento, no la de confirmación.
La prueba de regresión solo se hace manualmente
La regresión es una firme candidata a la automatización y no es solo manual.
La prueba de confirmación reejecuta la prueba fallida tras la corrección; la de regresión comprueba que las áreas no cambiadas siguen funcionando tras el cambio.
¿Cuál es un beneficio clave de las pruebas estáticas frente a las dinámicas?
Los defectos se encuentran antes, sin ejecutar código
Las pruebas estáticas detectan defectos en productos tempranos y reducen el coste posterior.
Mide el rendimiento real en ejecución
El comportamiento en ejecución requiere pruebas dinámicas, no estáticas.
Elimina la necesidad de cualquier prueba dinámica
Las pruebas estáticas y dinámicas son complementarias, no sustitutas.
Solo puede aplicarse al código fuente
Las pruebas estáticas se aplican a muchos productos, incluidos requisitos y diseños.
Las pruebas estáticas examinan productos de trabajo sin ejecutar código, por lo que pueden hallar defectos (p. ej. en requisitos) antes y de forma más económica que las dinámicas.
Una revisión formal es dirigida por un moderador capacitado, usa roles definidos y criterios de entrada/salida, recopila métricas y sigue un proceso documentado. ¿Qué tipo de revisión es?
Inspección
La inspección es el tipo más formal, con moderador, roles y métricas.
Revisión informal
Una revisión informal no tiene proceso, roles ni métricas definidos.
Recorrido (walkthrough)
El recorrido lo dirige el autor y es menos formal que una inspección.
Revisión en pareja ad-hoc
Es informal y carece de los roles y métricas definidos de una inspección.
La inspección es el tipo de revisión más formal: dirigida por un moderador capacitado, con roles definidos, reglas, listas de verificación, métricas y criterios de salida formales.
En una revisión formal, ¿quién es el principal responsable del producto de trabajo revisado y de corregir los defectos identificados?
El autor
El autor es dueño del producto y corrige los defectos hallados.
El moderador
El moderador dirige el proceso; no es dueño ni corrige el producto.
El escriba
El escriba documenta hallazgos pero no es responsable del producto.
El representante de la dirección
La dirección puede patrocinar la revisión pero no corrige el producto.
El autor es responsable del producto de trabajo bajo revisión y de corregir los defectos hallados.
Una especificación de requisitos muy extensa se revisa repetidamente, pero las revisiones encuentran poco y los revisores se quejan de fatiga y de falta de tiempo de preparación. ¿Qué DOS medidas abordan factores de éxito reconocidos de las revisiones? (Elija dos.)
Dividir la especificación en partes pequeñas para que los revisores no pierdan la concentración durante la revisión individual.
Correcto — mantener pequeñas las porciones revisadas es un factor de éxito explícito, porque la efectividad cae bruscamente al perderse la concentración.
Conseguir que la dirección asigne tiempo suficiente en el calendario para la preparación y el seguimiento de la revisión.
Correcto — el apoyo de la dirección, con tiempo suficiente para preparar y para actuar sobre los hallazgos, es uno de los factores organizativos de éxito.
Incluir el número de anomalías encontradas en cada documento en la evaluación de desempeño del autor.
Eso convierte la revisión en evaluación personal y destruye la confianza de la que depende. Las anomalías deben plantearse objetivamente sobre el producto, nunca para juzgar a quien lo escribió.
Eliminar las revisiones y confiar en pruebas dinámicas adicionales del producto terminado.
La prueba dinámica no puede examinar un documento de requisitos, y problemas como ambigüedades o contradicciones aparecerían mucho más tarde y con un coste de corrección muy superior.
Entre los factores de éxito reconocidos están dividir los productos grandes en partes pequeñas para que los revisores mantengan la concentración y el apoyo de la dirección proporcionando tiempo suficiente para preparación y seguimiento. Además, las revisiones deben ser objetivas y nunca usarse para evaluar personas.
¿Qué afirmación describe mejor la partición de equivalencia (EP)?
Los datos se dividen en grupos que se espera tratar igual, probando un valor por grupo
Es la definición de la partición de equivalencia.
Debe probarse individualmente cada valor de entrada posible
Eso es prueba exhaustiva, que la EP evita explícitamente.
Solo se prueban valores en los extremos de los rangos
Probar extremos es análisis de valores límite, no partición de equivalencia.
Las pruebas se derivan del flujo de control del código
Derivar del flujo de control es una técnica de caja blanca, no EP.
La EP divide los datos de entrada (o salida) en particiones que se espera procesar igual; un valor por partición es representativo y reduce el número de casos de prueba.
Un campo «edad» acepta enteros. Reglas: 0–17 = «menor», 18–64 = «adulto», 65 o más = «senior», y cualquier valor menor que 0 es inválido. Con partición de equivalencia, ¿cuál es el número MÍNIMO de casos para cubrir cada partición exactamente una vez?
4
Cuatro particiones (inválida, menor, adulto, senior) requieren cuatro casos.
3
Omite la partición inválida (<0).
6
Solo hay cuatro particiones, no seis.
8
Ocho es demasiado; la EP necesita un valor por partición.
Particiones: inválida (<0), menor (0–17), adulto (18–64), senior (≥65). Son 4 particiones, por tanto un mínimo de 4 casos, uno por partición.
Una entrada numérica acepta valores de 1 a 100 inclusive. Con análisis de valores límite de 2 valores, ¿qué conjunto prueba los límites del rango válido?
0, 1, 100, 101
Son los dos pares límite del rango 1..100 en el AVL de 2 valores.
1, 50, 100
50 es un valor medio, no un límite; faltan los vecinos 0 y 101.
0, 1, 2, 99, 100, 101
Mezcla vecinos de AVL de 3 valores (2 y 99) que no hacen falta en 2 valores.
1, 100
Omite los valores inválidos vecinos 0 y 101 que requiere el AVL de 2 valores.
El AVL de 2 valores usa el límite y su vecino inmediato del otro lado. Para 1..100 son {0,1} en el límite inferior y {100,101} en el superior.
Un campo de temperatura acepta de 10 a 30 inclusive. Con análisis de valores límite de 3 valores, ¿cuántos valores límite distintos se prueban entre el límite inferior y el superior?
6
Inferior {9,10,11} y superior {29,30,31} dan seis valores distintos.
4
Cuatro valores corresponden al AVL de 2 valores, no de 3.
3
Tres cubre solo un límite; se necesitan ambos.
8
Ocho es demasiado; cada límite aporta tres valores, en total seis.
El AVL de 3 valores prueba cada límite más el valor a cada lado. Inferior: 9,10,11. Superior: 29,30,31. Son 6 valores distintos.
R5 — 25 %
Socio=N, Martes=Sí, Senior=Sí coincide con R5, 25 %.
R1 — 40 %
R1 exige que el cliente también sea socio (Socio=Sí).
R6 — 20 %
R6 exige senior=N; aquí el cliente es senior.
R7 — 10 %
R7 exige Martes=N; aquí la función es un martes.
Socio = N, Martes = Sí, Senior = Sí. Esa combinación es la regla R5, que da un 25 % de descuento.
La tabla de decisión del cine tiene tres condiciones binarias independientes (¿socio?, ¿martes?, ¿senior?) y ninguna combinación es inviable. ¿Cuántas columnas de reglas se requieren para la cobertura completa de la tabla?
8
2^3 = 8 combinaciones de tres condiciones binarias.
6
Seis se queda corto; tres condiciones binarias dan ocho combinaciones.
3
Tres es el número de condiciones, no de reglas.
16
16 = 2^4 requeriría cuatro condiciones, no tres.
Con tres condiciones binarias independientes y sin combinaciones inviables, la cobertura completa necesita 2^3 = 8 reglas, correspondientes a R1–R8.
start → pause → resume → submit → grade
Cada transición de esta secuencia existe en la máquina.
start → grade → submit
grade solo es válido desde Submitted, no puede seguir directamente a start.
pause → start → submit
pause no es válido desde NotStarted; la sesión debe iniciarse primero.
start → submit → resume
resume solo es válido desde Paused, no desde Submitted.
Transiciones válidas: start (NotStarted→InProgress), pause (InProgress→Paused), resume (Paused→InProgress), submit (InProgress→Submitted), grade (Submitted→Graded). La secuencia start, pause, resume, submit, grade las sigue todas.
5
Hay exactamente cinco transiciones válidas que cubrir una vez cada una.
4
Cuatro omite una transición; hay cinco en total.
6
Solo hay cinco transiciones válidas, no seis.
5 estados significan 5, pero con transiciones inválidas hay más
La cobertura 0-switch cuenta solo transiciones válidas, que son cinco.
La cobertura 0-switch (transición única) exige ejercitar cada transición válida una vez. La máquina tiene 5 transiciones (start, pause, resume, submit, grade), por tanto 5 casos.
¿Qué técnica deriva casos de prueba a partir de secuencias de interacciones entre un actor y el sistema para probar flujos de negocio de extremo a extremo?
Prueba de casos de uso
Deriva pruebas de secuencias de interacción actor-sistema.
Prueba de sentencias
La prueba de sentencias es una técnica de caja blanca basada en código, no en interacciones.
Análisis de valores límite
El AVL apunta a límites de rangos de entradas individuales, no a flujos de interacción.
Prueba de tabla de decisión
Las tablas de decisión modelan combinaciones de condiciones, no secuencias de interacción del actor.
La prueba de casos de uso deriva pruebas de los casos de uso, que describen interacciones entre actores y el sistema, y es eficaz para escenarios de extremo a extremo e integración.
¿Cuáles DOS de las siguientes son técnicas de prueba basadas en la experiencia?
Conjetura de errores
La conjetura de errores usa la experiencia del tester sobre defectos probables.
Pruebas exploratorias
Las pruebas exploratorias se basan en que el tester aprende y diseña pruebas a la vez.
Partición de equivalencia
La EP es una técnica de caja negra basada en especificación, no en experiencia.
Prueba de tabla de decisión
La prueba de tabla de decisión es basada en especificación, derivada de combinaciones de condiciones.
Las técnicas basadas en la experiencia se apoyan en el conocimiento e intuición del tester. La conjetura de errores y las pruebas exploratorias lo son; la partición de equivalencia y la tabla de decisión son de caja negra (basadas en especificación).
¿Cuáles DOS de las siguientes son técnicas de caja negra (basadas en especificaciones)? (Seleccione DOS.)
Análisis de valores límite.
Correcto — el BVA es una técnica basada en especificaciones (caja negra).
Prueba de transición de estados.
Correcto — deriva pruebas de una especificación de comportamiento (modelo de estados).
Prueba de sentencias.
La prueba de sentencias es una técnica de caja blanca basada en código.
Prueba de ramas.
La prueba de ramas es una técnica de caja blanca basada en el flujo de control.
Conjetura de errores.
La conjetura de errores es una técnica basada en experiencia, no en especificaciones.
Las técnicas de caja negra incluyen partición de equivalencia, análisis de valores límite, tabla de decisión y transición de estados. Sentencias y ramas son caja blanca; la conjetura de errores es basada en experiencia.
Un tester estima una tarea con estimación de tres puntos (PERT): optimista = 5 días, más probable = 8 días, pesimista = 17 días. ¿Cuál es el esfuerzo estimado con la fórmula (a + 4m + b) / 6?
9 días
(5 + 32 + 17)/6 = 54/6 = 9.
10 días
10 ignora la ponderación ×4 del valor más probable.
8 días
8 es solo el valor más probable, no la media ponderada PERT.
11 días
11 es un error de cálculo; el valor PERT correcto es 9.
(5 + 4×8 + 17) / 6 = (5 + 32 + 17) / 6 = 54 / 6 = 9 días.
¿Qué dos factores determinan el nivel de un riesgo de producto?
La probabilidad de ocurrencia y el impacto si ocurre
Nivel de riesgo = probabilidad × impacto.
El número de testers y el presupuesto de prueba
Son factores de recursos, no la definición del nivel de riesgo.
El lenguaje de programación y el IDE usado
Las herramientas no definen el nivel de riesgo de producto.
El número de casos de prueba y su longitud
La cantidad de casos no determina el nivel de riesgo.
El nivel de riesgo lo determinan la probabilidad de que ocurra y el impacto (daño) si ocurre.
¿Cuál de las siguientes es una métrica de progreso común en la monitorización de pruebas?
Porcentaje de casos de prueba planificados ejecutados
Es una métrica estándar de progreso.
El número de líneas de comentarios en el código
El conteo de comentarios no es una métrica de progreso.
El salario del equipo de prueba
El salario no es una métrica de progreso.
La temperatura de la oficina durante las pruebas
Es irrelevante para el progreso de la prueba.
La monitorización usa métricas como el porcentaje de casos planificados ejecutados, tasas de aprobado/fallo y tendencias de descubrimiento/cierre de defectos para seguir el avance frente al plan.
Un equipo define una regla de que la prueba de sistema solo puede comenzar cuando el build esté desplegado en el entorno de prueba y todos los defectos críticos de componentes estén corregidos. ¿De qué es esto un ejemplo?
Criterios de entrada
Son precondiciones que deben cumplirse antes de iniciar la prueba.
Criterios de salida
Los criterios de salida definen cuándo puede terminar la prueba, no cuándo empezar.
Un acta de prueba (charter)
Un charter guía una sesión exploratoria, no las precondiciones de entrada.
Un informe de defecto
Un informe de defecto documenta un fallo concreto, no precondiciones de actividad.
Los criterios de entrada (definición de listo) son las precondiciones que deben cumplirse antes de que una actividad de prueba pueda comenzar.
¿Cuáles DOS elementos se documentan típicamente en un plan de pruebas?
Alcance y objetivos de la prueba
Alcance y objetivos son contenido central del plan.
Criterios de entrada y salida
Los criterios de entrada/salida son elementos estándar del plan.
El código fuente completo de la aplicación
El código fuente no se documenta en el plan.
El diff exacto de código de cada corrección
Los diffs de código van en el control de versiones, no en el plan.
Un plan de pruebas documenta típicamente el alcance/objetivos, el enfoque, el cronograma, los recursos y los criterios de entrada/salida. El código fuente y las correcciones individuales no forman parte del plan.
¿Cuál es el propósito principal de la gestión de la configuración en el contexto de las pruebas?
Identificar y controlar versiones de testware y elementos de software para que las pruebas sean reproducibles
Es exactamente lo que aporta la gestión de la configuración.
Escribir el código fuente de producción
Escribir código es tarea de desarrollo, no gestión de configuración.
Priorizar riesgos por probabilidad e impacto
Eso es análisis de riesgos, otra actividad de gestión.
Garantizar cero defectos en la versión
Ninguna actividad puede garantizar cero defectos.
La gestión de la configuración establece y mantiene la integridad de los productos de trabajo (casos de prueba, testware, elementos de software) mediante identificación única y control de versiones, para que las pruebas sean trazables y reproducibles.
¿Qué DOS informaciones debería contener un informe de defecto bien escrito?
Pasos para reproducir el fallo
Los pasos de reproducción permiten confirmar y localizar el defecto.
Resultado esperado frente a resultado real
Comparar esperado y real aclara por qué el comportamiento es un defecto.
El nombre del desarrollador culpable
Los informes deben ser objetivos, no asignar culpas.
Un plazo vinculante para entregar la corrección
Programar correcciones es decisión de gestión, no parte del informe.
Un buen informe de defecto incluye pasos para reproducir, resultado esperado frente al real, severidad/prioridad y entorno. No debe contener culpas ni un tiempo de corrección impuesto.
Un jefe de pruebas estima el esfuerzo analizando datos medidos de proyectos similares anteriores (p. ej. cifras históricas de defectos y productividad). ¿Qué enfoque de estimación es?
Estimación basada en métricas
Usa datos medidos de proyectos anteriores.
Estimación basada en expertos
La basada en expertos se apoya en el juicio, no en datos históricos medidos.
Análisis de valores límite
El AVL es una técnica de diseño, no un enfoque de estimación.
Estimación exploratoria
No es una técnica de estimación reconocida en el temario.
La estimación basada en métricas usa datos de proyectos pasados; la basada en expertos se apoya en el juicio de personas con experiencia.
¿Cuál describe MEJOR el papel de la gestión de la configuración como apoyo a las pruebas?
Identifica y controla versiones de los elementos y el testware.
Correcto — la GC sustenta pruebas reproducibles.
Diseña los casos automáticamente.
La GC no diseña casos.
Garantiza que el software no tiene defectos.
La GC no lo garantiza.
Aprueba el presupuesto del proyecto.
Una función de gestión.
La GC asegura que los elementos y el testware estén identificados y con control de versiones, para que las pruebas sean reproducibles.
Un equipo usa una herramienta que captura y reproduce interacciones de usuario y compara automáticamente los resultados reales con los esperados. ¿Qué categoría de herramienta es?
Herramienta de ejecución (captura/reproducción)
Automatiza la ejecución de pruebas y la comparación de resultados.
Herramienta de análisis estático
El análisis estático examina código sin ejecutarlo, a diferencia de esta herramienta.
Herramienta de gestión de requisitos
Gestiona requisitos, no la ejecución automatizada de pruebas.
Herramienta de pruebas de rendimiento
Las de rendimiento generan carga y miden tiempos, no captura/reproducción de UI con comparación.
Las herramientas de ejecución de pruebas (incluidas captura/reproducción) ejecutan pruebas automáticamente y comparan resultados reales con esperados, apoyando la regresión.
¿Cuáles DOS son riesgos o costes potenciales de introducir la automatización de pruebas?
Esfuerzo de mantenimiento continuo cuando cambia la aplicación
Los scripts automatizados deben actualizarse al cambiar el sistema bajo prueba.
Inversión inicial en herramientas y competencias
Herramientas, configuración y formación suponen un coste inicial notable.
Garantiza que se encontrarán todos los defectos
Ningún enfoque puede garantizar hallar todos los defectos.
Elimina la necesidad de diseñar casos de prueba
La automatización ejecuta pruebas; no sustituye el análisis y diseño.
La automatización conlleva sobrecoste de mantenimiento de los scripts y requiere inversión inicial/competencias. No elimina la necesidad de diseño de pruebas ni garantiza encontrar todos los defectos.