Herramientas de Soporte de Pruebas (K2) - Herramientas de soporte para las pruebas estáticas (K1)

Objetivos:

1. Clasificar distintos tipos de herramientas de pruebas en función de su objetivo y de las actividades del proceso de pruebas fundamental y del ciclo de vida del software (K2).
2. Explicar el término herramienta de pruebas y el objetivo de las herramientas de soporte de pruebas (K2).

Términos: Herramienta de gestión de la configuración, herramienta de cobertura, herramienta de depuración, herramienta de análisis dinámico, herramienta de gestión de incidencias, herramienta de pruebas de carga, herramienta de modelado, herramienta de monitorización, herramienta de pruebas de rendimiento, efecto sonda, herramienta de gestión de requisitos, herramienta de revisión, herramienta de seguridad, herramienta de análisis estático, herramienta de pruebas de estrés, comparador de pruebas, herramienta de preparación de datos de prueba, herramienta de diseño de pruebas, herramienta de ejecución de pruebas, herramientas de gestión de pruebas, herramienta de marco de trabajo de pruebas unitarias.

Antecedentes.

Las herramientas de prueba estática proporcionan una manera efectiva de localizar más defectos en una etapa más temprana del proceso de desarrollo.

Herramientas de revisión 

Estas herramientas son útiles en los procesos de revisión, listas de comprobación y directrices de revisión, y se utilizan para almacenar y comunicar comentarios de revisión, informes sobre defectos y esfuerzos. Asímismo, pueden servir de ayuda para revisiones en línea de equipos grandes o geográficamente dispersos.

Herramientas de análisis estático (D)

Estas herramientas ayudan a los desarrolladores y probadores a localizar defectos antes de realizar pruebas dinámicas proporcionándoles soporte para aplicar las normas de codificaicón (incluyendo la codificación segura), el análisis de las estructuras y las dependencias, Asímismo, pueden útiles para planificar o analizar los riesgos facilitando métricas para el código (por ejemplo complejidad).

Herramientas de modelado (D)

Estas herramientas se utilizan para validar modelos de software (tales como, modelo de datos físicos (PDM) de una base de datos relacional) enumerado inconsistencias y localizando defectos. Estas herramientas a menudo sirven para generar algunos casos de prueba basados en un modelo.

Herramientas de Soporte de Pruebas (K2) - Herramientas de soporte para la gestión de pruebas (K1)

Objetivos:

1. Clasificar distintos tipos de herramientas de pruebas en función de su objetivo y de las actividades del proceso de pruebas fundamental y del ciclo de vida del software (K2).
2. Explicar el término herramienta de pruebas y el objetivo de las herramientas de soporte de pruebas (K2).

Términos: Herramienta de gestión de la configuración, herramienta de cobertura, herramienta de depuración, herramienta de análisis dinámico, herramienta de gestión de incidencias, herramienta de pruebas de carga, herramienta de modelado, herramienta de monitorización, herramienta de pruebas de rendimiento, efecto sonda, herramienta de gestión de requisitos, herramienta de revisión, herramienta de seguridad, herramienta de análisis estático, herramienta de pruebas de estrés, comparador de pruebas, herramienta de preparación de datos de prueba, herramienta de diseño de pruebas, herramienta de ejecución de pruebas, herramientas de gestión de pruebas, herramienta de marco de trabajo de pruebas unitarias.

Antecedentes.

Las herramientas de gestión son aplicables a todas las actividades de pruebas durante todo el ciclo de vida del software.

Herramientas de gestión de pruebas

Estas herramientas ofrecen para ejecutar pruebas, localizar defectos y gestionar requisitos, además de dar soporte al análisis cuantitativo y a la elaboración de informes sobre los objetos de prueba. Asímismo ayudan a localizar los objetos de prueba conforme a las especificaciones de requisitos y pueden tener una capacidad de control de versión independiente o una interfaz conforme a una externa.

Herramientas de gestión de requisitos

