La participación de probadores durante varias actividades del ciclo de vida de desarrollo del software (CVDS) ayudará a detectar defectos en los productos software.

Los probadores intentan no molestar a los desarrolladores mientras codifican, para que éstos escriban un código de mejor calidad.

Los probadores que colaboran con los usuarios finales ayudan a mejorar la calidad de los informes de defectos durante la integración de componentes y las pruebas de sistemas.

Los probadores certificados diseñan casos de prueba mucho mejores que los probadores no certificados.

Las pruebas se desgastan.

Falacia de la ausencia de errores.

Los defectos se agrupan.

Es imposible realizar pruebas exhaustivas.

Estimar que probar la integración con el servicio de pago llevará 8 días-persona.

Decidir que el equipo debe probar si es posible compartir correctamente el pago entre muchos usuarios.

Utilizar el análisis del valor frontera (AVF) para obtener los datos de prueba para los casos de prueba que comprueban el procesamiento correcto del pago para el importe mínimo permitido a pagar.

Analizar la discrepancia entre el resultado real y el resultado esperado tras ejecutar un caso de prueba que comprueba el proceso de pago con tarjeta de crédito e informar de un defecto.

I, II tienen una influencia significativa; III, IV, V no la tienen.

I, III, IV tienen una influencia significativa; II, V no la tienen.

II, IV, V tienen una influencia significativa; I, III no la tienen.

III, V tienen una influencia significativa; I, II, IV no la tienen

Configurar entornos de prueba.

Mantener la lista de trabajo acumulado del producto

Diseñar soluciones para nuevos requisitos.

Crear el plan de prueba.

Informar sobre la cobertura alcanzada

II y IV son importantes; I, III y V no lo son.

I, III y V son importantes; II y IV no lo son.

I, II y V son importantes; III y IV no lo son.

III y IV son importantes; I, II y V no lo son.

Los representantes de negocio deciden los enfoques de automatización de la prueba.

Los probadores ayudan a los representantes de negocio a definir la estrategia de prueba.

Los representantes de negocio no forman parte del enfoque de equipo completo.

Los probadores ayudan a los representantes de negocio a crear pruebas de aceptación

Sólo en modelos CVDS secuenciales.

Sólo en modelos CVDS iterativos.

Sólo en modelos CVDS iterativos e incrementales.

En modelos CVDS secuenciales, incrementales e iterativos.

En DGPA, los criterios de aceptación suelen crearse basádose en el formato "dado/cuando/entonces"

En DGPA, los casos de prueba se crean principalmente en la prueba de componente y están orientados al código.

En DGPA, se crean pruebas basadas en criterios de aceptación para impulsar el desarrollo de software correspondiente.

En DGPA, las pruebas se basan en el comportamiento deseado del software, lo que facilita su comprensión por parte de los miembros del equipo.

Revisar los requisitos de usuario antes de que sean aceptados formalmente por los implicados.

Escribir una prueba de componente antes de escribir el código correspondiente.

Ejecutar una prueba de eficiencia de desempeño de un componente durante la prueba de componente.

Redactar un guión de prueba antes de establecer el proceso de gestión de la configuración.

Las retrospectivas son muy populares hoy en día y los clientes agradecerían que las añadiéramos a nuestros procesos.

Organizar retrospectivas ahorrará dinero a la organización porque los representantes de los usuarios finales no proporcionan retroalimentación inmediata sobre el producto.

Los puntos débiles del proceso identificados durante la retrospectiva pueden analizarse y servir como lista de tareas para el programa de mejora continua del proceso de la organización.

Promover el Respeto y el Valor dentro del equipo.

1D, 2B, 3A, 4C

1D, 2B, 3C, 4A

1B, 2A, 3D, 4C.

1C, 2B, 3A, 4D.

Tener una gestión de defectos menos costosa debido a la facilidad de detectar defectos más tarde en el CVDS.

Corregir los defectos encontrados durante la prueba estática es generalmente mucho menos costoso que corregir los defectos encontrados durante la prueba dinámica.

Encontrar defectos de código que no se habrían encontrado con pruebas dinámicas.

