Todo software debe ser probado una vez ha realizado. Al principio de este modulo vimos que en todos los ciclos de vida del software teníamos una fase de pruebas y verificación.

Ciclo de vida en cascada.

Esta fase es fundamental antes de entregar el producto al cliente para su explotación, aunque dependiendo de la metodología elegida para el trabajo, las pruebas son una contante en todo proceso de desarrollo.

Aunque el software cuando este terminado se somete a una fuerte batería de pruebas para encontrar deficiencias en su funcionamiento, tanto de código como de usabilidad. Durante el proceso de desarrollo, ya sea en su totalidad o en partes, se ponen a disposición de los “testers” diferentes bloques del mismo para su prueba.

Para ello se dispone la aplicación en diferentes entornos de trabajo, los cuales van a ser diferentes, dependiendo de la complejidad del desarrollo, pero en general se definen los siguientes entornos:

Entorno de desarrollo

Es el entorno inicial, aquí es donde el equipo de desarrolladores trabajar realizando los códigos de la aplicación. La infraestructura utilizada a nivel de software y hardware, en general, no va a coincidir con la final prevista para el lanzamiento de la aplicación, siendo de características más bajas con el objeto de reducir los costes de infraestructura.

Entorno de pre-producción

En este entorno se realizan las pruebas para garantizar el funcionamiento de la aplicación. Estas pruebas serán de todo tipo tanto para someter a la aplicación a todos los supuestos posibles en su uso, como pruebas de cargar para garantizar el rendimiento o incluso de usabilidad. Este entorno debe ser igual en la medida de lo posible al entorno de producción a nivel de arquitectura, niveles de seguridad, hardware, software etc.

El acceso a la aplicación estará permitida solo para el grupo de testeadores y con datos que, si no son los reales, al menos deberán ser muy semejantes.

Entorno de producción

Este es el entorno final, donde la aplicación ya se encuentra en uso. Esta fase debería de carecer de fallos pues de producirse puede causar grandes problemas a la empresa o usuarios cliente. Por ello antes de enviar un desarrollo a este entorno debe haber sido sometido a todas las pruebas necesarias para garantizar su correcto funcionamiento.

Al mismo tiempo este entorno suele tener asociados una serie de planes de contingencia el cual debe ser implantado antes de su puesta en marcha. Pudiendo volver a versiones anteriores su fuese necesario o restauración de backups.

Para realizar las pruebas a un software es necesario tener un plan de pruebas donde se realizara la programación de los a los que se someterá a la aplicación y la estimación de recursos que serán tenidos en cuenta antes de realizar el proceso.

Para el establecimiento de los estándares asociados a cada caso de prueba a realizar se tendrán en cuenta los requisitos establecidos en la primera fase del ciclo de vida del desarrollo.

La planificación de pruebas es parte de la documentación de todo proyecto de software, donde se establecerán ya desde un inicio el tipo y forma en que se realizaran. Así mismo se debe tener en cuenta los recursos personales, de hardware y el tiempo para su realización.

Aunque un plan de pruebas variará dependiendo del tipo de proyecto, podemos indicar que sus partes mas importantes serían:

El proceso de prueba: descripción de cada una de las fases del proceso de pruebas.
Requisitos de trazabilidad: La planificación debe asegurar que se prueban todos los requisitos de forma individual.
Elementos a probar: Los elementos que van a ser probados.
Cronograma de pruebas: Un calendario de pruebas donde asignamos los recursos de personal, medios y tiempos.

Estructura de un plan de pruebas

Para que un plan de pruebas resulte efectivo debe componerse de las siguientes partes:

Procedimientos de registro de prueba: La realización de las pruebas no solo se limitan a ejecutar y verificar que todo funciona. Es imprescindible que los resultados obtenidos se documenten, por lo que deberán registrarse de forma sistemática.

También tenemos que tener encuentra que prácticamente todos los desarrollos de software son sometidos a diferentes auditorias, por lo que la documentación detallada de cada proceso es fundamental.

Requisitos de hardware y software: En la elaboración del plan de pruebas es necesario definir los recursos de software y hardware que serán necesarios para poder realizar los test necesarios.

