Las pruebas de software y el aseguramiento de calidad

Las pruebas y el aseguramiento de calidad.

Las pruebas en el software garantizan la calidad del producto validando que cumpla las especificaciones para las que fue diseñado. Existen diferentes tipos de pruebas, cada una con objetivos específicos y cuya responsabilidad recae sobre diferentes roles. En este post quería discutir los diferentes tipos de pruebas, su uso y la importancia en el proceso de calidad.

¿Por qué realizar diferentes tipos de pruebas a las clásicas validaciones funcionales?

Porque todos los problemas no se encuentran de esta forma.

Realizar solo pruebas funcionales al software es el equivalente a entrenar un equipo de fútbol solo con partidos amistosos. Es verdad que el equipo va mejorar y se van detectar algunos errores. Pero para lograr un rendimiento optimo en la defensa, el medio campo y el ataque  es necesario revisar diferentes detalles por separado. La táctica, el entrenamiento de arqueros y las jugadas preparas son algunas de las estrategias mas conocidas por los directores técnicos y deportivos. De la misma manera en que realizar solo pruebas funcionales corregiría una pequeña proporción de los posibles errores y defectos en nuestros productos de software. Utilizar las diferentes pruebas nos permitir realizar una evaluación integral para conseguir un producto de calidad.

Porque los errores y cambios en esta etapa del desarrollo son los más costosos.

Las clásicas validaciones funcionales se llevan a cabo casi al momento de la terminación del proyecto. La curva del costo del cambio propuesta por Barry Boehm in Software Engineering Economics (Prentice Hall, 1981) describe que el costo de los cambios crece exponencialmente con el tiempo. En mi opinión,  si bien aún hoy hay mucha discusión sobre el tema  la  detección temprana de errores ahorrara horas de depuración y de pruebas funcionales. Pues entre más tiempo pase sin detección un error en el sistema más supuestos se harán basados en esta idea y más componentes interactuaran con el.

Curva del costo

Metodologías de prueba

Existen diferentes aproximaciones o metodologías para orientan el diseño de las pruebas. Cada metolodiga puede usarse con los diferentes tipos de pruebas e incluso combinarse para adaptarse a las necesidades de los proyectos.

Caja Negra	Se evalúan los componentes como una caja negra. Solo las entradas y salidas.
Caja Blanca	Se evalúan los estados internos y llamados internos a otros componentes.
Caja Gris	Es una mezcla entre el método de caja blanca y caja negra. Básicamente se evalúa la especificación de alto nivel del sistema y los componentes y llamados internos.
Adhoc	Es una metodología de pruebas donde se validan los componentes sin documentación o especificación. El Ingeniero de calidad trata de encontrar bugs sin ningún plan basándose únicamente en su intuición.
Ágiles	Este tipo de pruebas son ejecutadas siguiendo los principios del desarrollo ágil. Por ejemplo, en una aproximación ágil las pruebas se crean y ejecutan antes y durante el desarrollo del producto.

Tipos de pruebas

A continuación una lista de las pruebas más comunes. Junto al nombre está la metodología recomendada y el rol que usualmente la desempeña. La selección del tipo de metodología no es una decisión trivial pues afectara significativamente el esfuerzo y efectividad. Por ejemplo, realizar las pruebas de aceptación con el cliente siguiendo un método de caja blanca de un componente en particular puede ser realmente frustrante pues sería necesario explicar los llamados y estados internos a los clientes que usualmente están interesados en el caso de negocio.

Pruebas de unidad [Rol principal: Desarrollador, Tipo: Caja blanca]

Este tipo de pruebas validan que una unidad de código (una clase, función o método) realice el trabajo para el que fue diseñado. Son fragmentos de código que validan la ejecución de las unidades de código del producto -código que valida código. Opcionalmente pueden validar los llamados a otros sistemas o estados intermedios.

public void validarSuma()
{
    int operandoA = 5;
    int operandoB = 7;

    int resultado = Sumador.sumar(5, 7)
    if (resultado != 12)
    {
        system.println("Error!");
    }
}

Pruebas de integración [Rol principal: Desarrollador, Tipo: Caja gris]

Las pruebas de integración validan el funcionamiento o integración entre dos o más sistemas. Por ejemplo, el acceso a un servicio web o el almacenamiento en la base de datos. El objetivo de las pruebas de integración es validar el comportamiento de múltiples componentes. Dependiendo de la implementación pueden validar estados intermedios.

Integración entre componentes.

Pruebas de regresión [Rol principal: ING Calidad & ING Desarrollador, Tipo: Caja negra]

Las pruebas de regresión son las pruebas que se ejecutan después de un cambio en el sistema (nueva característica o solución a un bug). Su objetivo principal es validar que las características previas al cambio no se vean afectadas. Son las primeras candidatas a automatización pues deben repartirse periódicamente con cada uno de los cambios o actualizaciones.

Pruebas de humo (Smoke) [Rol principal: ING Calidad, Tipo: Caja negra]

Este tipo de pruebas son pruebas rápidas que buscan encontrar problemas graves (fuego oculto) en el software recientemente modificado. El nombre viene de los sistemas electrónicos donde la prueba inicial es que no hay humo al conectar la fuente de energía. Las pruebas de humo buscan problemas críticos en la aplicación que hacen que no valga la pena validar otro tipo de pruebas. Preguntas como: ¿El sistema inicia correctamente? o ¿El menú principal se presenta correctamente?  caracterizan el objetivo de las pruebas de humo.

Prueba de Aceptación [Rol principal: Cliente, Tipo: Caja negra]

El objetivo de las pruebas de aceptación no es validar el comportamiento lógico específico de un componente sino un escenario, caso de uso o caso de negocio de la aplicación. Su característica principal es que se realiza con el cliente para validar que la aplicación permite a los clientes completar las tareas para la que fue diseñada.

Pruebas de sistema (System) [Rol principal: ING Calidad, Tipo: Caja negra/ Adhoc]

Las pruebas de sistema validan el funcionamiento del software en condiciones específicas (sistemas operativos, navegadores, servidores, bases de datos o tipo dispositivo). Las pruebas de sistema también pueden validar la escalabilidad, el desempeño y la confiabilidad del sistema en escenarios específicamente diseñados.

Eso es todo!, espero el post pueda darles una intruducción a cada tipo de pureba y su utilidad, recuerden  que si bien existen roles como con ingenieros de pruebas y calidad, la calidad es un asunto de todo el equipo!