CUESTIONARIO 02 – ISTQB FOUNDATION LEVEL 4.0 Ene, Vie, 2026 Uncategorized 0 Cuestionario 02 - ISTQB Foundation Level 4.0 ISTQB FOUNDATION LEVEL 4.0 1 / 26 ¿Cuál de las siguientes piezas de información contenidas en un informe de progreso de pruebas es la MENOS útil para los representantes comerciales? a) Obstáculos para las pruebas b) Cobertura de ramas alcanzada c) Progreso de las pruebas d) Nuevos riesgos dentro del ciclo de pruebas Explicación Los representantes comerciales (business stakeholders) suelen interesarse por información que les ayude a tomar decisiones de negocio, como: ¿Vamos a tiempo? ¿Hay riesgos que puedan afectar la entrega? ¿Hay bloqueos? ¿Qué tan estable parece el producto a alto nivel? Veamos cada opción desde ese punto de vista: a) Obstáculos para las pruebas ✔️Muy útil: pueden afectar plazos y compromisos. b) Cobertura de ramas alcanzada ❌Es una métrica técnica interna, relevante para desarrolladores o testers, pero poco comprensible o útil para negocio. c) Progreso de las pruebas ✔️Clave para saber si el proyecto avanza según lo planificado. d) Nuevos riesgos dentro del ciclo de pruebas ✔️Muy relevante para decisiones de alcance, fecha o prioridad. Regla rápida para el examen 🧠 👔 Negocio quiere riesgos, progreso y bloqueos🧑💻 Cobertura técnica (ramas, sentencias) es para perfiles técnicos 2 / 26 ¿Cuáles DOS de las siguientes opciones son métricas comunes utilizadas para informar sobre el nivel de calidad del objeto de prueba? a) Número de defectos encontrados durante las pruebas del sistema b) Esfuerzo total en el diseño de pruebas dividido por el número de casos de prueba diseñados c) Número de procedimientos de prueba ejecutados d) Número de defectos encontrados dividido por el tamaño de un producto de trabajo e) Tiempo necesario para reparar un defecto Seleccione DOS opciones. a) Número de defectos encontrados durante las pruebas del sistema b) Esfuerzo total en el diseño de pruebas dividido por el número de casos de prueba diseñados c) Número de procedimientos de prueba ejecutados d) Número de defectos encontrados dividido por el tamaño de un producto de trabajo e) Tiempo necesario para reparar un defecto Las DOS opciones correctas son: ✅ a) Número de defectos encontrados durante las pruebas del sistema✅ d) Número de defectos encontrados dividido por el tamaño de un producto de trabajo Por qué estas dos miden calidad del objeto de prueba a) da una indicación directa de la calidad: más defectos encontrados ⇒ menor calidad percibida. d) es densidad de defectos, una métrica clásica de calidad porque normaliza por tamaño (líneas de código, puntos de función, historias, etc.), permitiendo comparaciones objetivas. Por qué las otras NO son métricas de calidad del objeto b) ❌ mide productividad/eficiencia del proceso de pruebas, no calidad del producto. c) ❌ mide actividad o progreso, no calidad. e) ❌ mide mantenibilidad o eficiencia de corrección, no la calidad intrínseca del objeto probado. Regla rápida para el examen 🧠 📊 Calidad del producto ⇒ defectos (conteo o densidad)⏱️ Proceso/gestión ⇒ esfuerzo, tiempo, cantidad de pruebas 3 / 26 ¿Cuál de las siguientes opciones es un ejemplo de cómo el análisis de riesgos de producto influye en la rigurosidad y el alcance de las pruebas? a) El director de pruebas supervisa y reporta el nivel de todos los riesgos conocidos a diario para que las partes interesadas puedan tomar una decisión informada sobre la fecha de entrega. b) Uno de los riesgos identificados fue "Falta de soporte para bases de datos de código abierto", por lo que el equipo decidió integrar el sistema con una base de datos de código abierto. c) Durante el análisis cuantitativo de riesgos, el equipo estimó el nivel total de todos los riesgos identificados y lo informó como el riesgo residual total antes de las pruebas. d) La evaluación de riesgos reveló un nivel muy alto de riesgos de rendimiento, por lo que se decidió realizar pruebas detalladas de eficiencia de rendimiento temprano en el ciclo de vida de desarrollo de software. Explicación El análisis de riesgos de producto influye directamente en: qué se prueba (alcance), con qué profundidad (rigurosidad), cuándo se prueba (prioridad y momento). La opción d) muestra exactamente esa relación: Se identifica un riesgo de producto (rendimiento). El riesgo es alto. Como consecuencia, se decide aumentar la rigurosidad (pruebas detalladas). Y adelantar esas pruebas en el SDLC. 👉 Eso es el uso clásico del testing basado en riesgos. Por qué las otras opciones no aplican a) ❌ Es monitoreo y reporte, no ajuste del alcance o rigor de las pruebas. b) ❌ Describe una decisión de diseño, no una decisión de pruebas. c) ❌ Habla de medición agregada, no de cómo cambia qué o cómo se prueba. Regla clave para examen 🧠 ⚠️ Riesgo alto ⇒ más pruebas, más temprano, más profundas 4 / 26 La siguiente lista contiene riesgos que se han identificado para un nuevo producto de software que se va a desarrollar: i. La dirección traslada a dos probadores experimentados a otro proyecto. ii. El sistema no cumple con las normas de seguridad funcional. iii. El tiempo de respuesta del sistema supera los requisitos del usuario. iv. Las partes interesadas tienen expectativas inexactas. v. Las personas discapacitadas tienen problemas al usar el sistema. ¿Cuáles de ellos son riesgos de proyecto? a) i, iv son riesgos de proyecto; ii, iii, v no son riesgos de proyecto. b) iv, v son riesgos de proyecto; i, ii, iii no son riesgos de proyecto. c) i, iii son riesgos de proyecto; ii, iv, v no son riesgos de proyecto. d) ii, v son riesgos de proyecto; i, iii, iv no son riesgos de proyecto. Explicación clara En ISTQB se distinguen principalmente dos tipos de riesgos: Riesgos de proyecto → afectan a la planificación, recursos, organización y gestión del proyecto. Riesgos de producto → afectan a la calidad del software (funcionalidad, rendimiento, seguridad, usabilidad, etc.). Veamos cada uno: i. La dirección traslada a dos probadores experimentados a otro proyecto✔️ Riesgo de proyecto → pérdida de recursos clave, impacto en planificación y calidad del trabajo. ii. El sistema no cumple con las normas de seguridad funcional❌ Riesgo de producto → problema de calidad del software. iii. El tiempo de respuesta del sistema supera los requisitos del usuario❌ Riesgo de producto → riesgo de rendimiento. iv. Las partes interesadas tienen expectativas inexactas✔️ Riesgo de proyecto → afecta a alcance, prioridades y aceptación del proyecto. v. Las personas discapacitadas tienen problemas al usar el sistema❌ Riesgo de producto → riesgo de usabilidad / accesibilidad. Regla rápida para el examen 🧠 🏗️ Personas, recursos, expectativas, planificación → riesgos de proyecto🧪 Calidad, rendimiento, seguridad, usabilidad → riesgos de producto 5 / 26 Durante el análisis de riesgos, el equipo consideró el siguiente riesgo: "El sistema permite un descuento demasiado alto para un cliente". El equipo estimó que el impacto del riesgo era muy alto. ¿Qué se puede decir sobre la probabilidad del riesgo? a) También es muy alta. Un alto impacto de riesgo siempre implica una alta probabilidad de riesgo b) Es muy baja. Un alto impacto de riesgo siempre implica una baja probabilidad de riesgo. c) No se puede decir nada sobre la probabilidad del riesgo. El impacto del riesgo y la probabilidad del riesgo son independientes. d) La probabilidad del riesgo no es importante con un impacto de riesgo tan alto. No es necesario definirla. Explicación En análisis de riesgos (ISTQB): Impacto = qué tan grave sería si el riesgo ocurre Probabilidad = qué tan probable es que ocurra Son dos dimensiones independientes.Un riesgo puede tener: impacto muy alto pero probabilidad baja (ej. fallo catastrófico raro), impacto bajo pero probabilidad alta, o cualquier combinación. 👉 Que el impacto sea “muy alto” no permite inferir nada sobre la probabilidad. Por qué las otras opciones son incorrectas a) ❌ Impacto alto no implica probabilidad alta. b) ❌ Impacto alto no implica probabilidad baja. d) ❌ La probabilidad siempre es importante para priorizar riesgos. Regla rápida para el examen 🧠 ⚖️ Riesgo = Impacto × Probabilidad📌 Impacto ≠ Probabilidad 6 / 26 ¿Cuál de las siguientes afirmaciones NO es cierta con respecto a la pirámide de pruebas? a) La pirámide de pruebas enfatiza tener un mayor número de pruebas en los niveles de pruebas inferiores b) Cuanto más cerca estés de la cima de la pirámide, más formal debería ser tu automatización de pruebas. c) Por lo general, las pruebas de componentes y las pruebas de integración de componentes se automatizan utilizando herramientas basadas en API. d) Para las pruebas de sistema y las pruebas de aceptación, las pruebas automatizadas generalmente se crean utilizando herramientas basadas en la interfaz gráfica de usuario (GUI) Explicación Esa afirmación NO es cierta según el concepto de la pirámide de pruebas. La pirámide establece que: 🔽 Niveles inferiores (componentes / integración de componentes) Muchas pruebas Rápidas Estables Altamente automatizadas (a menudo a nivel de API o código) 🔼 Niveles superiores (sistema / aceptación) Pocas pruebas Más lentas Más frágiles Menos automatización, y cuando se automatizan, suele ser más costosa y difícil de mantener 👉 Por tanto, no es cierto que cuanto más arriba estés, más “formal” deba ser la automatización; ocurre justo lo contrario: la automatización es más eficiente y estable en los niveles bajos. Por qué las otras opciones SÍ son ciertas a) ✔️ Correcta: la pirámide enfatiza más pruebas en niveles inferiores. c) ✔️ Correcta: componentes e integración suelen probarse con herramientas basadas en API. d) ✔️ Correcta: sistema y aceptación suelen automatizarse (cuando se hace) con herramientas GUI. Regla rápida para el examen 🧠 🏗️ Pirámide de pruebas Abajo → muchas pruebas, rápidas, baratas, fáciles de automatizar Arriba → pocas pruebas, lentas, frágiles, automatización costosa 7 / 26 Tu equipo utiliza planificación poker para estimar el esfuerzo de prueba requerido para una nueva característica solicitada. En tu equipo existe una regla que establece que si no hay tiempo para llegar a un acuerdo completo y la variación en los resultados es pequeña, se pueden aplicar reglas como "aceptar el número con la mayoría de los votos". Después de dos rondas, no se llegó a un consenso, por lo que se inició la tercera ronda. Puedes ver los resultados de la estimación de pruebas en la siguiente tabla. ¿Cuál de las siguientes es el MEJOR ejemplo del siguiente paso? a) El dueño del producto debe intervenir y tomar una decisión final. b) Aceptar 13 como la estimación final de las pruebas, ya que cuenta con la mayoría de los votos. c) No es necesario tomar más medidas. Se ha alcanzado un consenso. d) Eliminar la nueva característica de la versión actual porque no se ha alcanzado un consenso. Explicación paso a paso El enunciado dice que el equipo usa planning poker y que existe una regla explícita: si no hay tiempo para llegar a un acuerdo completo y la variación es pequeña, se puede aceptar el número con la mayoría de los votos. En la tercera ronda, las estimaciones son: 13, 8, 13, 13, 13, 13, 8 👉 El valor 13 tiene clara mayoría.👉 La variación ya es pequeña (solo 8 y 13).👉 Se cumple exactamente la regla definida por el equipo. Por tanto, el mejor siguiente paso es aceptar 13 como estimación final. Por qué las otras opciones no son correctas a) ❌ El planning poker es una técnica colaborativa del equipo, no una decisión unilateral del Product Owner. c) ❌ No hay consenso total (no todos votaron igual). d) ❌ No alcanzar consenso no justifica eliminar una funcionalidad. Regla rápida para el examen 🧠 🃏 Planning Poker Primero: discutir diferencias Si la variación es pequeña y hay presión de tiempo → mayoría gana 8 / 26 Considera la siguiente parte de un plan de pruebas. Las pruebas se realizarán utilizando pruebas de componentes y pruebas de integración de componentes. Las regulaciones requieren demostrar que se logra una cobertura de rama del 100% para cada componente clasificado como crítico. ¿A qué parte del plan de pruebas pertenece esta parte? a) Comunicación b) Registro de riesgos c) Contexto de las pruebas d) Enfoque de pruebas Explicación El fragmento del plan de pruebas describe cómo se van a realizar las pruebas, específicamente: Tipos de prueba: pruebas de componentes y de integración de componentes Niveles de prueba Criterios de cobertura: 100% de cobertura de rama Restricciones/regulaciones que influyen en la forma de probar Todo eso forma parte del enfoque de pruebas (test approach), que define: qué tipos y niveles de prueba se aplican, qué técnicas se usarán, qué criterios de cobertura son obligatorios. Por qué las otras opciones no encajan a) Comunicación ❌ Trata de reportes, reuniones, canales. b) Registro de riesgos ❌ Enumera riesgos y mitigaciones. c) Contexto de las pruebas ❌ Describe el sistema, entorno o stakeholders, no el cómo se prueba. Regla rápida para el examen 🧠 🧪 Tipos de prueba + técnicas + criterios de cobertura = Enfoque de pruebas 9 / 26 ¿Cuál de las siguientes opciones describe MEJOR el enfoque colaborativo para escribir historias de usuario? a) Las historias de usuario son creadas por probadores y desarrolladores, y luego son aceptadas por representantes de negocios. b) Las historias de usuario son creadas por representantes de negocios, desarrolladores y probadores juntos. c) Las historias de usuario son creadas por representantes de negocios y verificadas por desarrolladores y probadores. d) Las historias de usuario son creadas de manera que sean independientes, negociables, valiosas, estimables, pequeñas y comprobables. Explicación El enfoque colaborativo en Agile (y según ISTQB) implica que todas las partes clave participen juntas en la creación de las historias de usuario: 👔 Representantes de negocio → aportan el valor y las necesidades 💻 Desarrolladores → aportan viabilidad técnica 🧪 Probadores → aportan criterios de prueba, riesgos y claridad Esto fomenta: Entendimiento compartido Menos ambigüedades Historias más comprobables 👉 Eso es exactamente lo que describe la opción b). Por qué las otras opciones no son la mejor a) ❌ No es plenamente colaborativo; el negocio solo “acepta” al final. c) ❌ La verificación posterior no equivale a colaboración en la creación. d) ❌ Describe INVEST, una característica de calidad, no un enfoque colaborativo. Regla rápida para el examen 🧠 🤝 Colaborativo = negocio + dev + test desde el inicio 10 / 26 Estás probando una aplicación móvil que permite a los clientes acceder y gestionar sus cuentas bancarias. Estás ejecutando un conjunto de pruebas que implica evaluar cada pantalla y cada campo en cada pantalla según una lista general de mejores prácticas de interfaz de usuario derivadas de un libro popular sobre el tema que maximiza la atractividad, facilidad de uso y accesibilidad para tales aplicaciones. ¿Cuál de las siguientes opciones categoriza MEJOR la técnica de prueba que estás utilizando? a) Caja negra b) Exploratoria c) Basada en lista de comprobación d) Predicción de errores Explicación Estás probando: Cada pantalla y cada campo Siguiendo una lista general de mejores prácticas Derivada de una fuente externa (un libro) Eso encaja perfectamente con la técnica de prueba basada en listas de comprobación (checklist-based testing), donde: Se usan listas predefinidas de criterios, reglas o buenas prácticas Se verifica sistemáticamente que el sistema las cumpla Por qué las otras opciones no son la mejor a) Caja negra ❌Es una clasificación, no una técnica específica (muchas técnicas pueden ser de caja negra). b) Exploratoria ❌En la exploratoria no se sigue una lista fija; aquí sí hay una guía estructurada. d) Predicción de errores ❌Se basa en la experiencia del tester para anticipar defectos, no en una checklist formal. Regla rápida para el examen 🧠 ☑️ Checklist conocida + verificación sistemática = pruebas basadas en listas de comprobación 11 / 26 ¿Cuál de las siguientes afirmaciones sobre las pruebas de rama es CORRECTA? a) Si un programa incluye solo ramas incondicionales, entonces se puede lograr una cobertura de rama del 100% sin ejecutar ningún caso de prueba. b) Si los casos de prueba ejercen todas las ramas incondicionales en el código, entonces se logra una cobertura de rama del 100%. c) Si se logra una cobertura de sentencias del 100%, entonces también se logra una cobertura de rama del 100%. d) Si se logra una cobertura de rama del 100%, entonces se ejercen todas las salidas de decisión en cada sentencia de decisión en el código. Explicación clara La cobertura de rama (branch coverage) exige que cada posible resultado de una decisión (por ejemplo, true y false en un if) sea ejecutado al menos una vez. Eso es exactamente lo que describe la opción d). Por qué las otras opciones son incorrectas a) ❌ Aunque haya ramas incondicionales, el código debe ejecutarse para contar cobertura. b) ❌ Las ramas incondicionales no cuentan para la cobertura de rama; esta se centra en decisiones. c) ❌ 100% de cobertura de sentencias no garantiza 100% de cobertura de rama (puede ejecutarse una sentencia sin cubrir todas las salidas de decisión). Regla rápida para el examen 🧠 🌿 Cobertura de rama = todas las salidas (true/false) de cada decisión ejecutadas 12 / 26 Un sistema de almacenamiento de vino utiliza un dispositivo de control que mide la temperatura de la cava de vinos T (medida en °C, redondeada al grado más cercano) y alerta al usuario si se desvía del valor óptimo de 12, de acuerdo con las siguientes reglas: • Si T = 12, el sistema dice: "temperatura óptima". • Si T < 12, el sistema dice: "¡la temperatura es demasiado baja!" • Si T > 12, el sistema dice: "¡la temperatura es demasiado alta!" Deseas utilizar el análisis de valores límite de 3 puntos (BVA) para verificar el comportamiento del dispositivo de control. Una entrada de prueba es una temperatura en °C proporcionada por el dispositivo. ¿Cuál es el conjunto MÍNIMO de entradas de prueba que logra el 100% de la cobertura deseada? a) 11, 12, 13 b) 10, 12, 14 c) 10, 11, 12, 13, 14 d) 10, 11, 13, 14 Por qué:Las clases de equivalencia son: T < 12, T = 12 y T > 12. Hay un solo punto límite relevante en 12. Con el análisis de valores límite de 3 puntos (BVA), para un límite L se toman L-1, L y L+1. Como las temperaturas se redondean a grados enteros, los valores mínimos necesarios para cubrir los límites son 11 (justo por debajo), 12 (en el límite) y 13 (justo por encima).Ese conjunto es mínimo y garantiza que se verifique el comportamiento en las tres situaciones (demasiado baja, óptima, demasiado alta). 13 / 26 ¿Qué tarea puede asumir la dirección durante una revisión formal? a) Asumir la responsabilidad general de la revisión. b) Decidir qué se va a revisar. c) Asegurar el funcionamiento efectivo de las reuniones de revisión y mediar, si es necesario. d) Registrar la información de la revisión, como las decisiones de la revisión. Explicación En una revisión formal, la dirección (management) puede asumir tareas como: Definir el alcance de la revisión, es decir, qué productos de trabajo se revisan. Proveer recursos, tiempo y apoyo organizativo. 👉 Esto corresponde exactamente a la opción b. Por qué las otras opciones no son correctas a) ❌ La responsabilidad general de la revisión suele recaer en el moderador o líder de revisión, no en la dirección. c) ❌ Asegurar el funcionamiento de la reunión y mediar es tarea del moderador. d) ❌ Registrar decisiones y datos es tarea del secretario o escriba. Regla rápida para examen 🧠 👔 Dirección = define alcance y prioridades🎯 Moderador = conduce la revisión📝 Secretario = registra 14 / 26 ¿Cuál de las siguientes afirmaciones sobre las revisiones formales es VERDADERA? a) Algunas revisiones no requieren más de un rol. b) El proceso de revisión tiene varias actividades. c) La documentación a revisar no se distribuye antes de la reunión de revisión, excepto el producto de trabajo para tipos de revisión específicos. d) Los defectos encontrados durante la revisión no se informan, ya que no se encuentran mediante pruebas dinámicas. Explicación Las revisiones formales (según ISTQB, por ejemplo inspecciones) siguen un proceso definido, que incluye varias actividades, como: Planificación Inicio (kick-off) Preparación individual Reunión de revisión Reelaboración Seguimiento Por eso, la afirmación b) es claramente verdadera. Por qué las otras opciones son falsas a) ❌ Las revisiones formales requieren varios roles (autor, moderador, revisor, etc.). c) ❌ La documentación sí se distribuye antes para la preparación individual. d) ❌ Los defectos encontrados sí se registran y reportan, aunque no sean pruebas dinámicas. Frase clave para examen 🧠 📋 Revisión formal = proceso estructurado con actividades definidas 15 / 26 Decide cuáles de las siguientes afirmaciones (i-v) son ciertas para las pruebas dinámicas y cuáles son ciertas para las pruebas estáticas. i. Los comportamientos externos anormales son más fáciles de identificar con estas pruebas. ii. Las discrepancias con un estándar de codificación son más fáciles de encontrar con estas pruebas. iii. Identifican fallos causados por defectos cuando se ejecuta el software. iv. Su objetivo de prueba es identificar defectos lo más temprano posible. v. Es más fácil encontrar y corregir la cobertura faltante para los requisitos de seguridad críticos. a) i, iv, v son verdaderas para las pruebas estáticas; ii, iii son verdaderas para las pruebas dinámicas. b) i, iii, iv son verdaderas para las pruebas estáticas; ii, v son verdaderas para las pruebas dinámicas. c) ii, iii son verdaderas para las pruebas estáticas; i, iv, v son verdaderas para las pruebas dinámicas. d) ii, iv, v son verdaderas para las pruebas estáticas; i, iii, iv son verdaderas para las pruebas dinámicas a) i, iv, v son verdaderas para las pruebas estáticas; ii, iii son verdaderas para las pruebas dinámicas. b) i, iii, iv son verdaderas para las pruebas estáticas; ii, v son verdaderas para las pruebas dinámicas. c) ii, iii son verdaderas para las pruebas estáticas; i, iv, v son verdaderas para las pruebas dinámicas. d) ii, iv, v son verdaderas para las pruebas estáticas; i, iii, iv son verdaderas para las pruebas dinámicas. Justificación rápida (una por una) i. Comportamientos externos anormales → Pruebas dinámicas👉 Solo se observan cuando el software se ejecuta. ii. Discrepancias con estándares de codificación → Pruebas estáticas👉 Revisiones y análisis estático detectan violaciones sin ejecutar el código. iii. Identifican fallos cuando se ejecuta el software → Pruebas dinámicas👉 Un fallo aparece únicamente durante la ejecución. iv. Identificar defectos lo más temprano posible → Pruebas estáticas👉 Su gran ventaja es detectar problemas antes de que exista software ejecutable. v. Encontrar cobertura faltante en requisitos de seguridad críticos → Pruebas estáticas👉 Revisar requisitos y diseño permite detectar omisiones de cobertura. Regla de oro para el examen 🧠 📄 Estáticas → estándares, requisitos, cobertura, detección temprana ▶️ Dinámicas → ejecución, fallos, comportamiento observable 16 / 26 La siguiente es una lista de los productos de trabajo producidos en el ciclo de vida del desarrollo de software (SDLC). i. Requisitos de negocio ii. Cronograma iii. Presupuesto de pruebas iv. Código ejecutable de terceros v. Historias de usuario y sus criterios de aceptación ¿Cuáles de ellos se pueden revisar? a) Se pueden revisar i y iv; ii, iii y v no se pueden revisar. b) Se pueden revisar i, ii, iii y iv; v no se puede. c) Se pueden revisar i, ii, iii y v; iv no se puede. d) Se pueden revisar iii, iv, v; i y ii no se pueden revisar. Explicación Según ISTQB, una revisión (prueba estática) se puede aplicar a cualquier producto de trabajo que sea documentable y evaluable, no solo a requisitos o código fuente. Veamos uno por uno: i. Requisitos de negocio ✔️Son uno de los principales candidatos a revisión (ambigüedades, inconsistencias, omisiones). ii. Cronograma ✔️Puede revisarse para detectar riesgos, inconsistencias y problemas de planificación. iii. Presupuesto de pruebas ✔️También es revisable para evaluar viabilidad, cobertura y riesgos. iv. Código ejecutable de terceros ❌No se puede revisar porque no hay acceso al contenido interno (solo se puede probar dinámicamente). v. Historias de usuario y criterios de aceptación ✔️Son productos de trabajo clave en entornos ágiles y sí se revisan. Regla de oro para el examen 🧠 📄 Si es un producto de trabajo documentado → se puede revisar📦 Si es solo un ejecutable sin visibilidad interna → no se puede revisar 17 / 26 La estrategia de pruebas de su organización sugiere que una vez que un sistema va a ser retirado, se debe probar la migración de datos. ¿En qué tipo de prueba es MÁS probable que se realice esta prueba? a) Prueba de mantenimiento b) Prueba de regresión c) Prueba de componente d) Prueba de integración Explicación Cuando un sistema va a ser retirado (decommissioned), suelen realizarse actividades como: Migración de datos a un nuevo sistema Archivado o conversión de información Verificación de que los datos se transfirieron correctamente Según ISTQB, las pruebas de mantenimiento incluyen pruebas realizadas: durante modificaciones del sistema, durante migraciones, y antes del retiro del sistema. 👉 Por eso, probar la migración de datos al retirar un sistema es claramente prueba de mantenimiento. Por qué las otras opciones no aplican b) Prueba de regresión ❌ Se enfoca en verificar que cambios no rompan funcionalidad existente. c) Prueba de componente ❌ Se limita a componentes individuales. d) Prueba de integración ❌ Se centra en interfaces entre componentes, no en retiro del sistema. Frase clave para el examen 🧠 🛠️ Migración, retiro, correcciones → pruebas de mantenimiento 18 / 26 Trabajas como probador en un proyecto de una aplicación móvil para pedidos de comida para uno de tus clientes. El cliente te envió una lista de requisitos. Uno de ellos, con alta prioridad, dice: "El pedido debe procesarse en menos de 10 segundos en el 95% de los casos". Creaste un conjunto de casos de prueba en los que se realizaron una serie de pedidos aleatorios, se midió el tiempo de procesamiento y se comprobaron los resultados de las pruebas con los requisitos. ¿Qué tipo de prueba realizaste? a) Funcional, porque los casos de prueba cubren el requisito comercial del usuario para el sistema b) No funcional, porque miden el rendimiento del sistema. c) Funcional, porque los casos de prueba interactúan con la interfaz de usuario. d) Estructural, porque necesitamos conocer la estructura interna del programa para medir el tiempo de procesamiento de pedidos. Explicación El requisito dice: “El pedido debe procesarse en menos de 10 segundos en el 95% de los casos” Esto no describe qué hace el sistema, sino qué tan rápido lo hace.Eso corresponde a un atributo de calidad, específicamente rendimiento (tiempo de respuesta). Los casos de prueba que creaste: envían pedidos, miden tiempos de procesamiento, comparan los resultados con un umbral (10 segundos, 95%). 👉 Eso es prueba no funcional de rendimiento. Por qué las otras opciones son incorrectas a) ❌ Que sea un requisito del negocio no lo convierte en funcional. c) ❌ Usar la interfaz de usuario no define el tipo de prueba. d) ❌ No se analiza la estructura interna del código; por tanto no es estructural. Regla rápida para examen 🧠 ⏱️ Tiempo, carga, volumen, estrés, seguridad, usabilidad ⇒ pruebas NO funcionales🧩 Qué hace el sistema ⇒ pruebas funcionales 19 / 26 ¿Cuáles de las siguientes son ventajas de DevOps? i. Entrega más rápida del producto y tiempo reducido para llegar al mercado. ii. Aumenta la necesidad de pruebas manuales repetitivas. iii. Disponibilidad constante de software ejecutable. iv. Reducción en el número de pruebas de regresión asociadas a la refactorización de código. v. El establecimiento del marco de trabajo de automatización de pruebas es económico, ya que todo está automatizado. a) i, ii, iv son ventajas; iii, v no lo son. b) iii, v son ventajas; i, ii, iv no lo son. c) i, iii son ventajas; ii, iv, v no lo son. d) ii, iv, v son ventajas; i, iii no lo son. Explicación opción por opción i. Entrega más rápida del producto y tiempo reducido para llegar al mercado✔️ Verdadero. DevOps busca CI/CD, automatización y ciclos cortos → entregas más rápidas. ii. Aumenta la necesidad de pruebas manuales repetitivas❌ Falso. DevOps promueve la automatización, reduciendo pruebas manuales repetitivas. iii. Disponibilidad constante de software ejecutable✔️ Verdadero. Con integración continua hay builds frecuentes y software siempre ejecutable. iv. Reducción en el número de pruebas de regresión asociadas a la refactorización de código❌ Falso. La refactorización aumenta la necesidad de regresión; lo que cambia es que se automatiza, no que se reduzca el número. v. El marco de automatización es económico porque todo está automatizado❌ Falso. La automatización requiere inversión inicial (herramientas, tiempo, skills). Resumen para memorizar 🧠 🚀 DevOps = rapidez + automatización + feedback continuo💰 Automatizar ahorra a largo plazo, pero no es gratis al inicio. 20 / 26 Estás trabajando como probador en el equipo que sigue el modelo V. ¿Cómo afecta la elección de este modelo de ciclo de vida de desarrollo de software (SDLC) al momento de las pruebas? a) Las pruebas dinámicas no se pueden realizar temprano en el SDLC. b) Las pruebas estáticas no se pueden realizar temprano en el SDLC. c) La planificación de pruebas no se puede realizar temprano en el SDLC. d) Las pruebas de aceptación se pueden realizar temprano en el SDLC. Explicación En el modelo V: Las actividades de prueba se planifican y diseñan temprano (lado izquierdo de la V). Las pruebas estáticas (revisiones de requisitos, diseño, etc.) sí pueden y deben hacerse temprano. Las pruebas dinámicas requieren software ejecutable, por lo que solo pueden realizarse después de que el código existe (lado derecho de la V). Por eso, no es posible ejecutar pruebas dinámicas temprano en el SDLC. Por qué las otras opciones son incorrectas b) ❌ Las pruebas estáticas sí se realizan temprano. c) ❌ La planificación de pruebas comienza temprano en el modelo V. d) ❌ Las pruebas de aceptación se diseñan temprano, pero se ejecutan más tarde, no temprano. Regla rápida para el examen 🧠 🧪 Pruebas estáticas → temprano▶️ Pruebas dinámicas → cuando hay software ejecutable 21 / 26 ¿Cuál de las siguientes opciones explica MEJOR un beneficio de la independencia en las pruebas? a) El uso de un equipo de pruebas independiente permite a la gestión del proyecto asignar la responsabilidad de la calidad del entregable final al equipo de pruebas. b) Si se puede pagar un equipo de pruebas externo a la organización, entonces existen beneficios distintos en términos de que este equipo externo no se deje influenciar fácilmente por las preocupaciones de entrega de la gestión de proyectos y la necesidad de cumplir con plazos de entrega estrictos. c) Un equipo de pruebas independiente puede trabajar por separado de los desarrolladores, no necesita distraerse con cambios en los requisitos del proyecto y puede restringir la comunicación con los desarrolladores a la presentación de informes de defectos a través del sistema de gestión de defectos. d) Cuando las especificaciones contienen ambigüedades e inconsistencias, se hacen suposiciones sobre su interpretación, y un probador independiente puede ser útil para cuestionar esas suposiciones y la interpretación hecha por el desarrollador. Explicación El beneficio clave de la independencia en las pruebas (según ISTQB) es que un probador independiente puede: Ver el sistema con ojos frescos Cuestionar supuestos hechos por quienes diseñaron o desarrollaron el software Detectar ambigüedades, inconsistencias y malentendidos en requisitos y diseño Eso es exactamente lo que describe la opción d. Por qué las otras opciones son incorrectas a) ❌ La calidad no se delega solo al equipo de pruebas; es responsabilidad de todo el equipo. b) ❌ Aunque puede ser cierto en algunos contextos, no es el mejor ni el beneficio fundamental que define la independencia. c) ❌ La independencia no implica aislamiento ni reducción de la comunicación; al contrario, la colaboración es clave. Frase clave para examen 🧠 👀 Independencia = cuestionar supuestos y detectar problemas que otros pasan por alto 22 / 26 ¿Cuál de las siguientes es el MEJOR ejemplo de cómo la trazabilidad respalda las pruebas? a) Realizar el análisis de impacto de un cambio proporcionará información sobre la finalización de las pruebas. b) Analizar la trazabilidad entre casos de prueba y resultados de pruebas proporcionará información sobre el nivel estimado de riesgo residual. c) Realizar el análisis de impacto de un cambio ayudará a seleccionar los casos de prueba correctos para las pruebas de regresión. d) Analizar la trazabilidad entre la base de pruebas, los objetos de prueba y los casos de prueba ayudará a seleccionar los datos de prueba para lograr la cobertura asumida del objeto de prueba. Explicación La trazabilidad permite relacionar elementos como: requisitos (base de pruebas), casos de prueba, código/objetos de prueba, defectos y cambios. Gracias a esas relaciones, cuando ocurre un cambio, se puede hacer un análisis de impacto para identificar qué partes del sistema y qué casos de prueba se ven afectados. 👉 Esto es exactamente lo que se necesita para seleccionar los casos de prueba adecuados en pruebas de regresión. Por qué las otras opciones NO son la mejor a) La finalización de pruebas depende de criterios de salida, no directamente de la trazabilidad. b) El riesgo residual se estima con base en riesgos y resultados, pero la trazabilidad por sí sola no lo determina. d) La trazabilidad ayuda a cobertura de requisitos, no a seleccionar datos de prueba específicos. Resumen para examen 🧠 🔗 Trazabilidad = saber qué probar cuando algo cambia➡️ Ideal para análisis de impacto y pruebas de regresión. 23 / 26 Considera el siguiente testware. ¿Qué actividad de prueba produce este testware como salida? a) Planificación de pruebas b) Monitoreo y control de pruebas c) Análisis de pruebas d) Diseño de pruebas Explicación:La Carta de Prueba que se muestra es un test charter, típico del testing exploratorio. Este artefacto define: Qué se va a probar (Página de Registro) Cómo se va a probar (con diferentes datos incorrectos) Con qué objetivo (descubrir defectos de aceptación) Según ISTQB, los test charters son testware producido durante la actividad de diseño de pruebas, igual que los casos de prueba o los datos de prueba. Para ubicarlo rápido en el ciclo: Planificación → estrategia, enfoque, cronograma Análisis → condiciones de prueba Diseño → casos de prueba, test charters, datos de prueba ✅ Monitoreo y control → métricas, seguimiento, reportes 24 / 26 Un teléfono sonando en un cubículo vecino distrae a un programador y lo lleva a programar incorrectamente la lógica que verifica el límite superior de una variable de entrada. Más tarde, durante las pruebas del sistema, un probador nota que este campo de entrada acepta valores de entrada no válidos. ¿Cuál de las siguientes opciones describe correctamente un límite superior codificado incorrectamente? a) La causa raíz b) Una falla c) Un error d) Un defecto Por qué: El programador distraído comete un error (acción humana incorrecta). Ese error se introduce en el código como una lógica mal implementada del límite superior: eso es un defecto (también llamado bug). Durante las pruebas, cuando el sistema acepta valores no válidos, eso es una falla (comportamiento observable incorrecto). El teléfono sonando sería parte de la causa raíz del error humano. Así que, específicamente, un límite superior codificado incorrectamente describe un defecto. ✅ 25 / 26 En muchas organizaciones de software, el departamento de pruebas se llama el departamento de Aseguramiento de la Calidad (QA). ¿Es correcta o no esta oración y por qué? a) Es correcta. Las pruebas y QA significan exactamente lo mismo. b) Es correcta. Estos nombres se pueden usar indistintamente porque tanto las pruebas como QA se centran en las mismas cuestiones de calidad. c) No es correcto. Las pruebas son algo más; las pruebas incluyen todas las actividades relacionadas con la calidad. QA se centra en procesos relacionados con la calidad. d) No es correcto. QA se enfoca en procesos relacionados con la calidad, mientras que las pruebas se concentran en demostrar que un componente o sistema es apto para su propósito y en detectar defectos. Por qué: QA (Aseguramiento de la Calidad) es un enfoque preventivo: define, mejora y controla procesos para asegurar la calidad desde el inicio (normas, métodos, auditorías, mejora continua). Pruebas de software son un enfoque detectivo: se centran en ejecutar el software para encontrar defectos y verificar que el sistema cumple su propósito. Aunque en muchas organizaciones el área de pruebas se llame “QA”, no significan lo mismo conceptualmente. QA abarca procesos; las pruebas son solo una parte de la gestión de la calidad. 26 / 26 Se te asignó la tarea de analizar y corregir las causas de los fallos en un nuevo sistema que se va a entregar. ¿Qué actividad estás realizando? a) Depuración b) Pruebas de software c) Elicitación de requisitos d) Gestión de defectos Por qué:La depuración consiste justamente en analizar y corregir las causas de los fallos (errores) que aparecen en un sistema. No solo se detectan, sino que se investiga su origen y se arreglan. Para contrastar rápidamente: Pruebas de software → buscan detectar fallos, no corregirlos. Elicitación de requisitos → se enfoca en obtener necesidades del usuario. Gestión de defectos → administra y da seguimiento a los errores, pero no necesariamente los corrige. 👉 Así que, si estás analizando y corrigiendo fallos, estás haciendo depuración. Tu puntación es La puntuación media es 92% 0% Reinicia el cuestionario
