Pruebas Clásicas a Software

Al desarrollar un nuevo software o sistema de información, la primera etapa de pruebas a considerar es la etapa de pruebas unitarias o también llamada pruebas de caja blanca (White Box), estás pruebas también son llamadas pruebas modulares ya que nos permiten determinar si un modulo del programa esta listo y correctamente terminado, estas pruebas no se deben confundir con las pruebas informales que realiza el programador mientras esta desarrollando el módulo. El principal factor que se debe considerar al inicio de las pruebas es el tamaño del módulo a probar, se debe considerar si el tamaño del módulo permitirá probar adecuadamente toda su funcionalidad de manera sencilla y rápida. También es importante separar los módulos de acuerdo a su funcionalidad, si los módulos son muy grandes y contienen muchas funcionalidades, estos se volverán más complejos de probar y al encontrar algún error será más difícil ubicar la funcionalidad defectuosa y corregirla. Al hacer esta labor el analista de pruebas podrá recomendar que un modulo muy complejo sea separado en 2 o 3 módulos más sencillos. Integración Incremental Al realizar una integración incremental debemos combinar o unir el siguiente módulo que se debe probar con el conjunto de módulos ya probados. El número de módulos se incrementa progresivamente hasta formar el programa completo. Esto lo podemos realizar de 2 formas. Integración Incremental Ascendente. Integración Incremental Descendente. Integración Incremental Ascendente En este tipo de integración se combinan los módulos de más bajo nivel en grupos que realizan alguna sub función específica. A través de un driver (módulo impulsor) se simulan llamadas a los módulos, se introducen los datos de prueba y se recogen los resultados. Cada grupo se prueba usando su driver (test integrador), y este luego es sustituido por los módulos de nivel superior en la jerarquía. En el último paso se prueba el programa completo con sus entradas y salidas reales. En mi experiencia como analista de pruebas, me toco probar un sistema bancario, en esa oportunidad empezamos por los módulos que aplicaban lógica de negocio y hacían cambios en la base de datos, una vez que cada uno de estos módulos funcionaba correctamente, iniciamos las pruebas de los módulos de nivel superior, que básicamente hacían llamadas a estos módulos de más bajo nivel, esta segunda etapa fue mucho más rápida, pues estos últimos tenían muy poca lógica, al reemplazar los drivers que creamos por los módulos de más alto nivel encontrábamos pequeños pero muy críticos errores, por ejemplo componentes que fueron renombrados en el nivel bajo y no fueron actualizados en las llamadas de los niveles superiores. La siguiente imagen muestra la primera fase de la integración ascendente, en este ejemplo cada módulo debe ser probado por separado, para esto se debe construir un driver o impulsor para probar cada módulo. Tal como se muestra en la figura 3, luego de probar los módulos de más bajo nivel (E, F y G), continuamos con los módulos del siguiente nivel, para esto debemos construir nuevos drivers o impulsores (B y C), que se aplicaran directamente a los módulos superiores (B y C) y estos a su vez se integrarán a los de más bajo nivel (E, F Y G). Este proceso se repite algunas veces hasta que se culmina por probar el sistema completo, en la figura 4 se muestra un nivel más de integracion incremental ascendente. Fig. 3 Integración Incremental Ascendente Fig. 4 Integración Incremental Ascendente Ventajas de la integración incremental ascendente: Las entradas para las pruebas son más fáciles de crear ya que los módulos inferiores suelen tener funciones más específicas. Es más fácil la observación de los resultados de las pruebas puesto que es en los módulos inferiores donde se elaboran. Resuelve primero los errores de los módulos inferiores que son los que acostumbran tener el procesamiento más complejo, para luego nutrir de datos al resto del sistema. Desventajas de la integración incremental ascendente: Se requieren módulos impulsores, que deben escribirse especialmente y que no son necesariamente sencillos de codificar. El sistema como entidad no existe hasta que se agrega el último módulo. Integración incremental Descendente Inicia del módulo de control principal (de mayor nivel) para luego ir incorporando los módulos subordinados progresivamente. No hay un procedimiento considerado óptimo para seleccionar el siguiente módulo a incorporar. La única regla es que el módulo incorporado tenga todos los módulos que lo invocan previamente probados. En general no hay una secuencia óptima de integración. Debe estudiarse el problema concreto y de acuerdo a este, buscar el orden de integración más decuado para la organización de las pruebas. No obstante, pueden considerarse las siguientes pautas: Si hay secciones críticas como ser un módulo complicado, se debe proyectar la secuencia de integración para incorporarlas lo antes posible. El orden de integración debe incorporar cuanto antes los módulos de entrada y salida. Existen principalmente dos métodos para la incorporación de módulos: Primero en profundidad: Primero se mueve verticalmente en la estructura de módulos. Primero en anchura: Primero se mueve horizontalmente en la estructura de módulos. Etapas de la integración descendente: El módulo de mayor nivel hace de impulsor y se escriben módulos ficticios simulando a los subordinados, que serán llamados por el módulo de control superior. Probar cada vez que se incorpora un módulo nuevo al conjunto ya engarzado. Al terminar cada prueba, sustituir un módulo ficticio subordinado por el real que reemplazaba, según el orden elegido. Escribir los módulos ficticios subordinados que se necesiten para la prueba del nuevo módulo incorporado. Ventajas de la integración descendente: Las fallas que pudieran existir en los módulos superiores se detectan en una etapa temprana. Permite ver la estructura del sistema desde un principio, facilitando la elaboración de demostraciones de su funcionamiento. Concuerda con la necesidad de definir primero las interfaces de los distintos subsistemas para después seguir con las funciones específicas de cada uno por separado. Desventajas de la integración descendente: Requiere mucho trabajo de desarrollo adicional ya que se deben escribir un gran número de módulos ficticios subordinados que no siempre son fáciles de realizar. Suelen ser más complicados de lo que aparentan. Antes de incorporar los módulos de entrada y salida resulta difícil introducir los casos de prueba y obtener los resultados. Los juegos de datos de prueba pueden resultar difíciles o imposibles de generar puesto que generalmente son los módulos de nivel inferior los que proporcionan los detalles. Induce a diferir la terminación de la prueba de ciertos módulos. Integración No Incremental La integración no incremental es bastante sencilla y generalmente se recomienda para proyectos de poca envergadura, la integración consiste en probar cada modulo por separado de manera similar a la intregación incremental pero una vez de terminar con los módulos independientes, se continua probandolos todos juntos como un todo. La única ventaja es que no se necesita ningún tipo de trabajo adicional: ni planificar el orden de integración, ni crear módulos impulsores, ni crear módulos ficticios subordinados. Por otro lado, la lista de desventajas incluye: No se tiene noción de la comunicación de los módulos hasta el final. En ningún momento se dispone de un producto (ni siquiera parcial) para mostrar o presentar. El hecho de realizar todas las pruebas de una vez hace que las sesiones de prueba sean largas y tediosas. La cantidad de errores que arroje puede ser atemorizante. La tarea de encontrar la causa de los errores resulta mucho más compleja que con los métodos incrementales. Se corre el riesgo de que a poco tiempo de que se cumpla el plazo de entrega, haya que volver sobre el diseño y la codificación del sistema.