Plan de contingencias: Se deben plantear posibles procedimientos o recursos, para solucionar los imprevistos. Así como en un desarrollo en producción es imprescindible que tenga medios de respaldo, en las fases de desarrollo también debemos tener los sistemas necesarios para solucionar posibles problemas, ya sea de personal o del sistema.

Definición de los casos de pruebas: Como su nombre indica, define los casos de prueba que deben aplicarse al sistema.

Puedes descargarte de esta página una plantilla para la realización de un plan de pruebas de software.
http://www.pmoinformatica.com/2014/05/plan-de-pruebas-de-software.html

El proceso de pruebas

Durante el proceso de pruebas se valida y verifica la aplicación. Parece entenderse que validación es sinónimo de verificación. Pero son términos con significados diferentes.

La validación es el proceso que comprueba que el sistema se este construyendo de la forma adecuada. Mientras que la verificación se refiere a si el sistema está bien diseñado y sin errores de funcionamiento.

Es decir, la validación se refiere a la comprobación de que el sistema cumplirá con las necesidades reales del cliente, y la verificación que carece de errores o fallos.

Tipos de pruebas

Pruebas estáticas

En las pruebas estáticas no es necesario ejecutar la aplicación, este tipo de pruebas se centran en la inspección de los requisitos, prototipos o errores de en el código fuente buscando posibles errores con el objetivo de eliminar defectos en fases tempranas del desarrollo.

Estas revisiones se pueden hacer de forma manual o con software especifico dentro de las herramientas CASE. En muchos casos se trata de la revisión de la documentación, como por ejemplo:

Especificaciones de requisitos.
Documentos de diseño.
Códigos fuente.
Planes de prueba.
Casos de prueba.
Scripts de prueba.
Documentos de ayuda de usuario.
Contenido de la página web.

Pruebas dinámicas

En este tipo de pruebas se comprueba el correcto, o mejor dicho el esperado comportamiento del código generado. De tal modo que se la aplicación se sometera a este tipo de pruebas cuando ya este, al menos en parte realizada.

Para efectuar este tipo de pruebas es necesario ejecutar el código, de tal modo que se revisara su ejecución y se comprobara que cumple los requerimientos establecidos.

En estas pruebas, además de la ejecución se comprobara que el consumo de recursos del sistema como, uso de la CPU, memoria, etc.

Dentro de este tipo de pruebas tenemos las funcionales y las no funcionales.

En las pruebas funciones se comprueba los datos de entrada y se analizan los resultados obtenidos. Por tanto su metodología es probar y validar que el software hace lo que se esperaba de el.

En contraposición las denominadas pruebas no funcionales, no están dirigidas a probar l as funciones, sino a otros aspectos de la aplicación, como pueden ser las de rendimiento, carga, usabilidad, seguridad, etc.

Características de una prueba funcional:

Identificación de las funciones que el software debe realizar.
Generación de los datos de entrada en base a las especificaciones de la funciones.
Determinación de los elementos de salida en base a las especificaciones de la función.
Ejecución de la prueba en base a los parámetros establecidos.
Comparación de los resultados obtenidos frente a los esperados.

Pruebas estructurales (Caja Blanca)

Para testear la aplicación se elige una entrada. A partir de esta se examina la aplicación por los distintos posibles caminos, obtenidos a partir del código, por los que se puede ejecutar la aplicación, revisando las salidas que se producen.

En las pruebas estructurales el diseño y la implementación del sistema son conocidos por la persona que realiza la prueba.

Durante la ejecución de estas pruebas el testeador se centra en determinar como trabaja la ejecución del programa. Por lo que someterá a diferentes partes del código como bucles, a casos de pruebas con distintos valores.

Las pruebas de caja blanca, se engloban dentro de los siguientes tipos de pruebas:

Pruebas unitarias: Se testean las posibles resultados con parametros.
Pruebas de integración: Se testean los posibles caminos entre las unidades.
Pruebas de sistema: Se testean diferentes caminos entre los subsistemas.

Las ventajas de las pruebas de caja blanca son:

Se pueden realizar en fases tempranas del desarrollo, pues podemos ir testeando las partes del código que estén realizados.
Se pueden realizar pruebas complejas, puesto que es posible verificar todos y cada uno de los posibles caminos.

Por el contrario los inconvenientes son:

