Prueba y documentación de programas. Técnicas.

El testing

Las pruebas de software son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad.

Las pruebas son un conjunto de actividades dentro del desarrollo de software. Por lo tanto el modelos de pruebas será distinto dependiendo del modelo de desarrollo de software.

Su importancia es clave porque con este proceso se pretende:

• que el software funciona acorde a los requisitos
• que todos los requisitos hayan sido completados
• validar que el elemento u objeto de nuestras pruebas es el esperado
• incrementar la confianza en el desarrollo
• encontrar fallos y defectos y prevenir su aparición
• reportar al cliente el estado del software en términos de calidad y asegurar el cumplimiento de los acuerdos alcanzados

Todo ello redunda en una reducción de costes, plazos de entrega y riesgos a la par que aumenta la calidad aumentando la satisfacción del cliente.

Error, defecto y fallo

Señalada la importancia de las pruebas, vamos a clarificar algunos de los conceptos asociados más importantes: el error, el defecto y el fallo.

Una persona puede cometer un error, que conlleva la introducción de un defecto en el código o en otras áreas del desarrollo del producto. Cuando un defecto introducido en el código es ejecutado en un test, se produce un fallo

Son muchas las causas que pueden provocar un error:

• La presión del tiempo
• Falta de conocimientos o de experiencia
• Malentendidos en las comunicaciones del equipo
• Complejidad de la solución
• Errores en las Comunicaciones entre sistemas
• Error humano
• Nuevas tecnologías no suficientemente testadas

Niveles de testing

Test unitarios

Es la prueba que se realiza sobre la unidad más básica de nuestro código, métodos, funciones, clases, interfaces,...

Las pruebas unitarias son el método por el cual validamos que cada unidad desarrollada está lista para uso.

Los desarrolladores de software escriben estos casos de prueba para asegurar su funcionamiento en términos de diseño e implementación.

En ocasiones también los QAs pueden escribir estos casos de prueba, pero no es común.

Los test unitarios validan el correcto funcionamiento de la unidad más pequeña de código que utiliza nuestro software, por lo tanto lo que estamos consiguiendo es asegurar que para un conjunto de valores de entrada, nuestra función, método o clase devuelve el valor esperado.

Uno de los métodos utilizados es el de pruebas de caja blanca o TDD (Test Driven Development), entre otras, las cuales se detallaran más adelante.

Entre sus ventajas se encuentran:

1. Los defectos aparecen temprano
2. Ayuda a mantener el código
3. Reduce el coste de solución
4. Facilita las tareas de depuración
5. ayudan en el proceso de debugging

Hay que tener en cuenta que con su incremento pueden ralentizar los despliegues, y que su uso requiere concimiento: otra mentalidad al momento de escribir las pruebas, aprender el funcionamiento de la librería de pruebas, saber cómo trabajar con datos de prueba, saber abstraer/simplificar unas partes del sistema para poder escribir las pruebas, saber estructurarles, hacerlas resistentes al cambio y comprensibles, etc.

Test de integración

Un test de integración es aquel que combinando diferentes módulos prueba la comunicación entre ellos. Por ejemplo, comunicaciones:

• Interfaz -> BBDD
• Interfaz -> API
• Interfaz -> Interfaz

Como estos sistemas ya tienen sus pruebas unitarias pasadas, los fallos detectados están realacionados con la interoperabilidad y la comunicación entre los mismos.

Normalmente cada equipo, o cada miembro de un equipo, desarrolla una parte del software. Por lo que, deben acordar, por ejemplo el paso de parámetros, o si tenemos que trabajar con una API de terceros, tendremos que seguir lo acordado en el juego de petición respuesta. Uno de los métodos utilizados es el de pruebas de caja negra, caja blanca o caja gris, entre otras, las cuales se detallaran más adelante.

