ISTQB Foundation (CTFL v4.0) Examen de práctica #1 — 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 describe mejor la diferencia entre las pruebas y la depuración?
Las pruebas identifican fallos causados por defectos; la depuración encuentra, analiza y elimina el defecto.
Correcto — las pruebas dinámicas revelan fallos, y la depuración diagnostica y corrige su causa.
Las pruebas y la depuración son dos nombres para la misma actividad.
Son actividades distintas, con objetivos diferentes y a menudo realizadas por personas distintas.
La depuración demuestra que el software está libre de defectos.
Ninguna actividad puede probar la ausencia de defectos; es un principio de las pruebas y no la función de la depuración.
Las pruebas corrigen los defectos que encuentran durante la ejecución.
Corregir es depuración/desarrollo, no pruebas.
Las pruebas buscan fallos (evidencia de defectos); la depuración es la actividad de desarrollo que localiza, analiza y corrige el defecto subyacente.
Un jefe de proyecto afirma: “Seguiremos probando hasta ejecutar todas las combinaciones posibles de entradas, así el producto quedará libre de defectos.” ¿Qué principio de las pruebas viola esta afirmación?
Las pruebas exhaustivas son imposibles.
Correcto — probar todo no es viable, por eso se usan técnicas y el riesgo para enfocar el esfuerzo.
Las pruebas se desgastan.
La “paradoja del pesticida” trata de que los tests repetidos hallan menos defectos nuevos, no de las pruebas exhaustivas.
Los defectos se agrupan.
Este principio trata de la distribución desigual de defectos, no de la viabilidad de probar todo.
Las pruebas dependen del contexto.
Es un principio, pero no el que se viola aquí.
Las pruebas exhaustivas (todas las combinaciones de entradas/precondiciones) son imposibles salvo en casos triviales; en su lugar se usan el riesgo y las prioridades.
¿Cuáles DOS de los siguientes son objetivos de las pruebas? (Elija dos.)
Encontrar defectos y fallos.
Un objetivo primario de las pruebas es detectar defectos antes de la entrega.
Generar confianza sobre el nivel de calidad.
Ganar confianza en que la calidad es suficiente es un objetivo central.
Demostrar que el software no contiene defectos.
Imposible — las pruebas muestran la presencia de defectos, no su ausencia.
Reparar los defectos encontrados.
Reparar es depuración/desarrollo, no un objetivo de las pruebas.
Las pruebas encuentran defectos y generan confianza en el nivel de calidad; no pueden probar la ausencia de defectos, y corregir no es un objetivo de las pruebas.
Un desarrollador escribe mal una fórmula en el código fuente. Más tarde, durante una prueba, el programa muestra un total incorrecto en pantalla. En términos ISTQB, ¿qué es el total incorrecto en pantalla?
Un fallo.
Correcto — un fallo es el resultado incorrecto observable de ejecutar código que contiene un defecto.
Un error.
El error (equivocación) fue la acción humana de escribir mal la fórmula.
Un defecto.
El defecto es la fórmula errónea en el código, no el total incorrecto mostrado.
Una causa raíz.
La causa raíz es el motivo subyacente; el total incorrecto es el fallo visible.
Error (equivocación) → Defecto (en el código) → Fallo (comportamiento incorrecto observado al ejecutar).
Al probar un sistema grande, el equipo observa que la mayoría de los defectos se concentran en dos de los veinte módulos. ¿Qué principio de las pruebas ilustra esto?
Los defectos se agrupan.
Correcto — la mayoría de los defectos tienden a concentrarse en unos pocos componentes.
Las pruebas muestran la presencia, no la ausencia, de defectos.
Es un principio cierto, pero no describe la concentración de defectos.
Probar pronto ahorra tiempo y dinero.
Trata de cuándo probar, no de dónde se concentran los defectos.
La paradoja del pesticida.
Ese principio trata de la pérdida de eficacia con el tiempo, no de la agrupación.
Agrupación de defectos: un pequeño número de módulos suele contener la mayoría de los defectos (relacionado con el principio de Pareto).
Un producto superó todas sus pruebas sin fallos pendientes, pero tras la entrega los usuarios se quejaron de que no cubría sus necesidades. ¿Qué principio de las pruebas demuestra esta situación?
La falacia de ausencia de errores.
Correcto — un sistema puede no tener defectos frente a su especificación y aun así no cubrir las necesidades del usuario.
Las pruebas exhaustivas son imposibles.
No aplica — el problema es la adecuación al uso, no la completitud de las pruebas.
Los defectos se agrupan.
Trata de dónde están los defectos, no de las necesidades del usuario.
Las pruebas dependen del contexto.
Cierto, pero no describe la brecha entre pruebas superadas y necesidades no satisfechas.
La falacia de ausencia de errores: encontrar y corregir defectos no sirve si el sistema construido no satisface las necesidades y expectativas de los usuarios.
¿Por qué suele ser beneficioso involucrar las actividades de prueba lo antes posible en el ciclo de vida de desarrollo?
Los defectos hallados pronto suelen ser más baratos de eliminar y pueden prevenirse del todo.
Correcto — el coste de corregir un defecto aumenta cuanto más tarde se encuentra.
Garantiza que ningún defecto llegará a producción.
Ningún enfoque puede garantizar una entrega libre de defectos.
Elimina la necesidad de pruebas dinámicas posteriores.
Las pruebas tempranas (a menudo estáticas) complementan, pero no sustituyen, las dinámicas posteriores.
Permite al equipo de pruebas omitir el plan de pruebas.
La planificación sigue siendo necesaria independientemente de cuándo se empiece a probar.
Probar pronto (shift-left) detecta defectos cuando son más baratos y fáciles de corregir y ayuda a prevenir defectos en productos de trabajo posteriores.
¿Cuál de los siguientes es un ejemplo de análisis de causa raíz y no solo el registro de un fallo?
Determinar que varios defectos comparten una fuente común en un requisito poco claro y mejorar el proceso de revisión de requisitos.
Correcto — aborda la fuente subyacente para evitar que se repita.
Registrar los pasos para reproducir un cierre inesperado en el informe de defecto.
Documenta el fallo, pero no analiza su causa subyacente.
Volver a ejecutar la prueba fallida para confirmar el fallo.
Es una confirmación, no un análisis de causa raíz.
Asignar severidad y prioridad al defecto.
La clasificación ordena el defecto, pero no identifica su fuente.
El análisis de causa raíz va más allá del síntoma hasta la fuente subyacente (p. ej., una carencia de proceso o de conocimiento) para prevenir defectos similares.
Dos módulos desarrollados de forma independiente se combinan, y las pruebas se centran en si intercambian datos correctamente a través de su interfaz. ¿Qué nivel de prueba se está realizando?
Pruebas de integración.
Correcto — se dirigen a las interfaces e interacciones entre componentes integrados.
Pruebas de componentes.
Las pruebas de componentes (unitarias) comprueban un único módulo de forma aislada.
Pruebas de sistema.
Las pruebas de sistema comprueban el comportamiento del sistema completo, de extremo a extremo.
Pruebas de aceptación.
Las pruebas de aceptación establecen la disposición para el uso por usuarios/clientes.
Las pruebas de integración se centran en las interacciones e interfaces entre componentes o sistemas.
Un equipo mide el tiempo de respuesta del sistema bajo carga de usuarios creciente. ¿Qué tipo de prueba representa esto?
Pruebas no funcionales.
Correcto — el tiempo de respuesta bajo carga es una característica de rendimiento (no funcional).
Pruebas funcionales.
Las pruebas funcionales comprueban qué hace el sistema frente a los requisitos funcionales.
Pruebas de caja blanca.
Las pruebas de caja blanca se basan en la estructura interna, no en la carga/rendimiento en sí.
Pruebas de confirmación.
Las pruebas de confirmación repiten pruebas tras una corrección para confirmar que el defecto desapareció.
Las pruebas no funcionales evalúan características como rendimiento, fiabilidad, usabilidad y seguridad — es decir, cómo de bien se comporta el sistema, no qué hace.
Un organismo regulador exige evidencia de que una aplicación bancaria cumple normas legales obligatorias antes de entrar en producción. ¿Qué forma de prueba de aceptación es esta?
Prueba de aceptación regulatoria.
Correcto — aporta evidencia de cumplimiento de leyes/regulaciones.
Prueba alfa.
La prueba alfa es un uso operativo (simulado o real) por usuarios potenciales en las instalaciones del desarrollador.
Prueba de aceptación del usuario (UAT).
La UAT valida la adecuación al uso por usuarios finales, no específicamente el cumplimiento legal.
Prueba de aceptación operativa.
La operativa cubre aspectos como copia/restauración y mantenimiento, no el cumplimiento legal.
La prueba de aceptación regulatoria demuestra el cumplimiento de reglas fijadas por un organismo regulador; la contractual demuestra el cumplimiento de un contrato.
¿Cuál de los siguientes es un beneficio típico que una sólida cadena de integración continua (CI) aporta a las pruebas?
Retroalimentación rápida y automatizada sobre si un cambio ha roto la funcionalidad existente.
Correcto — la CI ejecuta pruebas automáticas en cada cambio y revela regresiones pronto.
Elimina la necesidad de diseñar pruebas.
Las pruebas aún deben diseñarse; la CI solo automatiza su ejecución.
Garantiza una cobertura del 100 %.
La CI por sí sola no garantiza ningún nivel de cobertura concreto.
Elimina la necesidad de pruebas de aceptación.
Las pruebas de aceptación siguen siendo necesarias para establecer la disposición para el uso.
La CI permite retroalimentación rápida y automatizada: los cambios de código disparan compilación y pruebas automáticas, detectando regresiones pronto.
¿Cuáles DOS de los siguientes son niveles de prueba reconocidos en el temario ISTQB Foundation? (Elija dos.)
Pruebas de sistema.
Un nivel de prueba reconocido centrado en el sistema completo.
Pruebas de componentes.
Un nivel de prueba reconocido centrado en componentes/unidades individuales.
Pruebas de regresión.
La regresión es un tipo de prueba relacionado con cambios, no un nivel.
Pruebas de rendimiento.
El rendimiento es un tipo de prueba no funcional, no un nivel.
Los cuatro niveles de prueba son: de componentes, de integración, de sistema y de aceptación. La regresión y la confirmación son tipos de prueba relacionados con cambios, no niveles.
Al final de cada iteración, un equipo celebra una reunión para comentar qué fue bien, qué fue mal y qué podría mejorarse, y acuerda acciones concretas. ¿Cuál es un beneficio reconocido de esas retrospectivas para la prueba?
Se identifican y acuerdan mejoras de proceso, por ejemplo mayor efectividad y eficiencia de la prueba o mejor calidad del testware.
Correcto — el valor de una retrospectiva está en las acciones de mejora acordadas que mejoran la prueba de la siguiente iteración.
Sustituyen la necesidad de monitorización y control durante la iteración.
Una retrospectiva mira atrás cuando la iteración ha terminado. La monitorización y el control ocurren mientras se trabaja y siguen siendo necesarios.
Son la reunión en la que se registran y clasifican formalmente las anomalías encontradas en un producto de trabajo.
Eso pertenece a una revisión (prueba estática), donde se discuten las anomalías de un producto concreto y se les asigna estado y severidad. La retrospectiva trata del proceso, no de un documento.
Su propósito principal es decidir si el producto puede liberarse.
Esa es una decisión de liberación basada en criterios de salida y riesgo residual. La retrospectiva produce acciones de mejora, no un veredicto de liberación.
Las retrospectivas conducen a mejoras de proceso acordadas, por ejemplo mayor efectividad y eficiencia de la prueba, mejor calidad del testware, mejor trabajo en equipo y aprendizaje, y mejor tratamiento de la base de prueba.
¿Cuál es una característica clave de las pruebas estáticas?
Examinan productos de trabajo sin ejecutar el software.
Correcto — las pruebas estáticas (revisiones, análisis estático) no ejecutan el código.
Requieren que el código se ejecute en el entorno destino.
Eso describe las pruebas dinámicas, no las estáticas.
Solo pueden aplicarse al código fuente.
Las pruebas estáticas se aplican a requisitos, diseños, historias de usuario y más, no solo al código.
Solo pueden encontrar fallos, no defectos.
Las pruebas estáticas encuentran defectos directamente; los fallos requieren ejecución.
Las pruebas estáticas examinan productos de trabajo sin ejecutar el código (revisiones y análisis estático) y pueden aplicarse muy pronto.
Una revisión sigue un procedimiento documentado, usa criterios de entrada y salida, recopila métricas y la dirige un moderador formado. ¿Qué tipo de revisión es?
Inspección.
Correcto — las inspecciones son la revisión más formal, con métricas, reglas y un moderador formado.
Revisión informal.
Las revisiones informales no tienen proceso formal, roles ni resultados documentados.
Recorrido (walkthrough).
Un recorrido suele dirigirlo el autor y es menos formal que una inspección.
Revisión ad hoc.
Ad hoc es un enfoque informal y no estructurado, no el formal descrito.
La inspección es el tipo de revisión más formal, con roles, reglas, métricas y un moderador definidos.
En una revisión formal, ¿quién es el principal responsable del producto de trabajo revisado y de corregir los defectos encontrados en él?
El autor.
Correcto — el autor creó el producto de trabajo y es responsable de corregirlo.
El moderador (facilitador).
El moderador dirige la reunión de revisión; no es dueño del producto de trabajo.
El escriba.
El escriba registra los problemas planteados; no corrige el producto.
El líder de la revisión / gestor.
Estos roles planifican o deciden sobre la revisión, pero no son dueños del producto.
El autor es dueño del producto de trabajo y corrige los defectos; el moderador dirige la revisión, el escriba registra y los revisores identifican los problemas.
¿Cuál de los siguientes defectos es más probable que detecte una herramienta de análisis estático?
Una variable que se usa antes de habérsele asignado un valor.
Correcto — las anomalías de flujo de datos como esta son hallazgos típicos del análisis estático.
Un tiempo de respuesta lento cuando 1.000 usuarios inician sesión a la vez.
Es un problema de rendimiento en ejecución que requiere ejecutar el sistema, no análisis estático.
Un malentendido de la verdadera necesidad de negocio del cliente.
Es un problema de requisitos/validación, no algo que un analizador estático detecte en el código.
Una fuga de memoria que solo aparece tras horas de operación.
Surge en ejecución con el tiempo y suele requerir pruebas dinámicas.
El análisis estático examina el código/estructura sin ejecutarlo y detecta cosas como variables no definidas, código inalcanzable y violaciones de normas de codificación.
Un campo acepta una edad entera de 18 a 65 inclusive. Con partición de equivalencia, ¿qué conjunto representa mejor un valor de cada una de las tres particiones (inválido-bajo, válido, inválido-alto)?
10, 40, 80
Correcto — 10 es inválido-bajo, 40 válido, 80 inválido-alto: un valor de cada partición.
18, 40, 65
Los tres caen en la única partición válida, dejando dos particiones sin probar.
17, 18, 19
Tantean los límites (AVL) pero solo cubren el borde bajo, no las tres particiones.
40, 50, 60
Los tres están en la partición válida; las particiones inválidas no se representan.
La partición de equivalencia agrupa entradas que deben tratarse igual; basta un representante por partición. Válido: 18–65; inválido por debajo: <18; inválido por encima: >65.
Un campo acepta números enteros de 1 a 100 inclusive. Con el análisis de valores límite de dos valores, ¿qué conjunto contiene exactamente los valores límite que deben probarse?
0, 1, 100, 101
Correcto — el límite inferior (1) y su vecino exterior (0), más el superior (100) y su vecino exterior (101).
1, 50, 100
50 es un punto medio de partición, no un límite; faltan los vecinos exteriores 0 y 101.
0, 50, 101
Omite los límites reales 1 y 100.
1, 2, 99, 100
Son los vecinos internos del método de tres valores; el de dos valores usa 0 y 101.
El AVL de dos valores prueba cada límite y su vecino inmediato justo fuera del rango. Para 1–100 son 0, 1, 100, 101.
Considere la siguiente tabla de decisión para un proceso de pago. Un cliente NO es cliente registrado, pero realiza un pedido con un total de 150 $. Según la tabla, ¿qué acción(es) aplica(n)?
Ni envío gratis ni descuento (Regla 3).
Correcto — la Regla 3 tiene F (no registrado) y T (pedido >= 100) y muestra '-' en ambas acciones.
Envío gratis y 5 % de descuento (Regla 1).
La Regla 1 exige cliente registrado (T); este no lo es.
Solo 5 % de descuento (Regla 2).
La Regla 2 exige registrado = T y pedido < 100; aquí ambas condiciones difieren.
Solo envío gratis.
El envío gratis solo aplica en la Regla 1, que requiere un cliente registrado.
No registrado = F y pedido >= 100 = T coincide con la Regla 3 (F, T), que no activa ni 'Free shipping' ni '5% discount'.
Según el siguiente diagrama de transición de estados, el sistema está en el estado S1 (Awaiting PIN). ¿Qué secuencia de eventos lleva el sistema al estado S3 (Account locked)?
Tres entradas de PIN incorrectas consecutivas.
Correcto — el diagrama bloquea la cuenta con el 3.er PIN incorrecto.
Una entrada de PIN incorrecta.
Un único PIN incorrecto vuelve a S1; no bloquea la cuenta.
Una entrada de PIN correcta.
Un PIN correcto va a S2 (Access granted), no a S3.
Dos PIN incorrectos seguidos de un PIN correcto.
Tras dos intentos fallidos el sistema sigue en S1; un PIN correcto va entonces a S2.
Desde S1, un PIN correcto va a S2; los dos primeros PIN incorrectos vuelven a S1; el tercer PIN incorrecto consecutivo dispara la transición a S3 (bloqueado).
Para el siguiente grafo de flujo de control, ¿cuántos casos de prueba se necesitan para lograr cobertura completa de decisiones (ramas), suponiendo que cada decisión se ejerce en ambos sentidos al menos una vez?
2
Correcto — dos caminos pueden ejercer ambos resultados de la ramificación del nodo 2 y los del bucle del nodo 5.
1
Un solo camino no puede tomar ambos lados de la ramificación y de la decisión del bucle.
4
La cobertura de decisiones no exige todas las combinaciones de resultados; 4 es más de lo necesario.
6
Es excesivo; aquí la cobertura de decisiones se logra con muchos menos de seis casos.
Hay dos decisiones: la ramificación en el nodo 2 (a 3 o 4) y la decisión del bucle en el nodo 5 (volver a 2 o seguir a 6). Dos caminos bien elegidos cubren ambos resultados de cada decisión.
¿Qué requiere lograr la “cobertura 0-switch” (también llamada 0-switch de Chow) en las pruebas de transición de estados?
Que cada transición individual válida se ejerza al menos una vez.
Correcto — la cobertura 0-switch cubre todas las transiciones válidas individuales.
Que se ejerza cada par válido de transiciones consecutivas.
Eso define la cobertura 1-switch, no la 0-switch.
Que se intente cada transición inválida.
Probar transiciones inválidas es un asunto aparte, no lo que mide la cobertura 0-switch.
Que se visite cada estado al menos una vez, sin importar las transiciones.
Visitar estados no basta; la 0-switch trata de cubrir las transiciones en sí.
La cobertura 0-switch requiere ejercer cada transición individual válida una vez; la 1-switch requiere cada par válido de transiciones consecutivas.
¿Qué situación es la mejor candidata para usar pruebas con tabla de decisión?
La salida depende de varias condiciones que pueden combinarse de distintas formas.
Correcto — las tablas de decisión capturan sistemáticamente combinaciones de condiciones y sus acciones.
Una única entrada numérica debe comprobarse en los bordes de su rango válido.
Eso es el análisis de valores límite, no una tabla de decisión.
El sistema cambia de modo según eventos a lo largo del tiempo.
Eso apunta a las pruebas de transición de estados.
No hay requisitos, solo una versión en ejecución para explorar.
Eso sugiere pruebas exploratorias, una técnica basada en la experiencia.
Las tablas de decisión son ideales cuando el comportamiento depende de combinaciones de condiciones, asegurando que no se omitan combinaciones importantes.
Las pruebas de casos de uso derivan los casos de prueba principalmente de ¿cuál de los siguientes?
Del flujo básico y los flujos alternativos/de excepción de las interacciones usuario-sistema.
Correcto — los casos de uso describen esos flujos, que se convierten en la base de los casos de prueba.
Del grafo de flujo de control interno del código.
Eso es prueba de caja blanca (estructural), no de casos de uso.
De los límites de cada campo numérico de entrada.
Eso describe el análisis de valores límite.
De la intuición del tester sobre los defectos probables.
Eso es la conjetura de errores, una técnica basada en la experiencia.
Las pruebas de casos de uso derivan pruebas de las interacciones entre actores y sistema, cubriendo el flujo básico (principal) y los flujos alternativos/de excepción.
¿Qué afirmación describe correctamente la relación entre la partición de equivalencia y el análisis de valores límite?
El análisis de valores límite amplía la partición de equivalencia probando los bordes de las particiones.
Correcto — el AVL refina la partición apuntando a los límites entre particiones.
Son técnicas totalmente independientes.
Están estrechamente relacionadas; el AVL amplía la partición.
La partición de equivalencia es de caja blanca y el AVL de caja negra.
Ambas son técnicas de caja negra (basadas en especificación).
El análisis de valores límite sustituye la necesidad de la partición de equivalencia.
El AVL complementa la partición; suelen usarse juntas.
El AVL es una extensión de la partición de equivalencia que se centra en los bordes (límites) de las particiones, donde suelen aparecer defectos.
Un formulario web acepta la edad de un usuario como entero. El rango válido es de 18 a 65 inclusive y los valores fuera de rango deben rechazarse. Usando el análisis de valores límite de dos valores (por cada límite, el valor límite y su vecino inmediatamente fuera del rango), ¿qué conjunto de edades debe seleccionarse para ejercitar ambos límites?
17, 18, 65 y 66
Prueba cada límite (18, 65) y su vecino exterior (17, 66), tal como exige el AVL de dos valores.
18 y 65
Solo los valores límite; faltan los vecinos exteriores que el AVL de dos valores también exige.
17, 18, 19, 64, 65 y 66
Es el AVL de tres valores, que además prueba el vecino interior (19, 64).
0, 18, 65 y 100
0 y 100 son valores arbitrarios, no los vecinos de límite que exige el AVL.
El AVL de dos valores prueba por cada límite el valor límite y el inmediatamente exterior: límite inferior 18 → 17 y 18; límite superior 65 → 65 y 66.
Para la misma rutina (un único IF sin ELSE, seguido de una sentencia final), ¿cuál es el número mínimo de casos de prueba para lograr el 100% de cobertura de ramas (decisiones)?
2
Una prueba toma la rama verdadera y la otra el resultado falso.
1
Una prueba cubre solo uno de los dos resultados de la decisión.
3
Dos casos bastan para una única decisión binaria.
4
Sobreestima; solo existen dos resultados.
Una prueba para el IF verdadero y otra para el falso = 2.
¿Cuál es el mejor ejemplo de criterio de salida (definición de hecho) para un nivel de prueba?
Se han ejecutado todas las pruebas planificadas y no quedan defectos graves abiertos.
Correcto — define las condiciones bajo las cuales las pruebas pueden considerarse completas.
El entorno de pruebas está disponible y los datos de prueba preparados.
Es un criterio de entrada (precondición para empezar), no de salida.
Los requisitos se han establecido como línea base.
También un criterio de entrada / precondición, no de salida.
Se ha asignado a los testers al proyecto.
Es un asunto de recursos/planificación, no un criterio de finalización.
Los criterios de salida definen cuándo se considera suficientemente completas las pruebas, p. ej., cobertura planificada lograda y sin defectos graves abiertos.
¿Cuál es el propósito principal de la monitorización y el control de pruebas?
Reunir información sobre el progreso de las pruebas y tomar acciones correctivas cuando sea necesario.
Correcto — la monitorización mide el progreso y el control lo dirige hacia los objetivos.
Diseñar los casos de prueba detallados.
El diseño de pruebas es una actividad aparte, no la monitorización y el control.
Corregir los defectos encontrados durante las pruebas.
Corregir defectos es depuración/desarrollo.
Configurar el entorno de pruebas.
Configurar el entorno es parte de la implementación de pruebas, no de la monitorización y el control.
La monitorización reúne información sobre el progreso de las pruebas; el control la usa para tomar acciones correctivas y cumplir los objetivos de prueba.
En las pruebas basadas en riesgo, ¿mediante qué dos factores se suele evaluar el nivel de riesgo de un elemento?
La probabilidad de que ocurra el problema y su impacto si ocurre.
Correcto — nivel de riesgo = probabilidad x impacto.
El número de casos de prueba y el número de testers.
Son cifras de esfuerzo/recursos, no la definición de riesgo.
El tamaño del código y el lenguaje de programación usado.
Pueden influir en el esfuerzo, pero no definen el nivel de riesgo.
El coste de las herramientas y del entorno de pruebas.
Los costes son cuestiones de presupuesto, no los dos factores del riesgo.
El nivel de riesgo es una combinación de la probabilidad de que ocurra un problema y el impacto si ocurre.
¿Cuál de los siguientes es un ejemplo de riesgo de proyecto (frente a un riesgo de producto)?
Testers clave abandonan el equipo antes de completar la fase de pruebas.
Correcto — un problema de personal/gestión es un riesgo de proyecto.
El cálculo de pagos produce importes incorrectos.
Un defecto en el comportamiento del producto es un riesgo de producto.
El sistema es demasiado lento bajo carga máxima.
Una cuestión de calidad del producto (rendimiento) es un riesgo de producto.
La interfaz de usuario es difícil de usar.
Un problema de usabilidad del producto es un riesgo de producto.
Los riesgos de proyecto se refieren a la gestión y ejecución del proyecto (p. ej., personal, plazos, proveedor). Los de producto se refieren a la calidad del producto en sí.
¿Qué información es esencial en un buen informe de defecto para ayudar a los desarrolladores a reproducir el problema?
Pasos claros para reproducir, con el resultado esperado y el real.
Correcto — los pasos de reproducción más los resultados esperado/real son clave para diagnosticar el defecto.
La opinión del tester sobre el desarrollador que escribió el código.
Los informes de defecto deben ser objetivos y factuales, no personales.
Una garantía de que el defecto se corregirá antes de la entrega.
Un informe no puede garantizar una corrección; es una decisión de clasificación/gestión.
El número total de casos de prueba del proyecto.
Las cifras de todo el proyecto no ayudan a reproducir un defecto concreto.
Un informe útil incluye pasos para reproducir, resultados esperado y real, entorno y severidad/prioridad, para poder reproducir y clasificar el problema.
Un equipo pide a varios testers expertos estimar el esfuerzo de prueba de forma independiente y, tras varias rondas de debate, converge en una estimación de consenso. ¿Qué enfoque de estimación es?
Un enfoque basado en expertos (p. ej., Wideband Delphi).
Correcto — las estimaciones de expertos consensuadas mediante debate son basadas en expertos.
Un enfoque basado en métricas con datos históricos.
La estimación basada en métricas usa datos de proyectos pasados, no rondas de consenso de expertos.
Análisis de valores límite.
El AVL es una técnica de diseño de pruebas, no un enfoque de estimación.
Priorización basada en riesgo.
Priorizar por riesgo no es una técnica de estimación del esfuerzo.
Es un enfoque basado en expertos; la forma iterativa (primero anónima, luego en debate) se conoce como Wideband Delphi.
¿Cuál de las siguientes es una métrica típica reportada en un informe de progreso (estado) de pruebas?
Número de casos de prueba ejecutados, superados, fallidos y bloqueados.
Correcto — el estado de ejecución es una métrica estándar del progreso de pruebas.
Los salarios personales del equipo de desarrollo.
Los salarios no son una métrica de progreso de pruebas.
La marca de los portátiles que usan los testers.
Irrelevante para el informe de progreso de pruebas.
El presupuesto de marketing del lanzamiento del producto.
Una cifra de negocio/marketing, no una métrica de pruebas.
Los informes de progreso suelen incluir el estado de ejecución de los casos (superados/fallidos/bloqueados), conteos y tendencias de defectos y la cobertura lograda.
En la estimación de pruebas un equipo usa la técnica de tres puntos (PERT). Para una actividad estima optimista = 4 días, más probable = 9 días y pesimista = 20 días. ¿Cuál es la estimación según E = (O + 4M + P) / 6?
10 días
(4 + 36 + 20) / 6 = 60 / 6 = 10.
9 días
9 es el valor más probable, no la estimación ponderada PERT.
11 días
11 es el promedio simple (4+9+20)/3, no la media ponderada PERT.
12 días
No coincide con la fórmula; la estimación ponderada correcta es 10.
E = (4 + 4×9 + 20) / 6 = (4 + 36 + 20) / 6 = 60 / 6 = 10 días.
Cuatro riesgos se valoran 1-5: R1 L=2 I=3; R2 L=4 I=5; R3 L=3 I=3; R4 L=5 I=2. Si nivel de riesgo = Probabilidad x Impacto, ¿cuál se prueba PRIMERO?
R2 (nivel de riesgo 20)
4*5 = 20 es el más alto.
R4 (nivel de riesgo 10)
5*2 = 10 es menor que el 20 de R2.
R3 (nivel de riesgo 9)
3*3 = 9 es menor que el 20 de R2.
R1 (nivel de riesgo 6)
2*3 = 6 es el más bajo.
R2 tiene el producto más alto (20).
Una herramienta que registra defectos, los vincula a requisitos y sigue su estado a lo largo del ciclo de vida, ¿a qué categoría pertenece?
Herramientas de gestión de pruebas / gestión de defectos.
Correcto — seguir defectos y la trazabilidad es una función de las herramientas de gestión de pruebas.
Herramientas de pruebas de rendimiento.
Las herramientas de rendimiento generan carga y miden la respuesta, no siguen defectos.
Herramientas de análisis estático.
El análisis estático examina el código sin ejecutarlo; no gestiona defectos.
Herramientas de preparación de datos de prueba.
Crean o enmascaran datos de prueba, no siguen defectos.
Las herramientas de gestión de pruebas (incluida la gestión de defectos/incidencias) apoyan la gestión de las pruebas, la trazabilidad y la generación de informes.
¿Cuál de los siguientes es un riesgo realista de introducir automatización de pruebas, en lugar de un beneficio?
El esfuerzo de mantener las pruebas automatizadas puede subestimarse.
Correcto — el mantenimiento de los scripts automatizados es un coste/riesgo común y a menudo subestimado.
Las pruebas de regresión automatizadas pueden ejecutarse con más frecuencia y consistencia.
Es un beneficio de la automatización, no un riesgo.
Las pruebas repetitivas pueden ejecutarse más rápido que a mano.
Es un beneficio, no un riesgo.
Se producen resultados objetivos y repetibles para las mismas entradas.
La repetibilidad es un beneficio de la automatización, no un riesgo.
La automatización tiene costes y riesgos: el esfuerzo de mantenimiento puede subestimarse, puede haber dependencia excesiva de la herramienta y expectativas poco realistas. Entre los beneficios están la repetibilidad y ejecuciones de regresión más rápidas.