Estas herramientas almacenan sentencias de requisitos, almacenan los atributos de los requisitos (incluida la prioridad), proporcionan identificadores únicos y facilirtan la localización de los requisitos para pruebas individuales. Asímismo, estas herramientas pueden ayudar a identificar la ausencia o la inconsistencia de requisitos.

Herramientas de gestión de incidencias (Herramientas de seguimiento de defectos)

Estas herramientas almacenan y gestionan informes de incidencias, es decir, defectos, fallos, cambio de peticiones o problemas y anomalías percibidas y , ayudan a gestionar el ciclo de vida de las incidencias , y alternativamente contribuyen al análisis estático.

Herramientas de gestión de la configuración

A pesar de no contribuir estrictamente herramientas de prueba, estas herramientas son necesarias para le almacenamiento y la gestión de versiones de productos de soporte de software asociado, especialmente a la hora de configurar más de un entorno de hardware/software en términos de versiones del sistema operativo, compiladores, navegadores, etc.

30 A tool that supports traceability, recording of incidents or scheduling of tests is called:
a) a dynamic analysis tool
b) a test execution tool
c) a debugging tool
d) a test management tool
e) a configuration management tool-->OK

30 Una herramienta que soporta la trazabilidad , registro de incidentes o la programación de pruebas se llama :
a) una herramienta de análisis dinámico
b ) una herramienta de ejecución de la prueba
c ) una herramienta de depuración
d ) una herramienta de gestión de pruebas

e) una herramienta de gestión de la configuración-->OK

Herramientas de Soporte de Pruebas (K2) - Clasificación de herramientas de pruebas (K2)

Objetivos:

1. Clasificar distintos tipos de herramientas de pruebas en función de su objetivo y de las actividades del proceso de pruebas fundamental y del ciclo de vida del software (K2).
2. Explicar el término herramienta de pruebas y el objetivo de las herramientas de soporte de pruebas (K2).

Términos: Herramienta de gestión de la configuración, herramienta de cobertura, herramienta de depuración, herramienta de análisis dinámico, herramienta de gestión de incidencias, herramienta de pruebas de carga, herramienta de modelado, herramienta de monitorización, herramienta de pruebas de rendimiento, efecto sonda, herramienta de gestión de requisitos, herramienta de revisión, herramienta de seguridad, herramienta de análisis estático, herramienta de pruebas de estrés, comparador de pruebas, herramienta de preparación de datos de prueba, herramienta de diseño de pruebas, herramienta de ejecución de pruebas, herramientas de gestión de pruebas, herramienta de marco de trabajo de pruebas unitarias.

Antecedentes.

Hay varias herramientas que dan soporte a distintos aspectos de las pruebas, Las herramientas pueden clasificarse en base a distintos criterios, tales como el objetivo, comercial/libre/fuente abierta/"shareware", tecnología utilizada, etc, En este programa de estudio, las herramientas se clasifican en función de las actividades de pruebas a las que dan soporte.

Algunas herramientas dan soporte a una actividad de manera clara, mientras que otras pueden dar soporte a más de una actividad, pero se clasifican  dentro de la actividad a la que están más estrechamente vinculada, pero se clasifican dentro de la actividad a la están más estrechamente vinculadas. Las herramientas procedentes de un único proveedor, especialmente aquellas que han sido diseñadas para funcionar juntas, pueden incluirse en un sólo paquete.

Algunos tipos de herramientas de prueba pueden ser intrusivos, es decir, pueden afectar al resultado real de la prueba. Así por ejemplo, los tiempos reales pueden diferir a las instrucciones adicionales que la herramienta ejecutada , o incluso puede obtenerse una medida distinta de cobertura de código. La consecuencia del uso de herramientas intrusivas se denomina efecto sonda.

Algunas herramientas ofrecen un soporte más adecuado para los desarrolladores (como por ejemplo, las herramientas que se utilizan durante las pruebas de componente y de integración de componentes). Estas herramientas aparecen marcadas con el símbolo "(D)") en la lista a continuación.

Herramientas de Soporte de Pruebas (K2) - Tipos de herramientas de pruebas (K2)

Objetivos:

