ISTQB Foundation (CTFL v4.0) Examen de práctica #10 — 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.
¿Qué afirmación describe mejor la diferencia entre probar (testing) y depurar (debugging)?
Las pruebas identifican fallos causados por defectos; la depuración localiza, analiza y corrige esos defectos.
Distinción ISTQB correcta entre ambas actividades.
Las pruebas corrigen defectos; la depuración solo los encuentra.
Invertido: corregir es parte de la depuración/desarrollo.
Probar y depurar son dos nombres para la misma actividad.
Son actividades distintas con objetivos diferentes.
La depuración la realizan solo los testers.
La depuración es típicamente una actividad de desarrollo.
Las pruebas detectan fallos; la depuración localiza y corrige los defectos subyacentes.
Un tester junior propone probar todas las combinaciones posibles de entrada de un formulario para garantizar que no tenga defectos. ¿Qué principio de prueba explica por qué esto no es viable?
Las pruebas exhaustivas son imposibles.
Probarlo todo no es viable; hay que enfocarse con riesgo y técnicas.
Agrupación de defectos.
Ese principio trata de la concentración de defectos en pocos módulos.
Paradoja del pesticida.
Trata de que las pruebas repetidas pierden eficacia con el tiempo.
Las pruebas muestran la presencia de defectos, no su ausencia.
Principio cierto, pero no explica la inviabilidad de las pruebas exhaustivas.
Las pruebas exhaustivas son imposibles salvo en casos triviales.
¿Cuáles de los siguientes son objetivos de las pruebas? (Elija DOS.)
Encontrar defectos.
Un objetivo primario de las pruebas.
Generar confianza en el nivel de calidad.
También un objetivo central de las pruebas.
Probar que el software no tiene defectos.
Imposible: las pruebas no pueden probar la ausencia de defectos.
Reparar los defectos encontrados.
Corregir es depuración/desarrollo, no pruebas.
Las pruebas encuentran defectos y generan confianza; no pueden probar su ausencia, y corregir no es probar.
Un desarrollador escribe > en lugar de >= en una comparación. En ejecución el programa rechaza un valor límite válido y el usuario ve un mensaje incorrecto. Asocie esto con los términos ISTQB error, defecto y fallo.
El tecleo erróneo es el error; el operador incorrecto en el código es el defecto; el valor válido rechazado es el fallo.
Cadena correcta error a defecto a fallo.
El operador incorrecto es el error; el tecleo es el defecto.
Se intercambian error y defecto.
Los tres términos describen el mismo evento.
Denotan etapas distintas.
El fallo es el código incorrecto; el defecto es el mensaje.
El fallo es el efecto en ejecución, no el código.
El error humano es el 'error', el código incorrecto es el defecto y el comportamiento incorrecto observado es el fallo.
¿Por qué es valioso para una organización el análisis de causa raíz de los defectos?
Abordar las causas raíz puede prevenir clases enteras de defectos futuros.
La mejora de procesos reduce la recurrencia.
Asigna la culpa al desarrollador que causó el defecto.
El análisis de causa raíz no busca culpables.
Garantiza que la próxima versión no tenga defectos.
Ninguna actividad garantiza cero defectos.
Reemplaza la necesidad de pruebas dinámicas.
Complementa, no reemplaza, las pruebas.
Eliminar las causas raíz puede prevenir clases enteras de defectos futuros (mejora de procesos).
¿Qué afirmación ilustra correctamente que las pruebas dependen del contexto?
Un dispositivo médico crítico para la seguridad se prueba con más rigor que un prototipo interno desechable.
El contexto y el riesgo determinan la intensidad de las pruebas.
Todo software debe probarse de forma idéntica sin importar el riesgo.
Contradice la dependencia del contexto.
El contexto solo afecta al lenguaje de programación, no a las pruebas.
El contexto afecta a todo el enfoque de prueba.
La dependencia del contexto significa que probar es opcional.
Significa que el enfoque varía, no que se omitan las pruebas.
La intensidad de las pruebas debe ajustarse al riesgo y contexto del producto.
¿Qué DOS afirmaciones sobre la mentalidad y la independencia de un tester son correctas?
La curiosidad y la atención al detalle ayudan a los testers a encontrar defectos sutiles.
Una mentalidad de prueba constructiva mejora la detección.
Cierto grado de independencia puede aumentar la eficacia de la detección de defectos.
La independencia reduce el sesgo del autor.
Testers y desarrolladores nunca deben comunicarse.
La colaboración es esencial.
La independencia total siempre encuentra más defectos que cualquier otra disposición.
Exagerado; la independencia tiene compensaciones.
La curiosidad y cierto grado de independencia ayudan; el aislamiento total o las afirmaciones absolutas son incorrectos.
Crear un equipo de prueba separado con un alto grado de independencia aporta beneficios reconocidos, pero el programa de estudio también enumera inconvenientes. ¿Cuál de los siguientes es un inconveniente de un alto grado de independencia?
Los desarrolladores pueden perder su sentido de responsabilidad por la calidad y el equipo independiente puede aislarse o ser visto como un cuello de botella.
Correcto — son exactamente los inconvenientes que el programa asocia a un alto grado de independencia.
Los testers independientes están menos dispuestos a cuestionar las suposiciones de los autores de los productos de trabajo.
Es lo contrario: la independencia aumenta la disposición a cuestionar suposiciones, porque no participaron en la creación. Eso es un beneficio, no un inconveniente.
Un equipo de prueba independiente no puede usar la especificación de requisitos como base de prueba.
Nada limita la base de prueba según quién prueba. Los testers independientes usan los mismos requisitos, diseños y fuentes que cualquier otro.
La prueba independiente hace imposible un enfoque de equipo completo hacia la calidad.
Ambos son complementarios: distintos grados de independencia pueden coexistir con la responsabilidad compartida de todo el equipo. El inconveniente real es el riesgo de aislamiento, no una imposibilidad.
Los testers independientes pueden aislarse del equipo de desarrollo, ser vistos como un cuello de botella o como los únicos responsables de la calidad, y los desarrolladores pueden perder su propio sentido de responsabilidad por la calidad.
¿Por qué corregir un defecto encontrado durante la revisión de requisitos suele costar menos que corregirlo en producción?
El defecto se elimina antes de propagarse al diseño, el código y los componentes dependientes.
Las pruebas tempranas limitan el coste de retrabajo posterior.
Los defectos de requisitos siempre son triviales.
La severidad no depende de cuándo se encuentre.
Las correcciones en producción son gratuitas.
Las correcciones en producción suelen ser las más caras.
Las revisiones corrigen automáticamente los defectos que encuentran.
Las revisiones detectan, no corrigen.
La eliminación temprana evita que el defecto se propague al diseño, el código y el trabajo dependiente.
¿Qué nivel de prueba se centra en las interfaces e interacciones entre componentes o sistemas integrados?
Prueba de integración.
Apunta a las interfaces entre componentes/sistemas integrados.
Prueba de componentes.
Prueba módulos de forma aislada, no sus interacciones.
Prueba de sistema.
Prueba el comportamiento del sistema completo, no específicamente interfaces.
Prueba de aceptación.
Valida la idoneidad de uso para las partes interesadas.
La prueba de integración ejercita las interfaces e interacciones entre partes integradas.
Un tester verifica que el sistema sigue atendiendo a 5000 usuarios simultáneos en 2 segundos tras un cambio de código. ¿Qué tipo de prueba es principalmente?
Prueba no funcional (de rendimiento).
Evalúa cómo de bien funciona el sistema, no qué hace.
Prueba funcional.
Las pruebas funcionales comprueban qué hace el sistema, no el rendimiento.
Prueba de caja blanca (estructural).
Se basa en la estructura interna, no en la carga de usuarios.
Prueba de confirmación.
Vuelve a comprobar un único defecto corregido.
Comprobar el tiempo de respuesta bajo carga es una prueba no funcional (de rendimiento).
Tras corregir un defecto, un tester primero vuelve a ejecutar la prueba que falló para verificar la corrección y luego ejecuta pruebas cercanas para asegurar que nada más se rompió. Nombre las dos actividades en orden.
Prueba de confirmación, luego prueba de regresión.
Confirmar la corrección y después buscar efectos secundarios no deseados.
Prueba de regresión, luego prueba de confirmación.
Orden invertido.
Prueba de sistema, luego de aceptación.
Esos son niveles de prueba, no actividades de cambio.
Prueba de humo, luego prueba exploratoria.
Ninguna coincide con el propósito descrito.
Primero prueba de confirmación de la corrección, luego prueba de regresión del área circundante.
¿Cuáles DOS de los siguientes son NIVELES de prueba (no tipos de prueba ni pruebas de cambio)?
Prueba de integración de componentes.
Un nivel de prueba reconocido en CTFL v4.0.
Prueba de aceptación.
Un nivel de prueba centrado en la idoneidad de uso.
Prueba de rendimiento.
Es un tipo de prueba no funcional.
Prueba de regresión.
Es una prueba relacionada con cambios, no un nivel.
La integración de componentes y la aceptación son niveles; el rendimiento es un tipo y la regresión es de cambio.
¿Qué forma de prueba de aceptación realizan los usuarios potenciales en las instalaciones del desarrollador y no en el campo?
Prueba alfa.
Realizada por usuarios potenciales en las instalaciones del desarrollador.
Prueba beta.
Realizada por usuarios en su propio entorno.
Prueba de aceptación operativa.
Comprueba aspectos operativos como copia/restauración.
Prueba de aceptación contractual.
Comprueba el cumplimiento de los criterios del contrato.
La prueba alfa se realiza en las instalaciones del desarrollador; la beta en el entorno del usuario.
¿Qué beneficio es característico de las pruebas estáticas frente a las dinámicas?
Puede encontrar defectos (p. ej. en requisitos) antes de ejecutar código.
Las pruebas estáticas examinan productos sin ejecutarlos.
Mide el tiempo de respuesta real bajo carga.
Eso requiere ejecución dinámica.
Siempre reemplaza la necesidad de pruebas dinámicas.
Ambas son complementarias.
Solo puede aplicarse al código fuente.
Se aplica a requisitos, diseños y más.
Las pruebas estáticas pueden encontrar defectos en productos de trabajo antes de ejecutar código.
En una reunión de revisión formal, ¿quién es el principal responsable de registrar los defectos y problemas planteados?
El secretario (anotador).
Documenta los problemas y decisiones de la revisión.
El moderador.
Dirige la reunión pero no registra principalmente los problemas.
El autor.
Es dueño del producto de trabajo, no registra por el equipo.
Cualquier revisor.
Los revisores encuentran problemas; registrar es función del secretario.
El secretario (anotador) documenta los problemas planteados durante la revisión.
¿Qué DOS tipos de revisión son normalmente los más formales, con criterios de entrada/salida definidos y métricas?
Inspección.
El tipo de revisión más formal, con métricas y roles.
Revisión técnica.
Una revisión documentada, a menudo formal, por pares técnicos.
Revisión informal.
Por definición no tiene un proceso formal.
Comprobación ad-hoc de escritorio.
Una comprobación informal y no estructurada.
La inspección y la revisión técnica son los tipos más formales; las informales y ad-hoc no.
¿Cuáles DOS de los siguientes son beneficios típicos de las pruebas estáticas? (Elija dos.)
Detectar defectos temprano, antes de ejecutar el código.
Correcto — la detección temprana reduce el costo de corrección.
Hallar defectos difíciles de detectar con pruebas dinámicas (p. ej. código inalcanzable).
Correcto — el análisis estático puede revelar tales defectos estructurales.
Medir el rendimiento real del sistema en ejecución.
Las pruebas estáticas no ejecutan el sistema, no miden rendimiento.
Confirmar que el sistema se comporta bien con datos reales de usuario.
Confirmar el comportamiento en ejecución requiere pruebas dinámicas.
Las pruebas estáticas detectan defectos temprano (más baratos de corregir) y hallan defectos difíciles para las dinámicas, como código inalcanzable o inconsistencias en requisitos. No ejecutan código ni miden rendimiento.
Un sistema de venta de entradas fija el precio por edad: 0-17 pagan tarifa infantil, 18-64 tarifa estándar y 65 o más tarifa sénior. La edad se introduce como número entero. Con partición de equivalencia solo sobre entradas de edad VÁLIDAS, ¿cuál es el número mínimo de casos de prueba para cubrir cada partición de precio válida exactamente una vez?
3
Un valor representativo por cada partición válida.
2
Tres particiones válidas no se cubren con dos casos.
4
Solo existen tres particiones válidas; las inválidas se excluyeron.
6
Eso contaría los límites, no las particiones.
Hay tres particiones válidas (infantil, estándar, sénior); un representante de cada una da 3.
Un campo de cantidad acepta enteros de 1 a 100 inclusive; los valores fuera se rechazan. Con el análisis de valores límite de 2 valores (cada límite más su vecino más cercano), ¿qué conjunto de valores prueba AMBOS límites?
{0, 1, 100, 101}
Cada límite (1, 100) más su vecino exterior más cercano (0, 101).
{1, 100}
Solo los límites, omiten los valores vecinos.
{0, 1, 2, 99, 100, 101}
Ese es el enfoque de 3 valores (seis valores).
{1, 2, 99, 100}
Usa vecinos interiores en lugar de los exteriores.
El BVA de 2 valores prueba cada límite y su vecino más cercano: {0,1} y {100,101}.
Para el mismo campo que acepta enteros de 1 a 100 inclusive, ¿cuántos valores distintos requiere el enfoque de análisis de valores límite de 3 valores para cubrir AMBOS límites (el límite más el valor justo por debajo y por encima de cada uno)?
6
Tres valores por límite, dos límites, sin solapamiento.
4
Ese es el enfoque de 2 valores.
8
Cuenta de más; solo se necesitan tres valores por límite.
3
Tres valores cubren solo un límite.
Inferior {0,1,2} y superior {99,100,101} = seis valores distintos.
Use la tabla de decisión siguiente. Un suscriptor del plan Premium tiene un pago válido, pero inicia una cuarta transmisión simultánea, lo que supera su límite de dispositivos. ¿Qué regla aplica y cuál es la acción resultante?
Regla R2 - Denegar (límite de dispositivos superado)
Pago S, Premium S, Dispositivo OK N es exactamente la columna R2.
Regla R1 - Permitir 4K/HD
R1 requiere Límite de dispositivos OK = S.
Regla R5 - Denegar (pago)
R5 requiere Pago válido = N.
Regla R4 - Denegar (límite de dispositivos)
R4 requiere Plan = Premium N (Estándar).
Pago S, Premium S, Límite de dispositivos OK = N coincide con R2: Denegar (límite de dispositivos).
En la tabla de decisión siguiente, siempre que Pago válido = N (reglas R5-R8) la acción es siempre Denegar (pago), sin importar las otras dos condiciones. Con simplificación 'don't-care', ¿cuántas de las ocho columnas pueden fusionarse en una sola regla combinada?
4 (R5-R8 se fusionan en una regla)
Las cuatro dan Denegar (pago) cuando Pago = N.
2
Aquí más de dos columnas comparten la acción idéntica.
8
Solo se fusionan las cuatro columnas con pago inválido, no las ocho.
1
Una columna no puede 'fusionarse'; cuatro se fusionan en una.
R5-R8 comparten la misma acción y solo difieren en condiciones 'don't-care', así que 4 se fusionan en 1.
Un tester debe derivar pruebas de una regla de negocio que combina varias condiciones produciendo distintos resultados. ¿Qué técnica de caja negra es la más adecuada?
Prueba de tabla de decisión
Diseñada para combinaciones de condiciones y resultados.
Prueba de transición de estados
Mejor para cambios de estado por eventos, no combinaciones de condiciones.
Análisis de valores límite
Apunta a los bordes de rangos ordenados, no a combinaciones lógicas.
Prueba de sentencias
Una técnica de caja blanca basada en código, no en reglas de negocio.
La prueba de tabla de decisión cubre sistemáticamente combinaciones de condiciones y sus acciones.
Usando la máquina de estados de la sesión del cajero siguiente, ¿qué secuencia de eventos es un camino VÁLIDO que empieza y termina en el estado Idle?
insertar tarjeta -> PIN correcto -> retirar -> efectivo retirado -> salir -> tarjeta retirada
Cada transición existe en el diagrama y vuelve a Idle.
insertar tarjeta -> retirar -> efectivo retirado
No hay transición de AwaitPIN a Dispensing sin PIN correcto.
insertar tarjeta -> 3.er PIN incorrecto -> tarjeta retirada
Desde Locked la transición a Idle es 'tarjeta retenida', no 'tarjeta retirada'.
insertar tarjeta -> PIN correcto -> salir -> retirar
Tras salir, está en CardReturned; retirar no es válido ahí.
El recorrido válido es insertar tarjeta, PIN correcto, retirar, efectivo retirado, salir, tarjeta retirada.
Considere esta rutina con cuatro sentencias ejecutables: (1) INPUT x; (2) IF x > 10; (3) PRINT big; (4) PRINT done. La sentencia PRINT big se ejecuta solo cuando el IF es verdadero. Una sola prueba se ejecuta con x = 5. ¿Qué cobertura de sentencias logra esta única prueba?
75%
Se ejecutan las sentencias 1, 2 y 4; se omite la 3: 3/4.
100%
La sentencia 3 (PRINT big) no se alcanza con x = 5.
50%
Se ejecutan tres de cuatro sentencias, no dos.
25%
Solo se omite una sentencia, se ejecutan tres.
Con x = 5 el IF es falso, así que se ejecutan 3 de 4 sentencias = 75%.
¿Cuáles DOS de los siguientes son técnicas de prueba de caja negra (basadas en especificación)?
Partición de equivalencia
Derivada de la especificación, no del código.
Prueba de transición de estados
Basada en estados y eventos especificados (caja negra).
Prueba de sentencias
Una técnica de caja blanca basada en la estructura del código.
Prueba de ramas
Una técnica de caja blanca basada en decisiones del código.
La partición de equivalencia y la prueba de transición de estados son de caja negra; las de sentencias y ramas son de caja blanca.
Un tester investiga una aplicación sin guiones predefinidos, diseñando y ejecutando pruebas a la vez y aprendiendo de cada resultado para guiar el siguiente. ¿Qué técnica es?
Prueba exploratoria
Diseño, ejecución y aprendizaje concurrentes.
Prueba basada en listas de verificación
Guiada por una lista fija, no exploración libre.
Prueba de tabla de decisión
Una técnica basada en especificación con casos predefinidos.
Conjetura de errores
Anticipa errores probables, no exploración abierta.
Diseñar y ejecutar pruebas de forma concurrente mientras se aprende es prueba exploratoria.
¿Qué afirmación caracteriza mejor las pruebas exploratorias?
El diseño de pruebas, la ejecución y el aprendizaje se realizan simultáneamente, a menudo en sesiones acotadas en el tiempo.
Correcto — las pruebas exploratorias entrelazan aprendizaje, diseño y ejecución.
Todos los casos de prueba se escriben por completo de antemano antes de cualquier ejecución.
Eso describe las pruebas guionizadas, lo opuesto a las pruebas exploratorias.
Solo pueden realizarse mediante herramientas automatizadas.
Las pruebas exploratorias son fundamentalmente una actividad humana y manual.
Garantizan una cobertura estructural medible.
Las pruebas exploratorias por sí solas no garantizan una cifra de cobertura estructural.
En las pruebas exploratorias, el diseño de pruebas, la ejecución y el aprendizaje ocurren simultáneamente; suelen organizarse en sesiones acotadas en el tiempo y guiadas por una carta (charter), y resultan eficaces cuando las especificaciones son escasas.
¿Cuál de los siguientes se documenta normalmente en un plan de pruebas?
Alcance, objetivos, cronograma y criterios de entrada/salida de las actividades
Son contenidos centrales de un plan de pruebas.
La lista exacta de defectos que se encontrarán
Los defectos no pueden conocerse de antemano.
El código fuente completo del sistema
El código fuente no forma parte de un plan de pruebas.
El texto de marketing del lanzamiento
Irrelevante para la planificación de pruebas.
Un plan de pruebas documenta alcance, objetivos, cronograma y criterios de entrada/salida.
Que un tester clave abandone inesperadamente a mitad del proyecto es un ejemplo de ¿qué tipo de riesgo?
Riesgo de proyecto
Amenaza la gestión/entrega del proyecto, no el producto en sí.
Riesgo de producto
El riesgo de producto concierne a la calidad del entregable.
Riesgo residual
El riesgo residual es lo que queda tras la mitigación.
Nivel de riesgo
El nivel de riesgo es una medida, no una categoría.
Los problemas de personal afectan a la capacidad de entrega del proyecto: un riesgo de proyecto.
¿Cómo influye principalmente la prueba basada en riesgos en la asignación del esfuerzo de prueba?
Se asigna más y mayor profundidad de pruebas a las áreas de mayor riesgo
El esfuerzo sigue al riesgo para maximizar el valor.
El esfuerzo se reparte por igual sin importar el riesgo
Eso ignora el propósito de la prueba basada en riesgos.
Solo se prueban las áreas de bajo riesgo
Las de alto riesgo son justo donde más se necesita probar.
Se omite por completo la prueba de las áreas de riesgo
El riesgo aumenta, no elimina, la necesidad de probar.
Las áreas de mayor riesgo reciben más pruebas y más profundas.
¿Cuáles DOS son criterios de ENTRADA realistas para comenzar un nivel de prueba?
El entorno de prueba está disponible y configurado
Necesario antes de poder iniciar la ejecución.
Los casos y datos de prueba están listos
Entradas requeridas para empezar a probar.
Todos los defectos ya están corregidos
Es irreal como criterio de entrada.
El producto ya se ha entregado a los clientes
El lanzamiento es posterior a las pruebas, no un criterio de entrada.
Un entorno listo y casos/datos de prueba preparados son criterios de entrada típicos.
¿Qué elemento es contenido esencial de un buen informe de defectos?
Pasos para reproducir, resultados esperado y real
Información central para analizar y corregir el defecto.
La dirección particular del desarrollador
Irrelevante e inapropiada.
Una conjetura sobre quién tiene la culpa
Los informes deben ser objetivos, no acusatorios.
El presupuesto de marketing
No tiene relación con el defecto.
Los pasos para reproducir más los resultados esperado y real permiten actuar sobre el informe.
Un equipo estima una tarea de prueba con estimación de tres puntos: optimista = 3 días, más probable = 6 días, pesimista = 15 días. Con la fórmula (a + 4m + b) / 6, ¿cuál es la duración esperada?
7 días
(3 + 4*6 + 15)/6 = 42/6 = 7.
6 días
6 es el valor más probable, no la estimación ponderada.
8 días
Resultado de un error aritmético; el valor correcto es 7.
9 días
No coincide con el resultado de la fórmula, que es 7.
(3 + 24 + 15) / 6 = 42 / 6 = 7 días.
Cuatro riesgos de producto se valoran en escala 1-5: R1 L=3 I=4; R2 L=4 I=4; R3 L=5 I=2; R4 L=2 I=5. Si el nivel de riesgo es el producto de Probabilidad (L) e Impacto (I), ¿qué riesgo debe probarse PRIMERO?
R2 (nivel de riesgo 16)
4*4 = 16 es el más alto de los cuatro.
R1 (nivel de riesgo 12)
3*4 = 12 es menor que el 16 de R2.
R3 (nivel de riesgo 10)
5*2 = 10 es menor que el 16 de R2.
R4 (nivel de riesgo 10)
2*5 = 10 es menor que el 16 de R2.
R2 tiene el producto más alto (16) y se prueba primero.
¿Cuáles DOS son métricas útiles para monitorear el progreso de las pruebas?
Número de casos ejecutados frente a planificados
Muestra el progreso de ejecución respecto al plan.
Tendencias de detección y cierre de defectos en el tiempo
Indica calidad y convergencia.
El número de líneas del documento del plan
La longitud del documento no es métrica de progreso.
La velocidad media de escritura de los testers
Irrelevante para el progreso de las pruebas.
Pruebas ejecutadas frente a planificadas y tendencias de defectos son métricas significativas.
¿Por qué es importante la gestión de configuración para las pruebas?
Garantiza que los elementos de prueba, el testware y los entornos estén versionados y sean reproducibles
La reproducibilidad depende de versiones controladas.
Garantiza que el software no tiene defectos
La gestión de configuración no elimina defectos.
Reemplaza la necesidad de un plan de pruebas
La GC complementa, no reemplaza, la planificación.
Escribe automáticamente los casos de prueba
La GC gestiona versiones, no redacta pruebas.
Versiona elementos de prueba, testware y entornos para que los resultados sean reproducibles.
¿Qué tipo de herramienta apoya principalmente la vinculación de requisitos, casos de prueba y defectos, y su reporte?
Herramienta de gestión de pruebas
Gestiona la trazabilidad y el reporte del proceso de prueba.
Herramienta de pruebas de rendimiento
Genera carga y mide rendimiento, no trazabilidad.
Herramienta de análisis estático
Analiza el código sin ejecutarlo.
Herramienta de medición de cobertura
Mide la cobertura estructural, no la trazabilidad.
Una herramienta de gestión de pruebas vincula requisitos, pruebas y defectos y los reporta.
¿Cuáles DOS son beneficios reales de la automatización de pruebas?
Reduce el esfuerzo manual repetitivo en pruebas de regresión
Libera a los testers para tareas de mayor valor.
Mejora la consistencia y repetibilidad de la ejecución
Las máquinas ejecutan los mismos pasos igual.
Garantiza un producto sin defectos
Ninguna técnica garantiza cero defectos.
Elimina la necesidad de diseñar pruebas
La automatización ejecuta pruebas que igualmente hay que diseñar.
La automatización reduce el esfuerzo repetitivo y mejora la repetibilidad; no garantiza software sin defectos ni elimina el diseño de pruebas.