Detectar carencias e incoherencias en los requisitos.

Mejora el proceso de prueba para futuros proyectos.

Obliga a los clientes a priorizar sus requisitos en función de los riesgos acordados.

Es la única forma de medir la calidad de los cambios.

Ayuda a evitar malentendidos sobre los requisitos.

Revisión informal.

Revisión guiada.

Revisión técnica.

Inspección.

Los participantes deben dedicar un tiempo adecuado a la revisión.

Dividir los productos de trabajo grandes en partes pequeñas para que el esfuerzo requerido sea menos intenso.

Los participantes deben evitar comportamientos que puedan indicar aburrimiento, exasperación u hostilidad hacia otros participantes.

Los fallos encontrados deben reconocerse, valorarse y tratarse objetivamente.

Los casos de prueba se crean a partir de información de diseño detallada.

Los elementos probados en la sección de código de la interfaz se utilizan para medir la cobertura.

Las técnicas se basan en gran medida en los conocimientos del probador sobre el software y el dominio de negocio.

Los casos de prueba se utilizan para identificar desviaciones con respecto a los requisitos

3

4

5

6

Cada instrucción del código que contiene un defecto se ha ejecutado al menos una vez.

Cualquier juego de prueba que contenga más casos de prueba que su juego de prueba también alcanzará una cobertura de sentencia del 100%.

Cada camino del código se ha ejecutado al menos una vez.

Cada combinación de valores de entrada se ha probado al menos una vez.

Durante la prueba de caja blanca se tiene en cuenta toda la implementación del software.

Las métricas de cobertura de caja blanca pueden ayudar a identificar pruebas adicionales para aumentar la cobertura de código.

Las técnicas de prueba de caja blanca pueden utilizarse en pruebas estáticas.

La prueba de caja blanca puede ayudar a identificar lagunas en la implementación de requisitos.

La predicción de errores implica utilizar sus conocimientos y experiencia sobre los defectos encontrados en el pasado y los errores típicos cometidos por los desarrolladores.

La predicción de errores implica utilizar su experiencia personal en el desarrollo y los errores que cometió como desarrollador.

La predicción de errores requiere que imagine que es el usuario del objeto de prueba y que adivine los errores que podría cometer al interactuar con él.

La predicción de errores requiere replicar rápidamente la tarea de desarrollo para identificar el tipo de equivocación que podría cometer un desarrollador.

Prueba basada en lista de comprobación.

Predicción de errores.

Prueba exploratoria.

Prueba de rama.

Realizar retrospectivas para determinar las necesidades reales de los implicados con respecto a una historia de usuario dada.

Utilizar el formato "dado/cuando/entonces" para describir un ejemplo de condición de prueba relacionada con una historia de usuario determinada

Utilizar la comunicación verbal para reducir el riesgo de que los demás malinterpreten los criterios

Documentar los riesgos relacionados con una historia de usuario dada en un plan de prueba para facilitar la prueba basada en el riesgo de una historia de usuario dada.

Probar si el editor puede guardar el documento después de borrar el contenido de la página.

Probar si el propietario del contenido puede iniciar sesión y realizar actualizaciones del contenido.

Probar si el editor puede programar el contenido editado para su publicación.

Probar si el editor puede reasignar a otro editor para realizar actualizaciones.

Los probadores determinan la prioridad de las historias de usuario que hay que desarrollar.

Los probadores se concentran sólo en los aspectos funcionales del sistema que se va a probar.

Los probadores participan en la identificación detallada del riesgo y en la evaluación del riesgo de las historias de usuario.

Los probadores garantizan la entrega de software de alta calidad mediante un diseño de prueba temprano durante la planificación de la entrega.

9 horas-persona.

14 horas-persona.

11 horas-persona.

10 horas-persona.

1C, 2A, 3B, 4D

1D, 2A, 3C, 4B

1C, 2B, 3D, 4A

1D, 2B, 3C, 4A

Aceptación del riesgo.

Plan de contingencia.

Mitigación del riesgo.

Transferencia del riesgo.

Criterios de aceptación.

Informe de defecto.

