Los procesos de aseguramiento de calidad de un producto de software suelen dividirse en lo que respecta a su componente analítico en pruebas estáticas y dinámicas. La diferencia fundamental entre estos tipos de pruebas, radica en que las pruebas estáticas se centran en evaluar la calidad con la que se está generando la documentación del proyecto, por medio de revisiones periódicas, mientras que las pruebas dinámicas, requieren de la ejecución del software con el fin de medir el nivel de calidad con la que este fue codificado y el nivel de cumplimiento en relación con la especificación del sistema.
Realizar pruebas dinámicas a un producto de software, suele en la mayoría de los casos confundirse con una simple actividad de ejecución de pruebas y reporte de incidencias, sin embargo, para productos de complejidad media en adelante, lo recomendable es implementar de manera formal una metodología de pruebas que se ajuste y acople uniformemente con la metodología de desarrollo seleccionada por la firma desarrolladora.
Para procesos de desarrollo basados en la metodología RUP o métodos tradicionales, implementar una metodología de pruebas es totalmente viable, teniendo en cuenta que estas metodologías están orientadas a la documentación y a la formalización de todas las actividades ejecutadas. Si por el contrario, la firma desarrolladora guía su proceso bajo lineamientos basados en metodologías ágiles, será necesario reevaluar la conveniencia de ejecutar todas las actividades que implica un proceso de pruebas formal, lo que en la mayoría de los casos, conlleva a reducir al mínimo las actividades relacionadas con un proceso de pruebas, circunstancia que naturalmente puede desencadenar en la liberación de productos con bajos niveles de calidad.
Un proceso de pruebas formal, está compuesto, cuando menos por las siguientes 5 típicas etapas:
- Planeación de pruebas.
- Diseño de pruebas.
- implementación de pruebas.
- Evaluación de criterios de salida.
- Cierre del proceso.
Planeación de Pruebas.
Es la etapa en donde se ejecutan las primeras actividades correspondientes al proceso de pruebas y tiene como resultado un entregable denominado plan de pruebas el cual debe estar conformado en cuando menos por aspectos tales como:
- Alcance de la prueba: determina que funcionalidades del producto y/o software serán probadas durante el transcurso de la prueba. Este listado de funcionalidades a probar se extrae con base a un análisis de riesgos realizado de manera previa, que tienen en cuenta variables tales como el impacto que podría ocasionar la falla de una funcionalidad y la probabilidad de falla de una funcionalidad. Producto de este análisis, se cuenta con información adicional que permite determinar además del alcance detallado del proceso de pruebas, la prioridad con la que las funcionalidades deben probarse y la profundidad de las pruebas.
- Tipos de Prueba: en este punto se debe determinar qué tipos de pruebas requeriría el producto. No todos los productos de software requieren la aplicación de todos los tipos de pruebas que existen, por esta razón, es estrictamente necesario que el líder de pruebas se plantee preguntas que le permitan determinar qué tipos de prueba son aplicables al proyecto en evaluación. Los posibles tipos de prueba a aplicar son: pruebas de stress, pruebas de rendimiento, pruebas de carga, pruebas funcionales, pruebas de usabilidad, pruebas de regresión, entre otros.
- Estrategia de Pruebas: teniendo en cuenta que no es viable probar con base a todas las posibles combinaciones de datos, es necesario determinar a través de un análisis de riesgos sobre que funcionalidades debemos centrar nuestra atención. Adicionalmente, una buena estrategia de pruebas debe indicar los niveles de pruebas (ciclos) que aplicaremos y la intensidad o profundidad a aplicar para cada nivel de pruebas definido. En este punto también es importante definir los criterios de entrada y salida para cada ciclo de pruebas a ejecutar.
- Criterios de Salida: entre las partes involucradas en el proceso, se define de manera formal, bajo qué condiciones se puede considerar que una actividad de pruebas fue finalizada. Los criterios de salida se deben definir para cada nivel de pruebas a ejecutar. Algunos ejemplos de criterios de salida que pueden ser utilizados son: porcentaje de funcionalidades de alto riesgo probadas con éxito, número defectos críticos y/o mayores aceptados, etc.
- Otros aspectos: tal y como se realiza en cualquier plan de proyecto, se debe incluir una estimación de tiempos, los roles y/o recursos que harán parte del proceso, la preparación del entorno de pruebas, cronograma base, etc.
Diseño de Pruebas: una vez elaborado y aprobado el plan de pruebas, el equipo de trabajo debe iniciar el análisis de toda la documentación existente con respecto al sistema, con el objeto de iniciar el diseño de los casos de prueba. Los entregables claves para iniciar este diseño pueden ser: casos de uso, historias de usuario, arquitectura del sistema, diseños, manuales de usuario (si existen), manuales técnicos (si existen). El diseño de los casos, debe considerar la elaboración de casos positivos y negativos. Los casos de prueba negativos permiten validar cómo se comporta el sistema ante situaciones atípicas y permite verificar la robustez del sistema, atributo que constituye unos de los requerimientos no funcionales indispensable para cualquier software. Por último, es necesario definir cuáles son los datos de prueba necesarios para la ejecución de los casos de prueba diseñados.
Implementación y Ejecución de Pruebas: la ejecución de pruebas debe iniciar con la creación de los datos de prueba necesarios para ejecutar los casos de prueba diseñados. La ejecución de estos casos, puede realizarse de manera manual o automatizada; en cualquiera de los casos, cuando se detecte un fallo en el sistema, este debe ser documentado y registrado en una herramienta que permita gestionar los defectos (Bug Tracker). Una vez el defecto ha sido corregido por la firma desarrolladora en su respectivo proceso de depuración, es necesario realizar un re-test que permita confirmar que el defecto fue solucionado de manera exitosa. Por último, es indispensable ejecutar un ciclo de regresión que nos permita garantizar, que los defectos corregidos en el proceso de depuración de la firma, no hayan desencadenado otros tipos de defectos en el sistema.
Evaluación de Criterios de Salida: los criterios de salida son necesarios para determinar si es posible dar por finalizado un ciclo de pruebas. Para esto, es conveniente definir una serie de métricas que permitirán al finalizar un proceso de pruebas, comparar los resultados obtenidos contra las métricas definidas, sí los resultados obtenidos no superan la métricas definidas, no es posible continuar con el siguiente ciclo de pruebas.
Existen varios tipos de criterios de salida dentro de los cuales se pueden mencionar: cubrimiento de funcionalidades en general, cubrimiento de funcionalidades críticas para el sistema, Número de defectos críticos y mayores detectados, etc. También es importante aclarar que el proceso de pruebas puede ser suspendido y/o paralizado, debido entre otros, a aspectos relacionados con el presupuesto y la calidad mínima del sistema requerida para el inicio formal de pruebas.
Cierre del proceso: durante este periodo de cierre el cual históricamente se ha comprobado que se le destina muy poco tiempo en la planeación, se deben cerrar las incidencias reportadas, se debe verificar si los entregables planeados han sido entregados y aprobados, se deben finalizar y aprobar los documentos de soporte de prueba, analizar las lecciones aprendidas para aplicar en futuros proyectos, etc.