1. Clasificar distintos tipos de herramientas de pruebas en función de su objetivo y de las actividades del proceso de pruebas fundamental y del ciclo de vida del software (K2).
2. Explicar el término herramienta de pruebas y el objetivo de las herramientas de soporte de pruebas (K2).

Términos: Herramienta de gestión de la configuración, herramienta de cobertura, herramienta de depuración, herramienta de análisis dinámico, herramienta de gestión de incidencias, herramienta de pruebas de carga, herramienta de modelado, herramienta de monitorización, herramienta de pruebas de rendimiento, efecto sonda, herramienta de gestión de requisitos, herramienta de revisión, herramienta de seguridad, herramienta de análisis estático, herramienta de pruebas de estrés, comparador de pruebas, herramienta de preparación de datos de prueba, herramienta de diseño de pruebas, herramienta de ejecución de pruebas, herramientas de gestión de pruebas, herramienta de marco de trabajo de pruebas unitarias.

Antecedentes.
Las herramientas que se utilizan pueden en una o más actividades de soporte de prueba. Entre las que se encuentran:

1. Las herramientas que se utilizan directamente en las pruebas, como herramientas de ejecución de pruebas, las herramientas de generación de datos de prueba y las herramientas de comparación  de resultados.
2. Las herramientas que ayudan a gestionar el proceso de pruebas, como las que sirven para gestionar pruebas, resultados de pruebas, resultados de pruebas, datos requisitos, incidencias, defectos, etc., y para elaborar informes y monitorizar la ejecución de pruebas. 
3. Las herramientas que se utilizan en la fase de reconocimiento, o en otras palabras: exploración (por ejemplo, herramientas de monitorizan la actividad de archivos de una aplicación).
4. Cualquier herramienta que contribuye al proceso de pruebas (en este sentido, una hoja de datos también se considera una herramienta de prueba).

Las herramientas de soporte de pruebas pueden tener uno o más de los siguientes objetivos, en función del contexto:

• Mejorar la eficiencia de las tareas de pruebas automatizando tareas repetitivas o dando soporte a las actividades de pruebas manuales, como la planificación, el diseño, la elaboración de informes y la monitorización de pruebas.
• Automatizar aquellas actividades que requieren muchos recursos si se hacen de forma manula (como por ejemplo, las pruebas estáticas).
• Automatizar aquellas actividades que no pueden ejecutarse de forma manual (como por ejemplo , pruebas de rendimiento a grana escala de aplicaciónes cliente-servidor).
• Aumentar la fiabilidad de las pruebas (por ejemplo, automatizando las comparaciones de grandes ficheros de datos y simulando comportamientos).

El término "marco de trabajo de pruebas" se utiliza a menudo en el sector y puede tener, como mínimo, cualquier de los tres siguientes significados:

1. Librerías de pruebas reutilizables y ampliables que pueden utilizarse para crear herramientas de pruebas (también conocido como arnés de pruebas).
2. Un tipo de diseño de automatización  de pruebas (por ejemplo, guiadas por datos o guiadas por palabras clave).
3. Proceso general de ejecución de las pruebas.

A efectos de este, término "marcos de trabajo de pruebas" se utilizan en sus dos primeros significados.

Pregunta de examen:

16 The place to start if you want a (new) test tool is:
a) Attend a tool exhibition
b) Invite a vendor to give a demo
c) Analyze your needs and requirements-->OK
d) Find out what your budget would be for the tool
e) Search the internet

16 El lugar para empezar si quieres un ( nuevo) herramienta de prueba es:
a) Asistir a una exposición de herramientas
b ) Invitar a un proveedor para dar una demostración
c ) Analizar sus necesidades y requerimientos-->OK
d ) Averigüe lo que su presupuesto sería para la herramienta
e) Buscar en la Internet

17 When a new testing tool is purchased, it should be used first by:
a) A small team to establish the best way to use the tool
b) Everyone who may eventually have some use for the tool-->OK
c) The independent testing team
d) The managers to see what projects it should be used in
e) The vendor contractor to write the initial scripts