Suelen ser también los desarrolladores los que escriben estos test en fases tempranas del desarrollo, cuando todavía no se implica al QA. Sin embargo, otra práctica habitual, es la de contratar a una empresa tercera especializada en pruebas.

Entre las estrategias de integración, podemos indicar las siguientes:

1. Big bang
2. Top down
3. Bottom up
4. Hibrido / sandwich

Test de sistemas

Las pruebas de sistema implican las pruebas del sistema al completo, desde que una acción es activada en el producto hasta que acaba.

De esta manera con todos los elementos integrados comprobaremos si el sistema al completo funciona como se espera o no.

Son los QAs especializados, o independientes, los que diseñan y ejecutan estos casos de prueba.

Los tipos de pruebas se pueden clasificar en funcionales y no funcionales.

Entre sus ventajas:

• No es necesario tener ningún conocimiento de cómo se ha desarrollado el código.
• Reduce los errores post-despliegue
• Valoración de la experiencia de usuario
• Multidisciplinar
• Testing de navegación (Exploratory Testing)
• Entornos para reproducir incidencias
• Se prueban Arquitectura y Requisitos

Test de aceptación

Son las pruebas que se realizan sobre el producto final, si no en el entorno final, en uno practicamente igual.

Esta es la fase en la que el cliente decide el GO/NO GO del producto a un entorno productivo. Es el último paso para finalizar la entrega del producto al cliente.

Entre los objetivos de las pruebas de aceptación se encuentran:

• Ganar confianza en el producto
• Conseguir el OK para el paso a producción
• Conseguir la aceptación del cliente de que lo que se ha diseñado y aprobado en las fases anteriores es realmente lo que el cliente pedía
• Asegurar que el producto sigue los estándares de mercado (Lo prueban diferentes perfiles)
• Comparar el producto con otros similares del mercado

Algunos de los tipos de test de aceptación son:

• UAT (User Acceptance Testing)
• BAT (Business Acceptance Testing)
• CAT (Contract Acceptance Testing)
• RAT (Regulations / Compliance Acceptance Testing)
• OAT (Operational Acceptance Testing)
• Alfa testing
• Beta testing

Tipos de prueba

Funcionales

En ellas se comprueba lo que el sistema hace. La funcionalidad puede estar descrita en:

• Requerimientos
• Especificaciones funcionales
• Casos de uso
• No estar documentadas

Suelen estar relacionadas con las pruebas de caja negra.

A su ves, según su ejecución, las pruebas funcionales se clasifican en manuales y automáticas.

Las pruebas manuales son las que ejecuta un tester como si fuese un usuario pero siguiendo una serie de pasos establecidos o test plan, diseñado en el análisis de los requisitos para garantizar que hace lo que debe (casos positivos), que no falla (casos negativos) y que es lo que se ha solicitado.

El tester realizará las acciones indicadas en cada step del caso de prueba comprobando que se cumple el resultado esperado.

Si el resultado es distinto al esperado, se reportará un defecto con todo detalle: descripción, datos utilizados, capturas de pantalla, etc. para facilitar la solución del defecto por parte de los desarrolladores.

Las pruebas funcionales automáticas son pruebas funcionales que se automatizan para "ahorrar tiempo de pruebas". El objetivo de las pruebas funcionales automáticas es comprobar que nada de lo probado con anterioridad ha dejado de funcionar como debería.

A partir de los casos de prueba de las pruebas manuales, se automatizan los casos de prueba que se repitan en las ejecuciones. Esos casos suelen ser los más importantes (happy flow) de los módulos o procesos de negocio "vitales" de la aplicación, es decir, los procesos que siempre tienen que funcionar y que bajo ningún concepto pueden fallar.

Para esa automatización, estos deben ser los pasos a seguir:

1. Elegir la prueba
2. Precondición
3. Pasos
4. Comprobaciones
5. Reporte estado final

No funcionales

Consideran el “comportamiento externo” del sistema comprobando cómo responde en términos de estrés, escalabilidad, carga, seguridad, etc.

