ISTQB Foundation (CTFL v4.0) Examen de práctica #14 — 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.
¿Por qué es necesario probar en un proyecto de desarrollo de software?
Reduce el riesgo de que ocurran fallos en operación
Correcto — una razón central de las pruebas es reducir el riesgo residual antes del lanzamiento.
Demuestra que el software no contiene defectos
Incorrecto — las pruebas no pueden demostrar la ausencia de defectos (principio de prueba).
Elimina la necesidad de revisar los requisitos
Incorrecto — las pruebas dinámicas complementan las revisiones estáticas, no las sustituyen.
Garantiza que el software satisfará a todos los usuarios
Incorrecto — ninguna cantidad de pruebas garantiza satisfacción universal.
Las pruebas reducen el riesgo de fallos en operación; no pueden garantizar un producto libre de defectos.
¿Cuáles de los siguientes son objetivos de las pruebas? (Elija DOS.)
Encontrar defectos y fallos
Correcto — detectar defectos es un objetivo primario.
Generar confianza en el nivel de calidad
Correcto — aportar información para generar confianza es un objetivo declarado.
Corregir los defectos encontrados
Incorrecto — corregir defectos es depuración/desarrollo, no pruebas.
Demostrar que no quedan defectos
Incorrecto — imposible; las pruebas no prueban la ausencia de defectos.
Las pruebas evalúan la calidad, encuentran defectos y generan confianza en el nivel de calidad. Corregir defectos es depuración; probar que no hay defectos es imposible.
Un equipo ejecuta cada noche la misma suite de regresión automatizada. Con el tiempo encuentra cada vez menos defectos nuevos. ¿Qué principio lo explica?
La paradoja del pesticida
Correcto — reutilizar pruebas idénticas deja de revelar defectos nuevos; hay que variarlas.
Agrupamiento de defectos
Incorrecto — el agrupamiento trata de la concentración de defectos en pocos módulos.
Las pruebas dependen del contexto
Incorrecto — este principio trata de adaptar las pruebas al contexto.
Falacia de la ausencia de defectos
Incorrecto — esa falacia trata de calidad vs. necesidades del usuario.
La paradoja del pesticida: repetir las mismas pruebas deja de encontrar defectos nuevos; hay que revisarlas y modificarlas.
Un desarrollador escribe mal una fórmula. Más tarde el programa muestra un total incorrecto en pantalla. En términos ISTQB, ¿qué es ese total incorrecto?
Un fallo
Correcto — una desviación observable del resultado esperado es un fallo.
Un error
Incorrecto — el error es la equivocación humana (escribir mal).
Un defecto
Incorrecto — el defecto es la fórmula defectuosa en el código.
Una causa raíz
Incorrecto — la causa raíz es el origen subyacente del error.
Error (equivocación) → defecto (en el código) → fallo (comportamiento erróneo observable). La salida errónea es un fallo.
¿Qué afirmación distingue correctamente las pruebas de la depuración?
Las pruebas pueden mostrar fallos; la depuración localiza, analiza y elimina sus causas
Correcto — es la distinción estándar de ISTQB.
Pruebas y depuración son dos nombres de la misma actividad
Incorrecto — son actividades distintas con objetivos diferentes.
La depuración solo la realizan los testers
Incorrecto — la depuración la suelen realizar los desarrolladores.
Las pruebas eliminan defectos; la depuración solo los reporta
Incorrecto — invierte los roles; las pruebas no eliminan defectos.
Las pruebas pueden provocar fallos; la depuración es la actividad de desarrollo que localiza, analiza y corrige los defectos.
Un producto tiene muy pocos defectos pero los usuarios lo rechazan porque no cubre sus necesidades reales. ¿Qué principio ilustra esto?
La falacia de la ausencia de defectos
Correcto — pocos defectos no garantizan un sistema que cubra las necesidades.
Probar pronto ahorra tiempo y dinero
Incorrecto — ese principio trata de anticipar las pruebas, no las necesidades.
Las pruebas muestran la presencia de defectos
Incorrecto — ese principio trata de lo que las pruebas pueden probar.
Las pruebas exhaustivas son imposibles
Incorrecto — ese principio trata de la inviabilidad de probarlo todo.
Falacia de la ausencia de defectos: encontrar y corregir defectos no sirve si el sistema no cubre las necesidades del usuario.
¿En qué actividad de prueba se derivan las condiciones de prueba y los elementos de cobertura a partir de la base de prueba?
Análisis de prueba
Correcto — el análisis deriva condiciones y elementos de cobertura de la base.
Diseño de prueba
Incorrecto — el diseño convierte las condiciones en casos concretos.
Implementación de prueba
Incorrecto — la implementación prepara el testware para la ejecución.
Finalización de prueba
Incorrecto — la finalización archiva el testware e informa al final.
El análisis de prueba identifica características comprobables y define condiciones de prueba desde la base ("qué"). El diseño define los casos ("cómo").
Un equipo guarda sus casos de prueba, scripts automatizados y datos de prueba en el mismo sistema de control de versiones que el código que ejercitan. ¿Cuál es el beneficio principal de someter así el testware a gestión de la configuración?
Los cambios en el testware son trazables y cada versión puede reproducirse y relacionarse con la versión del objeto de prueba a la que pertenece.
Correcto — esa es exactamente la razón por la que el testware debe estar bajo gestión de la configuración: identificable, versionado y coherente con el objeto de prueba.
Garantiza que las pruebas revelarán todos los defectos restantes en el objeto de prueba.
Ninguna práctica lo garantiza. La prueba puede mostrar la presencia de defectos, pero nunca demostrar su ausencia, con independencia de las herramientas.
Elimina la necesidad de mantener el testware cuando cambia el objeto de prueba.
La gestión de la configuración registra y controla los cambios, no los realiza. El testware sigue necesitando mantenimiento cuando el objeto evoluciona.
Hace que el objeto de prueba sea independiente del entorno en el que se ejecuta.
Versionar el testware no dice nada sobre dependencias del entorno. Las diferencias de entorno siguen siendo una causa conocida de fallos que solo aparecen en producción.
La gestión de la configuración del testware hace trazables los cambios y permite reproducir cualquier versión del testware y relacionarla con la versión del objeto de prueba para la que se creó, algo esencial para las pruebas de regresión y de mantenimiento.
En un ciclo de vida secuencial (modelo en V), ¿cuándo deberían comenzar idealmente la planificación y el diseño de pruebas del nivel de prueba de sistema?
En cuanto estén disponibles los requisitos del sistema
Correcto — la participación temprana permite diseñar contra los requisitos y hallar defectos pronto.
Después de escribir todo el código
Incorrecto — esperar al final del código retrasa la detección y encarece.
Solo tras superar las pruebas de componente
Incorrecto — la planificación puede empezar mucho antes, en paralelo.
Durante la fase de pruebas de aceptación
Incorrecto — eso es demasiado tarde para el nivel de sistema.
Shift-left: las actividades de prueba de un nivel deben empezar en cuanto exista la base correspondiente (p. ej., requisitos de sistema), no tras codificar.
¿Qué nivel de prueba verifica principalmente las interfaces e interacciones entre componentes o sistemas integrados?
Pruebas de integración
Correcto — se enfoca en interfaces e interacciones entre elementos integrados.
Pruebas de componente
Incorrecto — verifican componentes individuales de forma aislada.
Pruebas de aceptación
Incorrecto — establecen la disposición de uso frente a necesidades del usuario.
Pruebas de sistema
Incorrecto — evalúan el comportamiento del sistema completo.
Las pruebas de integración se centran en interfaces e interacciones entre componentes o sistemas.
¿Cuáles de los siguientes son ejemplos de pruebas no funcionales? (Elija DOS.)
Medir el tiempo de respuesta bajo carga máxima
Correcto — la eficiencia de rendimiento es un atributo no funcional.
Evaluar con qué facilidad los nuevos usuarios completan una tarea
Correcto — la usabilidad es un atributo no funcional.
Comprobar que un descuento se calcula correctamente
Incorrecto — verificar un cálculo contra una regla es prueba funcional.
Verificar que un login acepta credenciales válidas
Incorrecto — comprobar comportamiento funcional esperado es prueba funcional.
Las pruebas no funcionales evalúan el cómo — rendimiento, usabilidad, fiabilidad, seguridad. Verificar un cálculo o una regla de negocio es funcional.
Tras corregir un defecto en el módulo de pago, el equipo vuelve a ejecutar exactamente las pruebas que fallaban para confirmar la corrección. ¿Cómo se llama?
Prueba de confirmación (reprueba)
Correcto — confirma que el defecto original se corrigió.
Prueba de regresión
Incorrecto — busca efectos secundarios no deseados en otras áreas.
Prueba de humo
Incorrecto — la prueba de humo comprueba de forma amplia y superficial la estabilidad del build.
Prueba de mantenimiento
Incorrecto — es una actividad más amplia por cambios en un sistema en operación.
Reejecutar las pruebas que fallaban para confirmar la corrección es prueba de confirmación. La de regresión comprueba que el cambio no rompió otras áreas.
¿Qué caracteriza mejor el enfoque 'shift-left' de pruebas?
Realizar actividades de prueba antes en el ciclo de vida
Correcto — shift-left adelanta las pruebas para detectar defectos cuanto antes.
Retrasar todas las pruebas hasta justo antes del lanzamiento
Incorrecto — es lo contrario de shift-left.
Probar solo en producción con usuarios reales
Incorrecto — eso describe pruebas en producción, no shift-left.
Asignar las pruebas por completo al equipo de operaciones
Incorrecto — shift-left trata del momento, no de reasignar la responsabilidad.
Shift-left significa realizar actividades de prueba antes en el ciclo (revisar requisitos, escribir pruebas antes del código) para hallar defectos antes.
Un banco modifica su sistema central para que funcione en una nueva versión del sistema operativo, sin cambiar funcionalidades. ¿Qué tipo de mantenimiento origina esta prueba?
Mantenimiento adaptativo
Correcto — adaptar a un nuevo entorno sin cambiar funciones es adaptativo.
Mantenimiento correctivo
Incorrecto — el correctivo corrige defectos hallados en operación.
Mantenimiento perfectivo
Incorrecto — el perfectivo mejora o añade funciones/rendimiento.
Mantenimiento de emergencia
Incorrecto — la de emergencia es una corrección urgente, no una adaptación.
Adaptar el sistema a un entorno nuevo o modificado (p. ej., nuevo SO) es mantenimiento adaptativo; la prueba resultante es de mantenimiento.
¿Por qué las pruebas estáticas (p. ej., revisar un documento de requisitos) pueden ser más rentables que las dinámicas para ciertos defectos?
Encuentra defectos en productos de trabajo antes de que lleguen al código
Correcto — la detección temprana evita retrabajo costoso posterior.
Ejecuta el código más rápido que las pruebas dinámicas
Incorrecto — las pruebas estáticas no ejecutan el código.
Garantiza la eliminación de todos los defectos
Incorrecto — ninguna técnica garantiza eliminar todos los defectos.
Elimina la necesidad de cualquier prueba dinámica
Incorrecto — estáticas y dinámicas son complementarias.
Las pruebas estáticas hallan defectos directamente en productos de trabajo antes de que exista código — pronto y barato — y detectan defectos (ambigüedades) difíciles de ver dinámicamente.
¿Qué actividades forman parte del proceso de revisión según el temario? (Elija DOS.)
Revisión individual (preparación individual)
Correcto — los revisores examinan el producto individualmente y anotan hallazgos.
Comunicación y análisis de los hallazgos
Correcto — se discuten los hallazgos y se decide su estado/responsable.
Ejecutar los casos de prueba
Incorrecto — ejecutar es prueba dinámica, no parte de la revisión.
Depurar el código fuente
Incorrecto — depurar es actividad de desarrollo, no de revisión.
El proceso de revisión incluye planificar, iniciar, revisión individual, comunicación y análisis, y corregir e informar. Ejecutar casos y depurar no forman parte.
Un equipo necesita una revisión formal y documentada dirigida por un moderador capacitado, con roles definidos, criterios de entrada/salida y métricas. ¿Qué tipo encaja mejor?
Inspección
Correcto — la revisión más formal, con moderador capacitado, roles, criterios y métricas.
Revisión informal
Incorrecto — una revisión informal no tiene proceso ni roles definidos.
Recorrido (walkthrough)
Incorrecto — un walkthrough lo dirige el autor y es menos formal.
Revisión técnica
Incorrecto — la revisión técnica es formal pero se centra en decisiones técnicas y suele dirigirla un par.
La inspección es el tipo más formal: dirigida por un moderador capacitado, con roles definidos, criterios y métricas.
En el proceso de revisión, una actividad se dedica a discutir las anomalías comunicadas por los revisores, asignar a cada una un estado y una severidad y decidir quién debe actuar sobre ellas. ¿Qué actividad es?
Comunicación y análisis de los hallazgos
Correcto — es la actividad en la que se discuten las anomalías, se clasifican por estado y severidad y se asignan para su tratamiento.
Revisión individual
En la revisión individual cada revisor examina el producto por su cuenta y registra posibles anomalías. Aún no se discuten, clasifican ni asignan.
Inicio de la revisión
En el inicio se distribuyen a los participantes el producto y el material relacionado y se responden sus dudas sobre el encargo, antes de empezar a revisar.
Corrección e informe
En la corrección e informe el autor corrige las anomalías aceptadas y se informa del resultado de la revisión, incluido el cumplimiento de los criterios de salida.
La comunicación y análisis de los hallazgos es la actividad en la que se discuten las anomalías comunicadas, se decide su estado y severidad, se asigna responsabilidad y se evalúan las características de calidad del producto.
Un tester con profundo conocimiento del dominio anticipa dónde son probables los defectos (p. ej., campos vacíos, caracteres especiales, valores grandes) y diseña pruebas en torno a esas conjeturas. ¿Qué técnica usa?
Conjetura de errores.
Correcto — diseñar pruebas a partir de defectos probables anticipados es conjetura de errores.
Partición de equivalencia.
La partición es una técnica sistemática de caja negra basada en particiones de entrada, no en la intuición.
Pruebas con tabla de decisión.
Las tablas de decisión abordan combinaciones de condiciones, no defectos conjeturados.
Pruebas de sentencias.
Las pruebas de sentencias son una técnica de cobertura de caja blanca.
La conjetura de errores usa la experiencia y el conocimiento de errores probables para diseñar pruebas; puede apoyarse en listas de defectos/fallos.
Un campo 'edad' acepta números enteros de 18 a 65 inclusive. Los precios difieren para tres grupos: 18–25, 26–59, 60–65. Con partición de equivalencia, ¿cuál es el número MÍNIMO de casos para cubrir todas las particiones válidas e inválidas una vez?
5
Correcto — 3 particiones válidas + 2 inválidas = 5 casos.
3
Incorrecto — solo cuenta las válidas e ignora las dos inválidas.
4
Incorrecto — falta una partición; hay 3 válidas y 2 inválidas.
6
Incorrecto — cuenta de más; solo hay 5 particiones distintas.
Particiones válidas: 18–25, 26–59, 60–65 (3). Inválidas: menor de 18 y mayor de 65 (2). Total 5 particiones → 5 casos.
Un descuento se aplica solo si el total del pedido está entre 100 y 500 inclusive. Con el enfoque de 2 valores del análisis de valores límite, ¿qué conjunto prueba los límites del rango válido?
99, 100, 500, 501
Correcto — cada límite (100, 500) más su vecino inmediato fuera del rango.
100, 300, 500
Incorrecto — 300 es un valor central; faltan los vecinos justo fuera del rango.
99, 101, 499, 501
Incorrecto — usa vecinos internos en vez de los límites 100 y 500.
0, 100, 500, 1000
Incorrecto — 0 y 1000 están lejos de los límites, no son los vecinos.
El AVL de 2 valores prueba cada límite y su vecino más próximo del otro lado. Para [100,500]: 99, 100, 500, 501.
Para el mismo rango válido de 100 a 500 inclusive, ¿cuántos valores distintos requiere el enfoque de 3 valores del AVL para cubrir AMBOS límites?
6
Correcto — 3 valores por límite × 2 límites = 6 valores.
4
Incorrecto — 4 es el resultado del enfoque de 2 valores.
3
Incorrecto — 3 cubre solo un límite; se requieren ambos.
8
Incorrecto — cuenta de más; solo se necesitan 6 valores.
El AVL de 3 valores prueba, por límite, el límite y ambos vecinos. Inferior: 99,100,101; superior: 499,500,501 → 6 valores.
¿Qué afirmaciones sobre la partición de equivalencia son correctas? (Elija DOS.)
Normalmente basta un valor representativo por partición
Correcto — se asume que todos los miembros se tratan igual.
Deben identificarse particiones válidas e inválidas
Correcto — la partición cubre entradas válidas e inválidas.
Las particiones pueden solaparse para aumentar la cobertura
Incorrecto — las particiones deben ser disjuntas.
Cada valor de una partición debe probarse individualmente
Incorrecto — eso anula el propósito; basta un representante.
En la partición de equivalencia, los valores de una clase se procesan igual; basta un representante por clase. Las clases no deben solaparse y se identifican válidas e inválidas.
Use la tabla de decisión de tarifas de aparcamiento. Un MIEMBRO del club aparca un DÍA LABORABLE (no fin de semana) y permanece 4 horas. ¿Qué regla aplica y qué tarifa se cobra?
R6 → 15 $
Correcto — Member=Sí, Weekend=No, Stay>3h=Sí es la columna R6, tarifa 15 $.
R2 → 20 $
Incorrecto — R2 es no miembro (Member=N); aquí el conductor es miembro.
R5 → 7,50 $
Incorrecto — R5 es miembro con estancia CORTA (Stay>3h=No); aquí son 4 horas.
R8 → 12 $
Incorrecto — R8 es miembro en FIN DE SEMANA; aquí es día laborable.
Member=Sí, Weekend=No, Stay>3h=Sí corresponde a R6, con una tarifa de 15 $.
La tabla de decisión del aparcamiento tiene tres condiciones booleanas (Member?, Weekend?, Stay > 3 hours?) y cada combinación produce una tarifa distinta. ¿Cuántos casos se requieren para cobertura completa de la tabla (cada regla/columna una vez)?
8
Correcto — 2^3 = 8 reglas y ninguna se colapsa porque cada una tiene acción única.
4
Incorrecto — 4 asume colapsar la mitad, pero las 8 acciones difieren.
6
Incorrecto — no hay base para 6; son 8 reglas distintas.
3
Incorrecto — 3 es el número de condiciones, no de reglas/casos.
Con 3 condiciones booleanas independientes hay 2^3 = 8 combinaciones. Como cada combinación da una acción distinta, no se pueden colapsar columnas → 8 casos.
La máquina de estados del reproductor comienza en el estado Stopped. ¿Cuál de las siguientes secuencias de eventos es un camino VÁLIDO (cada evento dispara una transición definida)?
play, pause, play, stop
Correcto — Stopped→Playing→Paused→Playing→Stopped; las cuatro transiciones existen.
pause, play, stop
Incorrecto — 'pause' no está definido desde el estado inicial Stopped.
play, stop, pause
Incorrecto — tras stop el estado es Stopped, donde 'pause' no tiene transición.
stop, play, pause
Incorrecto — 'stop' no está definido desde el estado inicial Stopped.
Desde Stopped: play→Playing, pause→Paused, play→Playing, stop→Stopped. Cada evento tiene transición definida; la secuencia es válida.
Para la misma máquina de estados del reproductor, ¿cuántos casos se necesitan para cobertura 0-switch (todas las transiciones simples válidas cubiertas una vez)?
5
Correcto — hay 5 transiciones válidas; 0-switch cubre cada una una vez.
3
Incorrecto — 3 es el número de estados, no de transiciones.
6
Incorrecto — solo hay 5 transiciones definidas en el diagrama.
9
Incorrecto — 9 corresponde a todos los pares estado×evento (incluidos inválidos), no 0-switch.
La cobertura 0-switch exige cada transición válida una vez. Transiciones: Stopped→Playing (play), Playing→Paused (pause), Playing→Stopped (stop), Paused→Playing (play), Paused→Stopped (stop) = 5.
Un tester sénior usa su conocimiento de dónde han aparecido defectos en sistemas similares para diseñar pruebas en áreas propensas a error, sin un modelo formal. ¿Qué técnica utiliza?
Conjetura de errores (error guessing)
Correcto — técnica basada en experiencia y defectos anticipados.
Análisis de valores límite
Incorrecto — el AVL es una técnica sistemática de caja negra.
Prueba de sentencias
Incorrecto — es una técnica de caja blanca basada en el código.
Prueba de tabla de decisión
Incorrecto — usa un modelo formal, es sistemática de caja negra.
Usar experiencia e intuición sobre defectos probables sin un modelo sistemático es la conjetura de errores (error guessing), una técnica basada en la experiencia.
En un enfoque de prueba colaborativo como Acceptance Test-Driven Development (ATDD), ¿cuándo se crean típicamente las pruebas de aceptación?
De forma colaborativa, antes de comenzar el desarrollo de la funcionalidad correspondiente
Correcto: en ATDD, negocio, desarrollo y pruebas colaboran para definir las pruebas de aceptación por adelantado a partir de las historias.
Solo después de implementar y lanzar completamente la función
Incorrecto: contradice la naturaleza 'driven' de ATDD, donde las pruebas van primero.
Por el equipo de operaciones durante el monitoreo en producción
Incorrecto: las pruebas de aceptación las define el equipo multifuncional, no operaciones en producción.
Generadas automáticamente por la canalización de compilación sin intervención humana
Incorrecto: ATDD es una práctica humana colaborativa, no una generación automática.
En las pruebas basadas en riesgo, ¿cómo se determina normalmente el nivel de un riesgo de producto?
Combinando la probabilidad del riesgo con su impacto
Correcto — nivel de riesgo = probabilidad × impacto.
Contando el número de requisitos
Incorrecto — el número de requisitos no define el nivel de riesgo.
Por el tamaño del equipo de pruebas
Incorrecto — el tamaño del equipo no se relaciona con el nivel de riesgo.
Por el número de casos ya escritos
Incorrecto — el número de casos es un resultado, no un determinante del riesgo.
El nivel de riesgo es función de la probabilidad de que ocurra el problema y de su impacto (daño).
¿Cuál de los siguientes es un ejemplo de criterio de SALIDA (definición de terminado) de un nivel de prueba?
Se alcanzó la cobertura planificada y no quedan defectos de alta prioridad abiertos
Correcto — criterio de salida típico para detener la prueba.
El entorno de pruebas está instalado y disponible
Incorrecto — un entorno disponible es criterio de entrada.
Se han preparado los datos de prueba
Incorrecto — los datos preparados son criterio de entrada.
Se ha asignado a los testers al proyecto
Incorrecto — la asignación de recursos es precondición (entrada).
Los criterios de salida definen cuándo se puede detener la prueba, p. ej., cobertura alcanzada y sin defectos de alta prioridad abiertos. Un entorno disponible es criterio de entrada.
¿Qué información debería contener un buen informe de defecto? (Elija DOS.)
Pasos para reproducir el fallo
Correcto — los pasos permiten investigar y confirmar el defecto.
Resultados esperados y reales
Correcto — la desviación entre esperado y real es esencial.
El salario mensual del tester
Incorrecto — irrelevante para diagnosticar o corregir.
El plan de marketing del producto
Incorrecto — no forma parte de un informe de defecto.
Un informe de defecto debe incluir identificador/resumen, pasos para reproducir, resultado esperado vs. real, severidad/prioridad. El salario o el plan de marketing son irrelevantes.
Con la estimación de tres puntos, una tarea se estima: optimista = 4 días, más probable = 10 días, pesimista = 22 días. ¿Cuál es la estimación con la fórmula (a + 4m + b) / 6?
11 días
Correcto — 66 / 6 = 11 días.
12 días
Incorrecto — es el promedio simple (4+10+22)/3 = 12, no PERT.
10 días
Incorrecto — 10 es el valor más probable, no la estimación ponderada.
13 días
Incorrecto — no coincide con la fórmula; el resultado correcto es 11 días.
(4 + 4×10 + 22) / 6 = (4 + 40 + 22) / 6 = 66 / 6 = 11 días.
¿Cuál es el propósito principal de la monitorización de pruebas?
Recopilar información del progreso y compararla con el plan
Correcto — la monitorización da visibilidad para decisiones de control.
Corregir los defectos encontrados durante las pruebas
Incorrecto — corregir es depuración, no monitorización.
Diseñar los casos de prueba
Incorrecto — diseñar casos no es monitorización.
Redactar la política de pruebas de la organización
Incorrecto — la política es un documento organizativo de nivel superior.
La monitorización recopila información del progreso y compara lo real con el plan, para poder tomar acciones de control.
¿Cuál de los siguientes es un riesgo de producto y no de proyecto?
El software podría calcular mal los intereses
Correcto — un defecto en el producto entregado es riesgo de producto.
Un tester clave podría irse antes de terminar
Incorrecto — la disponibilidad de personal es riesgo de proyecto.
El entorno de pruebas podría entregarse tarde
Incorrecto — plazos/logística del entorno es riesgo de proyecto.
El presupuesto de pruebas podría recortarse
Incorrecto — presupuesto/recursos son riesgos de proyecto.
Un riesgo de producto es una posible deficiencia del producto (p. ej., errores de cálculo). Un riesgo de proyecto es de gestión/plazos/recursos (entrega tardía, falta de personal).
El control de pruebas implica tomar acciones correctivas cuando la monitorización muestra una desviación del plan. ¿Cuáles son ejemplos de acciones de control? (Elija DOS.)
Repriorizar pruebas cuando cambia un riesgo
Correcto — repriorizar es una acción de control.
Ajustar el cronograma cuando se retrasa una dependencia
Correcto — replanificar ante una desviación es acción de control.
Escribir los requisitos originales del sistema
Incorrecto — es una actividad de requisitos, no control de pruebas.
Programar una nueva función del producto
Incorrecto — desarrollar funciones no es control de pruebas.
Las acciones de control incluyen repriorizar pruebas al cambiar el riesgo y ajustar el cronograma. Escribir requisitos o programar una función no lo son.
¿Cuáles son beneficios potenciales de las pruebas independientes (realizadas por quienes no escribieron el código)? (Elija DOS.)
Los testers independientes suelen ver defectos distintos y adicionales
Correcto — una perspectiva fresca revela fallos que el autor pasaría por alto.
Están menos influidos por las suposiciones del autor
Correcto — la independencia reduce el sesgo de confirmación.
Elimina la necesidad de pruebas del desarrollador
Incorrecto — las pruebas del desarrollador siguen siendo necesarias.
Garantiza que se encontrarán todos los defectos
Incorrecto — ningún enfoque garantiza hallar todos los defectos.
Los testers independientes suelen reconocer otros tipos de fallos y están menos sujetos al sesgo del autor. La independencia no elimina las pruebas del desarrollador ni garantiza hallar todos los defectos.
¿Cuál es el MEJOR ejemplo de acción de mitigación que las pruebas pueden tomar ante un riesgo de producto?
Diseñar pruebas adicionales y más rigurosas para la función de alto riesgo.
Correcto — las pruebas dirigidas mitigan el riesgo.
Contratar más desarrolladores para el próximo proyecto.
Una acción de personal general.
Ignorar el riesgo porque el plazo es ajustado.
Ignorar no es mitigación.
Reducir las pruebas de la función de alto riesgo.
Esto aumenta el riesgo.
Las pruebas mitigan diseñando pruebas dirigidas y técnicas más rigurosas donde el riesgo es alto.
Un equipo ejecuta una gran suite de pruebas de regresión estables y repetitivas en cada build. ¿Cuál es un beneficio clave de automatizarlas?
Menos esfuerzo manual repetitivo y retroalimentación más rápida y consistente
Correcto — la automatización repite pruebas estables e informa de forma consistente.
Garantiza que el software no tiene defectos
Incorrecto — la automatización ejecuta pruebas, no garantiza ausencia de defectos.
Elimina la necesidad de diseñar pruebas
Incorrecto — las pruebas deben diseñarse; la automatización solo las ejecuta.
Siempre es más barata que las pruebas manuales a corto plazo
Incorrecto — la automatización tiene costes iniciales y de mantenimiento importantes.
La automatización destaca en pruebas repetitivas y estables: reduce el esfuerzo manual repetitivo y da retroalimentación rápida y consistente.
¿Cuáles de los siguientes son RIESGOS o desafíos reales al introducir una herramienta de automatización? (Elija DOS.)
Subestimar el esfuerzo de mantener las pruebas automatizadas
Correcto — el mantenimiento es un coste conocido y a menudo subestimado.
Tener expectativas poco realistas de lo que la herramienta puede lograr
Correcto — el exceso de confianza es un riesgo reconocido.
La herramienta define automáticamente la estrategia de pruebas
Incorrecto — una herramienta no define la estrategia; es responsabilidad humana.
Comprar una herramienta siempre mejora la calidad por sí misma
Incorrecto — la calidad viene de buenas prácticas, no de poseer una herramienta.
Riesgos reales: subestimar el esfuerzo de introducción y mantenimiento, y confiar en exceso en la herramienta (expectativas poco realistas). Una herramienta no elimina la estrategia de pruebas ni mejora por sí sola la calidad.