El testeador debe tener profundos conocimientos de programación y ejecución, puesto que las pruebas están basadas en la interpretación del código fuente.
Todo proceso de software tiene continuas modificaciones de código, por lo que debemos someter el programa a la batería de pruebas con cada cambio.

Pruebas de integración.

Con las pruebas de integración comprobamos que las interacciones entre los distintos módulos de la aplicación funciona correctamente.

Un aplicación esta formada por multitud de elementos, que interactúan entre si, enviando y/o procesando datos. Con estas pruebas no solo comprobamos que cada modulo hace lo que se le pide, sino que interactúa con el resto de módulos de forma correcta. Un ejemplo sería la interfaz de una aplicación que se debe comunicar con el núcleo controlador del programa.

Las pruebas de integración detectan los errores derivados de las interacciones entre las unidades que se integran.

Pruebas de usabilidad y accesibilidad

Usabilidad

En una aplicación es importante que ejecute los métodos que le codificamos correctamente. Pero también debemos tener en cuenta, que el usuario es el que hará uso de la misma. Por lo que el modo en que se presente esta es fundamental para el éxito.

La usabilidad en una aplicación es la medida en la que el uso de la misma por los usuarios resulta clara, sencilla, efectiva y satisfactoria.

Para realizar estas pruebas se escoge a un grupo de personas (normalmente 5), y se les propone una serie de supuestos a realizar. Estas personas no deben tener un perfil técnico aunque si ser expertos en temas de usabilidad como usuarios finales de distintos perfiles.

Para ver el proceso completo y saber como hacer una prueba de usabilidad puedes visitar este enlace:
https://kinsta.com/es/blog/prueba-usabilidad-sitio-web/

Accesibilidad

Según la W3C, se habla de que un sitio web es accesible cuando “el acceso se realiza de forma universal, independientemente del tipo de hardware, software, infraestructura de red, idioma, cultura, localización geográfica y capacidades de los usuarios”.

Cada una de las categorías principales de discapacidad requiere un determinado tipo de adaptación. Se trata de realizar aplicaciones adaptadas para que accedan usuarios con discapacidad visual, de audición, de motricidad, cognitiva…

Para más información sobre las pruebas de accesibilidad puedes visitar este enlace:
https://mosaic.uoc.edu/ac/le/es/m5/ud2/index.html

Pruebas de caja negra (detección de errores)

Las pruebas de caja negra suelen ser de tipo funcional, pero también incluyen las no funcionales, como por ejemplo una prueba de rendimiento.

Las pruebas de caja negra o pruebas de “comportamiento”, estas pruebas no requieren que el testeador vea el código que se esta ejecutado, de ahí su nombre de caja negra. Estas pruebas se realizan desde el punto de vista del usuario, por lo que no es necesario que el testeador tenga un perfil técnico.

Básicamente consisten en someter a la aplicación a diferentes pruebas de uso y comprobar que el resultado sea el buscado. Con este tipo de pruebas podemos localizar los siguientes errores:

Funciones incorrectas o que no existen.
Errores en la interfaz.
Errores en el acceso a los datos.
Errores en el comportamiento.
Errores en el inicio o terminación de la aplicación.

Gracias a estas pruebas podemos encontrar errores de funcionamiento, como un error en la interfaz o fallo al procesar algún dato. Y además detectaremos si la aplicación cumple con las especificaciones, puesto que se realizan a nivel de usuario, en muchos casos personal del propio cliente.

La gran desventaja de las pruebas de caja negra es que requieren que la aplicación este prácticamente terminada, al menos los módulos a probar. Por lo que un error suele producir grandes cambios en el desarrollo.

Pruebas de seguridad

Las pruebas de seguridad son las encargadas de asegurar que el software esta libre de amenazas internas o externar procedentes de personas o software malicioso.

Como dicen los expertos en seguridad. “LA SEGURIDAD TOTAL NO EXISTE”, pero eso bueno realizar una serie de comprobaciones, para asegurar que estamos libres de los peligros mas frecuentes. En resumen con estas pruebas se verifica:

Si existe una autenticación adecuada.
Si el control de acceso es adecuado.
Si el software es capaz de mantener la confidencialidad de los datos.
La disponibilidad del software en caso de un ataque por parte de hackers y programas maliciosos.