17 Cuando se compra una nueva herramienta de prueba , que debe ser usado por primera vez por :
a) Un pequeño equipo para establecer la mejor manera de utilizar la herramienta
b ) Todas las personas que pueden llegar a tener algún uso para la herramienta-->OK
c ) El equipo de pruebas independiente
d ) Los administradores para ver qué proyectos se debe utilizar en
e) El contratista proveedor para escribir los guiones iniciales

21 Given the following types of tool, which tools would typically be used by developers and
which by an independent test team:
i. static analysis
ii. performance testing
iii. test management
iv. dynamic analysis
v. test running
vi. test data preparation
a) developers would typically use i, iv and vi; test team ii, iii and v
b) developers would typically use i and iv; test team ii, iii, v and vi-->OK
c) developers would typically use i, ii, iii and iv; test team v and vi
d) developers would typically use ii, iv and vi; test team I, ii and v
e) developers would typically use i, iii, iv and v; test team ii and vi


21 Teniendo en cuenta los siguientes tipos de herramienta , cuales herramientas podrían ser utilizado por desarrolladores y cuales por un equipo de pruebas independiente :
i . análisis estático -->desarrolladores
ii . Pruebas de rendimiento -->testing
iii . gestión de pruebas -->testing
iv . Análisis Dinámico--> desarrolladores
v . prueba de funcionamiento-->testing
vi . preparación de datos de prueba-->testing

a) los desarrolladores podrían usar I, IV y VI ; el equipo de pruebas II, III y V
b) Los desarrolladores podrían usar i y iv; el equipo de pruebas ii, iii, v and vi -->OK
c) Los desarrolladores podrían usar i, ii, iii y iv; el equipo de pruebas v and vi
d) Los desarrolladores podrían usar i, iii, iv y v; el equipo de pruebas ii and vi

25 A typical commercial test execution tool would be able to perform all of the following
EXCEPT:
a) generating expected outputs
b) replaying inputs according to a programmed script
c) comparison of expected outcomes with actual outcomes
d) recording test inputs
e) reading test values from a data file

25 Una herramienta de ejecución de la prueba comercial típico sería capaz de realizar todo lo siguiente EXCEPTO:

a) generar resultados esperados
b) reproducir entradas de acuerdo a un guión programado
c) la comparación de los resultados previstos con los resultados reales
d) grabación de los imput de las pruebas
e) valores de la prueba de lectura de un archivo de datos

Gestión de pruebas (K3) - Gestión de Incidencias (K3).

Objetivos:

1. Reconocer el contenido de un informe de incidencias de conformidad con la "Norma para la documentación de prueba de software" (IEEE Std 829-1998) (K1).
2. Redactar un informe de incidencias sobre la observación de un fallo durante el proceso de pruebas (K3)

Términos: Registro de incidencia, gestión de incidencias, informe de incidencias..

Antecedentes.

Dado que uno de los objetivos de las pruebas es la detección de defecto, las discrepancias entre los resultados reales y los resultados esperados deben registrarse como incidencias.
Todas las incidencias deben ser investigadas, ya que algunas pueden constituir defectos. A continuación, se define las acciones adecuadas para eliminar las incidencias y los defectos.
Las incidencias y los defectos se rastrean desde su identificación y clasificación hasta la corrección y confirmación de su solución. Con vistas a gestionar todas las incidencias hasta su compleción, la organización , debe establecer un proceso de gestión de incidencias y normas para su clasificación.
Las incidencias pueden surgir durante el desarrollo, la revisión, las pruebas o el uso de un producto de software. Asímismo, pueden surgir por problemas en el código o en el sistema de funcionamiento, o en cualquier tipo de documentación que incluya requisitos, documentos de desarrollo, documentos de prueba e información de usuario, como guías de ayuda o instalación.
Los informes de incidencias tienen los siguientes objetivos:

• Facilitar feedback sobre el problema a los desarrolladores y demás partes implicadas permitiendo su identificación, aislamiento y corrección, según proceda.
• Proporcionar a los líderes de prueba un medio de seguimiento de la calidad del sistema probado y del progreso de las pruebas.
• Aportar ideas para la mejora del proceso de pruebas.

