Proceso de Pruebas de Software

Las pruebas de software son los procesos que permiten verificar y revelar la calidad de un producto software antes de su puesta en marcha. Básicamente, es una fase en el desarrollo de software que consiste en probar las aplicaciones construidas.

Las pruebas de software se integran dentro de las diferentes fases del ciclo de vida del software dentro de la Ingeniería de software. En este sentido, se ejecuta el aplicativo a probar y mediante técnicas experimentales se trata de descubrir qué errores tiene.

Estas pruebas hay que realizarlas al comienzo del ciclo de vida del software ya que, cuando avanzamos en el ciclo de vida, más costoso sería solucionar el fallo encontrado.

Generar Plan de Pruebas

El Plan de pruebas describe la estrategia, recursos y planificación de las pruebas. La estrategia de prueba incluye la definición del tipo de pruebas a realizar para cada iteración y sus objetivos, el nivel de cobertura de prueba y el porcentaje de prueba que deberían ejecutarse con un resultado específico.

El Plan de pruebas proporciona el marco dentro del cual el equipo de prueba desarrolla las pruebas trabajando con los recursos y la planificación dada.
El Plan de pruebas proporciona la siguiente información:
La definición de los objetivos de los objetivos de las pruebas en el ámbito de la iteración.
La definición de los elementos que se van a probar.
Una explicación del enfoque o estrategia que se usará.
Los recursos y planificación necesarios.
Los resultados que se obtienen del proceso de prueba.

Diseñar Pruebas Específicas

Al igual que la etapa de análisis, el diseño de las pruebas es una parte considerable de trabajo. Durante esta fase se diseñan e implementan los casos de prueba (Test Cases). Tomando como punto de partida el resultado del análisis de pruebas, se diseñan las pruebas en detalle, indicando cuáles son los pasos o el procedimiento a seguir, las técnicas, medidas o análisis que hay que aplicar así como los conjuntos de datos de prueba que se usarán, y los resultados esperados que se producirán, para conseguir demostrar que los objetivos de la prueba se cumplen y por lo tanto verifican y validan el requisito que cubren.
El diseño de las pruebas persigue la prevención de defectos, antes de que por codificación puedan haberse llegado a producir.

Un buen diseño de pruebas previene, en consecuencia, los defectos antes de que lleguen a etapas más tardías, con el consecuente ahorro que supondrá su corrección. Un buen plan de pruebas es una valiosa herramienta para luchar contra los defectos y será la base para el refinamiento del mismo tanto por que el producto software evoluciona, como porque el propio plan es susceptible de recisión y mejora.
Atendiendo a la fase en que serán aplicadas.

Pruebas unitarias.

Pruebas de integración. Tienen como objetivo validar la correcta operación entre los diferentes módulos del sistema. El objetivo es demostrar que las interfaces de cada módulo funcionan correctamente.

Pruebas de sistema.

Verifican el correcto funcionamiento del sistema completo incluyendo casos de prueba que busquen los fallos del sistema. Son pruebas destructivas y persiguen demostrar la robustez del sistema aun en condiciones adversas. Verifican requisitos funcionales y no funcionales. 

Pruebas de aceptación del usuario.

Similares a las de sistema, pero no destructivas. Permiten demostrar que el sistema funciona en condiciones normales. 

Pruebas de regresión.

Ejecutadas al final de cada iteración y antes de las pruebas de aceptación para asegurar que funcionalidades desarrolladas en iteraciones previas no han sufrido daños.

Pruebas de humo (Smoke o Sanity Tests). Selección de pruebas de alta prioridad que en poco tiempo ayudan a identificar si un despliegue en los entornos de producción o de aceptación ha funcionado de forma correcta. 

Estas pruebas se componen de pruebas desarrolladas con técnicas más específicas, como valores límite, tablas de decisión, pruebas de penetración etc. pero por su importancia para el sistema cabe destacar las pruebas de rendimiento.

Pruebas de rendimiento
Pruebas de carga (Load). 
Pruebas de redundancia (Failover) 
Pruebas de estrés.

Pruebas de rendimiento.

Pruebas de sensibilidad a carga de red.
Pruebas de Volumen.

Etc. 
Tomar Configuración del Software a Probar

La Gestión de Configuración de Software (SCM) es una disciplina de la Ingeniería de Software que se preocupa de:

Identificar y documentar las características funcionales y físicas de los elementos de configuración.
Controlar los cambios a tales características.
Reportar el proceso de tales cambios y su estado de implantación.

Evaluar Resultados.

Una vez obtenidos los resultados, antes de informar de ellos, el investigador debe dedicar algún tiempo a una fase especial: la evaluación. Debe evaluar los resultados: ¿son lo que él quería?, ¿Es posible mejorar algo en el informe? ¿Debe ser dejado fuera algo o merece el informe publicarse en su totalidad? 

