Pruebas software: Introducción

Las pruebas software son esenciales. Realizar pruebas a tu código, programa o aplicación es algo fundamental si buscas tanto calidad como dar una buena imagen a tus usuarios y/o clientes. En este artículo vamos ver una introducción general a los distintos tipos de pruebas que se pueden realizar.

¿Qué son las pruebas software?

Antes de pasar a mayores debes tener en cuenta algo muy importante: por muchas pruebas que hagas no tendrás garantías de que tu código esté exento de errores. Esto es así, lo mires por donde lo mires. Dicho esto te doy una definición de pruebas en el ámbito de la programación.

Una prueba es el proceso por el cual ejecutamos un producto software con la intención de verificar y validar su correcto funcionamiento.

Esto implícitamente conlleva lo más importante: buscamos errores. No tratamos de demostrar que un programa funciona correctamente al 100%, porque no es posible. Puedes realizar millones de pruebas y que se te escape un error, o realizar 3 pruebas y detectar en ellas todos los errores de tu código. Sin embargo, nunca estarás seguro de que no puedan aparecer más.

Dicho esto, considera que una prueba es exitosa si has conseguido encontrar algún problema en la implementación. Además, gracias a las pruebas aportarás calidad al producto que estés desarrollando.

Y grábate esto que te voy a decir:

No probar de forma adecuada un software puede acarrear consecuencias: pérdidas económicas, pérdida de prestigio, incluso dependiendo del tipo de software, daños en instalaciones o personas

En cambio, las pruebas pueden ayudar a nuestro producto a:

  • Asegurar que nuestro producto se adecúa a los requerimientos: hace lo que se le pide y de forma correcta.
  • Afinar la eficiencia y la usabilidad: usa el mínimo de recursos y es fácil de utilizar.
  • Comprobar la compatibilidad y portabilidad en diferentes entornos: sistemas operativos, escritorio/web/móvil…
  • Mejorar la fiabilidad y seguridad: hemos tratado de encontrar el máximo número de errores posible.
  • Facilitar la mantenibilidad: al solucionar problemas encontrados en las pruebas estamos haciendo más sencillo añadir nuevas funcionalidades y localizar posibles taras.

¿Qué es un caso de prueba?

Un caso de prueba es un conjunto de entradas, condiciones de ejecución y salidas esperadas bajo las cuales podremos estudiar si un programa, aplicación, sistema software o una característica de éstos es parcial o completamente satisfactoria.

Para poder lanzar un caso de prueba es necesario definir sus precondiciones (estado del sistema antes de la ejecución), postcondiciones (estado del sistema después de la ejecución), identificar los valores de entrada adecuados y conocer el comportamiento que el elemento testado debería tener frente a esos valores.

Una vez todo eso claro, se ejecuta el caso de prueba y se observa si el comportamiento es el previsto o no y cuáles son las causas, pudiendo así determinar si la prueba ha sido o no pasada.

Se pueden llevar a cabo muchos casos de prueba para verificar que un requisito se cumple. Con el fin de comprobar que todos los requerimientos de una aplicación son examinados, debe haber al menos un caso de prueba para cada requerimiento a menos que éste tenga requisitos secundarios. En ese caso, cada requerimiento secundario deberá tener por lo menos un caso de prueba.

Ten en cuenta que a mayor calidad y número de tus casos de prueba, mayor calidad ganará el elemento probado.

Resumiendo la estructura de un caso de prueba que nos indica la Wikipedia, cada caso de prueba debe documentarse con al menos los siguientes puntos:

  • Introducción
    • Identificador único que lo haga distinguible del resto
    • Autor del diseño del caso de prueba
    • Versión actual
    • Nombre entendible y legible
    • Requerimientos para los que está diseñado
    • Propósito de la prueba, qué trata de comprobar
    • Dependencias, por si otras partes externas al ítem probado están involucradas
  • Proceso
    • Configuración hardware y software en la que se ejecuta el caso
    • Inicialización o acciones que deben llevarse a cabo antes de iniciar el caso (por ejemplo, abrir un archivo, ejecutar cierto proceso, etc.)
    • Finalización o acciones que deben ejecutarse después de realizado el caso (por ejemplo, corregir errores derivados de la ejecución del caso, como estados no deseados en archivos, bases de datos, etc.)
    • Pasos a realizar para completar la prueba
    • Datos de entrada y descripción de los mismos
  • Resultados
    • Salida esperada
    • Salida real obtenida
    • Resultado del caso de prueba: Correcto/Fallido
    • Severidad del defecto en caso de haber encontrado uno: Grave, Mayor, Normal, Menor
    • Evidencias o pruebas tangibles de la salida obtenida: capturas de pantalla, archivo log, consultas a la base de datos, etc.
    • Seguimiento del caso de prueba, por si no es la primera vez que lo ejecutamos. Aquí debemos incluir por ejemplo el número ordinal de ejecución de este caso, el código que se ha ido modificando y el identificador del defecto tratado.
    • Estado del caso de prueba: No iniciado/En curso/Terminado.

Cómo llevar a cabo las pruebas software

Existen técnicas probadas y documentadas, específicamente creadas para encontrar errores. Dos de las más famosas son las de ‘caja blanca’ y las de ‘caja negra’.

Pruebas de caja blanca
Pruebas de Caja Blanca (Arunseochiefs, CC BY-SA 4.0, via Wikimedia Commons)

