Repaso

En las pruebas de sistema. Los requisitos funcionales se basan en la definición de requisitos, los procesos de negocio y los casos de uso. Los requisitos no funcionales vienen especificados, entre otras, en la norma ISO 9216. Los requisitos no funcionales suelen venir mejor definidos que los funcionales. No se repiten casos que se hayan ejecutado en pruebas anteriores (componentes, integración…).

Las pruebas estáticas: Requieren la preparación de datos de prueba. Engloban procedimientos de análisis manual del objeto de prueba. Requieren la ejecución del objeto de prueba. Descubren los errores exclusivamente en base a sus efectos.

Respecto a las revisiones: Las inspecciones llevan aparejados modos de proceder altamente informales. Los walkthrough requieren la existencia de un moderador. Las revisiones informales suelen ser iniciadas por el autor. En las revisiones técnicas el autor actúa como moderador.

En cuanto al análisis de valores límite, ¿Cuál es verdad?. La experiencia muestra que los errores son más frecuentes en las regiones límite. Es una técnica útil, sea cual sea la clase de equivalencia. Considera exclusivamente los límites de la clase. Todas las respuestas anteriores son ciertas.

En cuanto a la pruebas referidas al estado, ¿Cuál no es verdad?. Al igual que en la técnica de particiones de equivalencia se consideran las consecuencias de los procesos que ya han tenido éxito sobre el desarrollo posterior. Un elemento de ayuda para la determinación de casos de prueba es la formación de un árbol de transiciones para el objeto de prueba. El estado inicial representa la raíz del árbol. . Los criterios de finalización de pruebas son que cada estado se debe alcanzar al menos una vez y que cada transición de estados se debe alcanzar al menos una vez.

Respecto a la gestión de pruebas, indicar la afirmación incorrecta. Las pruebas sistemáticas de software y la gestión de la calidad disminuyen a corto plazo los costes de desarrollo y mantenimiento. La utilización temprana de la gestión de pruebas minimiza los riesgos en la implantación y permite acortar los tiempos del desarrollo del proyecto. Dentro del ciclo de vida de un producto deben llevarse a cabo diferentes tareas de pruebas. La gestión de pruebas temprana y profesional asegura a largo plazo las inversiones.

Respecto a la planificación de las pruebas. A. Se lleva a cabo una planificación al principio del proyecto. B. Es necesario que se siga estrictamente la planificación establecida para el proyecto. C. Se lleva a cabo una planificación detallada para cada ciclo de prueba. A y C son correctas.

Las herramientas para el análisis de pruebas y objetos de prueba que permiten supervisar y registrar el estado interno de los objetos (ej: utilización de memoria) se denominan: Herramientas para el análisis dinámico. Depuradores. Herramientas para el análisis estático. Herramientas para el análisis ciclomático.

Entre las fases a seguir a la hora de introducir una nueva herramienta no está: El lanzamiento de un piloto. La elaboración del proceso asociado. La formación a los usuarios. La adaptación de procesos o herramientas.

Respecto a las Ventajas e inconvenientes del procedimiento de pruebas referidas al estado, ¿Cuál no es cierta?. Es una buena posibilidad de probar objetos de prueba dependientes del estado. Método apropiado para las pruebas de clases en caso de disponer del ciclo de vida del objeto. Los estados son a menudo muy complejos en su estructura – esto es, quedan determinados por un gran número de parámetros diferentes. La cobertura de todas las transiciones de estado garantiza unas pruebas completas.

Indicar la afirmación incorrecta. En cualquier momento debe ser posible tener en cuenta en la planificación los resultados de las pruebas. El seguimiento y control del éxito de las pruebas ejecutadas se sucede en función de las métricas de pruebas acordadas en el plan de pruebas. Nunca se debe prescindir de pruebas o casos de prueba planificados para compensar el tiempo perdido. El fin de las pruebas se confirma por el gestor de pruebas cuando se han cumplido los criterios de finalización.

La implementación de las pruebas incluye: La generación de casos de prueba. La preparación de los datos de prueba. El establecimiento de las condiciones marco y la determinación de los resultados esperados. Todas las anteriores son correctas.

Entre las ventajas de las revisiones se encuentran: Bajos costes. Aumento de la comunicación. No requiere recursos especializados. Todas las anteriores.

Una técnica de diseño de pruebas puede consistir en: Un proceso de selección de casos de prueba. Un proceso para determinar los resultados esperados. Una forma de medir la calidad del software. Una manera de medir en un plan de prueba que es lo que se tiene que hacer.