Los criterios para la labor de evaluar proyectos de investigación se pueden derivar del propósito del proyecto. Las metas diferentes para la investigación se discuten bajo el título El contexto de un proyecto de investigación. Caen generalmente en dos grupos:

·         Los blancos teóricos apuntan a promover el conocimiento colectivo en el campo apropiado del estudio. Estos blancos pertenecen a los proyectos de la investigación básica y de la investigación aplicada.

·         Los blancos prácticos apuntan a mejorar el estado del objeto del estudio o de otros objetos similares en el futuro. Son típicas en los proyectos de la investigación aplicada y del desarrollo tecnológico. 

Los resultados teóricos son a menudo relativamente difíciles de ser evaluado directamente, porque los hallazgos más valiosos contienen a menudo descubrimientos novedosos para los cuales no hay todavía criterios. Por lo tanto la evaluación debe incluir generalmente no sólo el salida final ("output") pero también todas las tareas que el investigador ha ejecutado antes de llegar los resultados finales.

Estas evaluaciones se discuten en Evaluar la entrada teórica, Evaluar datos recogidos y Evaluar la corrección del análisis.

Los resultados prácticos pueden ser evaluados a menudo directamente e también fácilmente, vea la discusión en Evaluar los resultados prácticos. Esta sola evaluación da a menudo ya una resolución clara, y en tal un acontecimiento las evaluaciones adicionales son innecesarias. Sin embargo, los resultados prácticos, incluyendo los efectos secundarios no previstos, afectan a menudo a varios grupos de gente, y no es infrecuente que varios evaluadores deben ser utilizados y éstos dan opiniones disidentes. En tal caso puede ser provechoso recurrir a los procedimientos más meticulosos enumerados arriba.

Depuración

La depuración está estrechamente relacionada con el concepto de calidad. En un sentido amplio, depurar un programa significa librarlo de errores e inconvenientes más o menos graves, que con frecuencia es un proceso mucho más costoso y arduo de lo que pudiera parecer a primera vista, en especial en programas grandes y complejos. Sin embargo, es imprescindible si queremos ofrecer al público un producto con un mínimo de calidad.
En general la depuración de un programa se completa en tres fases; es un proceso en el que el producto se va acercando a la perfección (estar libre de errores e inconvenientes graves) mediante una serie de transformaciones sucesivas que responden al esquema de la figura.

En una primera fase, cuando ya el programa está prácticamente terminado, se somete a pruebas que podríamos llamar "de laboratorio" para comprobar que todo marcha según lo esperado y sin errores.  Son pruebas que realiza el propio programador antes de dar a conocer el producto. Estas versiones se suelen denominar alfa y corresponden a un punto en que el programa todavía está en fase de gestación. En una versión alfa son de esperar todo tipo de errores y "cuelgues".

En una segunda fase, cuando el programador cree que su producto ya está suficientemente presentable y él no consigue encontrar más errores aparentes (o los ya conocidos están en proceso de depuración), se procede a la distribución del producto a una serie de probadores seleccionados ("beta testers"). Son las denominadas versiones beta, que aunque con errores esporádicos, pueden tener un comportamiento más o menos aceptable.
Finalmente, en una tercera fase, con la información, opiniones y sugerencias de los "beta testers", se procede a lanzar la primera versión pública v 1.0 del producto ("Release"),  también denominadas versiones gamma. A partir de aquí, lo normal es que se vayan recogiendo las sugerencias, cuestiones y posibles errores que hayan pasado inadvertidos en las pruebas beta y sean reportados por los usuarios. Las soluciones a estos problemas, junto con las mejoras que se vayan incorporando, son implementadas en versiones sucesivas.  Generalmente a partir de la versión 2.0 el producto se considera estable.

Análisis de Errores

Al realizar cálculos mediante algoritmos más o menos complejos, es inevitable cometer errores. Estos errores pueden ser de tres tipos:
Errores en los datos de entrada: Este tipo de error viene causado por los errores al realizar mediciones de magnitudes físicas.

Errores de redondeo: En este caso, el error aparece al operar con representaciones numéricas finitas. Se puede solucionar utilizando más decimales, pero esto conlleva utilizar más memoria (recursos). 

Errores de truncamiento (o discretización): Este tipo de error se refiere al error que se comete al utilizar un algoritmo determinado. Esto quiere decir que si se refina la discretización o se cambia el algoritmo, puede disminuir. Refinar la discretización generalmente lleva a realizar más cuentas lo que equivale a incrementar el error de redondeo y el tiempo de cálculo. 

El primer tipo de error no es analizable matemáticamente dado a que está sujeto al avance tecnológico de los aparatos de medida. El segundo y el tercer tipo de errores se pueden cuantificar de una forma aproximada utilizando expresiones adecuadas.

Descarga el PDF aquí