Pruebas del Sistema

El Equipo de Proyecto comprobará cada componente que va generando para detectar posibles errores y evitar que éstos se reproduzcan en componentes o módulos posteriores. Además, cada vez que se implemente la comunicación entre dos o más módulos que estén integrados, el equipo de proyecto comprobará dicha integración. De este modo es más sencillo detectar y corregir los errores que si el sistema se encuentra totalmente desarrollado y todos sus módulos integrados. Para ello, deberá realizar las siguientes pruebas:

• Pruebas unitarias. Conjunto de pruebas que comprueban el correcto funcionamiento de cada componente de código por separado. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Posteriormente, con las pruebas de integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión. Para la ejecución de las pruebas unitarias se deberá utilizar una herramienta que automatice el proceso, por ejemplo, JUnit. Se propone la siguiente plantilla como ayuda a la definición de las pruebas unitarias.
• Pruebas de integración. Conjunto de pruebas que verifican la correcta integración entre todos los componentes/módulos del sistema. La necesidad de realizar las pruebas de integración viene dada por el hecho de que los módulos que forman un programa suelen fallar cuando trabajan de forma conjunta, aunque previamente se haya demostrado que funcionan correctamente de manera individual. Por ello se deberán realizar este tipo de pruebas, las cuáles asegurarán que los módulos que están relacionados se ejecutan correctamente. Con el uso de estas pruebas, se conseguirá formar el producto global a medida que se comprueba como los distintos componentes interaccionan y se comunican libres de errores. Para automatizar las pruebas de integración se pueden emplear las mismas herramientas que para las pruebas unitarias (por ejemplo, JUnit), pero los casos de pruebas por regla general serán más largos y la verificación de resultados puede requerir más de una comprobación. Se propone la siguiente plantilla como ayuda a la definición de las pruebas de integración.
• Pruebas de código estático. Son verificaciones de código estático que todo programador debe realizar en su código para evitar errores de compilación, ejecución durante las fases posteriores. Un alto porcentaje de las pruebas se podrán automatizar en herramientas, tales como Checkstyle, PMD, Findbugs.

Se puede definir un caso de prueba como “el conjunto de entradas, condiciones de ejecución y resultados esperados" para satisfacer un objetivo concreto. La definición de los casos de pruebas se debe basar en la explotación de los distintos escenarios de ejecución de los casos de uso; en un diagrama de actividad, se puede asumir que existen distintos tipos de escenarios marcados por cada que camino que se puede trazar partiendo de su estado inicial.

No obstante el número de caminos posibles en un diagrama de actividad suele ser muy elevado, incluso en los casos más sencillos. Pero además, hay que añadir las múltiples posibilidades de escenarios de pruebas si se consideran todos los posibles valores de entrada posibles. Puesto que no resulta viable comprobar el comportamiento del software en todas las situaciones de funcionamiento, debemos seleccionar los casos de pruebas eligiendo aquellos que resulten más representativos, asegurando siempre una cobertura mínima. Se entenderá que un caso de uso, a través de su diagrama de actividad, estará los suficientemente probado, si los caminos utilizados permiten pasar por todas las flechas y transiciones del diagrama, al menos una vez.

Además, se deberá realizar un análisis del dominio de valores de entrada, para detectar grupos de datos que cuentan con un comportamiento homogéneo en el sistema, de forma que si el sistema falla con un dato concreto, podamos suponer que fallará también con otro dato del mismo grupo.

Por tanto, a partir de los caminos mínimos identificados y de los grupos de datos se establecerán los casos de pruebas necesarios para probar la funcionalidad completa del sistema. Se recomienda utilizar la plantilla propuesta por MADEJA.

Una vez finalizada la construcción del sistema, el Equipo de Proyecto deberá ejecutar los casos de pruebas definidos, con el fin de probar la funcionalidad completa del sistema software desarrollado.

Del conjunto de servicios disponibles, el Equipo de Testing ejecutará aquellas pruebas previamente acordadas con la Dirección del Proyecto. Durante la ejecución de las pruebas, el Equipo de Testing irá registrando los defectos encontrados y tras la ejecución de las pruebas, elaborará un informe final con los resultados de las pruebas realizadas.

El usuario que ejecuta el plan de pruebas de aceptación es un usuario experto que ha definido las características del sistema y conoce el alcance del sistema, por lo que los casos de pruebas no requerirán estar especificados con todos los pasos a realizar, sino que permitirá al usuario ejecutar cada caso de prueba de todas las formas imaginables por éste. Por ejemplo, un caso de prueba podría ser "tramitar favorablemente un expediente", sin indicar los trámites por los que pasa el expediente. Así, el usuario podrá verificar todos los caminos del circuito de tramitación que se le ocurran, incluso aquellos que no deben estar permitidos por el sistema. De esto modo el usuario comprueba si el sistema se ajusta realmente a sus necesidades, no si el sistema realiza correctamente los casos de prueba predefinidos en el plan de prueba.

Para la realización de este tipo de pruebas el usuario se apoyará en los Manuales de usuarios así como en la formación específica a realizar cuando, por la magnitud o complejidad del conjunto de pruebas, se estime conveniente.