La cobertura de código se utiliza como una medida de: Defectos. Análisis de tendencias. Eficacia de las pruebas. Tiempo empleado en pruebas.

¿Cuál de las siguientes afirmaciones es cierta?. Las pruebas de componentes deberían ser de caja negra, las pruebas de sistema deberían ser de caja blanca. Si se encuentran muchos errores en las pruebas, el nivel de confianza de la calidad del software no será muy bueno. Cuanto menos errores encuentren, mejores fueron las pruebas. Cuanto más pruebas se ejecutan, más errores se encontrarán.

Se habla de verificación y validación independiente cuando es: Realizada por el desarrollador. Realizada por los ingenieros de prueba. Realizada por la dirección. Realizada por una entidad externa a la esfera de influencia del proyecto.

El análisis de impacto ayuda a decidir: Cuantas pruebas de regresión se deben hacer en el proyecto o entrega. Los criterios de finalización a aplicar en las pruebas de los proyectos. La estrategia de pruebas en la organización. Las diferentes herramientas para realizar las pruebas de regresión.

Empareja las siguientes fases dentro del ciclo de vida del software con el ciclo de vida de las pruebas. Diseño de alto nivel. Codificación. Diseño de bajo nivel. Requisitos de negocio.

La provisión y gestión de un repositorio con todos los elementos de configuración se llama: Control de la configuración. Estado de la contabilidad. Configuración e identificación. Gestión de incidencias.

Una prueba de regresión: Sólo se correrá una vez. Siempre será automatizada. Comprobará áreas del software sin cambios para ver si han sido afectadas. Comprobará áreas del software cambiadas para ver si han sido afectadas.

¿Que sentencia acerca de la función de una herramienta de análisis estático es Verdadera?. Da información acerca de la calidad del código sin ejecutarlo. Comprueba resultados esperados con los resultados obtenidos. Puede descubrir pérdidas de memoria (memory leaks). Da información acerca de qué código ha sido ejercitado y de cual no.

El análisis estático de código suele identificar todos menos uno de los siguientes problemas. ¿Cuál es?. Código inalcanzable. Variables no declaradas. Fallos en los requisitos. Demasiados pocos comentarios.

¿Cómo difieren las técnicas basadas en la experiencia de las basadas en la especificación?. Dependen de la comprensión del probador de la forma en que el sistema está estructurado más que de un registro documentado de qué debería hacer el sistema. Dependen de tener probadores más viejos más que probadores más jóvenes. Dependen de un registro documentado de qué debería hacer el sistema más que de la visión de una persona concreta. Dependen de la visión de una persona concreta más que de un registro documentado de qué debería hacer el sistema.

De acuerdo con el Glosario ISTQB, ¿a qué nos referimos cuando llamamos a alguien jefe de pruebas (test manager)?. Un jefe de pruebas gestiona un conjunto de líderes de pruebas. Un jefe de pruebas es el jefe de un equipo o equipos de pruebas. Un jefe de pruebas está mejor pagado que un líder de pruebas. Un jefe de pruebas informa a un líder de pruebas.

¿Cuál de los siguientes factores influye en el esfuerzo de pruebas implicado en la mayoría de los proyectos?. Separación geográfica de probador y programadores. Que despidan al jefe de pruebas durante el proyecto. La calidad de la información usada para desarrollar las pruebas. Enfermedad larga imprevista de un miembro del equipo de pruebas.

Considere los siguientes criterios de salida que podrían ser encontrados en un plan de pruebas: I. No hay defectos conocidos críticos para el cliente. II. Todas las interfaces entre componentes han sido probadas. III. 100% de cobertura de código de todas las unidades. IV. Todos los requisitos especificados han sido satisfechos. V. La funcionalidad del sistema coincide con la de los sistemas heredados (legacy) para todas las reglas de negocio. ¿Cuál de las siguientes sentencias es cierta acerca de si estos criterios de salida pertenecen a un plan de pruebas de aceptación?. Todas las sentencias pertenecen a un plan de pruebas de aceptación. Sólo la sentencia I pertenece a un plan de pruebas de aceptación. Sólo las sentencias I, II, y V pertenecen a un plan de pruebas de aceptación. Sólo las sentencias I, IV, y V pertenecen a un plan de pruebas de aceptación.

