ISTQB Foundation (CTFL v4.0) Examen de práctica #13 — Preguntas y respuestas
Todas las preguntas de este examen de práctica, con la respuesta correcta marcada y una justificación escrita para cada opción a continuación — para leer y repasar, no una prueba cronometrada.
Un desarrollador recorre el código en un depurador para localizar por qué un cálculo devuelve un total incorrecto y luego cambia la línea defectuosa. Según la distinción de ISTQB, ¿cómo se llama esta actividad?
Depuración
Localizar, diagnosticar y corregir un defecto es depuración, una actividad de desarrollo.
Pruebas dinámicas
Las pruebas dinámicas ejecutan el código para observar fallos, no para corregir la causa.
Prueba de confirmación
La prueba de confirmación reejecuta una prueba tras la corrección; no realiza la corrección.
Análisis estático
El análisis estático examina el código sin ejecutarlo y no corrige defectos.
Las pruebas encuentran fallos; la depuración localiza, analiza y corrige el defecto subyacente.
Un equipo ejecuta cada noche una suite aparentemente exhaustiva y la compilación siempre está en verde, pero los usuarios siguen reportando fallos en producción. ¿Qué principio de prueba explica mejor esta situación?
Las pruebas muestran la presencia, no la ausencia, de defectos
Las pruebas en verde no prueban que no haya defectos; condiciones no probadas pueden fallar.
Las pruebas exhaustivas son imposibles
Cierto en general, pero aquí el problema es que pasar pruebas no garantiza ausencia de defectos, no el número de combinaciones.
Las pruebas se desgastan (paradoja del pesticida)
Ese principio trata de que pruebas repetidas encuentran menos defectos nuevos con el tiempo, no de compilaciones en verde que ocultan fallos.
Los defectos se agrupan
La agrupación predice dónde se concentran los defectos; no explica por qué pruebas que pasan omiten fallos en producción.
Que las pruebas pasen solo muestra la ausencia de los fallos cubiertos, nunca la ausencia de todos los defectos.
En una revisión de sprint el responsable de producto dice: 'Tengo mucha más confianza para publicar ahora que el paquete de regresión está en verde.' ¿Qué objetivo de prueba se cumple aquí?
Generar confianza sobre el nivel de calidad
Una suite de regresión que pasa aumenta la confianza de los interesados en la calidad — un objetivo central.
Prevenir defectos
La prevención de defectos ocurre antes (p. ej. revisando requisitos), no al observar un paquete en verde.
Encontrar defectos
Aquí no se encontraron defectos nuevos; la afirmación trata de confianza, no de detección.
Cumplir requisitos contractuales
No se menciona contrato ni normativa; el motor es la confianza de los interesados.
Generar confianza en el nivel de calidad es un objetivo reconocido de las pruebas, junto con encontrar defectos.
Un tester escribe '30/02/2026' en un campo de fecha. El campo lo acepta y el sistema calcula mal una fecha de factura. Identifique el error, el defecto y el fallo en ese orden.
Error: suposición equivocada del desarrollador sobre la validación; defecto: falta de comprobación de rango de fecha en el código; fallo: fecha de factura incorrecta
El equívoco humano es el error, la falla resultante en el código es el defecto y la salida errónea observable es el fallo.
Error: fecha de factura incorrecta; defecto: error de tecleo del tester; fallo: falta de validación
Esto invierte la cadena — la fecha de factura incorrecta es el fallo, no el error.
Error: falta de validación; defecto: fecha de factura incorrecta; fallo: suposición del desarrollador
La falta de validación es el defecto y la suposición del desarrollador el error — los roles están intercambiados.
Los tres términos describen el mismo único suceso
Son conceptos distintos, causalmente enlazados, no sinónimos.
Error → defecto (en el código) → fallo (comportamiento erróneo observado) forman la cadena causal.
¿Qué afirmación describe mejor por qué se valora un enfoque de todo el equipo con independencia del tester, aunque los desarrolladores también prueben su propio código?
Los testers independientes tienen supuestos distintos y están menos sujetos al sesgo del autor
Otras perspectivas revelan defectos que los autores, anclados en su propio modelo mental, omiten.
Los testers independientes pueden garantizar software sin defectos
Ninguna prueba garantiza ausencia de defectos; la independencia solo mejora la detección.
Los desarrolladores nunca deberían probar su propio código
Los desarrolladores sí prueban su código; la independencia lo complementa, no lo sustituye.
La independencia elimina la necesidad de técnicas de diseño de pruebas
La independencia no sustituye las técnicas sistemáticas; ambas son necesarias.
Los testers independientes aportan supuestos y sesgos distintos, por lo que tienden a encontrar defectos que los autores pasan por alto.
Un banco exige que cada actividad de prueba sea trazable a un requisito documentado, y un auditor revisa esa trazabilidad. ¿Qué dos objetivos de prueba se cumplen de forma más directa? (Elija dos.)
Cumplir requisitos contractuales, legales o normativos
La trazabilidad auditable es un objetivo clásico impulsado por el cumplimiento.
Proporcionar información a los interesados para decisiones informadas
La trazabilidad da a los interesados evidencia de cobertura para basar decisiones de publicación.
Reducir el coste del alojamiento en la nube
El coste de alojamiento no se relaciona con los objetivos de trazabilidad de requisitos.
Garantizar la ausencia de defectos
Ningún objetivo puede garantizar la ausencia de defectos; la trazabilidad no cambia ese principio.
La trazabilidad a los requisitos respalda tanto la verificación de cumplimiento/contractual como la provisión de información para decisiones.
¿Qué par relaciona correctamente una actividad típica del proceso de prueba con su propósito?
Análisis de pruebas — determinar 'qué probar' identificando condiciones de prueba
El análisis de pruebas evalúa la base de prueba para derivar condiciones de prueba.
Implementación de pruebas — decidir los objetivos y el alcance generales
Objetivos y alcance pertenecen a la planificación, no a la implementación.
Finalización de pruebas — ejecutar los casos por primera vez
La primera ejecución es parte de la ejecución; la finalización archiva activos e informa resultados.
Diseño de pruebas — supervisar el progreso frente al plan
La supervisión es una actividad de control; el diseño crea casos a partir de condiciones.
El análisis de pruebas identifica características probables y define condiciones de prueba ('qué probar').
A mitad de un ciclo de prueba los informes muestran que solo se ha ejecutado el 40 % de las pruebas planificadas. El responsable de pruebas reduce entonces el alcance de la suite de regresión y reprioriza las pruebas restantes. En términos ISTQB, esta decisión es un ejemplo de:
Control de pruebas
Correcto — tomar acciones correctivas basadas en la información de monitorización (repriorizar, cambiar alcance, reasignar esfuerzo) es control de pruebas.
Monitorización de pruebas
La monitorización produjo la cifra del 40 % al recoger e informar datos de progreso. La decisión posterior pertenece al control.
Planificación de pruebas
La planificación establece objetivos, enfoque y calendario antes del ciclo. Aquí se dirige un plan existente durante la ejecución, es decir, control.
Finalización de pruebas
La finalización ocurre al terminar el ciclo o el proyecto: se archiva el testware, se informan resultados y se recogen lecciones aprendidas. Allí no se repriorizan pruebas.
La monitorización recoge e informa datos sobre el progreso; el control usa esa información para tomar acciones correctivas, como repriorizar pruebas o cambiar el alcance, de modo que los objetivos aún puedan cumplirse.
Un equipo adopta un enfoque shift-left. ¿Qué acción concreta lo representa mejor?
Los testers revisan historias de usuario y criterios de aceptación durante el refinamiento, antes de codificar
Participar en revisiones antes de escribir código es una actividad shift-left de manual.
Añadir más pruebas exploratorias manuales en el sprint final de estabilización
Concentrar el esfuerzo al final es shift-right en el tiempo, lo opuesto a shift-left.
Monitorizar el sistema en vivo con registro en producción
La monitorización en producción es una práctica shift-right, valiosa pero no shift-left.
Posponer todas las pruebas hasta tener una compilación completa
Esperar una compilación completa retrasa las pruebas, contradiciendo shift-left.
Shift-left significa iniciar antes las actividades de prueba, p. ej. revisar requisitos y escribir pruebas antes del código.
En el lado izquierdo de un modelo en V, los casos de prueba de sistema se diseñan en paralelo con ¿qué producto de trabajo?
La especificación de requisitos del sistema/software
Las pruebas de sistema verifican el sistema contra su especificación de requisitos, diseñadas junto a ella.
El diseño detallado de componentes (unidades)
El diseño de componentes corresponde a la prueba de componentes, no a la de sistema.
El caso de negocio / estudio de viabilidad
Un caso de negocio precede a los requisitos y no es base para diseñar pruebas de sistema.
El código fuente
El código fuente se construye después; las pruebas de sistema se diseñan antes a partir de requisitos.
En el modelo en V cada nivel de prueba se diseña contra su nivel de desarrollo correspondiente; las pruebas de sistema se asocian a la especificación de requisitos del sistema/software.
Un candidato a versión ha pasado las pruebas de sistema. Antes del despliegue, usuarios finales reales del departamento de negocio validan que el software soporta su flujo de trabajo diario según las necesidades del negocio. ¿Qué nivel de prueba es?
Pruebas de aceptación
Validar la idoneidad de uso frente a las necesidades del negocio por los usuarios es prueba de aceptación.
Pruebas de integración
Las pruebas de integración verifican interfaces entre componentes/sistemas, no la idoneidad de negocio.
Pruebas de componentes
Las pruebas de componentes se centran en unidades aisladas, realizadas por desarrolladores, no por usuarios de negocio.
Pruebas de integración de componentes
Esto sigue siendo sobre interfaces internas, no validación de usuario de flujos de negocio.
Las pruebas de aceptación validan la idoneidad de uso y la preparación para el despliegue desde la perspectiva de usuario/negocio.
Tras corregir un defecto en el módulo de pago, el equipo reejecuta exactamente la prueba que fallaba para verificar la corrección y luego reejecuta pruebas vecinas del flujo de compra que antes pasaban. Nombre los dos tipos de prueba en ese orden.
Prueba de confirmación, luego de regresión
Reejecutar la prueba fallida es confirmación; reejecutar las vecinas que antes pasaban es regresión.
Prueba de regresión, luego de confirmación
El orden está invertido — primero se confirma la corrección y luego se buscan regresiones.
Prueba de humo, luego reprueba
Una prueba de humo es una verificación amplia, no la reejecución dirigida del caso fallido.
Pruebas de mantenimiento, luego de confirmación
Las pruebas de mantenimiento son un contexto más amplio (cambios a un sistema desplegado), no estas dos reejecuciones específicas.
La prueba de confirmación verifica la corrección; la de regresión comprueba que el cambio no rompió comportamiento que antes funcionaba.
Una app móvil lleva dos años en producción. Sale una nueva versión del SO y un cambio en la ley fiscal exige cálculos actualizados. ¿Qué dos puntos son ejemplos de desencadenantes de pruebas de mantenimiento? (Elija dos.)
Actualizar a la nueva versión del sistema operativo (cambio del entorno operativo)
La migración/actualización del entorno operativo es un desencadenante reconocido de pruebas de mantenimiento.
Modificar la lógica de cálculo para la nueva ley fiscal
Una modificación correctiva/adaptativa al software en producción desencadena pruebas de mantenimiento.
Escribir las primeras pruebas unitarias durante el desarrollo inicial
Las pruebas del desarrollo inicial no son de mantenimiento, que aplica tras el despliegue.
Elegir la combinación de colores del sitio web de marketing
Una elección cosmética en un sitio web aparte no es un desencadenante de pruebas de mantenimiento de la app.
Las pruebas de mantenimiento se desencadenan por modificaciones, migración/actualización del entorno y retirada; aquí la actualización del SO y un cambio normativo califican.
¿Cuál es un ejemplo de tipo de prueba no funcional en lugar de funcional?
Medir el tiempo de respuesta de la página con 1.000 usuarios concurrentes (eficiencia de rendimiento)
La eficiencia de rendimiento es una característica de calidad no funcional ('cómo de bien').
Comprobar que un inicio de sesión válido lleva al panel
Verificar qué hace el sistema (resultado del login) es prueba funcional.
Verificar que el descuento se aplica al total del carrito
Calcular el descuento correcto es un comportamiento funcional.
Confirmar que aparece un mensaje de error en un campo obligatorio vacío
Validar el comportamiento de campos obligatorios es prueba funcional.
Rendimiento, usabilidad, fiabilidad, portabilidad y seguridad son características de calidad no funcionales.
Un documento de requisitos se examina en una revisión formal dirigida por un moderador capacitado, con roles definidos, preparación individual, reunión registrada y métricas recopiladas. ¿Qué tipo de revisión es?
Inspección
El moderador capacitado, los roles definidos, la preparación y las métricas distinguen a una inspección.
Revisión informal
Una revisión informal no tiene proceso, roles ni métricas definidos — lo opuesto a este caso.
Recorrido (walkthrough)
Un walkthrough lo dirige el autor y no requiere métricas ni un moderador capacitado.
Comprobación de escritorio ad hoc
Una comprobación de escritorio es informal e individual, sin el aparato formal descrito.
Una inspección es la revisión más formal: moderador capacitado, roles, criterios de entrada/salida, preparación y métricas.
¿Por qué el análisis estático de una especificación de requisitos suele ser más rentable que esperar a que las pruebas dinámicas expongan el mismo problema?
Los defectos hallados en requisitos se eliminan antes de propagarse a diseño, código y pruebas
Eliminar un defecto de requisitos pronto evita el coste multiplicado de corregirlo después.
Las pruebas estáticas ejecutan el código más rápido que las dinámicas
Las pruebas estáticas no ejecutan código, así que no pueden 'ejecutar más rápido'.
Las pruebas estáticas garantizan que ningún defecto llegue a producción
Ninguna técnica garantiza cero defectos escapados.
Las pruebas estáticas hacen innecesarias las dinámicas
Ambas son complementarias; las estáticas no pueden hallar fallos de ejecución/comportamiento.
Las pruebas estáticas encuentran defectos pronto, antes de que se propaguen al código y a las pruebas, reduciendo el coste de eliminación.
¿Qué dos anomalías puede detectar de forma realista una revisión de requisitos que las pruebas dinámicas normalmente no pueden? (Elija dos.)
Un requisito ambiguo que dos lectores interpretan de forma distinta
La ambigüedad es un defecto documental que revela una revisión; ejecutar código no lo expone.
Un requisito que falta por completo en la especificación
Una omisión la detectan los revisores al comparar con las necesidades; las pruebas dinámicas solo verifican lo existente.
Una fuga de memoria que aparece solo tras horas de ejecución
Una fuga de memoria en ejecución es un fallo solo dinámico, no detectable por una revisión estática.
Una condición de carrera temporal bajo alta carga concurrente
Una carrera de concurrencia se manifiesta solo en ejecución y se halla con pruebas dinámicas.
Las revisiones detectan ambigüedades, contradicciones, requisitos faltantes y desviaciones de estándares — problemas no visibles al ejecutar código.
El proceso de revisión comienza con una actividad de planificación. ¿Qué se determina en esa actividad, antes de que los revisores reciban el producto de trabajo?
El alcance y propósito de la revisión, el tipo y los roles, las listas de comprobación y, en revisiones más formales, los criterios de entrada y salida.
Correcto — todo ello se fija en la planificación, para que los revisores sepan qué buscar y cuándo se considera completa la revisión.
El estado y la severidad asignados a cada anomalía encontrada.
En la planificación aún no existen anomalías. Se discuten y se les asigna estado y severidad más tarde, en la comunicación y análisis de los hallazgos.
Las correcciones que el autor hará en el producto de trabajo.
Las correcciones se deciden y realizan en la actividad final, corrección e informe, una vez aceptadas las anomalías.
Los hallazgos individuales de cada revisor.
Los hallazgos individuales se producen durante la revisión individual, cuando cada revisor examina el producto por su cuenta.
La planificación de la revisión define el alcance y propósito, el producto a revisar, las características de calidad a evaluar, el tipo de revisión y los roles, las listas de comprobación, el esfuerzo y, en revisiones más formales, los criterios de entrada y salida.
Un formulario de registro tiene un campo 'edad' que acepta números enteros. La regla de negocio indica: edades de 18 a 65 inclusive se aceptan; por debajo de 18 se rechaza la solicitud; por encima de 65 se deriva a revisión manual. Usando partición de equivalencia solo en el campo de edad, ¿cuál es el número mínimo de casos de prueba para cubrir cada partición válida e inválida exactamente una vez?
3
Un valor de cada una de las tres particiones de resultado (p. ej. 40, 10, 80) da cobertura completa.
2
Dos casos no cubren tres particiones distintas; una quedaría sin probar.
4
Cuatro probaría una partición de forma redundante; solo existen tres particiones del resultado.
6
Seis corresponde al análisis de valores límite, no a la cobertura mínima de particiones.
Hay tres particiones para el resultado (aceptar 18–65, rechazar <18, derivar >65). La partición de equivalencia exige al menos un valor por partición → 3 casos.
Reutilice el mismo campo de edad, cuyo rango válido es de 18 a 65 inclusive (enteros). Aplicando análisis de valores límite de 2 valores (cada límite más su vecino más cercano del lado inválido), ¿qué conjunto exacto de edades debe probarse?
17, 18, 65, 66
Cada límite (18, 65) más el vecino inválido más cercano (17, 66) — cuatro valores.
17, 18, 19, 64, 65, 66
Eso es AVL de 3 valores (límite más ambos vecinos), no de 2 valores.
18, 65
Solo los límites — faltan los vecinos inválidos más cercanos.
18, 19, 64, 65
Son los límites y sus vecinos del lado válido; el AVL de 2 valores usa el vecino del lado inválido.
El AVL de 2 valores prueba cada límite y el valor inmediatamente fuera: para [18,65] son 17, 18, 65, 66.
Un motor de descuentos concede envío gratis cuando el subtotal del pedido es al menos 50 € y como máximo 500 € (inclusive). Usando análisis de valores límite de 3 valores sobre el subtotal, ¿cuántos valores de prueba distintos se requieren para cubrir ambos límites?
6
Dos límites × tres valores cada uno (49/50/51 y 499/500/501) = 6 valores distintos.
4
Cuatro es AVL de 2 valores, no de 3.
3
Tres cubre solo un límite; hay dos límites a probar.
8
Ocho cuenta de más; el AVL de 3 valores necesita exactamente tres valores por límite.
El AVL de 3 valores prueba el límite y los valores justo por debajo y por encima: inferior 49,50,51 y superior 499,500,501 → 6 valores.
Regla R6 → Paid upgrade offer
R6 tiene Gold=N, disponible=Sí, tarifa>=200=N, asociada a la acción 'Paid upgrade offer'.
Regla R5 → Free upgrade
R5 exige tarifa>=200=Sí, pero 180 € está por debajo de 200, así que R5 no se activa.
Regla R2 → Free upgrade
R2 exige Gold=Sí; este huésped no es miembro Gold.
Regla R7 → No upgrade
R7 exige disponible=N, pero hay habitación disponible, así que R7 no coincide.
Gold=N, disponible=Sí, tarifa 180 € significa 'tarifa >= 200?' = N. Coincide con la columna R6, cuya acción es 'Paid upgrade offer'.
4 reglas se colapsan en 1
R3, R4, R7, R8 comparten disponible=N y la misma acción, fusionándose en una regla de indiferencia.
2 reglas se colapsan en 1
Más de dos reglas tienen disponible=N; las cuatro califican, no solo dos.
3 reglas se colapsan en 1
Cuatro reglas (R3, R4, R7, R8), no tres, comparten la condición de indiferencia.
No se puede colapsar ninguna regla
El colapso es válido precisamente porque cuatro reglas dan la misma acción bajo una condición indiferente.
Las reglas R3, R4, R7, R8 tienen habitación disponible=N y la misma acción 'No upgrade'; las demás condiciones son indiferentes, así que estas cuatro reglas se colapsan en una.
¿Qué afirmación sobre la partición de equivalencia es correcta?
Se asume que todos los valores de una partición se procesan igual, por lo que se puede probar un valor representativo
Es el supuesto definitorio que permite a la partición de equivalencia reducir el número de pruebas.
Las particiones siempre deben solaparse para asegurar cobertura completa
Las particiones válidas son disjuntas; el solape rompe el supuesto de equivalencia.
La partición de equivalencia solo aplica a entradas inválidas
La partición de equivalencia aplica tanto a particiones válidas como inválidas.
Requiere probar todos los valores posibles de cada partición
Eso sería prueba exhaustiva, que la partición de equivalencia busca evitar.
El supuesto central de la partición de equivalencia es que todos los miembros de una partición se procesan igual, por lo que probar un representante vale por toda la partición.
7
Hay siete transiciones válidas, así que la cobertura 0-switch necesita siete casos.
5
Cinco cuenta de menos — ignora ambas transiciones 'reject' o la transición 'decline'.
4
Cuatro equivale al camino feliz más largo, no al número de todas las transiciones.
8
Ocho cuenta de más; la flecha de inicio no es una transición de estado etiquetada que se pruebe aparte.
La cobertura 0-switch necesita un caso por transición válida. El diagrama tiene 7: review, pass(Screening→Interview), pass(Interview→Offer), reject(Screening), reject(Interview), accept, decline.
Alrededor del 83% (5 de 6 sentencias)
La línea 5 no se ejecuta porque b no es mayor que 0; las otras cinco sí.
100%
La línea 5 queda sin ejecutar, así que la cobertura no puede ser completa.
67%
67% significaría que solo 4 de 6 sentencias se ejecutaron, pero cinco lo hacen.
50%
La mitad sería 3 de 6; en realidad se ejecutan cinco de las seis sentencias.
Con a=5,b=-1 se ejecutan las líneas 1,2,3,4,6 pero se omite la línea 5 (rama b>0): 5 de 6 sentencias = 83%.
¿Cuáles dos de las siguientes son técnicas de caja negra (basadas en especificación)? (Elija dos.)
Partición de equivalencia
Deriva pruebas de la especificación de entradas/salidas, una técnica de caja negra.
Análisis de valores límite
El AVL es basado en especificación, centrado en los bordes de las particiones — caja negra.
Cobertura de sentencias
La cobertura de sentencias mide líneas de código ejecutadas — una técnica de caja blanca.
Cobertura de ramas
La cobertura de ramas se basa en el flujo de control del código — caja blanca, no negra.
La partición de equivalencia y el análisis de valores límite son de caja negra; la cobertura de sentencias y ramas es de caja blanca (basada en estructura).
Un tester sénior, sin casos de prueba formales, sondea una nueva función basándose en experiencia previa de defectos e intuición, diseñando y ejecutando pruebas a la vez en sesiones con límite de tiempo. ¿Qué dos términos describen lo que ocurre? (Elija dos.)
Prueba exploratoria
Diseñar y ejecutar pruebas a la vez en sesiones con límite de tiempo es prueba exploratoria.
Conjetura de errores
Apoyarse en la experiencia de defectos probables para dirigir pruebas es conjetura de errores.
Análisis de valores límite
El AVL es una técnica sistemática basada en especificación, no intuición basada en experiencia.
Prueba con tabla de decisión
Las tablas de decisión son una técnica estructurada basada en especificación que requiere reglas documentadas.
Es prueba basada en la experiencia; la conjetura de errores y la prueba exploratoria (a menudo basada en sesiones) son las dos técnicas reconocidas aquí.
Un tester sénior enumera áreas problemáticas probables — entradas vacías, cadenas muy largas, caracteres especiales, envíos simultáneos — según experiencias previas con sistemas similares, y luego diseña pruebas para ellas. ¿Qué técnica es esta?
Conjetura de errores.
Correcto — anticipar defectos probables desde la experiencia es conjetura de errores.
Partición de equivalencia.
La EP es basada en especificaciones y particiona el dominio de entrada, no conjetura por experiencia.
Prueba de tabla de decisión.
Las tablas de decisión modelan combinaciones especificadas, no conjeturas por experiencia.
Prueba de ramas.
La prueba de ramas es una técnica de caja blanca basada en la estructura del código.
La conjetura de errores es una técnica basada en la experiencia donde el tester anticipa defectos probables según el conocimiento de fallos pasados y errores comunes.
Un plan de pruebas indica: 'Las pruebas no comenzarán hasta que la compilación integrada se despliegue en el entorno de pruebas y pasen las pruebas de humo.' ¿De qué es esto un ejemplo?
Criterios de entrada
Son precondiciones que deben cumplirse antes de iniciar la ejecución de pruebas.
Criterios de salida
Los criterios de salida definen cuándo parar, no cuándo empezar.
Un objetivo de prueba
Un objetivo es una meta de las pruebas, no una precondición para empezar.
Un oráculo de prueba
Un oráculo de prueba es una fuente de resultados esperados, ajeno a las condiciones de inicio.
Las condiciones que deben cumplirse antes de iniciar una actividad son criterios de entrada (definición de preparado).
Un equipo etiqueta 'el proveedor de la pasarela de pago podría quebrar a mitad del proyecto, retrasando la entrega' como un riesgo a gestionar. ¿Cómo debe clasificarse este riesgo?
Riesgo de proyecto
Las amenazas de proveedor y plazos afectan la capacidad de entrega del proyecto — un riesgo de proyecto.
Riesgo de producto
Un riesgo de producto concierne a una deficiencia de calidad en el entregable, no a la solvencia del proveedor.
Un defecto
Un defecto es una falla existente, mientras que esto es un posible suceso futuro.
Un fallo
Un fallo es comportamiento erróneo observado en ejecución, no una amenaza de negocio/proveedor.
Un riesgo para la capacidad de entrega del proyecto (plazos, recursos, proveedores) es un riesgo de proyecto, no un riesgo de producto (calidad).
¿Cuáles dos de los siguientes son riesgos de producto (frente a riesgos de proyecto)? (Elija dos.)
El pago podría calcular mal el IVA para ciertos países
Un posible defecto de calidad funcional en el producto es un riesgo de producto.
La app podría responder demasiado lento bajo carga pico, dañando la usabilidad
Un posible déficit de rendimiento/calidad en el entregable es un riesgo de producto.
Dos testers clave podrían dimitir antes de la versión
Las amenazas de personal/recursos son riesgos de proyecto, no de calidad de producto.
El hardware del entorno de pruebas podría entregarse tarde
La entrega tardía de infraestructura es un riesgo de proyecto (plazos/recursos).
Los riesgos de producto se refieren a posibles deficiencias de calidad del entregable; los de proyecto, a la gestión del proyecto.
Durante la ejecución, un jefe de pruebas sigue el porcentaje de casos planificados ejecutados y el número de defectos abiertos de alta severidad frente al plan. ¿Qué actividad de prueba respalda esto principalmente?
Monitorización y control de pruebas
Seguir métricas frente al plan para dirigir el esfuerzo es monitorización y control.
Análisis de pruebas
El análisis de pruebas define qué probar; no es seguimiento del progreso.
Implementación de pruebas
La implementación prepara medios/entornos, no el seguimiento de métricas frente al plan.
Finalización de pruebas
La finalización cierra e informa al final; aquí el seguimiento ocurre durante la ejecución.
Comparar el progreso real con el plan mediante métricas es la monitorización y control de pruebas.
Una líder de pruebas estima el esfuerzo para probar una función con la técnica de tres puntos (PERT). La estimación optimista es de 4 días, la más probable de 10 días y la pesimista de 22 días. Según la fórmula (a + 4m + b) / 6, ¿cuál es el esfuerzo esperado?
11 días
(4 + 40 + 22)/6 = 66/6 = 11.
12 días
12 es el promedio simple de los tres valores, no la media ponderada PERT.
10 días
10 es solo el valor más probable, ignorando los extremos optimista y pesimista.
13 días
13 no resulta de la fórmula; la media ponderada correcta es 11.
(4 + 4×10 + 22) / 6 = (4 + 40 + 22) / 6 = 66 / 6 = 11 días.
¿Qué dos elementos son contenido esencial de un buen informe de defectos (incidencia)? (Elija dos.)
Pasos claros para reproducir el problema
Los pasos de reproducción permiten a los desarrolladores recrear y diagnosticar el defecto de forma fiable.
El resultado esperado frente al resultado real
Indicar esperado vs real precisa exactamente cómo se desvía el comportamiento.
La dirección particular del desarrollador que escribió el código
Los datos personales del autor son irrelevantes e inapropiados en un informe de defectos.
Una corrección garantizada de la causa raíz propuesta por el tester
Diagnosticar la causa raíz y la corrección es depuración, no contenido obligatorio del informe.
Un informe de defectos debe permitir reproducción y valoración: los pasos para reproducir y el resultado esperado frente al real son esenciales.
¿Qué tarea es típicamente responsabilidad de un jefe de pruebas y no de un tester?
Redactar y mantener el plan de pruebas y la estrategia general
La planificación y la estrategia son responsabilidades centrales de la gestión de pruebas.
Diseñar casos de prueba a partir de las condiciones
Diseñar casos concretos es tarea del tester.
Ejecutar pruebas y registrar los resultados
La ejecución y el registro de resultados son actividades del tester.
Preparar datos de prueba para casos individuales
Preparar datos de prueba es parte de la implementación que realizan los testers.
Las tareas de gestión de pruebas incluyen planificar, organizar y liderar el esfuerzo; los testers analizan, diseñan, implementan y ejecutan pruebas.
Un equipo ágil acuerda que una historia está 'terminada' solo cuando sus pruebas de aceptación pasan, el código se revisa y no quedan defectos de alta severidad abiertos. ¿Qué representa este acuerdo?
La definición de hecho (una forma de criterios de salida)
Enumera las condiciones que deben cumplirse para considerar la historia completa.
La definición de preparado (criterios de entrada)
La definición de preparado rige cuándo puede empezar el trabajo, no cuándo termina.
Una carta de prueba (test charter)
Una carta de prueba delimita una sesión exploratoria, no las condiciones de finalización.
Una matriz de trazabilidad
Una matriz de trazabilidad enlaza elementos con requisitos; no es un acuerdo de finalización.
Las condiciones de finalización compartidas para un elemento de trabajo forman la definición de hecho, una forma ágil de criterios de salida.
Un plan define que las pruebas de sistema solo pueden empezar cuando la compilación pasa una prueba de humo y las de componente están completas sin defectos críticos. ¿Cómo se llaman estas condiciones?
Criterios de entrada
Correcto — condiciones antes de iniciar las pruebas.
Criterios de salida
Definen cuándo termina una actividad.
Condiciones de prueba
Una condición es un aspecto comprobable.
Criterios de aceptación
Definen cuándo una historia es aceptable.
Las condiciones para iniciar una actividad son criterios de entrada.
¿Cuál es un beneficio realista de usar una herramienta de ejecución (automatización) de pruebas para una suite de regresión estable?
Las pruebas de regresión repetitivas pueden ejecutarse más a menudo y de forma consistente, liberando a los testers
La repetibilidad fiable y el menor esfuerzo manual en pruebas estables es un beneficio central de la automatización.
Elimina la necesidad de diseñar casos o mantener scripts
La automatización sigue requiriendo diseño de pruebas y mantenimiento continuo de scripts.
Garantiza el descubrimiento de todos los defectos
Ninguna herramienta garantiza hallar todos los defectos; la automatización solo ejecuta las pruebas dadas.
Es ideal para comprobaciones exploratorias únicas y cambiantes
La automatización conviene a pruebas estables y repetidas; las exploratorias volátiles se hacen mejor manualmente.
La automatización destaca en repetir de forma fiable grandes volúmenes de pruebas, reduciendo el esfuerzo manual repetitivo en casos estables.
Una herramienta analiza el código fuente en busca de violaciones de estándares de codificación y posibles defectos sin ejecutar el programa. ¿En qué categoría de herramienta encaja?
Una herramienta de análisis estático
Examina el código sin ejecutarlo — la definición de herramienta de análisis estático.
Una herramienta de ejecución de pruebas
Las herramientas de ejecución corren el software; esta no ejecuta el programa.
Una herramienta de pruebas de rendimiento
Las herramientas de rendimiento miden el comportamiento en ejecución bajo carga, lo que requiere ejecución.
Una herramienta de gestión de pruebas
Las herramientas de gestión organizan activos e informes, no el análisis de código.
Una herramienta que analiza código sin ejecutarlo es de análisis estático y respalda las pruebas estáticas.