Pueden hacer referencia a estándares de calidad, como la ISO 9126.

Podemos clasificar las pruebas no funcionales según el tipo de requisito no funcional que abarcan:

• Compatibilidad
• Seguridad
• Estrés
• Usabilidad
• Rendimiento
• Internacionalización y localización
• Escalabilidad
• Mantenibilidad
• Instalabilidad
• Portabilidad

Regresivas

Son cualquier tipo de pruebas de software con el objeto de descubrir errores (bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, causados por la realización de un cambio en el programa.

Se evalúa el correcto funcionamiento del software desarrollado frente a evoluciones o cambios funcionales. El propósito de éstas es asegurar que los casos de prueba que ya habían sido probados y fueron exitosos permanezcan así. Se recomienda que este tipo de pruebas sean automatizadas para reducir el tiempo y esfuerzo en su ejecución.

Técnicas de prueba

Caja blanca

Las técnicas de pruebas de caja blanca analizan las estructuras internas, las estructuras de datos utilizadas, el diseño interno, la estructura de código y el funcionamiento del software.

En este tipo de pruebas el código es accesible por el probador, por lo que tiene que tener conocimientos de codificación para entenderlo y diseñar las pruebas correspondientes.

Comprueban:

• problemas de seguridad internos
• mala o inexistente calidad en las estructuras de código
• el flujo para cada input en el código
• resultado esperado
• funcionalidad de los bucles condicionales
• prueba de cada declaración, objeto y función de forma individual

Se realizan de forma iterativa siguiendo estos tres pasos:

1. Entender el código fuente
2. Crear los casos de prueba
3. Ejecutar los casos de prueba

Las técnicas más conocidas implican:

• Cobertura de sentencia

Su objetivo es atravesar todos los estados al menos una vez. Por lo tanto, cada línea de código es probada. En el caso de un diagrama de flujo, cada nodo debe ser atravesado al menos una vez. Puesto que todas las líneas de código están cubiertas, ayuda encontrar el código defectuoso.

• Cobertura de rama

En esta técnica, los casos de prueba se diseñan de manera que cada rama de todos los puntos de decisión se atraviese al menos una vez

Caja negra

Se define como una técnica de prueba en la que la funcionalidad de la aplicación bajo prueba, se prueba sin tener en cuenta la estructura del código interno, los detalles de implementación y el conocimiento de las estructuras internas del software. Este tipo de pruebas se basa completamente en los requisitos y especificaciones del software

Las ténicas más habituales son:

• Dirigidas por la sintaxis
• Partición de equivalencia
• Valores Limite
• Gráficos efecto causa
• Basada en Requisitos
• Pruebas de Compatibilidad

Comparación

	Caja blanca	Caja negra
¿Qué valida?	La estructura interna y el funcionamiento del código	Los requisitos funcionales
Respecto al conocimiento del código....	El conocimiento del lenguaje de programación subyacente es esencial	Proporcionan abstracción del código y se centran en el esfuerzo de probar el comportamiento del sistema de software
Sobre la comunicación...	No facilitan la comunicación de pruebas entre los módulos	Facilitan la comunicación de pruebas entre los módulos

Basadas en la experiencia - Alfa y beta testing

El Alpha Testing es un tipo de prueba de aceptación; se realiza para identificar todos los posibles problemas/errores antes de lanzar el producto a los usuarios o al público en general.

El objetivo de esta prueba es simular usuarios reales utilizando técnicas de Caja Negra y Caja Blanca. El objetivo es llevar a cabo las tareas que un usuario típico podría realizar.

El Beta Testing es la segunda fase del Software Testing en la que una muestra de la audiencia objetivo prueba el producto. Las pruebas beta de un software son realizadas por usuarios reales de la aplicación en un entorno real.

Tipo de Beta Testig	Descripción
Tradicionales	El producto se distribuye al mercado objetivo, y los datos relacionados se recopilan en todos los aspectos. Estos datos pueden ser utilizados para mejorar el producto.
Públicas	El producto se da a conocer públicamente al mundo exterior a través de canales en línea y los datos se pueden obtener de cualquier persona
Ensayos Técnicos	El producto se entrega al grupo interno de una organización y recoge los comentarios y datos de los empleados de la organización.
Enfocada	El producto se lanza al mercado para recabar información sobre las características específicas del programa
Post-Lanzamiento	El producto se lanza al mercado y se recopilan datos para hacer mejoras para el futuro lanzamiento del producto

Se puede ver una comparativa sobre las características del alfa y beta testing en la siguiente tabla:

	Alfa	Beta
Entorno	Interno	Del cliente
Equipos implicados	Analistas de negocio y desarrolladores	Solamente el cliente final está implicado en las pruebas y en el reporte
Conocimientos	Equipo altamente cualificado en calidad	Pueden ser usuarios finales ingenuos o competentes del producto
Caja	Blanca y negra	Negra
Cuando se realizan	Antes del lanzamiento de un producto de software al mercado	En el momento de la comercialización del producto de software
Objetivo	Asegurar la calidad del producto	Además recogen las opiniones de los usuarios sobre el producto y aseguran que este está listo para los usuarios en tiempo real
Fiabilidad y seguridad	No se realizan pruebas de fiabilidad y seguridad	Pruebas de fiabilidad, seguridad y robustez
Sobre el tiempo de ciclo	Puede ser necesario un ciclo de ejecución largo	Sólo se requieren unas pocas semanas de ejecución
Sobre cuándo se resuelven los problemas	Los problemas críticos o correcciones pueden ser resueltos por los desarrolladores inmediatamente	La mayoría de los problemas o comentarios que se recogen se implementarán en futuras versiones del producto

Organización de los casos de prueba y herramientas para su gestión

Es necesario organizar los casos de prueba para:

1. Facilitar la comprensión del proyecto, desde un punto de vista de las pruebas.
2. Comprender la funcionalidad y la prioridad fácilmente
3. Facilitar las regresiones, completas o parciales
4. Aumentar la calidad
5. Facilitar la escalabilidad del proyecto

La documentación

Todo el proceso de desarrollo de software debe quedar perfectamente documentado, para pasar así de una fase a otra de forma clara y definida. Además, es importante también para poder acometer futuras revisiones del proyecto.Se distinguen tres grandes documentos en el desarrollo de software:

Guía técnica

Información que contiene:

• El diseño de la aplicación.
• La codificación de los programas.
• Las pruebas realizadas.

Está dirigido a:

• Personal técnico en informática (analistas y programadores)

El objetivo es:

• Facilitar un correcto desarrollo, realizar correcciones en los programas y permitir un mantenimiento futuro.

Guía de uso

Información que contiene:

• Descripción de la funcionalidad de la aplicación.
• Forma de comenzar a ejecutar la aplicación.
• Ejemplos de uso del programa.
• Requerimientos software de la aplicación.
• Soluciones de los posibles problemas que se pueden presentar.

Está dirigido a:

• Usuarios que van a utilizar la aplicación (clientes).

El objetivo es:

• Dar a los usuarios finales toda la información necesaria para utilizar la aplicación.

Guía de instalación

Información que contiene:

• Toda la información necesaria sobre puesta en marcha, explotación y seguridad del sistema.

Está dirigido a:

• Personal informático responsable de la instalación, en colaboración con los usuarios que van a usar la aplicación (clientes).

El objetivo es :

• Dar toda la información necesaria para garantizar que la implantación de la aplicación se realice de forma segura, confiable y precisa.

Conclusiones

Se ha presentado una visión global de las tareas de prueba y documentación ya que son de vital importancia durante el desarrollo de software.

Las pruebas permiten verificar que el software que se está creando es correcto y cumple con las especificaciones impuestas por el usuario, garantizando así la calidad del producto entregado.

Y por otra parte, una correcta documentación durante el desarrollo de software influirá también positivamente en la calidad del software, su utilización, soporte y posterior mantenimiento y evolución.

Anexo I - Herramientas Software para la realización de pruebas

Se presenta a continuación una tabla con varias herramientas que permiten la gestión y automatización de ciertos tipos de pruebas de software

Tipo de prueba	Herramienta	Lenguajes	Comentario
Unitaria	JUnit 5	Java
	Mocha	Javascript	Test framework que corre en Node.js y en el navegador
	PHPUnit	PHP	La versión 10 está en desarrollo
	NUnit	.NET
	PyUnit	Python
BDD	Behat	PHP	Framework libre de Behavior-Driven Development para PHP
	Cucumber		Herramienta utilizada para ejecutar pruebas de aceptación automáticas creadas en formato BDD. Destaca su capacidad de llevar a cabo descripciones funcionales de texto sin formato (escritas en un lenguaje llamado Gherkin) como pruebas automatizadas.
	Chai	Javascript
	Karma	Javascript
Funcional y de regresión	Selenium
	Cypress		Framework de pruebas todo en uno que facilita la integración continua
Integración	SoapUI		Aplicación de prueba de API para tecnologías SOAP y REST, permite también pruebas funcionales y de rendimiento
	Postman		Utilizada principalmente para el testing de API REST
Carga y rendimiento	Apache JMeter
	Gatling		Herramienta para pruebas de estrés
	LoadRunner
Aceptación	FitNesse		Herramienta de automatización de test de aceptación mediante su documentación en wiki
	Concordion		Framework orientado al desarrollo de tests de aceptación. Funciona a través de tests escritos en HTML
	Acunetix		Software de pruebas automáticas de seguridad web
	Nessus		Programa de escaneo de vulnerabilidades que permite agilizar pruebas de seguridad
Gestión	TestLink
	TestRail
	Practitest
Múltiples	Codeception	PHP	Permite realización de pruebas unitarias, integración, aceptación, BDD....
	TestNG	Java	Framework para pruebas y testing que. Está basado en JUnit (para Java) y NUnit (para .NET) pero introduciendo nuevas funcionalidades que los hacen más poderosos y fáciles de usar.

Anexo II - Herramientas Software para la documentación

Herramienta	Comentario
Atlassian Confluence	Módulo de Jira que permite documentar los how-to y las referencias técnicas llegando a asociar Ticket de Jira - Documentación de código – Rama de Git (o Subversion).
Javadoc	Generador de documentación para el lenguaje Java para generar documentación de API en formato HTML desde el código fuente de Java.
phpDoc	Es una adaptación de javadoc para php que define un estándar oficial para comentar código php.
Read the Docs	Plataforma gratuita para el alojamiento de documentación de software con código fuente; facilita la redacción de documentación técnica al automatizar la creación y el control de versiones.
Huddle	Centro de colaboración todo-en-uno para los equipos. Utilizado por empresas grandes que necesitan herramientas estar sincronizadas, incluidos el almacenamiento de archivos, la gestión de proyectos y las herramientas de colaboración.
Sphinx	Software generador de documentación que convierte ficheros reStructuredText en sitios web HTML y otros formatos, incluyendo PDF, EPub y man

Bibliografía

• Pressman, R. S. Ingeniería del Software: Un enfoque práctico. Editorial McGraw-Hill
• Sommerville, I. Ingeniería del software. Editorial Addison Wesley
• Norma ISO/IEC/IEEE 29119(Estándar para pruebas del software).
• Métrica versión 3. Metodología de planificación, desarrollo y mantenimiento de sistemas de información. Ministerio para las Administraciones Públicas.
• International Software Testing Qualifications Board

Referencias

• Curso de introducción al testing en OpenWebinars
• https://www.preparadorinformatica.com/images/pdf/Tema-30.pdf