ISTQB Foundation (CTFL v4.0) Examen de práctica #2 — 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 conjunto de pruebas de regresión se ha ejecutado sin cambios durante muchas versiones y ahora rara vez encuentra nuevos defectos. ¿Qué principio de las pruebas lo explica?
La paradoja del pesticida.
Correcto — las pruebas sin cambios pierden eficacia para hallar defectos nuevos con el tiempo.
Las pruebas exhaustivas son imposibles.
Trata de la inviabilidad de probarlo todo, no de la menor eficacia de pruebas repetidas.
Los defectos se agrupan.
Describe la distribución desigual de defectos, no el valor decreciente de pruebas repetidas.
Las pruebas dependen del contexto.
Cierto, pero sin relación con la pérdida de eficacia de pruebas repetidas.
La paradoja del pesticida: repetir las mismas pruebas deja de encontrar defectos nuevos; las pruebas deben revisarse, actualizarse y ampliarse.
Un software médico de seguridad crítica se prueba con mucho más rigor que un simple sitio web interno de marketing. ¿Qué principio de las pruebas ilustra esto?
Las pruebas dependen del contexto.
Correcto — la cantidad y el tipo de pruebas dependen del contexto y el riesgo.
La falacia de ausencia de errores.
Trata de construir el producto equivocado, no de adaptar el rigor al contexto.
Probar pronto ahorra tiempo y dinero.
Trata del momento de las pruebas, no del rigor según el contexto.
Las pruebas exhaustivas son imposibles.
Trata de la inviabilidad de probarlo todo, no de la adaptación contextual.
Las pruebas dependen del contexto: el tipo y la cantidad de pruebas dependen de factores como el riesgo, el dominio y la criticidad.
Un tester ejecuta muchas pruebas en un módulo y no encuentra fallos. ¿Qué se puede concluir correctamente?
El módulo aún puede contener defectos que estas pruebas no revelaron.
Correcto — superar pruebas no prueba la ausencia de defectos.
Ahora está demostrado que el módulo no tiene defectos.
Ninguna cantidad de pruebas puede probar la ausencia de defectos.
Seguir probando este módulo no tiene sentido.
Pruebas adicionales, sobre todo nuevas, aún pueden encontrar defectos.
Los requisitos debían de ser perfectos.
Los resultados de las pruebas no dicen nada sobre la corrección de los requisitos.
Las pruebas pueden mostrar la presencia de defectos pero nunca probar su ausencia; superar pruebas reduce el riesgo pero no garantiza un módulo sin defectos.
¿Cuáles DOS de las siguientes afirmaciones usan correctamente los términos ISTQB error, defecto y fallo? (Elija dos.)
Un error humano puede provocar que se introduzca un defecto en el código.
Correcto — una equivocación (error) puede causar un defecto en un producto de trabajo.
Un fallo ocurre cuando se ejecuta un defecto del código.
Correcto — los fallos son el efecto observable de ejecutar un defecto.
Un fallo en el código siempre provoca un error humano.
La cadena causal es error → defecto → fallo, no a la inversa.
Todo defecto del código siempre causará un fallo.
Un defecto causa un fallo solo si el código afectado se ejecuta en las condiciones adecuadas.
Un error (equivocación) de una persona puede introducir un defecto en un producto de trabajo; ejecutar el defecto puede causar un fallo (comportamiento incorrecto observable).
¿Qué pregunta responde la validación, a diferencia de la verificación?
¿Estamos construyendo el producto correcto para las necesidades del usuario?
Correcto — la validación comprueba la adecuación al uso previsto y a las necesidades del usuario.
¿El producto se ajusta a su especificación escrita?
Eso es verificación, no validación.
¿El código sigue las normas de codificación?
La conformidad con normas es un asunto de verificación.
¿Se ha construido cada módulo según su diseño?
La conformidad con el diseño es verificación.
La verificación pregunta “¿Estamos construyendo el producto correctamente?” (conforme a la especificación). La validación pregunta “¿Estamos construyendo el producto correcto?” (satisface las necesidades del usuario).
¿Cuál de las siguientes describe mejor la “base de prueba”?
La fuente de información a partir de la cual se derivan los casos de prueba.
Correcto — la base de prueba (requisitos, diseños, etc.) es de lo que se derivan las pruebas.
El hardware en el que se ejecutan las pruebas.
Eso es el entorno de pruebas, no la base de prueba.
El conjunto de resultados esperados de las pruebas.
Los resultados esperados provienen de la base de prueba, pero no son la base en sí.
La lista de defectos encontrados hasta ahora.
Los datos de defectos son una salida de las pruebas, no la base de prueba.
La base de prueba es el cuerpo de conocimiento usado como base del análisis y diseño de pruebas (p. ej., requisitos, diseño, historias de usuario, análisis de riesgos).
¿Cuál es un beneficio reconocido de tener un grado adecuado de independencia en las pruebas?
Los testers independientes probablemente reconozcan otros tipos de fallos que el autor.
Correcto — la independencia aporta otra perspectiva y reduce el sesgo del autor.
Los testers independientes pueden garantizar un producto sin defectos.
Ningún grado de independencia puede garantizar la ausencia de defectos.
La independencia elimina la necesidad de que el autor pruebe.
Los autores siguen beneficiándose de probar su propio trabajo; la independencia lo complementa.
La máxima independencia es siempre la mejor opción.
Demasiada independencia puede causar problemas de comunicación y no siempre es lo mejor.
Los testers independientes tienden a reconocer otros tipos de fallos y se ven menos afectados por las suposiciones del autor, aunque demasiada independencia puede dificultar la comunicación.
¿En qué se diferencian el aseguramiento de la calidad (QA) y las pruebas?
El QA se centra en el proceso para lograr calidad, mientras que las pruebas son una actividad de control de calidad centrada en los productos de trabajo.
Correcto — el QA está orientado al proceso (prevención); las pruebas, al producto (control de calidad).
El QA y las pruebas son exactamente lo mismo.
Están relacionados pero son distintos; el QA es más amplio y orientado al proceso.
Las pruebas están orientadas al proceso mientras que el QA solo examina el producto.
Esto invierte las definiciones correctas.
El QA se realiza solo tras la entrega, y las pruebas solo antes.
Ambos pueden abarcar el ciclo de vida; la diferencia es el enfoque proceso vs. producto.
El QA está orientado al proceso y busca niveles adecuados de calidad en todo el proceso; las pruebas son una actividad de control de calidad centrada en el producto/los productos de trabajo.
Un desarrollador escribe pruebas automatizadas que comprueban una única función de forma aislada, usando stubs para reemplazar sus dependencias. ¿Qué nivel de prueba es?
Pruebas de componentes (unitarias).
Correcto — probar un único componente aislado con stubs son pruebas de componentes.
Pruebas de sistema.
Las pruebas de sistema ejercen todo el sistema integrado, no una función aislada.
Pruebas de aceptación.
Las pruebas de aceptación establecen la disposición para el uso por usuarios/clientes.
Pruebas de integración.
La integración comprueba interacciones entre componentes, no un componente aislado.
Las pruebas de componentes verifican componentes individuales de forma aislada, a menudo con stubs/drivers que sustituyen a las dependencias.
Tras corregir un defecto, el equipo vuelve a ejecutar un amplio conjunto de pruebas que antes pasaban, para asegurarse de que el cambio no haya introducido nuevos defectos en otra parte. ¿Qué tipo de prueba es?
Pruebas de regresión.
Correcto — volver a ejecutar pruebas para detectar efectos secundarios no deseados de un cambio es regresión.
Pruebas de confirmación.
La confirmación reejecuta la prueba fallida concreta para verificar la corrección, no un conjunto amplio.
Pruebas de humo (smoke).
Las pruebas de humo son una comprobación superficial de que la versión es lo bastante estable para seguir probando.
Pruebas de aceptación.
Las pruebas de aceptación establecen la disposición para el uso, no los efectos secundarios de una corrección.
Las pruebas de regresión comprueban que un cambio no haya afectado negativamente a partes no modificadas. Las pruebas de confirmación comprueban que el defecto concreto se ha corregido.
¿Cuál de las siguientes describe mejor un enfoque de pruebas “shift-left”?
Realizar actividades de prueba antes en el ciclo de vida, como revisar requisitos y diseñar pruebas antes de escribir el código.
Correcto — shift-left adelanta el esfuerzo de prueba para detectar defectos antes.
Retrasar todas las pruebas hasta justo antes de la entrega.
Es lo contrario de shift-left.
Trasladar todas las pruebas a un equipo independiente separado.
Shift-left trata del momento, no de la independencia organizativa.
Sustituir por completo las pruebas manuales por automatización.
Shift-left trata de cuándo se prueba, no de manual vs. automatizado.
Shift-left significa realizar actividades de prueba antes en el ciclo de vida (p. ej., revisar requisitos, escribir pruebas antes del código) para hallar defectos cuanto antes.
¿Cuál de los siguientes desencadena normalmente las pruebas de mantenimiento?
Un cambio como un parche, una mejora o una migración a un nuevo entorno para un sistema en producción.
Correcto — las modificaciones y migraciones de un sistema operativo desencadenan pruebas de mantenimiento.
El primer desarrollo de un sistema totalmente nuevo.
El desarrollo inicial no es mantenimiento; el mantenimiento se aplica a sistemas operativos existentes.
Escribir la especificación de requisitos original.
Es una actividad de desarrollo temprano, no una prueba de mantenimiento.
Diseñar el primer conjunto de pruebas unitarias.
Forma parte del desarrollo inicial, no del mantenimiento.
Las pruebas de mantenimiento se realizan sobre un sistema operativo debido a modificaciones, migración o retirada del software.
En un ciclo de vida iterativo-incremental (p. ej., Agile), ¿en qué se diferencian normalmente las pruebas de uno secuencial (p. ej., modelo en V)?
Las pruebas ocurren de forma continua dentro de cada iteración corta, con regresión frecuente.
Correcto — los enfoques iterativos integran las pruebas a lo largo de cada iteración.
Las pruebas se realizan una sola vez, al final del proyecto.
Eso se acerca más a un modelo secuencial mal gestionado y no es propio del desarrollo iterativo.
Nunca se necesitan pruebas de regresión.
Los cambios frecuentes hacen la regresión más importante, no menos.
Los niveles y tipos de prueba ya no se aplican.
Los niveles y tipos de prueba siguen aplicándose; solo cambian su momento y cadencia.
En el desarrollo iterativo-incremental, las pruebas ocurren de forma continua dentro de iteraciones cortas, con regresión frecuente, en lugar de mayormente tras una larga fase de desarrollo.
En un enfoque de prueba primero, testers, desarrolladores y representantes del negocio convierten conjuntamente los criterios de aceptación de una historia de usuario en pruebas antes de implementarla, y esas pruebas guían el desarrollo. ¿De qué enfoque se trata?
Desarrollo dirigido por pruebas de aceptación (ATDD)
Correcto — ATDD parte de los criterios de aceptación acordados con las partes interesadas y los convierte en pruebas antes de implementar.
Desarrollo dirigido por pruebas (TDD)
TDD también es prueba primero, pero centrado en el desarrollador: primero se escriben pruebas unitarias de un fragmento pequeño y luego el código que las supera. No parte de los criterios de aceptación.
Desarrollo dirigido por el comportamiento (BDD)
BDD es un enfoque afín de prueba primero, pero su rasgo definitorio es expresar el comportamiento deseado en un formato estructurado de lenguaje natural (dado/cuando/entonces) automatizable directamente, no derivar las pruebas de los criterios de aceptación como tales.
Prueba de regresión
La prueba de regresión es una prueba relacionada con cambios que se realiza cuando el código ya existe, para detectar efectos secundarios no deseados. No es un enfoque de desarrollo de prueba primero.
El desarrollo dirigido por pruebas de aceptación (ATDD) deriva pruebas de forma colaborativa a partir de los criterios de aceptación antes de implementar. TDD se centra en el desarrollador y parte de pruebas unitarias; BDD expresa el comportamiento deseado en notación dado/cuando/entonces.
¿En qué tipo de revisión suele el autor dirigir la sesión, recorrer el producto de trabajo y recoger comentarios, a menudo para construir un entendimiento común?
Recorrido (walkthrough).
Correcto — los recorridos suele dirigirlos el autor para recorrer el producto y recoger comentarios.
Inspección.
Las inspecciones las dirige un moderador formado, no el autor, y son la revisión más formal.
Auditoría.
Una auditoría evalúa el cumplimiento de normas/regulaciones, no un recorrido dirigido por el autor.
Análisis estático.
El análisis estático es un examen del código con herramientas, no una reunión de revisión.
Un recorrido (walkthrough) suele dirigirlo el autor y sirve para hallar defectos, compartir conocimiento y crear consenso; es menos formal que una inspección.
¿Qué secuencia ordena correctamente las actividades de una revisión formal?
Planificación, inicio, revisión individual, comunicación y análisis, corrección e informe.
Correcto — es el orden estándar de las actividades de una revisión formal.
Corrección, planificación, revisión individual, informe, inicio.
La corrección no puede preceder a la planificación y la revisión; el orden es incorrecto.
Revisión individual, planificación, corrección, inicio, comunicación.
La planificación y el inicio deben preceder a la revisión individual.
Comunicación, corrección, planificación, revisión individual, inicio.
La planificación debe ir primero; este orden es incorrecto.
Una revisión formal sigue: planificación, inicio (kick-off), revisión individual (preparación), comunicación y análisis (reunión de revisión) y corrección/informe.
¿Cuáles DOS de los siguientes son tipos de revisión reconocidos? (Elija dos.)
Revisión técnica.
Un tipo de revisión reconocido, normalmente entre pares/expertos.
Inspección.
El tipo de revisión reconocido más formal.
Compilación.
La compilación traduce el código; no es un tipo de revisión.
Pruebas unitarias.
Las pruebas unitarias son pruebas dinámicas, no un tipo de revisión estática.
Los tipos de revisión reconocidos incluyen revisión informal, recorrido, revisión técnica e inspección. La “compilación” y las “pruebas unitarias” no son tipos de revisión.
¿Cuál de los siguientes es un factor de éxito para las revisiones?
Los defectos hallados se acogen y se expresan de forma objetiva, en un ambiente sin culpas.
Correcto — una cultura constructiva y sin culpas es un factor de éxito clave en las revisiones.
La revisión se usa para evaluar el desempeño del autor.
Usar las revisiones para juzgar a las personas las socava; las revisiones se dirigen al producto.
Se revisa el documento más grande posible en una sola sesión.
Revisar demasiado a la vez reduce la eficacia; las sesiones deben tener un tamaño adecuado.
Solo asiste el autor, para ahorrar tiempo.
Las revisiones necesitan revisores adecuados; el autor solo frustra el propósito.
Las revisiones exitosas tienen objetivos claros, las personas adecuadas, un ambiente constructivo (sin culpas), y los defectos hallados se ven como oportunidades de mejora.
Para la misma rutina (un IF sin ELSE seguido de una sentencia), ¿cuál es el mínimo de casos para el 100% de cobertura de ramas?
2
Una prueba hace verdadera la decisión y la otra falsa.
1
Una prueba cubre solo un resultado.
3
Dos resultados necesitan solo dos casos.
5
Coincide con el número de sentencias, no con ramas.
Una prueba para IF verdadero y otra para falso = 2.
Según el siguiente diagrama de transición de estados del reproductor multimedia, el reproductor está en el estado S2 (Playing). ¿Cuál de los siguientes eventos NO se acepta (no tiene transición definida) en este estado?
play
Correcto — no hay transición para 'play' desde el estado Playing en el diagrama.
pause
'pause' es una transición definida de Playing a Paused.
stop
'stop' es una transición definida de Playing a Stopped.
Tanto pause como stop no están definidas.
Ambas son transiciones definidas desde Playing, así que es incorrecto.
Desde S2 (Playing) el diagrama define 'pause' (a S3) y 'stop' (a S1). No hay transición para 'play' desde S2, por lo que 'play' no se acepta en el estado Playing.
¿Cuál es la complejidad ciclomática del siguiente grafo de flujo de control? (Use V(G) = Aristas − Nodos + 2.)
2
Correcto — 7 aristas − 7 nodos + 2 = 2; hay un punto de decisión (nodo 2).
1
Una única decisión da V(G) = 2, no 1; 1 significaría ninguna decisión.
3
Solo hay un nodo de decisión, así que el valor es 2, no 3.
7
7 es el número de aristas, no la complejidad ciclomática.
El grafo tiene 7 nodos y 7 aristas (1-2, 2-3, 2-4, 4-5, 3-6, 5-6, 6-7). V(G) = 7 − 7 + 2 = 2, coherente con una única decisión en el nodo 2.
Considere la siguiente tabla de decisión de seguros. Un conductor tiene 30 años y ha presentado un parte de siniestro en el último año. Según la tabla, ¿qué acción aplica?
Aplicar un recargo (regla R3).
Correcto — R3 tiene F (no menor de 25) y T (siniestro presentado) y activa el recargo.
Ofrecer una bonificación por no siniestralidad (regla R4).
R4 exige no haber tenido siniestros en el último año (F); este conductor sí tuvo uno (T).
No aplica ninguna acción.
R3 aplica explícitamente un recargo para esta combinación.
Aplicar un recargo y ofrecer una bonificación.
Estas acciones son mutuamente excluyentes entre las reglas; bajo R3 solo aplica el recargo.
Edad menor de 25 = F y siniestro en el último año = T coincide con la regla R3 (F, T), cuya acción es 'Apply surcharge' (aplicar recargo).
Un campo acepta números enteros de 10 a 20 inclusive. Con el análisis de valores límite de tres valores, ¿qué valores deben probarse en torno al límite inferior de 10?
9, 10, 11
Correcto — el AVL de tres valores prueba el límite (10) y sus vecinos inmediatos (9 y 11).
10, 11, 12
Omite el valor justo por debajo del límite (9).
8, 9, 10
Omite el 11 e incluye un valor (8) no adyacente al límite.
9, 11
El AVL de tres valores también debe incluir el propio valor límite 10.
El AVL de tres valores prueba el límite y los valores a cada lado. Para el límite inferior 10, son 9, 10 y 11.
El campo “país” de un formulario web acepta uno de 195 nombres de país válidos; cualquier otro se rechaza. Con la partición de equivalencia, ¿cuántas particiones conviene identificar como mínimo?
Dos: una partición válida y una inválida.
Correcto — los países aceptados forman una partición y todo lo rechazado otra.
195: una partición por cada país válido.
Cada país válido se trata igual, por lo que pertenecen a una única partición válida.
Una: solo hay que probar las entradas válidas.
Las entradas inválidas forman su propia partición y también deben probarse.
196: una por país válido más una inválida.
Los países válidos no necesitan cada uno su propia partición en la partición de equivalencia.
La partición agrupa entradas tratadas igual. Aquí hay una partición válida (cualquier país aceptado) y una inválida (todo lo rechazado) = dos particiones.
¿Por qué es valioso diseñar casos de prueba para transiciones inválidas (inesperadas) en las pruebas de transición de estados?
Para verificar que el sistema gestiona correctamente eventos no permitidos en el estado actual.
Correcto — las pruebas de transiciones inválidas comprueban el manejo robusto de eventos no permitidos.
Para reducir el número total de estados del modelo.
Probar transiciones no cambia el número de estados del modelo.
Porque las transiciones válidas nunca contienen defectos.
Las transiciones válidas también pueden contener defectos y deben probarse.
Para lograr automáticamente el 100 % de cobertura de sentencias.
La prueba de transición de estados es de caja negra y no garantiza por sí sola cobertura de sentencias.
Probar transiciones inválidas comprueba que el sistema rechaza o gestiona correctamente eventos que no deberían permitirse en el estado actual, una fuente habitual de defectos.
Una tabla de decisión tiene tres condiciones booleanas independientes. Antes de cualquier simplificación, ¿cuántas reglas (columnas) distintas contiene la tabla completa?
8
Correcto — 2^3 = 8 combinaciones de tres condiciones booleanas.
6
2^3 es 8, no 6 (confunde multiplicación con exponenciación).
3
3 es el número de condiciones, no de reglas.
9
9 es 3 al cuadrado; el número de combinaciones es 2 elevado a 3 = 8.
Para n condiciones booleanas independientes, la tabla completa tiene 2^n reglas. Para 3 condiciones son 2^3 = 8.
¿Qué afirmación sobre la cobertura de sentencias y de decisiones (ramas) es correcta?
El 100 % de cobertura de decisiones garantiza el 100 % de cobertura de sentencias, pero no al revés.
Correcto — la cobertura de decisiones subsume la de sentencias.
El 100 % de cobertura de sentencias garantiza el 100 % de cobertura de decisiones.
La cobertura de sentencias puede ser del 100 % aunque algunas ramas (p. ej., un else vacío) no se tomen.
Ambas medidas son siempre iguales.
Pueden diferir; la cobertura de decisiones suele ser más difícil de lograr.
Ninguna medida tiene relación con la otra.
Están relacionadas: la cobertura de decisiones subsume la de sentencias.
Lograr el 100 % de cobertura de decisiones garantiza el 100 % de cobertura de sentencias, pero no a la inversa; la cobertura de decisiones es el criterio más fuerte.
Un tester usa una lista de alto nivel de áreas, reglas y condiciones a comprobar, derivada de la experiencia, para guiar las pruebas sin prescribir pasos exactos. ¿Qué técnica es?
Pruebas basadas en listas de comprobación.
Correcto — usar una checklist derivada de la experiencia para guiar las pruebas es prueba basada en listas de comprobación.
Análisis de valores límite.
El AVL apunta a los bordes de los rangos de entrada, no a una lista de áreas.
Pruebas con tabla de decisión.
Las tablas de decisión capturan combinaciones de condiciones, no listas basadas en la experiencia.
Pruebas de sentencias.
Las pruebas de sentencias son una técnica de cobertura de caja blanca.
Las pruebas basadas en listas de comprobación usan una checklist de elementos a cubrir, basada en la experiencia; es una técnica basada en la experiencia.
Un campo acepta un porcentaje de descuento como entero de 1 a 100 inclusive. Usando el análisis de valores límite de tres valores (por cada límite, el valor límite y los valores justo por debajo y por encima), ¿cuántos valores de prueba distintos se requieren si ninguno se solapa?
6
Tres valores por límite por dos límites = seis valores distintos.
4
4 es el AVL de dos valores (dos por límite), no el de tres valores.
2
2 cubre solo los valores límite en sí.
8
Cuenta de más; el AVL de tres valores necesita tres por límite, no cuatro.
Límite inferior 1 → 0, 1, 2; límite superior 100 → 99, 100, 101. Son seis valores distintos.
¿Cuál de los siguientes es el mejor ejemplo de un criterio de entrada para las pruebas de sistema?
Se despliega una compilación estable en un entorno de pruebas configurado y disponible.
Correcto — esta es una precondición (criterio de entrada) para iniciar las pruebas de sistema.
Todas las pruebas de sistema planificadas han pasado.
Ese es un criterio de salida, que describe la finalización, no la entrada.
No quedan defectos de severidad alta abiertos.
También es un criterio de salida, no una condición de entrada.
El informe de resumen de pruebas ha sido aprobado.
La aprobación ocurre al final, por lo que esto no es un criterio de entrada.
Los criterios de entrada son las precondiciones que deben cumplirse antes de que las pruebas puedan comenzar de forma significativa, como una compilación estable desplegada en un entorno de pruebas preparado.
El modelo de la «pirámide de pruebas» generalmente sugiere ¿qué distribución de pruebas automatizadas?
Muchas pruebas de bajo nivel (unitarias/de componentes), menos pruebas de integración y pocas pruebas de extremo a extremo de interfaz de usuario.
Correcto — la pirámide favorece una base amplia de pruebas rápidas de bajo nivel.
Mayoritariamente pruebas de extremo a extremo de interfaz de usuario, con muy pocas pruebas unitarias.
Ese es el antipatrón invertido del «cono de helado», no la pirámide.
Un número igual de pruebas en cada nivel.
La pirámide tiene deliberadamente más pruebas en los niveles inferiores.
Solo pruebas manuales en todos los niveles.
La pirámide trata sobre la distribución de pruebas automatizadas entre los niveles.
La pirámide de pruebas sugiere muchas pruebas rápidas de bajo nivel (p. ej., unitarias/de componentes), menos pruebas de integración/API y relativamente pocas pruebas de extremo a extremo de interfaz de usuario, lentas y de alto nivel.
¿Cómo utilizan habitualmente las pruebas basadas en riesgos el nivel de riesgo evaluado?
Los elementos de mayor riesgo reciben más pruebas y más tempranas que los de menor riesgo.
Correcto — el esfuerzo se asigna en proporción al riesgo.
Cada elemento recibe exactamente la misma cantidad de pruebas independientemente del riesgo.
Eso ignora el riesgo y no son pruebas basadas en riesgos.
Los elementos de menor riesgo siempre se prueban primero.
Las pruebas basadas en riesgos priorizan los elementos de mayor riesgo, no los de menor riesgo.
Los niveles de riesgo se utilizan solo después de la liberación, nunca durante las pruebas.
El riesgo se utiliza para planificar y dirigir las pruebas en todo momento, no solo después de la liberación.
Las pruebas basadas en riesgos priorizan y asignan más pruebas, más tempranas y más profundas a los elementos de mayor riesgo, y menos esfuerzo a los elementos de menor riesgo.
¿Cuál es el papel de la gestión de la configuración en apoyo de las pruebas?
Identifica de forma única y controla por versión los elementos de prueba y el testware para que las pruebas se ejecuten contra versiones conocidas.
Correcto — la gestión de la configuración mantiene la integridad y trazabilidad de los elementos y el testware.
Escribe los casos de prueba detallados para cada requisito.
El diseño de pruebas produce los casos de prueba; la gestión de la configuración gestiona versiones e integridad.
Decide qué defectos se corregirán.
El triaje de defectos decide las correcciones; la gestión de la configuración controla versiones y configuraciones.
Estima el esfuerzo necesario para las pruebas.
La estimación es una actividad de planificación, no gestión de la configuración.
La gestión de la configuración garantiza que los productos de prueba (testware) y los elementos bajo prueba estén identificados, controlados por versión y sean trazables, de modo que las pruebas se ejecuten contra versiones conocidas.
¿Cuál es la diferencia entre la severidad y la prioridad de un defecto?
La severidad es el impacto en el sistema; la prioridad es con qué urgencia debe corregirse.
Correcto — la severidad trata del impacto, la prioridad de la urgencia, y pueden diferir.
La severidad y la prioridad siempre tienen el mismo valor.
Un defecto de severidad alta puede ser de prioridad baja y viceversa.
La prioridad es el impacto técnico; la severidad es la urgencia de negocio.
Esto invierte las definiciones.
Ambos términos se refieren solo a cuán reproducible es el defecto.
La reproducibilidad es un atributo distinto de la severidad y la prioridad.
La severidad refleja el impacto del defecto en el sistema; la prioridad refleja con qué urgencia debe corregirse desde una perspectiva de negocio. Son independientes.
¿Cuál de las siguientes tareas es típicamente responsabilidad de un gestor de pruebas y no de un probador (tester)?
Elaborar y revisar el plan de pruebas y la estrategia de pruebas general.
Correcto — la planificación y la estrategia son responsabilidades de la gestión de pruebas.
Diseñar e implementar casos de prueba individuales.
Esta es típicamente una tarea del probador.
Ejecutar pruebas y registrar los resultados.
La ejecución y el registro suelen ser realizados por los probadores.
Preparar los datos de prueba para un caso de prueba específico.
Preparar datos de prueba suele ser una tarea del probador.
El gestor de pruebas planifica, supervisa y controla las actividades de prueba (estrategia, planificación, informes), mientras que los probadores diseñan, implementan y ejecutan las pruebas.
Un equipo estima el esfuerzo de prueba analizando el esfuerzo dedicado a las pruebas en varios proyectos anteriores y similares. ¿Qué enfoque de estimación es este?
Una técnica de estimación basada en métricas.
Correcto — usar datos históricos de proyectos similares es estimación basada en métricas.
Una técnica de estimación basada en expertos.
La estimación basada en expertos se apoya en el juicio de expertos, no en métricas históricas.
Análisis de valores límite.
El análisis de valores límite (BVA) es una técnica de diseño de pruebas, no un enfoque de estimación.
Pruebas exploratorias.
Las pruebas exploratorias son una técnica de prueba, no un método de estimación.
La estimación basada en métricas utiliza datos de proyectos anteriores o similares (p. ej., esfuerzo pasado, tasas de defectos) para pronosticar el esfuerzo necesario.
¿Cuáles DOS de las siguientes se usan habitualmente como métricas de monitorización de pruebas? (Elija dos.)
Porcentaje de casos de prueba planificados ejecutados.
Una medida estándar del progreso de las pruebas.
Número de defectos encontrados, agrupados por severidad.
Las métricas de defectos son una parte esencial de la monitorización de pruebas.
Número de palabras en el folleto de marketing.
No es una métrica de prueba.
La temperatura de la oficina durante las pruebas.
Irrelevante para la monitorización de pruebas.
La monitorización de pruebas utiliza métricas como el progreso de ejecución de los casos de prueba, la información de defectos (recuentos, densidad, tendencias) y la cobertura alcanzada. Las líneas de texto de marketing y las valoraciones de la moral del equipo no son métricas de prueba estándar.
Un responsable de pruebas aplica la técnica de tres puntos (PERT) a una tarea con optimista = 2 días, más probable = 5 días y pesimista = 14 días. ¿Cuál es la estimación según E = (O + 4M + P) / 6?
6 días
(2 + 20 + 14) / 6 = 36 / 6 = 6.
5 días
5 es el valor más probable, no la estimación ponderada PERT.
7 días
7 es el promedio simple (2+5+14)/3, no la media ponderada PERT.
8 días
No coincide con la fórmula; la estimación ponderada correcta es 6.
E = (2 + 4×5 + 14) / 6 = (2 + 20 + 14) / 6 = 36 / 6 = 6 días.
Una herramienta que ejecuta scripts automatizados predefinidos contra la aplicación y compara los resultados reales con los esperados, ¿a qué categoría pertenece?
Herramientas de ejecución de pruebas.
Correcto — ejecutar scripts automatizados y comparar resultados es la función de las herramientas de ejecución de pruebas.
Herramientas de análisis estático.
El análisis estático examina el código sin ejecutarlo.
Herramientas de gestión de requisitos.
Estas gestionan los requisitos y la trazabilidad, no la ejecución de pruebas.
Herramientas de preparación de datos de prueba.
Estas generan o enmascaran datos de prueba; no ejecutan pruebas.
Las herramientas de ejecución de pruebas ejecutan pruebas automatizadas contra el sistema bajo prueba y comparan los resultados reales con los esperados, apoyando las pruebas de regresión.
¿Por qué es una buena práctica ejecutar un proyecto piloto antes de desplegar una nueva herramienta de prueba en toda la organización?
Para evaluar qué tan bien se ajusta la herramienta a los procesos existentes y aprender a usarla eficazmente antes de una adopción más amplia.
Correcto — un piloto reduce el riesgo al evaluar primero la idoneidad y desarrollar el conocimiento.
Para garantizar que la herramienta eliminará todas las pruebas manuales.
Las herramientas apoyan las pruebas pero no eliminan la necesidad de las pruebas manuales.
Para demostrar que la herramienta puede encontrar todos los defectos del sistema.
Ninguna herramienta puede encontrar todos los defectos; un piloto no lo pretende.
Porque las herramientas nunca requieren mantenimiento una vez instaladas.
Las herramientas y sus scripts requieren mantenimiento continuo.
Un piloto evalúa cómo se ajusta la herramienta a los procesos y la infraestructura de la organización, decide los estándares de uso y valora los costes y beneficios antes de un despliegue completo.