Durante un periodo temprano de ejecución de las pruebas, un defecto es localizado, resuelto y confirmado como resuelto mediante re-prueba, pero es visto de nuevo más tarde durante una posterior ejecución de pruebas. ¿Cuál de los siguientes es un aspecto de gestión de configuración relacionado con las pruebas que es más probable que haya fallado?. Trazabilidad. Pruebas de confirmación. Control de configuración. Gestión de la documentación de pruebas.

En un informe de incidencia, el probador hace la siguiente afirmación, 'En este punto, espero recibir un mensaje de error explicando el rechazo de esta entrada inválida y pidiéndome que introduzca una entrada válida. En lugar de eso, el sistema acepta la entrada, muestra un reloj de arena entre uno y cinco segundos y finalmente termina anormalmente, dando el mensaje, " tipo de datos Imprevisto: 15. Click para continuar." ' Esta sentencia se encontrará, posiblemente, ¿en cuál de las siguientes secciones de un informe de incidencia IEEE 829 estándar?. Resumen. Impacto. Criterios de paso / fallo del elemento. Descripción de la incidencia.

¿Que herramientas ayudan a soportar pruebas estáticas?. Herramientas de análisis estático y herramientas de ejecución de las pruebas. Herramientas de soporte al proceso de Revisión, herramientas de análisis estático y herramientas de medida de cobertura. Herramientas de análisis dinámico y herramientas de modelado. Herramientas de soporte al proceso de Revisión, herramientas de análisis estático y herramientas de modelado.

Una suite exhaustiva de pruebas debería incluir: Todas las combinaciones de valores de entrada y precondiciones. Todas las combinaciones de valores de entrada y valores de salida. Todas las parejas de valor entrada y precondiciones. Todos los estados y transiciones de estado.

¿Qué es una condición de pruebas?. Una entrada, resultado esperado, pre-condición y post- condición. Los pasos a seguir para llevar al sistema a un punto dado. Algo que puede ser probado. Un estado específico del software, p. ej. antes de que pueda lanzarse una prueba.

¿Qué son las pruebas exploratorias?. El proceso de anticipar o conjeturar dónde pueden aparecer defectos. Un enfoque sistemático para identificar clases de entrada equivalente específicas. Las pruebas llevadas a cabo por un ingeniero certificado. Diseño concurrente de pruebas, ejecución de pruebas, registro de pruebas y aprendizaje.

Un plan de pruebas es escrito específicamente para describir un nivel de pruebas en el que la meta principal es establecer confianza en el sistema. ¿Cuál de los siguientes es un nombre adecuado para este documento?. Plan maestro de pruebas. Plan de pruebas de sistema. Plan de pruebas de Aceptación. Plan de proyecto.

Un plan de pruebas incluía las siguientes causas entre los criterios de salida: # Las Pruebas de Sistema continuarán hasta que todo riesgo del producto significativo haya sido cubierto con la extensión especificada en el documento de análisis de riesgos de producto. # Las Pruebas de Sistema continuarán hasta que no queden defectos de corrección obligatoria asociados a cualquier riesgo de producto especificado en el documento de análisis de riesgos de producto. Durante la ejecución de las pruebas, el equipo de pruebas detecta 430 defectos de corrección obligatoria antes del despliegue y todos los defectos de corrección obligatoria son resueltos. Después del despliegue, los clientes encuentran 212 defectos nuevos, ninguno de los cuales fue detectado durante las pruebas. Esto significa que sólo el 67% de los defectos importantes se han encontrado antes del despliegue, un porcentaje que está muy por debajo del promedio en tu industria. Te han pedido que encuentres la causa raíz del alto número de fallos en campo. Considere la siguiente lista de explicaciones: I. No todas las pruebas planificadas para los riesgos del producto significativos se ejecutaron. II. La organización tiene expectativas poco realistas del porcentaje de defectos que las pruebas puede encontrar. III. Un aspecto relacionado con el control de versiones ha dado lugar al despliegue de una versión de software que se utilizó al principio de las pruebas. IV. El análisis de riesgos de producto ha fallado al identificar los riesgos desde el punto de vista del cliente. V. El análisis de riesgos del producto no fue actualizado durante el proyecto a medida que se iba disponiendo de nueva información. ¿Cuál de las siguientes sentencias indican que explicaciones son posibles causa raíz?. II, III y IV son posibles explicaciones, pero I y V son no posibles. Las cinco son posibles explicaciones. I, IV y V son posibles explicaciones, pero II y III son no posibles. III, IV y V son posibles explicaciones, pero I y II son no posibles.