ISTQB Foundation (CTFL v4.0) Examen de práctica #3 — Preguntas y respuestas
Todas las preguntas de este examen de práctica, con la respuesta correcta marcada y una justificación escrita para cada opción a continuación — para leer y repasar, no una prueba cronometrada.
¿Cuál de las siguientes afirmaciones sobre los siete principios de prueba es CORRECTA?
Las pruebas exhaustivas son imposibles, por lo que deben enfocarse usando riesgo y prioridades.
Correcto — es el principio 'las pruebas exhaustivas son imposibles'.
Las pruebas pueden demostrar que el software está completamente libre de defectos.
Las pruebas muestran la presencia de defectos, no su ausencia.
Ejecutar las mismas pruebas repetidamente sigue encontrando nuevos defectos.
Contradice la paradoja del pesticida — las pruebas repetidas dejan de hallar defectos nuevos.
Los defectos se distribuyen uniformemente entre todos los módulos.
Los defectos se agrupan — pocos módulos suelen contener la mayoría.
Las pruebas exhaustivas (todas las combinaciones de entradas/precondiciones) son imposibles salvo en casos triviales; el riesgo y las prioridades deben enfocar el esfuerzo.
Un desarrollador comete un error al programar un cálculo. Esto produce código incorrecto que, al ejecutarse, muestra un total equivocado en pantalla. Según la terminología ISTQB, ¿qué es el total equivocado en pantalla?
Un fallo
Correcto — el total equivocado mostrado es el fallo observable.
Un defecto
El defecto es la imperfección en el código, no la salida equivocada.
Un error
El error es la acción humana que introdujo el defecto.
Una causa raíz
La causa raíz es el motivo subyacente del error, no el total visible.
Error (humano) → defecto (en el código) → fallo (el comportamiento observable). El total equivocado mostrado es un fallo.
¿Cuál de los siguientes ejemplos muestra que las pruebas contribuyen al éxito, más allá de encontrar defectos?
Los testers revisan los requisitos antes de codificar, previniendo defectos.
Correcto — la participación temprana previene defectos y contribuye al éxito.
Registrar tantos defectos como sea posible durante la prueba de sistema.
Es detección de defectos, no la contribución más amplia.
Volver a ejecutar pruebas fallidas tras una corrección.
La prueba de confirmación verifica correcciones; no es la contribución preventiva descrita.
Contar el número de casos de prueba ejecutados por día.
Una métrica de productividad, no una contribución al éxito.
Los testers que revisan los requisitos temprano pueden evitar que se introduzcan defectos — una contribución al éxito más allá de la detección.
¿Cuáles DOS de los siguientes son objetivos típicos de prueba? (Elija dos.)
Generar confianza en la calidad del objeto de prueba.
Correcto — un objetivo reconocido de las pruebas.
Proporcionar información para la toma de decisiones.
Correcto — las pruebas aportan información a los interesados.
Corregir los defectos encontrados.
Corregir es depuración/desarrollo, no un objetivo de prueba.
Redactar la especificación de requisitos del sistema.
Redactar requisitos es tarea del análisis de negocio, no de las pruebas.
Objetivos típicos: prevenir defectos, encontrar defectos/fallos, generar confianza, aportar información para decisiones y verificar/validar. Corregir defectos y escribir requisitos no son objetivos de prueba.
¿Qué par distingue correctamente verificación de validación?
Verificación: cumplir requisitos especificados; Validación: cumplir necesidades reales del usuario.
Correcto — la distinción estándar.
Verificación: pruebas dinámicas; Validación: pruebas estáticas.
Ambas pueden ser estáticas o dinámicas; la asignación es incorrecta.
Verificación: por usuarios; Validación: por desarrolladores.
Los roles no definen la distinción.
Verificación y validación son sinónimos.
Están relacionadas pero son distintas.
La verificación comprueba que los productos de trabajo cumplen los requisitos especificados (construir bien el producto); la validación comprueba que el producto satisface las necesidades reales (construir el producto correcto).
¿En qué actividad de prueba se verifica que el entorno, la infraestructura y las herramientas estén listos y se comprueban los criterios de entrada antes de ejecutar?
Implementación de pruebas
Correcto — la implementación prepara y verifica el entorno y los recursos.
Planificación de pruebas
La planificación define objetivos y enfoque, no la verificación final del entorno.
Diseño de pruebas
El diseño transforma condiciones de prueba en casos de prueba.
Finalización de pruebas
La finalización recopila datos e informa al terminar las pruebas.
En el proceso de prueba ISTQB, la implementación de pruebas incluye verificar que el entorno y los recursos estén correctamente preparados antes de la ejecución.
¿Qué describe MEJOR la trazabilidad entre la base de prueba y los productos de trabajo de prueba?
Permite evaluar la cobertura, analizar el impacto y auditar las pruebas.
Correcto — son beneficios clave de la trazabilidad.
Garantiza que no quedan defectos en el software.
La trazabilidad no demuestra la ausencia de defectos.
Elimina la necesidad de planificar las pruebas.
La trazabilidad apoya, pero no reemplaza, la planificación.
Solo es útil para pruebas automatizadas.
La trazabilidad aplica a pruebas manuales y automatizadas por igual.
Una buena trazabilidad enlaza condiciones, casos y resultados con la base de prueba, permitiendo análisis de impacto, evaluación de cobertura y auditabilidad.
¿Cuál es el MEJOR ejemplo de un tester que demuestra una buena mentalidad de prueba y las habilidades interpersonales adecuadas al reportar un defecto?
Describir el defecto de forma objetiva y neutral, centrándose en el producto, no en la persona.
Correcto — la comunicación constructiva y basada en hechos mantiene buenas relaciones.
Indicar en el informe qué desarrollador causó el defecto.
Culpar a personas daña las relaciones y es contraproducente.
Esperar a que se acumulen muchos defectos para reportarlos juntos.
Retrasar los informes reduce su valor y oportunidad.
Reportar solo los defectos que confirman las expectativas del tester.
El sesgo de confirmación socava la objetividad.
Los defectos deben comunicarse de forma constructiva y objetiva, centrándose en el producto y no en culpar al autor, para mantener buenas relaciones de trabajo.
Según el principio de 'pruebas tempranas' (shift left), ¿cuál es la MEJOR razón para involucrar las pruebas durante la fase de requisitos?
Los defectos hallados temprano son más baratos de corregir y no se propagan.
Correcto — el costo de corrección sube cuanto más tarde se halla el defecto.
Permite omitir las pruebas de sistema y aceptación más adelante.
Las pruebas tempranas complementan, no sustituyen, los niveles posteriores.
Los requisitos nunca contienen defectos, así que la revisión es rápida.
Los requisitos a menudo contienen defectos como ambigüedades y vacíos.
Garantiza que el proyecto terminará a tiempo.
Las pruebas tempranas reducen riesgo, pero no garantizan el plazo.
Los defectos hallados en requisitos son mucho más baratos de corregir que los posteriores; revisar temprano evita que defectos costosos pasen a diseño y código.
Un equipo acaba de integrar varios componentes y quiere verificar que las interfaces y flujos de datos entre ellos funcionan correctamente. ¿Qué nivel de prueba es?
Pruebas de integración
Correcto — se centran en interfaces e interacciones entre componentes.
Pruebas de componente
Las pruebas de componente verifican un componente aislado.
Pruebas de aceptación
Las pruebas de aceptación validan la disposición para uso por usuarios/clientes.
Pruebas de sistema
Las pruebas de sistema verifican el comportamiento del sistema completo integrado.
Las pruebas de integración se centran en las interacciones e interfaces entre componentes o sistemas integrados.
¿Cuál de las siguientes es un tipo de prueba FUNCIONAL?
Verificar que una transferencia debita y acredita las cuentas correctas.
Correcto — prueba una función que el sistema debe realizar.
Medir el tiempo de respuesta con 1000 usuarios concurrentes.
Es prueba de rendimiento (no funcional).
Evaluar la facilidad con que nuevos usuarios completan el pago.
Es prueba de usabilidad (no funcional).
Comprobar que la app se instala en tres sistemas operativos.
Es prueba de portabilidad (no funcional).
Las pruebas funcionales evalúan qué hace el sistema (sus funciones). Rendimiento, usabilidad y portabilidad son características no funcionales.
Tras corregir un defecto, el equipo vuelve a ejecutar pruebas en áreas no modificadas de la aplicación para asegurar que la corrección no introdujo efectos secundarios. ¿Cómo se llama esto?
Pruebas de regresión
Correcto — detecta efectos secundarios no deseados de los cambios.
Prueba de confirmación
La confirmación reejecuta solo la prueba que falló originalmente.
Prueba de humo
La prueba de humo verifica superficialmente que la compilación es estable.
Pruebas exploratorias
Las exploratorias combinan aprendizaje, diseño y ejecución simultáneos.
Las pruebas de regresión verifican que la funcionalidad que antes funcionaba no se rompió por los cambios. La prueba de confirmación reejecuta solo la prueba que falló originalmente.
Se realiza un cambio de mantenimiento en un sistema en producción para que funcione en una nueva versión del sistema operativo, sin cambio de funcionalidad. ¿Qué desencadenante de mantenimiento representa?
Migración a un nuevo entorno operativo.
Correcto — adaptarse a un nuevo SO/plataforma es un desencadenante reconocido.
Mantenimiento correctivo para arreglar un fallo en producción.
Aquí no se corrige defecto; la funcionalidad no cambia.
Mejora para añadir una nueva característica.
No se añade funcionalidad nueva.
Retiro del sistema.
El sistema se mantiene en uso, no se retira.
Migrar el software a un nuevo entorno operativo (nuevo SO, plataforma o hardware) es un desencadenante de mantenimiento de entorno/migración.
Además de los tipos funcional y no funcional, el programa describe un tipo de prueba que evalúa si la estructura interna o la implementación del objeto de prueba se ha ejercitado lo suficiente, por ejemplo midiendo cobertura de sentencias o de decisiones. ¿Qué tipo es?
Prueba de caja blanca
Correcto — la prueba de caja blanca (basada en la estructura) es el tipo que se ocupa de cuán exhaustivamente se ha ejercitado la estructura interna del objeto.
Prueba no funcional
La prueba no funcional evalúa cómo se comporta el sistema (rendimiento, usabilidad, fiabilidad y similares), no cuánta de su estructura de código se ha ejercitado.
Prueba funcional
La prueba funcional evalúa qué hace el sistema frente a sus requisitos funcionales; la estructura interna es irrelevante para seleccionar las pruebas.
Prueba de confirmación
La prueba de confirmación está relacionada con cambios: se reejecutan las pruebas que fallaron para comprobar que la corrección funciona. No dice nada sobre cobertura estructural.
La prueba de caja blanca (basada en la estructura) deriva las pruebas de la estructura interna o la implementación del objeto de prueba y suele informar cobertura estructural, como cobertura de sentencias o de decisiones.
¿Cuál de los siguientes puede examinarse mediante pruebas estáticas pero NO mediante pruebas dinámicas?
Ambigüedades e inconsistencias en un documento de requisitos.
Correcto — solo las pruebas estáticas revisan documentos no ejecutables.
Fugas de memoria durante la ejecución.
Las fugas aparecen solo al ejecutar el código — pruebas dinámicas.
El tiempo de respuesta real de una transacción.
El tiempo de respuesta requiere ejecución — pruebas dinámicas.
Resultados incorrectos al ejecutar el programa.
Observar resultados erróneos requiere ejecución — pruebas dinámicas.
Las pruebas estáticas detectan defectos en productos no ejecutables, como ambigüedades e inconsistencias en requisitos, que las dinámicas (que requieren ejecución) no pueden.
¿En qué tipo de revisión los propósitos principales son detectar defectos, evaluar la calidad y generar confianza, con un moderador/facilitador capacitado y un proceso formal documentado basado en reglas y listas de verificación?
Inspección
Correcto — la revisión más formal con moderador capacitado y métricas.
Revisión informal
Una revisión informal no tiene proceso definido ni resultados documentados.
Recorrido (walkthrough)
El recorrido lo dirige el autor y es menos formal que la inspección.
Revisión técnica
La revisión técnica es formal pero se centra en decisiones técnicas, a menudo sin moderador capacitado.
La inspección es el tipo de revisión más formal: dirigida por un moderador capacitado, con proceso definido, roles, reglas, listas de verificación y métricas.
¿Cuál de los siguientes es un factor clave de éxito de una revisión, relacionado con las personas más que con el proceso?
Realizar la revisión en un ambiente de confianza, sin culpar a los participantes.
Correcto — un factor de personas que fomenta la apertura.
Definir objetivos claros para la revisión.
Importante, pero es un factor del proceso.
Usar listas de verificación adecuadas al producto.
Técnica útil, pero un factor del proceso.
Mantener el producto suficientemente pequeño para revisarlo bien.
Un factor de proceso/organización, no de personas.
Los factores de éxito relacionados con las personas incluyen realizar revisiones en un ambiente de confianza, sin culpas, para que los participantes se sientan seguros e implicados.
En una revisión formal, ¿quién es responsable del documento revisado y normalmente corrige los defectos encontrados?
El autor
Correcto — el autor es dueño del producto y aplica las correcciones.
El moderador (facilitador)
El moderador dirige el proceso, no el contenido del documento.
El secretario (registrador)
El secretario registra los hallazgos durante la reunión.
El líder de la revisión
El líder planifica la revisión, pero no es dueño del documento.
El autor crea el producto de trabajo revisado, es responsable de él y realiza los cambios resultantes.
El diagrama de estados siguiente modela un reproductor multimedia. Si cada transición es un caso de prueba independiente, ¿cuál es el número mínimo de casos para lograr cobertura 0-switch (cada transición válida una vez)?
5
Hay cinco transiciones válidas; un caso por transición da cinco.
3
3 es el número de estados, no de transiciones a cubrir.
4
Cuenta de menos; el diagrama tiene cinco transiciones válidas, no cuatro.
6
Cuenta de más; no hay una sexta transición válida en el diagrama.
La cobertura 0-switch exige cada transición válida una vez. El diagrama muestra cinco transiciones, por tanto cinco casos de prueba.
Un campo acepta un entero 'edad' que la especificación trata igual de 18 a 65 inclusive. Con partición de equivalencia, ¿qué conjunto representa las TRES particiones para el tratamiento válido/inválido?
{ edad < 18 } , { 18 ≤ edad ≤ 65 } , { edad > 65 }
Correcto — una partición válida y dos inválidas alrededor.
{ 17, 18 } , { 65, 66 }
Son valores límite, no las tres particiones de equivalencia.
Solo { 18 } , { 65 }
Solo dos valores; faltan las particiones inválidas.
Una partición por cada entero de 18 a 65.
Eso anula el propósito de agrupar en clases equivalentes.
La partición de equivalencia da una partición válida (18–65) y dos inválidas (menor de 18 y mayor de 65). Un valor por partición basta para cobertura básica.
Un motor de descuentos asigna un nivel de fidelidad según un valor entero 'puntos': 0–199 = Bronce, 200–499 = Plata, 500–999 = Oro, 1000 o más = Platino. Con análisis de valores límite de dos valores (cada límite y su vecino más cercano), ¿qué conjunto prueba TODOS los límites entre Bronce y Plata, y entre Oro y Platino?
{ 199, 200, 999, 1000 }
Correcto — son los pares límite Bronce/Plata y Oro/Platino.
{ 200, 500, 1000 }
Faltan los vecinos inferiores (199 y 999) del AVL de dos valores.
{ 0, 199, 200, 499, 500, 999, 1000 }
Incluye el límite Plata/Oro (499/500) y 0, no solicitados.
{ 100, 350, 750, 1500 }
Son valores en medio de las particiones, no límites.
El AVL de dos valores prueba cada valor límite y su vecino más cercano. Límite Bronce/Plata en 199/200; límite Oro/Platino en 999/1000. Por tanto {199, 200, 999, 1000}.
Considere la tabla de decisión de solicitud de préstamo. Un solicitante tiene una puntuación crediticia de 680 y un ingreso anual de 60.000. Según la tabla, ¿qué acción aplica?
Revisión manual
Correcto — puntuación < 700 e ingreso ≥ 50.000 corresponde a la regla R3.
Aprobar
Aprobar requiere ambas condiciones verdaderas (R1); aquí la de puntuación es falsa.
Rechazar
Rechazar (R4) requiere ambas falsas; aquí el ingreso es al menos 50.000.
No puede determinarse con la tabla
Las entradas corresponden claramente a R3, la acción está determinada.
Puntuación 680 es menor que 700 (condición 1 = F); ingreso 60.000 es al menos 50.000 (condición 2 = T). Es la regla R3 (F, T), cuya acción es Revisión manual.
El diagrama de transición de estados muestra un flujo de revisión de documentos. Contando solo las transiciones válidas mostradas, ¿cuál es el número mínimo de casos de prueba para lograr cobertura 0-switch (cada transición válida al menos una vez)?
5
Correcto — hay 5 transiciones válidas, una por caso para cobertura 0-switch.
4
Omite una de las cinco transiciones válidas (p. ej. retract).
3
Tres cubre solo los estados, no cada transición válida.
6
Solo hay 5 transiciones válidas, no 6.
La cobertura 0-switch exige cada transición válida una vez. Las transiciones válidas son: submit, approve, reject, publish, retract = 5 transiciones, por tanto 5 casos de prueba.
Una función contiene este pseudocódigo: IF (a > 0) THEN print 'X' ENDIF; IF (b > 0) THEN print 'Y' ENDIF. ¿Cuál es el número mínimo de casos para 100% de cobertura de sentencias y para 100% de cobertura de ramas (decisiones), respectivamente?
1 para cobertura de sentencias, 2 para cobertura de ramas
Correcto — un test cubre ambas sentencias; dos cubren los cuatro resultados de ramas.
2 para sentencias, 2 para ramas
La cobertura de sentencias necesita solo 1 test, no 2.
1 para sentencias, 4 para ramas
La cobertura de ramas necesita solo 2 tests; los dos IF son independientes.
2 para sentencias, 4 para ramas
Ambos números son demasiado altos para esta estructura simple.
Un test con a>0 y b>0 ejecuta ambas sentencias print → 100% de cobertura de sentencias con 1 test. Para cobertura de ramas cada IF debe ser verdadero y falso: a>0,b>0 y luego a≤0,b≤0 cubre los cuatro resultados → 2 tests.
¿Qué afirmación caracteriza MEJOR la relación entre cobertura de sentencias y cobertura de ramas?
El 100% de cobertura de ramas implica el 100% de sentencias, pero no a la inversa.
Correcto — la cobertura de ramas subsume la de sentencias.
El 100% de sentencias implica el 100% de ramas.
Falso — se puede ejecutar cada sentencia sin tomar cada rama.
Siempre requieren el mismo número de casos.
La de ramas suele requerir al menos tantos, a menudo más.
No tienen ninguna relación entre sí.
Sí se relacionan — la de ramas subsume la de sentencias.
El 100% de cobertura de ramas (decisiones) garantiza el 100% de cobertura de sentencias, pero no al revés: la cobertura de ramas es el criterio más fuerte.
¿Cuál describe MEJOR cuándo usar técnicas basadas en la experiencia como las pruebas exploratorias y la conjetura de errores?
Cuando las especificaciones son pobres o el tiempo es escaso, para complementar las técnicas sistemáticas.
Correcto — aprovechan la experiencia del tester.
Solo cuando se requiere una medición formal completa de cobertura.
No proporcionan medidas sistemáticas de cobertura.
Solo por testers sin conocimiento del dominio.
Dependen de la experiencia y el conocimiento del dominio.
Como reemplazo total de todas las técnicas de caja negra.
Complementan, no reemplazan.
Las técnicas basadas en la experiencia son valiosas cuando las especificaciones son escasas, el tiempo es limitado, o para complementar las sistemáticas.
¿Cuál de las siguientes es una técnica de prueba de caja negra (basada en especificación)?
Partición de equivalencia
Correcto — derivada de la especificación.
Prueba de sentencias
La prueba de sentencias es de caja blanca.
Prueba de ramas
La prueba de ramas es de caja blanca.
Conjetura de errores
La conjetura de errores es basada en experiencia.
La partición de equivalencia deriva pruebas de la especificación. Las pruebas de sentencias y ramas son de caja blanca.
Un campo acepta un 'nombre de usuario' de 5 a 12 caracteres inclusive. Con AVL de dos valores sobre la longitud, ¿qué conjunto debe probarse?
{ 4, 5, 12, 13 }
Correcto — cada límite y su vecino inválido más cercano.
{ 5, 12 }
Faltan los vecinos fuera del rango.
{ 1, 5, 12, 20 }
1 y 20 no son vecinos inmediatos.
{ 6, 11 }
Están dentro del rango válido.
El AVL de dos valores prueba cada límite y su vecino: 5 con 4; 12 con 13. Por tanto {4, 5, 12, 13}.
Al derivar casos de prueba de un caso de uso, ¿qué tipos de comportamiento deben cubrir?
El flujo básico más los flujos alternativos y de excepción.
Correcto — no solo el camino feliz.
Solo el flujo básico.
También deben probarse alternativos y de excepción.
Solo las ramas de código internas.
Las pruebas de casos de uso son de caja negra.
Solo los valores límite de las entradas numéricas.
Eso es análisis de valores límite.
Las pruebas de casos de uso deben cubrir el flujo básico y los flujos alternativos y de excepción.
En las pruebas basadas en riesgos, ¿cómo se determina el nivel de un riesgo de producto?
Combinando la probabilidad de ocurrencia y el impacto si ocurre.
Correcto — nivel = probabilidad × impacto.
Solo por el número de defectos ya hallados.
No es la definición completa.
Solo por el tamaño en líneas de código.
El tamaño no define el nivel de riesgo.
Por el número de testers disponibles.
Los recursos no definen el nivel de riesgo.
El nivel de riesgo es la combinación de probabilidad e impacto.
Un jefe de pruebas estima con tres puntos. Optimista = 6, más probable = 12, pesimista = 30. Con (a + 4m + b) / 6, ¿la estimación?
14 días
Correcto — 84 / 6 = 14.
12 días
12 es el valor más probable.
16 días
Es el promedio simple.
18 días
No coincide con 14.
(6 + 4×12 + 30) / 6 = 84 / 6 = 14 días.
¿Qué describe MEJOR el propósito de los criterios de salida de una actividad de prueba?
Definen las condiciones para considerar terminada la actividad.
Correcto — indican cuándo terminan las pruebas.
Definen las condiciones para que las pruebas comiencen.
Esos son criterios de entrada.
Enumeran todos los defectos hallados.
Eso es contenido de informes de defectos.
Especifican los datos de prueba.
Los datos se definen en diseño/implementación.
Definen las condiciones para considerar terminada una actividad o nivel de prueba.
¿Qué documento describe el alcance, enfoque, recursos y calendario de las actividades de prueba y es el principal resultado de planificación del jefe de pruebas?
El plan de pruebas
Correcto — recoge alcance, enfoque, recursos y calendario.
El informe de resumen de pruebas
Describe resultados tras las pruebas.
El informe de defectos
Documenta un defecto individual.
La especificación de casos de prueba
Especifica casos individuales.
El plan de pruebas documenta alcance, objetivos, enfoque, recursos, calendario y riesgos.
¿Qué información es la MÁS importante en un informe de defecto para que un desarrollador reproduzca el problema?
Pasos claros para reproducir, con resultados real y esperado.
Correcto — clave para diagnosticar.
El nombre del tester.
Útil, pero no esencial.
El número total de defectos ese día.
Ajeno a la reproducción.
La fecha de entrega de la próxima versión.
No necesaria para reproducir.
Pasos claros para reproducir, con resultados real y esperado.
Un equipo debe hacer regresión de cuatro funciones. Niveles de riesgo: Pagos = 9, Login = 6, Búsqueda = 4, Ayuda = 2. Solo hay tiempo para dos. ¿Cuáles priorizar?
Pagos y Login
Correcto — las dos puntuaciones más altas (9 y 6).
Búsqueda y Ayuda
Las puntuaciones más bajas.
Pagos y Ayuda
Login (6) supera a Ayuda (2).
Login y Búsqueda
Pagos (9) debe incluirse.
Riesgo: los más altos — Pagos (9) y Login (6).
¿Cuál es un ejemplo de riesgo de proyecto (no de producto)?
El entorno de prueba no se entrega a tiempo.
Correcto — un riesgo de proyecto.
Un cálculo produce resultados incorrectos.
Un riesgo de producto.
La aplicación se cae bajo carga.
Un riesgo de producto (rendimiento).
Acceso no autorizado a datos sensibles.
Un riesgo de seguridad del producto.
Los riesgos de proyecto se refieren a gestión/control, p. ej. entorno tardío. Los de producto a la calidad.
Un informe muestra retraso significativo con muchas pruebas de alta prioridad pendientes. ¿Cuál es la acción de control MÁS apropiada?
Repriorizar hacia los mayores riesgos.
Correcto — el control adapta el plan.
Ignorar el informe.
Ignorar desviaciones anula el control.
Dejar de escribir informes de defectos.
El reporte de defectos es esencial.
Marcar todas como aprobadas sin ejecutarlas.
Falsificar resultados es poco ético.
El control toma acciones correctivas, p. ej. repriorizar hacia los mayores riesgos.
¿Cuáles DOS se incluyen típicamente en un informe de finalización? (Elija dos.)
Un resumen de las pruebas realizadas y sus resultados.
Correcto — elemento central.
Una evaluación frente a los criterios de salida.
Correcto — valora los criterios de salida.
El código fuente completo.
El código no forma parte.
La especificación de diseño detallado.
Las especificaciones de diseño son entradas.
Incluye un resumen de las pruebas y una evaluación frente a los criterios de salida.
¿Cuál es un RIESGO potencial de introducir una herramienta de automatización?
Subestimar el esfuerzo de mantener las pruebas automatizadas.
Correcto — un riesgo conocido.
Reducir el esfuerzo de regresión manual repetitiva.
Un beneficio, no un riesgo.
Mejorar la consistencia de la ejecución.
Un beneficio.
Proporcionar mediciones objetivas de cobertura.
Un beneficio.
Riesgos comunes: subestimar el mantenimiento y confiar demasiado.
¿Qué categoría de herramienta apoyaría MEJOR la gestión del proceso, incluida la trazabilidad?
Una herramienta de gestión de pruebas
Correcto — gestiona el proceso y aporta trazabilidad.
Una herramienta de rendimiento
Mide rendimiento.
Una herramienta de análisis estático
Analiza código sin ejecutarlo.
Una herramienta de preparación de datos
Crea datos de prueba.
Las herramientas de gestión apoyan planificación, seguimiento y control, incluida la trazabilidad.