Informe de compleción de la prueba.

Gráfico de quemado.

Gestión de la trazabilidad.

Prueba de mantenimiento.

Gestión de la configuración.

Ingeniería de requisitos.

Resultado esperado y resultado real.

Referencias y estado de los defectos.

Entorno de prueba y elemento de prueba.

Prioridad y severidad.

Monitorización y control de prueba.

Análisis y diseño de la prueba.

Compleción de la prueba.

Implementación y ejecución de la prueba.

Puede introducir regresiones desconocidas en producción.

Es posible que no se dediquen suficientes esfuerzos al mantenimiento del producto de prueba.

Puede que no se confíe lo suficiente en las herramientas de prueba y los productos de prueba asociados.

Puede reducir el tiempo asignado a la prueba manual.

Depuración.

Prueba de software.

Educción de requisitos.

Gestión de defectos.

Es correcta. Probar y Aseguramiento de la Calidad significan exactamente lo mismo.

Es correcta. Estas denominaciones pueden utilizarse indistintamente porque tanto la prueba como el aseguramiento de la calidad centran sus actividades en los mismos problemas de calidad.

No es correcto. Las pruebas son algo más; las pruebas incluyen todas las actividades relacionadas con la calidad. El aseguramiento de la calidad se centra en los procesos relacionados con la calidad.

No es correcto. El aseguramiento de la calidad se concentra en los procesos relacionados con la calidad, mientras que las pruebas se centran en demostrar que un componente o sistema es adecuado para su finalidad y en detectar defectos.

La causa raíz.

Un fallo.

Un error.

Un defecto.

Realizar el análisis de impacto de un cambio dará información sobre la compleción de las Pruebas

El análisis de la trazabilidad entre los casos de prueba y los resultados de prueba proporcionará información sobre el nivel de riesgo residual estimado.

Realizar el análisis de impacto de un cambio ayudará a seleccionar los casos de prueba adecuados para la prueba de regresión.

El análisis de la trazabilidad entre la base de prueba, los objetos de prueba y los casos de prueba ayudará a seleccionar los datos de prueba para lograr la cobertura que se asume del objeto de prueba.

El uso de un equipo de prueba independiente permite a la gestión de proyecto asignar la responsabilidad de la calidad del entregable final al equipo de prueba.

Si se puede permitir un equipo de prueba externo a la organización, entonces hay claras ventajas en cuanto a que este equipo externo no se deja influir tan fácilmente por los asuntos de entrega de la gestión de proyectos y la necesidad de cumplir plazos de entrega estrictos.

Un equipo de prueba independiente puede trabajar separado de los desarrolladores, no necesita distraerse con los cambios de requisitos del proyecto y puede limitar la comunicación con los desarrolladores a los informes de defectos a través del sistema de gestión de defectos.

Cuando las especificaciones contienen ambiguedades e incoherencias, se hacen suposiciones sobre su interpretación, y un probador independiente puede ser útil para cuestionar esas suposiciones y la interpretación hecha por el desarrollador.

La prueba dinámica no puede realizarse al principio del CVDS.

La prueba estática no puede realizarse al principio del CVDS.

La planificación de la prueba no puede realizarse al principio del CVDS.

La prueba de aceptación puede realizarse al principio del CVDS.

I, II, IV son ventajas; III, V no lo son.

III, V son ventajas; I, II, IV no lo son.

I, III son ventajas; II, IV, V no lo son.

II, IV, V son ventajas; I, III no lo son.

Funcional, porque los casos de prueba cubren el requisito de negocio del usuario para el sistema.

No funcional, porque mide el rendimiento del sistema.

Funcional, porque los casos de prueba interactúan con la interfaz de usuario.

Estructural, porque necesitamos conocer la estructura interna del programa para medir el tiempo de procesamiento del pedido.

Prueba de mantenimiento.

Prueba de regresión.

Prueba de componente.

Prueba de integración.

I y IV pueden ser revisados; II, III y V no.

I, II, III y IV pueden ser revisados; V no.

I, II, III y V pueden ser revisados; IV no.

III, IV y V pueden ser revisados; I y II no.