Metodología de Testing

Metodología de Testing

Especificación

Metodologia_de_Calidad.doc

Versión 1.0.1

30 de septiembre de 2010

Historial de Revisiones

Aprobaciones

Índice

1.        Metodología de Testing        1

1.1.        Objetivo        1

1.2.        Estrategia de Prueba        1

1.3.        Conceptos        2

1.4.        Herramientas involucradas en el proceso de Testing        4

1.4.1.        TestLink        4

1.4.2.        Mantis        5

1.5.        Procedimiento de Pruebas Internas        6

1.5.1.        Roles y responsabilidades        6

1.5.2.        Descripción breve        7

1.5.3.        Preparar Plan de Pruebas        7

1.5.4.        Generar Casos de Prueba        8

1.5.5.        Generar Datos de Prueba        8

1.5.6.        Generar ambiente de testing        9

1.5.7.        Ejecución de Casos de Prueba        9

1.5.8.        Instalación de versión ambiente de testing        10

1.6.        Procedimiento de Pruebas de Aceptación        10

1.6.1.        Roles y responsabilidades        11

1.6.2.        Descripción breve        11

1.6.3.        Instalación en ambiente del cliente        11

1.6.4.        Realizar Pruebas de Aceptación        11

1.6.5.        Actividades de cierre        12

1. Metodología de Testing

1. Objetivo

Evaluar la calidad del producto mediante la aplicación de pruebas concretas, validando que los requerimientos han sido implementados apropiadamente,  documentando y corrigiendo los defectos encontrados en las pruebas realizadas. Las pruebas de un producto software involucran un proceso de verificación y validación.

El propósito de la verificación es asegurar que el producto cumple los requerimientos especificados. Debe satisfacer la interrogante: ¿se está construyendo correctamente el producto? La verificación incluye la verificación del producto y los productos de trabajo intermedios, contra los requerimientos (del cliente y del producto y componentes de producto).

El propósito de la validación es demostrar que un producto o un componente de producto cumplen con el uso para el cual fue creado en su ambiente final. Debe satisfacer la interrogante: ¿se está construyendo el producto correcto? La validación aplica no sólo al producto final, sino también a los productos de trabajo intermedios (descubrimiento temprano de los issues de validación).

1. Estrategia de Prueba

La estrategia de prueba a utilizar comprende la realización de pruebas a lo largo de todo el ciclo de vida del Proyecto. Se puede apreciar la estrategia en la figura que se muestra a continuación:

[pic 1]

Inicialmente las pruebas se focalizan en cada módulo individualmente, asegurando que funciona apropiadamente como una unidad. Después, los módulos deben integrarse o ensamblarse para formar un paquete completo. Finalmente se realiza una serie de pruebas orientadas a asegurar que el software satisfaga todos los requerimientos y a verificar que todos los elementos del sistema se acoplan adecuadamente.

1. Conceptos

Con el propósito de consistencia y claridad para el lector, diversos términos usados a través de este documento son definidos en esta sección:

• Falla: Una falla (failure) ocurre cuando un programa no se comporta adecuadamente. Representa una propiedad del sistema en ejecución.
• Defecto: Un defecto (default) existe en el código. Un defecto puede causar una falla.
• Error: Un error (error o mistake) es una acción humana que resulta en software que contiene un defecto. Un error puede llevar a incluir un defecto en el sistema, haciéndolo fallar.
• Unidad: Componente mínimo compilable, no incluye ningún llamado a un sub-componente.
• Componente: Las definiciones más relevantes son las siguientes:

• Ítem de SW mínimo para el cual se tiene una especificación.
• Parte reemplazable de un sistema, de baja cohesión y no trivial, que cumple una función específica en el contexto de una arquitectura bien definida. Un componente está acorde a un conjunto de interfaces y provee la realización física de dichas interfaces.
• Una unidad es un componente. La integración de 1 o más componentes, es un componente. Un componente puede integrarse a sí mismo si se llama recursivamente. Se dice que dos o más componentes están integrados cuando:

• Han sido compilados, linkeados y cargados conjuntamente.
• Han pasado satisfactoriamente la prueba de integración de la interface entre ellos.

• Prueba Unitaria: Prueba de cada unidad en la que los componentes “llamados” (o componentes de comunicación) son reemplazados por Stubs, simuladores o componentes comprobados. Los componentes que llaman a la unidad son reemplazados por Drivers o super componentes comprobados. La unidad se prueba de manera aislada.
• Prueba de Integración: Prueba que se realiza a medida que los diferentes módulos del sistema se integran en el mismo. Ya se ha realizado la prueba unitaria, de componente o  modular y se supone que todos los módulos son correctos. El objetivo fundamental de esta prueba es comprobar que las interfaces entre los distintos módulos son correctas.
• Prueba de Sistema: Prueba que se realiza cuando se han integrado todos los módulos. Su objetivo es comprobar que el sistema satisface los requerimientos del usuario, tanto los funcionales como los no funcionales.
• Prueba de Aceptación: Prueba que se realiza una vez que el sistema se ha implantado en su entorno real de funcionamiento y su objetivo es demostrar al usuario que el sistema satisface sus necesidades.
• Prueba de Regresión: Prueba cuyo objetivo es comprobar que toda nueva versión de un producto de sw no es de menor calidad que la versión anterior, es decir, que al introducir cambios no se ha reducido la valoración de ninguna de las características de calidad que tenía el producto.
• Caso de Prueba: Conjunto específico de datos y procedimientos asociados desarrollados para un objetivo particular, de manera de probar una sección particular de un programa o de verificar conformidad de un requerimiento específico.
• Cobertura de Pruebas: Cobertura es asegurar que la extensión y profundidad de las pruebas ha sido suficiente para verificar todos los requerimientos (y todos los aspectos de un requerimiento) y las funcionalidades claves. La cobertura “pregunta” lo siguiente:

• ¿Fue suficiente el rango de datos de entrada? ¿Se probaron casos de prueba “buenos” y “malos”? ¿Cuántas condiciones de error fueron probadas? ¿Se verificaron condiciones poco probables (pero posibles)? ¿Se verificaron las divisiones por cero?
• Para requerimientos con múltiples opciones, ¿se probó cada opción con casos de prueba “buenos” y “malos”?
• Si el requerimiento era un requerimiento general (por ejemplo: todos los reportes deben tener numeración de páginas), ¿cuántas pruebas comprobaron específicamente este requerimiento?

• Proceso: Un proceso se define como “un conjunto de actividades interrelacionadas que transforman entradas en salidas”. Las actividades de pruebas ejecutadas en distintos niveles (modular, integración, sistema) deben ser organizadas en conjunto con las personas, herramientas, políticas y métricas en un proceso bien definido, el cual debe ser considerado como parte del ciclo de vida de desarrollo

1. Herramientas involucradas en el proceso de Testing

1. TestLink

TestLink es una herramienta gratuita para la administración de casos de prueba. Es una aplicación web hecha en php por lo cual se requiere tener una máquina con php+MySQL como servidor y los usuarios accederán a TestLink a través de un navegador web. TestLink permite fácilmente crear y gestionar casos de prueba, así como organizarlos en planes de pruebas. Estos planes de pruebas permiten a los miembros del equipo ejecutar casos de prueba y realizar un seguimiento de los resultados de la prueba en forma dinámica, generar informes, traza de requisitos de software, priorizar y asignar tareas.

...