El informe de incidencias pueden incluir los siguientes detalles:

• fecha de expedición, organización emisora y autor.
• Resultados esperados y resultados reales.
• Identificación del elemento de prueba (elemento de configuración) y entorno.
• Proceso del ciclo de vida del software o del sistema en el que se ha observado la incidencia.
• Descripción de la incidencia para permitir su reproducción y resolución, incluyendo registros, volcados de bases de datos o pantallazos.
• Alcance do grado de impacto en los intereses de las partes interesadas.
• Gravedad del impacto en el sistema.
• Urgencia/prioridad de su corrección.
• Estado de la incidencia (por ejemplo, abierta, diferida, duplicada, esperando corrección, corregida esperando la repetición de las pruebas, cerradas).
• Conclusiones, recomendaciones y autorizaciones.
• Aspectos globales, como otras áreas que pueden verse afectadas por un cambio derivado de la incidencia.
• Historial del cambio, como la secuencia de acciones adoptadas por los miembros del equipo de proyecto por lo que respecta a la incidencia para aislarla y confirmarla como corregida.
• Referencias, incluyendo la identidad de la especificación de caso de prueba que puso de manifiesto el problema.

La estructura de los informes de incidencias se aborda en la "Norma para la documentación de prueba de software" (IEEE Std 829-1998). 

Pregunta de examen:

31 What information need not be included in a test incident report:
a) how to fix the fault-->NOK
b) how to reproduce the fault-->OK
c) test environment details-->OK
d) severity, priority-->OK
e) the actual and expected outcomes-->OK

31 ¿Qué información no debe figurar en un informe del incidente de prueba :
a) cómo arreglar el fallo-->NOK
b ) la forma de reproducir el fallo-->si deben ir
c ) detalles del entorno de prueba-->si deben ir
d ) la gravedad , la prioridad--->si deben ir
e) los resultados reales y esperados--> si deben ir

Gestión de pruebas (K3) - Riesgos y Pruebas (K2) - Riesgos de producto (K2).

Objetivos:

1. Describir un riesgo como un posible problema que amenazaría la consecución de uno o más objetivos de proyecto de las partes interesadas (K2).
2. Recordar que el nivel de riesgo viene determinado por la probabilidad (de suceder) y el impacto (daño resultante si llega a suceder) (K1).
3. Distinguir entre riesgos de proyecto y producto (K2).
4. Reconocer los riesgos típicos de producto y proyecto (K2).
5. Reconocer los riesgos típicos de producto y proyecto (K1).
6. Describir, mediante ejemplos, cómo puede utilizarse el ánalisis de riesgos y la gestión de riesgos para la planificación de pruebas (k2).

Términos: Rieasgo d producto, riesgo de proyecto, pruebas basadas en riesgos.

Antecedentes.
Las posibles áreas de fallo (eventos futuros adversos o peligros) en el software o sistema se conocen como riesgos de producto, y que suponen un riesgo para la calidad del producto.
Entre dichos riesgos se encuentran:

• El software entregado es proclive a los fallos.
• La posibilidad de que el software/hadware pueda dañar a un individuo o a una empresa.
• Malas características del software (por ejemplo, funcionalidad, fiabilidad, usabilidad y rendimiento). 
• Mala integridad y calidad de los datos (por ejemplo, problemas de migración de datos, problemas de conversión de datos, problemas de transporte de datos, violación de estándares de datos).
• El software no realiza las funciones previstas.

Los riesgos sirven para decidir dónde empezar las pruebas y dónde probar más; las pruebas sirven para reducir el riesgo de que suceda un efecto adverso, o para reducir el impacto del mismo.
Los riesgos de producto constituyen un tipo especial de riesgo para el éxito de un proyecto.
El hecho de realizar pruebas a modo de actividad de control del riesgo proporciona feedback sobre el riesgo residual midiendo la efectividad de la eliminación de los defectos críticos y los planes de contingencia.
 El enfoque basado en el riesgo en as pruebas ofrece oportunidades proactivas de reducir los niveles de riesgo de producto, empezando en las etapas iniciales del un proyecto. Este enfoque implica la identificación de riesgos de producto y su uso en la planificación de las pruebas y especificación de control, preparación y ejecución de las pruebas. En un enfoque basado en el riesgo, los riesgos identificados puede utilizarse para:

• Establecer las técnicas de pruebas a emplear.
• Establecer el alcance de las pruebas a ejecutar.
• Priorizar las pruebas en un intento por identificar los defectos críticos lo antes posible.
• Establecer si podría utilizarse alguna actividad no de prueba para reducir el riesgo (por ejemplo, impartir formación a diseñadores sin experiencias). 

Las pruebas basadas en riesgos se basan en el conocimiento colectivo y en la comprensión de las partes interesadas del proyecto para establecer los riesgos y los niveles de pruebas necesarios para abordar dichos riesgo.
Con vistas a garantizar que la posibilidad de fallo de un producto es mínimo, las actividades de gestión del riesgo establecen un enfoque disciplinado para:

• Evaluar (y re- evaluar de manera regular) qué puede fallar (riesgos).
• Establecer qué riesgos son importante tratar.
• Implementar acciones para abordar dichos riesgos.

Además, las pruebas pueden contribuir a identificar nuevos riesgos, pueden ayudar a establecer qué riesgos deben reducirse y pueden reducir la incertidumbre sobre los riesgos.

Gestión de pruebas (K3) - Riesgos y Pruebas (K2) - Riesgo de Proyecto (K2).

Objetivos:

1. Describir un riesgo como un posible problema que amenazaría la consecución de uno o más objetivos de proyecto de las partes interesadas (K2).
2. Recordar que el nivel de riesgo viene determinado por la probabilidad (de suceder) y el impacto (daño resultante si llega a suceder) (K1).
3. Distinguir entre riesgos de proyecto y producto (K2).
4. Reconocer los riesgos típicos de producto y proyecto (K2).
5. Reconocer los riesgos típicos de producto y proyecto (K1).
6. Describir, mediante ejemplos, cómo puede utilizarse el ánalisis de riesgos y la gestión de riesgos para la planificación de pruebas (k2).

Términos: Rieasgo d producto, riesgo de proyecto, pruebas basadas en riesgos.

Antecedentes.
El riesgo puede definirse como la oportunidad de un evento, peligro, amenaza o situación que sucede y tiene como resultados consecuencias no deseadas o un problema potencial. El nivel de riesgo vendrá determinado por la probabilidad de que ocurra en un evento adverso y su impacto (el daño resultante de dicho evento).

Los riesgos de proyecto son los riesgos relativos a la capacidad del proyecto de lograr sus objetivos, tales como:

Factores de organización

• Aptitudes, formación y falta de personal.
• 
  
• Aspectos de personal.
• Aspectos políticos, tales como:
•                  Problemas con la forma en la que los porbadores comunican sus necesidades                  y los resultados de las pruebas.
•                  Incapacidad del equipo de hacer un seguimiento de la información encontrada                  durante las pruebas y revisiones (por ejemplo, no se mejora el desarrollo y las                   prácticas de pruebas).
• Actitud indebida o falsas expectativas ante las pruebas (por ejemplo, no valorar el valor de detectar defectos durante las pruebas).

Aspectos técnicos

• Problemas para definir los requisitos adecuados.
• La medida en que no pueden cumplirse los requisitos dadas las limitaciones existentes.
• El entorno de pruebas no está listo a tiempo.
• Demora en la conversión de datos, planificación y desarrollo de migración y conversión de datos de prueba/ herramientas de migración.
• Baja calidad del diseño, código, datos de configuración, datos de prueba y pruebas.

Aspectos de proveedores:

• Fallos de terceros.
• Aspectos contractuales.

A la hora de analizar, gestionar y mitigar estos riesgos, el jefe de pruebas debe seguir principios de gestión de proyectos bien establecidos. La "Norma de Documentación de prueba de Software" (Norma IEEE 829-1998) esboza los planes de prueba y exige que se indiquen los riesgos y contingencias.