Pruebas de rendimiento

No siempre disponemos de la información necesaria para saber cuales son las necesidades reales que tendrá una aplicación, normalmente este se va incrementando con el tiempo de vida del software.

Pero si debemos establecer unos parámetros iniciales que garanticen su funcionamiento, partiendo un número de usuarios que puedan acceder concurrentemente o la carga de datos máxima a la que se someterá la aplicación.

Los valores que comúnmente se suelen medir son:

Tiempos de respuesta: Es la métrica más solicitada en las pruebas de rendimiento. Afecta de forma directa a la experiencia con la aplicación del usuario final.

El uso de recursos: Suelen ser de tipo narrativo, como por ejemplo “durante las pruebas no se alcanzaron nunca valores superiores al 60% de utilización de la CPU”.

Para probar estas variables existen dos tipos de pruebas clásicas a las que debemos someter nuestra aplicación.

Pruebas de carga: En esta prueba se somete a la aplicación a una carga de peticiones que se considera más elevada a la que soportará la aplicación cuando este en producción.

Pruebas de estrés: Este tipo de pruebas tienen como objetivo comprobar la robustez, la disponibilidad y la fiabilidad de una aplicación cuando es sometida a condiciones extremas.

Pruebas de código

Herramientas de testeo

La fase de pruebas en todo proyecto de software es un proceso laborioso. Es obvio que contar con herramientas que nos ayuden a automatizar las tareas donde configurando parámetros podamos construir una serie de pasos que nuestros códigos deban superar.

Para automatizar las pruebas tenemos muchas herramientas, cada una con funcionabilidades diferentes, vamos una clasificación donde separamos la herramienta según su objetivo.

Gestor de pruebas

Este tipo de aplicaciones es uno de los mas usados por los desarrolladores. Normalmente son frameworks de los propios lenguajes o herramientas integradas en los IDE, como el caso de JUnit.

Con JUnit, podemos automatizar las pruebas unitarias de una aplicación Java. Mediante conjunto de clases de Java podemos probar si los métodos implementados a partir de unos valores de entrada comprueba los datos de salida y, si no son los esperados nos devolverá un error.

Analizador dinámico

Con esta herramienta podremos introducir trozos de código en nuestro programa, para testear su comportamiento. Por ejemplo las veces que se ejecuta un bucle.

Oráculo

Es una herramienta que obtiene las predicciones de los resultados que se generan a partir de los datos de prueba. Esta herramienta puede ser la misma aplicación de una versión anterior o bien un prototipo creado para este fin.

Comparador de ficheros

Herramienta que compara los resultados obtenidos con otros de pruebas previas. Se utiliza en pruebas de regresión, donde se comparan pruebas de distintas versiones.

Generador de informes

Proporciona la definición de informes para los resultados de las pruebas.

Generador de datos de pruebas.

Genera los datos de pruebas para el programa que se desea probar. Estos se pueden obtener desde una BBDD o bien de forma aleatoria.

Simulador

Pueden ser, por ejemplo, pruebas de interfaces de usuario, que son programas guiados por scripts que simulan numerosas interacciones de los usuarios.

Automatización de pruebas

En el punto anterior ya hemos comentado como mediante el uso de herramientas podemos agilizar el trabajo de la realización de las pruebas. Estas pruebas pueden ser de dos tipos.

Pruebas codificadas: Se automatizan las pruebas unitarias utilizando casos de uso.

Pruebas de usuario: Se graban acciones que realizarán los usuarios sobre la interfaz de la aplicación a evaluar. Con esto se consigue que las acciones repetitivas puedan ser ejecutadas las veces que haga falta.

Existen entornos de pruebas dependiendo del lenguaje de programación:

Sistema para realizar pruebas unitarias con el lenguaje JAVA.
Creado para suplir algunas deficiencias en JUnit.
Basado en anotaciones, como TestNG, también para Java.
Entorno de pruebas para aplicaciones realizadas en PHP.
Sistema para la realización de pruebas unitarias en PHP.
Versión del framework para lenguajes C/C++.
Entorno de pruebas para Microsoft Visual FoxPro.
Entorno para la creación dinámica de objetos simuladores (mocks).
Librería para pruebas unitarias en JavaScript. Creada por la fundación jQuery.