La técnica de prueba de caja blanca se basan en aprovecharse de que conocemos y/o tenemos disponible el código fuente del programa, mientras que la de caja negra no presupone conocimiento de cómo está elaborado internamente el producto, simplemente se basa en buscar errores interactuando con la interfaz del programa teniendo solo en cuenta sus entradas y salidas.

Pruebas de Caja Negra (Krauss, CC BY-SA 4.0, via Wikimedia Commons)

Es importante tener en cuenta que no tenemos recursos infinitos, por lo que no podemos estar eternamente realizando pruebas, probando todas y cada una de las líneas de código o todas y analizando cada una de las posibles entradas de la aplicación. Por esto deberemos establecer un plan de pruebas que mezcle ambas técnicas estableciendo prioridades, identificando las posibles fuentes de riesgo y tratando con nuestras pruebas de reducir esos riesgos.

El 80% de los fallos de un software es generado por un 20% del código de dicho software, mientras que el otro 80% genera tan solo un 20% de los fallos.

Regla del 80/20, principio de Pareto.

Además, es interesante conocer y poner en práctica uno de los principios que se suelen aplicar a la realización de pruebas: el principio de Pareto.

Tipos de pruebas software

Clasificándolas según el propósito específico que persiguen unas pruebas, podemos definir estos tres tipos.

Pruebas Funcionales

Buscan probar los requerimientos funcionales indicados en la especificación de requisitos, es decir, que las salidas que proporciona el programa se ajusten a las necesidades del usuario. Requieren de:

  • Completitud: se resuelven todas las necesidades.
  • Corrección: se resuelven de forma correcta.
  • Pertenencia: sólo se llevan a cabo las funciones necesarias para resolver los requerimientos.

Estas pruebas suelen estar asociadas a técnicas de caja negra, relacionándose con el comportamiento externo del software.

Pruebas no funcionales

Buscan probar características no funcionales como fiabilidad, eficiencia, etc. Tienen así en cuenta el cómo, el comportamiento externo del sistema. También suelen utilizar pruebas de caja negra y se suelen tener las siguientes características no funcionales:

  • Carga: cómo funciona el sistema cuando se aumenta su carga de trabajo.
  • Rendimiento: velocidad de procesamiento y tiempo de respuesta.
  • Volumen: capacidad de gestionar grandes cantidades de datos.
  • Esfuerzo: se sobrecarga a propósito el sistema para ver su capacidad a la hora de recuperarse.
  • Seguridad: comprobar el comportamiento frente a acciones no autorizadas.
  • Estabilidad, eficiencia y robustez: cómo se comporta el sistema cuando se presentan errores de funcionamiento.
  • Compatibilidad: con diferentes sistemas operativos, plataformas, hardware, etc.
  • Usabilidad: facilidad de uso y grado de satisfacción.

Estructurales

Derivan del conocimiento de la estructura del software, por lo que son asociadas a las pruebas de caja blanca.

Estrategias de pruebas del software

La forma en la que mayormente se aplican las pruebas del software se asemejan a una espiral.

Estrategia de Prueba

Prueba de unidad

Se centra en probar cada unidad o módulo, partiendo del nivel más bajo posible: el código fuente. Tratamos así de eliminar errores tanto en la lógica interna como en la interfaz, usando técnicas de caja negra y caja blanca. Se realizarán pruebas sobre:

  • Comunicación entre los módulos (interfaces)
  • Estructuras de datos
  • Condiciones límite
  • Caminos independientes de el flujo de control (nos aseguramos que se ejecuten todas las sentencias del código al menos una vez)
  • Todas las posibilidades en el manejo de errores

Para las pruebas unitarias se utilizan herramientas tales como JUnit y sus variantes para los distintos lenguajes de programación.

Prueba de integración

Se busca probar la interacción entre módulos, que aun funcionando bien por separado puede ser que fallaran al comunicarse.

Esto se puede hacer probando todos los módulos juntos de una vez (integración no incremental) tras las pruebas unitarias, o bien construyendo poco a poco el programa completo y probando pequeñas partes (integración incremental).

Prueba de validación

Tratamos de probar que el software funciona de acuerdo con lo que el cliente espera, es decir, las funcionalidades descritas en el documento de especificación de requerimientos. Estas pruebas, de caja negra, pueden clasificarse en:

  • Pruebas Alfa: El cliente/usuario de pruebas realiza estas mismas en presencia de desarrolladores, que se encargan de observar la interacción y registrar aquellos sucesos que se vayan dando.
  • Pruebas Beta: Las llevan a cabo los usuarios finales pero en este caso sin supervisión. Es el usuario el que registra los problemas que encuentra e informa al desarrollador de los mismos. Ten en cuenta que lo que el usuario puede considerar un problema, a lo mejor no lo es tal, y al revés, el usuario puede ver que algo no es un problema y que lo sea de hecho.

Prueba del sistema

Se trata de poner a prueba el sistema en su conjunto y llevándolo al límite. Para ello se realizan:

  • Pruebas de recuperación: Se fuerza el fallo del sistema y se comprueba que se recupera adecuadamente.
  • Pruebas de seguridad: Se intentan realizar operaciones no permitidas para verificar si el sistema responde como se espera.
  • Prueba de resistencia o de estrés: se pone el sistema al límite, solicitando gran cantidad de recursos (memoria, comunicaciones, procesamiento, entrada y salida…) e incluso simulando problemas en un sistema operativo virtual.

Y eso es todo por esta introducción, en el siguiente artículo relativo a las Pruebas Software veremos las Pruebas de Caja Negra.