La Integración de las Pruebas: En los Modelos de Calidad

En anteriores columnas, hemos planteado la necesidad que tienen las pequeñas y medianas empresas, de adoptar metodologías de desarrollo de software para lograr productos de calidad. En estas columnas hemos comentado también, sobre las dificultades que enfrentan las empresas para poder implantar de manera efectiva, estas metodologías, ya sea por el factor económico o por los recursos humanos, o de tiempo, que la correcta implantación de la metodología representa. Uno de los rubros en los que los se hace evidente esta dificultad, es el área de pruebas de software. De hecho, sé por experiencia que, en la mayoría de las pequeñas empresas, las pruebas se limitan a comprobar la correcta compilación del código y el mínimo de funcionalidad, generalmente en un esquema de code and fix, en donde el código se corrige conforme los errores aparecen, de manera más o menos incierta. En particular, las pruebas son entendidas dentro del marco de pruebas de ejecución de código, perdiendo las ventajas de pruebas de no ejecución, sobre los distintos entregables en las etapas del ciclo de desarrollo de software. Se realizan pruebas sobre módulos del sistema, y pruebas sobre el sistema final, orientadas a la detección de errores de ejecución. Sin embargo, las pruebas son una parte importante de todas las metodologías de calidad de software, y los desarrolladores, deberían invertir un mínimo de esfuerzo en realizarlas durante todo el ciclo de vida de desarrollo. De nuevo, esto implica la disciplina para implantar un modelo de ingeniería de software y, adoptar su metodología.En mi opinión, aún con un modelo reducido de calidad de software, es posible introducir un flujo de trabajo de pruebas que sea efectivo y eficiente. Para ello, el desarrollador debería considerar los siguientes puntos:

1. Las pruebas deben estar basadas en la especificación de requerimientos.
Todos los modelos de calidad de software coinciden, de uno u otro modo, en que la correcta especificación de requerimientos, es de importancia para que el proceso de desarrollo sea lo más fluido y eficiente posible. El levantamiento y especificación de requerimientos, es una tarea complicada a la que en ocasiones no se presta la debida atención. Sin embargo, es posible obtener un buen levantamiento de requerimientos, usando por ejemplo, metodologías ágiles o prototipos. El prototipo o documento de requerimiento inicial, es el primer entregable sobre el que se pueden realizar pruebas. Un prototipo puede servir para realizar la validación del sistema, antes del desarrollo del mismo, evitando costosos errores posteriores por la falta de comprensión de los requerimientos. Así mismo, una revisión del documento de requerimientos, realizada en conjunto por el líder de proyecto y el usuario o dueño del sistema, permite detectar fallas u omisiones en la descripción del sistema a desarrollar. Una revisión de requerimientos, junto con la presentación de uno o dos prototipos, puede realizarse en un par de semanas, y ahorrar tiempo en el desarrollo posterior del proyecto.

2. Las pruebas deben realizarse por un equipo diferente al equipo de programación.
Esto, por supuesto, es lo que indican la mayoría de metodologías de calidad, en el entendido de que es muy difícil que un desarrollador perciba sus propios errores. Después de todo, muchos desarrolladores conocen la experiencia de estar por horas buscando la causa de un error, para que este sea señalado sin dificultad por el compañero de equipo que llega en ese momento. Es claro que la realización de pruebas por equipos distintos, puede ser imposible en empresas pequeñas. En este caso, se puede recurrir a la “revisión por pares” (peer revision) en la que el código es revisado por un segundo programador. Los desarrolladores pueden intercambiar los roles de programador y revisor, a ratos desarrollando su propio código, a ratos revisando el código de un colega, logrando de este modo mayor eficiencia en ambas tareas.

3. Es posible realizar pruebas estáticas tan pronto existen entregables del proyecto.
Es muy importante, romper lo más pronto posible el paradigma de que sólo el código puede probarse. Los diagramas de flujos de datos, diagramas de procesos, diagramas de clases, o cualquier otra herramienta de análisis, puede ser probada, ya sea contra las especificaciones o para verificar su funcionalidad específica. Estas pruebas no toman más de una hora, y pueden ser parte de las tareas a realizar en las juntas del equipo de desarrollo. Del mismo modo, pueden realizarse con bastante antelación, pruebas de usabilidad sobre prototipos e interfaces. Estas pruebas permiten conocer qué tan fácil será que el usuario final adopte, y utilice el sistema; y también pueden detectar flujos de datos faltantes en la especificación.

4. Es posible generar una batería mínima de casos de prueba.
La correcta selección de casos de prueba, es un tema de importancia en toda la bibliografía sobre verificación y validación de software. Las pruebas estáticas realizadas sobre documentos de análisis, aunadas a una sólida especificación de requerimientos (utilizando, por ejemplo, casos de usos) permiten la identificación de un conjunto de casos de prueba básicos. Usando metodologías sencillas de pruebas de software, como el método de particiones equivalentes, es posible obtener los casos de prueba adicionales para verificar la correcta funcionalidad de un producto software. Estos casos de prueba se convierten así, en parte de la documentación del sistema.

Quizá estos cuatro puntos son una versión muy reducida de una metodología de pruebas formales. Pero representan una gran diferencia con respecto a un enfoque code and fix, para proyectos medianos de software, y pueden ser el fundamento para la implantación de estándares de prueba más sólidos. Invito a los lectores a comprobarlo.

Acerca del autor
El Dr. Raúl A. Trejo es profesor investigador del Departamento de Sistemas de Información en el Tecnológico de Monterrey, Campus Estado de México. Sus áreas de especialidad incluyen Ingeniería de Software, Representación del Conocimiento y Algoritmos Computacionales. El Dr. Trejo ha presentado ponencias en diferentes foros nacionales e internacionales. Es miembro fundador de la Asociación de Sistemas de Información de América Latina y el Caribe y coordinador del Centro de Innovación Microsoft en Tecnología de 64 bits.