Normalmente, el testing está considerado como parte del Ciclo de Vida de Desarrollo de cualquier aplicación (Requisitos, análisis & diseño, implementación, testing y deployment), pero el testing, a su vez, tiene su propio ciclo de vida. Dependiendo de la organización, este ciclo puede tener más o menos fases, pero acontinuación comentaré las fases que son siempre comunes.

A grandes rasgo, podemos decir que el ciclo de vida del Software Testing incluye las siguientes fases:

1. Planificación.
2. Análisis
3. Diseño
4. Ejecución
5. Ciclos
6. Pruebas Finales e Implementation
7. Producción

¿En que fase del ciclo de vida deben comenzar las pruebas?
Lo antes posible. Si dividimos el ciclo de desarrollo en cuatro etapas: Inicio, Elaboración, Construcción y Transición…el equipo de Quality Assurance debería comenzar sus labores entre la fase de Inicio y Elaboración. Es recomendable que al menos el responsable del equipo de calidad asista a la reuniones de toma de requisitos.



1. Planificación de las pruebas (Fase de definición del Producto):
La fase de planificación de pruebas significa redactar el Test Plan ó Plan de Pruebas. El Test Plan es un documento a alto nivel que describe la estrategias a seguir durante el desarrollo de las pruebas.

Contenidos de un Test Plan :
+ Alcance de las pruebas.
+ Comienzo y fin (planificación)
+ Estrategias (Black Box, White Box, etc.)
+ Niveles de Pruebas (Integration testing, Regression testing, etc.)
+ Limitaciones
+ Riesgos
+ Revisiones y entregables.
+Técnicas de Pruebas (Boundary Value Analysis, Equivalence Partitioning, etc.)
Herramientas para realizar las pruebas (Automáticas, carga, integración co
+ Reporting (How would bugs be reported)
+ Hitos
+ Métricas
+ Recursos y planes de formación
+ Tareas y responsabilidades

Estas son sólo algunos de los contenidos de un Plan de pruebas aunque muchas veces varía dependiendo de la empresa. Hay algunas plantillas interesantes en internet, como la de la IEEE.

2.Análisis de pruebas (Fase de Documentación)
La fase de análisis es una extensión de la fase del planificación. Mientras que la fase de planificación es a más alto nivel, la fase de análisis es donde se comienza a documentar los planes detallados. Se comienza a analizar los casos de prueba:

+ Revisión de los Inputs: Se consideran, el documento de especificación de requisito y otros documentos de planificación del proyecto…mientras, el plan de pruebas se rompe en pequeñas partes que serán los futuros casos de prueba.

+ Formatos: Generalmente en esta fase se crea una matriz de validación basada en los requisitos. Estas matrices nos ayudarán a la hora de ejecutar los test cases. También, usando alguna de las herramientas de planificación de proyectos que hay en el mercado (phpcollab, MS project, gantt…) creamos la planificación de las pruebas basándonos en cada uno de los hitos del plan de proyecto. Las métricas a utilizar, también se diseñan en esta fase.

+ Test Cases: ó casos de prueba. Siguiendo la matriz de validación y otros documentos de entrada (inputs), se escriben los test cases. Comenzamos también a vincular los requisitos con cada test case.

+ Automatización: Mientras se crean test cases, se identifican los casos que deben ser automatizados. También se identifican las áreas para las pruebas de rendimineto, de carga y de stress.

+ Plan de Regresión: Los ciclos de pruebas, es decir, número de veces que se probará de nuevo la aplicación para verificar que los defectos encontrados no han introducido nuevos errores.

3. Diseño de pruebas:
Tenemos que darnos cuenta que el ciclo de vida de pruebas transcurre en paralelo al de desarrollo. Así, una vez que hayamos llegado a esta fase (el equipo de desarrollo probablemente habrá comenzado a escribir las primeras líneas de código) comenzaremos el diseño.

Durante esta fase todos los planes, test cases, etc… de la fase de análisis son revisados y finalizados. E

Nuevos test cases puden ser añadidos y se realiza el documento de gestión de riesgos. También es el momento para hacer los scripts de pruebas automaticas (nuevos ó updates de los ya existentes). Finalmente, los informes de pruebas, especialmente los informes sobre pruebas unitarias.

4. Ejecución de las pruebas:
En este momento el equipo de desarrollo tiene una versión estable y lista para testear. Lo más recomendable es hacer un test de cualificación de la versión (qualification testing) para evaluar que la aplicación es lo suficientemente estable para comenzar la ejecución de las pruebas. De nada sirve comenzar una ronda de test si al cabo de cinco golpes de ratón la aplicación rompe. Tiene que tener un mínimo de estabilidad.

Una vez terminado el “Qualification”, los ingenieros de pruebas ya pueden comenzar a ejecutar el plan de test. Así como los test automáticos (si los hubiera), unit testing, revisiones de código, performance….etc.

Para llevar el seguimiento de la ejecución de los test cases podemos utilizar alguna de las herramientas comerciales que hay en el mercado ó utlizar una matriz de excel donde iremos apuntado nuestros PASSED o FAILED (OK or NOT).

5. Ciclo de pruebas (Regresión):
En este momento del ciclo al menos alguna ronda de test ya se habrá ejecutado y algunos issues se habrán reportado. Una vez que el equipo de desarrollo ha arreglado los defectos, la segunda ronda de pruebas comienza. Esta nueva ronda de pruabas podría solamente centrarse en las areas ó funcionalidades que han sido arregladas. Pero también podría ser regresión testing, donde la aplicación es testeada nuevamente para verificar su correcto funcionamiento y que el arreglo de los defectos no ha afectado otras partes del código.

Pruebas —> Reporte de Defectos —> Arreglo de Defectos (y mejoras) —> Nueva ronda de Pruebas

Aquí es donde pruebas automáticas pueden ser de gran ayuda para repetir el mismo test case una y otra vez.

Durante esta fase es importante revisar el documento de requisitos (CRD) y el Project Plan por si han habido modificaciones.

Referencias:
+ UML (The Unified Software Development Process) ISBN 0-201-57169-2

Be Sociable, Share!