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.
