Pruebas de software

Este artículo o sección tiene referencias, pero necesita más para complementar su verificabilidad. Busca fuentes: «Pruebas de software» – noticias · libros · académico · imágenes Este aviso fue puesto el 27 de noviembre de 2018.

Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar una devolución sobre el funcionamiento de un programa de software. Es una actividad más en el proceso de desarrollo de software, usualmente parte del control de calidad.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo.

Un caso de pruebas es una breve declaración de algo que debería ser probado. Es el mecanismo, manual o automático, que verifica si el comportamiento del sistema es el deseado o no.^[1]​

El objetivo de las pruebas es presentar información sobre la calidad del producto a las personas responsables de éste. Las pruebas de calidad presentan los siguientes objetivos: encontrar defectos o bugs, aumentar la confianza en el nivel de calidad, facilitar información para la toma de decisiones, evitar la aparición de defectos.

Teniendo esta afirmación en mente, la información que puede ser requerida es de lo más variada. Esto hace que el proceso de pruebas sea completamente dependiente del contexto en el que se desarrolla.^[2]​

El ambiente ideal de las pruebas es aquel que es independiente del desarrollo del software, de esta manera se logra objetividad en las pruebas.

A pesar de lo que muchos promueven, no existen las "mejores prácticas" como tales. Toda práctica puede ser ideal para una situación, pero completamente inútil o incluso perjudicial en otra.

Por esto, las actividades técnicas, documentación, enfoques y demás elementos que condicionarán las pruebas a realizar deben ser seleccionadas y utilizadas de la manera más eficiente según contexto del proyecto.

Tenemos el proceso de desarrollo en cascada, se denomina de este modo, ya que a cada salida de una etapa cae en la siguiente, es decir, las etapas se llevan a cabo una a continuación de la otra. Una de las peculiaridades de este proceso, es que no está previsto volver a una etapa anterior, es decir si se olvidó relevar algún requerimiento al comienzo, no tiene una alternativa para considerar este caso. Este proceso supone cada etapa independiente de las etapas anteriores.

También tenemos el desarrollo iterativo y creciente, se tiene las mismas etapas que en el Proceso de Desarrollo en Cascada, sin embargo, en este proceso, la etapa de relevamiento se divide en distintos subconjuntos y cada uno de estos sub conjuntos se construye de la misma forma que con el ciclo de vida en cascada. Se van desarrollando por partes que luego se integran, una vez finalizadas las mismas.

Otro Proceso de Desarrollo que tenemos es el Iterativo, en este tenemos las mismas etapas de desarrollo que los procesos anteriores, pero trabajamos sobre el todo, no necesariamente conocemos al comienzo todos los detalles del producto que queremos construir.

Y por último tenemos el desarrollo ágil de software, este es un proceso iterativo e incremental, se caracteriza por contar con iteraciones cortas y por no tener fases lineales, tipo cascada en cada iteración. Existen distintas metodologías Ágiles, que entre las más conocidas y utilizadas encontramos "Scrum" y "XP: Extreme Programming".

Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación.

Puede referirse a la revisión de documentos, ya que no se hace una ejecución de código. Esto se debe a que se pueden realizar "pruebas de escritorio" con el objetivo de seguir los flujos de la aplicación.

Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación.

Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca con mayor amplitud. Debido a la naturaleza dinámica de la ejecución de pruebas es posible medir con mayor precisión el comportamiento de la aplicación desarrollada.

Antes de entender para que les sirve a los probadores beta trabajar con el documento de especificación de requerimientos, debemos saber qué son las especificaciones de requerimientos (ESRE).

Las Especificaciones de Requerimientos son un documento clave en el desarrollo de Software. Cuando consideramos los ciclos de vida clásicos, tiene la descripción completa de lo que va a hacer el sistema sin describir cómo lo va a hacer. Estos documentos tienen una estructura en forma de reporte bastante definida, poseen carátula, historial de cambios, introducción, definiciones, acrónimos y abreviaturas, especificación de requerimientos funcionales, especificación de requerimientos no funcionales y casos de uso.

Los probadores beta se guían en este documento para validar si el sistema se comporta de la manera que indican las ESRE. Contiene información detallada sobre los requisitos funcionales y no funcionales que el Cliente desea en el sistema. También se pueden ejecutar casos de pruebas a partir de las especificaciones de requerimientos ya que estos resultan muy útiles porque son sencillos de seguir y se conocen de antemano los posibles resultados.

• Pruebas manuales
• Pruebas automáticas

• Pruebas de Caja blanca

• Pruebas de Caja negra

• Pruebas aleatorias^[3]​

Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software (requisitos funcionales). Hay distintos tipos como por ejemplo:

Podemos considerar el proceso de pruebas funcionales como un proceso donde se va probando inicialmente lo de más bajo nivel y se van integrando y probando paulatinamente componentes hasta lograr un sistema completo totalmente probado. Por eso se dice que hay distintos niveles de prueba. Se empieza por las pruebas unitarias, luego las pruebas de Integración, luego las de pruebas de sistema, las de humo, las alpha, las beta y finalmente las de pruebas de aceptación.

Las pruebas de regresión se puede considerar como la ejecución (normalmente automática) de las pruebas ya realizadas hasta el momento.

Una prueba no funcional es una prueba cuyo objetivo es la verificación de un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema (requisitos no funcionales) como por ejemplo la disponibilidad, accesibilidad, usabilidad, mantenibilidad, seguridad, rendimiento. Podemos clasificar las pruebas no funcionales según el tipo de requisito no funcional que abarcan:

Se está probando otro aspecto que no tenga nada que ver con el uso final del entregable.

Este artículo o sección se encuentra desactualizado. La información suministrada ha quedado obsoleta o es insuficiente. Este aviso fue puesto el 18 de octubre de 2021.

El control de la calidad de software lleva consigo aplicativos que permiten realizar pruebas autónomas y masivas permitiendo así la verificación desde el punto de vista estático y de caja blanca, es decir pruebas donde se analiza el software sin ejecutar el software mediante el código fuente del mismo. Podemos encontrar herramientas escritas en software libre, código abierto o software privativo.^[4]​ Estas herramientas podrán ser utilizadas para diferentes tipos de pruebas como por ejemplo:

1. Herramientas de gestión de pruebas
2. Herramientas para pruebas funcionales
3. Herramientas para pruebas de carga y rendimiento

1. Herramientas de gestión de pruebas

1. Herramientas para pruebas funcionales

1. Herramientas para pruebas de carga y rendimiento

• Ingeniería de software.
• Automatización de pruebas.
• Pruebas de humo (informática).
• Pruebas de remojo (informática)

• Pressman, Roger S.: Ingeniería del software: un enfoque práctico (información en inglés). McGraw Hill Higher Education, sexta edición.

• Nueva tendencia y posible futuro del testing: el Crowd Testing
• Context-driven Testing
• www.testingeducation.org
• ISO/IEC/IEEE 29119 Pruebas de Software (Grupo de Trabajo de AENOR AEN/CTN71/SC7/GT26)
• MÉTRICA v3 en el CSAE
• Functional Testing Types Explained With Examples
• STELA Automation made simple by Software Testing Bureau