Un conjunto de actividades de pruebas suele orientase a

comprobar determinados aspectos de un sistema software (o de una parte del

mismo). Continuando as con nuestro anterior artculo sobre el modelo de
cebolla para los Niveles de Pruebas Software, y siguiendo las directrices
del ISTQB, acotaremos los Tipos de Pruebas Software en funcin del
objetivo en que se centran.

En primer lugar tenemos las Pruebas Software Funcionales. Tpicamente

encontraremos el comportamiento del sistema, subsistema o componente
software descrito en especificaciones de requisitos o casos de uso,
aunque tambin puede no estar documentado (que funcione como el sistema
al que sustituye) . Es decir, con las funciones establecemos lo que el
sistema hace.

Estas pruebas se definen a partir de funciones o caractersticas (como

decimos, bien descritas en documentos o bien interpretadas por los
probadores) y su interoperabilidad con sistemas especficos, pudiendo
ejecutarse en todos los niveles de pruebas (componentes, integracin,
sistema, etc).

Se consideran Pruebas de Caja Negra (black-box testing) puesto que

valoramos el comportamiento externo del sistema. Las Pruebas de
Seguridad o las Pruebas de Interoperabilidad entre sistemas o
componentes son casos especializados de las pruebas funcionales.

En segundo lugar figuran las Pruebas Software no Funcionales que

incluyen las pruebas de: Rendimiento, Carga, Estrs, Usabilidad,
Mantenibilidad, Fiabilidad o Portabilidad, entre otras. Por tanto se centran
en caractersticas del software que establecen cmo trabaja el sistema.

Estas pruebas tambin pueden ejecutarse en todos los niveles de

pruebas. Las caractersticas no funcionales del software se pueden medir de
diversas maneras, por ejemplo, por medio de tiempos de respuesta en el
caso de pruebas de rendimiento o por nmero mximo de sesiones en
pruebas de estrs.

Puesto que las Pruebas software no Funcionales normalmente consideran el

comportamiento externo del sistema, en la mayora de los casos se utilizan
tcnicas de Pruebas de Caja Negra.

A continuacin, en tercer lugar, tenemos las Pruebas Software

Estructurales. Nuevamente pueden ejecutarse en todos los niveles de
pruebas (ya sabis: componentes, integracin, sistema, etc.) y encajan muy
bien si hemos utilizado tcnicas de especificacin de la estructura o
arquitectura del Software. Es posible aplicar tcnicas estticas de anlisis de
cdigo.

Para expresar el alcance con un conjunto de pruebas (test suite) que ha

cubierto la estructura o arquitectura en cuestin, se utiliza el concepto
de Cobertura (Coverage), normalmente en forma de porcentaje.

Es especialmente habitual utilizar herramientas de apoyo para calcular la

cobertura del cdigo en el caso de Pruebas de Componentes o en Pruebas
de Integracin de Componentes (por ejemplo, trazando la jerarqua de
llamadas entre elementos). Puesto que indagamos en el comportamiento
interno, estas pruebas se denominan tambin Pruebas de Caja
Blanca (white-box testing).
Finalmente, el cuarto tipo de pruebas que nos presenta el ISTQB son las
pruebas derivadas de la realizacin de cambios: las Pruebas Software de
Regresin y las Re-pruebas.

Una vez que un defecto ha sido corregido, toca volver a probar el software
para confirmar que el defecto ha sido eliminado. Son pruebas repetidas o Re-
Pruebas.

Las Pruebas de Regresin consisten en volver a probar un componente, tras

haber sido modificado, para descubrir cualquier defecto introducido, o no
cubierto previamente, como consecuencia de los cambios. Los defectos
pueden encontrarse tanto en el software que se ha cambiado como en algn
otro componente. Se ejecutan cuando se cambia el software o su entorno. El
criterio para decidir la extensin de estas Pruebas de Regresin est basado
en el riesgo de no encontrar defectos en el software que anteriormente
estaba funcionando correctamente.

Las Pruebas de Regresin se realizan sobre un componente ya probado,

para verificar que no presenta nuevos defectos cuando se realiza una
modificacin despus de dichas pruebas.

Este tipo de pruebas software deben ser repetibles si han de usarse para
pruebas de confirmacin (o aseguramiento) y regresin (como Sondas de
Disponibilidad, por ejemplo). Los conjuntos de pruebas de regresin
(Regression test suites) suelen ser bastante estables por lo que son muy
buenos candidatos para actividades de automatizacin de pruebas
software.
Quiz ya no os sorprenda que estas pruebas tambin puedan ejecutarse en
todos los niveles de pruebas e incluyen casos de prueba de los tipos vistos
anteriormente: Pruebas Funcionales, No Funcionales y Estructurales

. 10 tipos de pruebas no funcionales

A continuacin te presentamos una lista no limitativa de 10 tipos de pruebas

no funcionales que puedes incluir en tu plan de pruebas de software.

1. - Pruebas de carga

Las pruebas de carga consisten en simular demanda sobre una aplicacin de

software y medir el resultado. Estas pruebas se realizan bajo demanda
esperada y tambin en condiciones de sobrecarga (picos en la demanda).

Para ejecutar estas pruebas, se requiere del uso de herramientas que

simulen la carga, como por ejemplo SoapUI.

Las pruebas de carga ayudan a identificar la mxima capacidad operativa de

una aplicacin, as como en el identificar cuellos de botella y las causas de
posible degradacin del desempeo.

Cuando la carga de prueba se eleva por encima de los parmetros

esperados, a estas pruebas se les conoce como pruebas de estrs.

2. - Pruebas de estrs

Son pruebas de carga que se realizan con demandas mayores a la capacidad

operativa, con frecuencia hasta llegar al punto de ruptura.

Este tipo de prueba de software se utiliza para determinar la estabilidad de

un sistema o aplicacin, con especial atencin en la disponibilidad y manejo
de errores cuando se enfrenta a la sobrecarga.

Al igual que para las pruebas de carga, se requieren de herramientas que

simulen la demanda, SoapUI es una de estas herramientas que permite
simular peticiones para servidores de aplicaciones web.

Aqu te compartimos un Tutorial de SopaUI.

Con las pruebas de estrs se pueden identificar los puntos de ruptura, lmites
para uso seguro de la aplicacin, confirmar las especificaciones de diseo,
identificar las formas en que el sistema falla, entre otros aspectos.

3. - Pruebas de volumen

Las pruebas de volumen consisten en validar el funcionamiento de la

aplicacin con ciertos volmenes de datos.

Por ejemplo, si se quiere ver el comportamiento de una aplicacin con un

tamao de base de datos especfico, se expande el tamao de base de datos
a dichos parmetros y luego e realizan consultas, procesos o funcionalidades
de la aplicacin, midiendo su desempeo.

El sujeto de pruebas no est limitado a bases de datos, tambin se puede

usar por ejemplo para medir el desempeo de una interfaz cuando el archivo
de interfaz (un archivo de texto, xml, etc.) supera cierto tamao.

El objetivo es ver si dado ciertos volmenes de datos la aplicacin funciona

con normalidad, cuales son los lmites mximos de volmenes de datos para
la operacin e identificar condiciones de falla.

4. - Pruebas de configuracin

En lugar de probar el desempeo de una aplicacin desde la perspectiva de

la carga, las pruebas de configuracin se usan para validar que efectos en el
desempeo tienen ciertos cambios en la configuracin.

Un ejemplo tpico de esta situacin es experimentar con diferentes mtodos

de balanceo de cargas y ver la respuesta de la aplicacin a niveles similares
de sobrecarga.

Otro ejemplo es verificar si el sistema es capaz de funcionar adecuadamente

en diferentes versiones o configuraciones de entornos de hardware y
software, como pueden ser diversos navegadores de internet, versiones de
navegadores, entre otros.

5. - Pruebas de usabilidad

En las pruebas de usabilidad, los testers de software se enfocan en validar

que tan fcil de usar es una determinada aplicacin.
Las caractersticas evaluadas en la usabilidad incluyen:

Facilidad de aprendizaje: Que tan fcil es para los usuarios realizar

funciones bsicas la primera vez que utilizan la aplicacin.
Eficiencia: Que tan rpido los usuarios experimentados pueden
realizar sus tareas.
Memorizacin: Que tan fcil de memorizar es el uso de la aplicacin,
esto es, cuando un usuario pasa mucho tiempo sin usar la aplicacin, puede
recordar lo suficiente para usarla con efectividad la prxima vez, o tiene que
empezar a aprender de nuevo.
Errores: Cuantos errores atribuibles al diseo comete el usuario, que
tan severos son y que tan fcil es recuperarse de los mismos.
Satisfaccin: Que tanto le gusta (o desagrada) al usuario utilizar el
sistema.

6. - Pruebas de seguridad

Consiste en probar los atributos o caractersticas de seguridad del sistema, si

es un sistema seguro o no, si puede ser vulnerado, si existe control de acceso
por medio de cuentas de usuario, si pueden ser vulnerados estos accesos.

Las pruebas de seguridad tambin sirven para validar si el equipo de

desarrollo de software ha seguido prcticas de seguridad recomendadas
en su programacin.

Entre las caractersticas de seguridad de un sistema, estn la

confidencialidad, integridad, autenticacin, autorizacin y la disponibilidad.

7. - Pruebas de resistencia

Las pruebas de resistencia implican someter a un Sistema o aplicacin a una

carga determinada durante un perodo de tiempo, para determinar cmo se
comporta luego de un uso prolongado.

Un sistema informtico puede comportarse de forma normal durante las

primeras horas, sin embargo, luego de cierto tiempo, problemas como fugas
de memoria suelen ocasionar fallas.

Estos defectos en el desarrollo de software no pueden identificarse bajo

pruebas funcionales normales, por lo que es conveniente involucrar pruebas
de resistencia entre los tipos de pruebas de software.
8. - Pruebas de escalabilidad

Las pruebas de escalabilidad consisten en verificar la capacidad de una

aplicacin de escalar cualquiera de sus caractersticas no funcionales, como
por ejemplo la carga que soporta, nmero de transacciones, volmenes de
datos, entre otros.

Al disear casos de prueba de escalabilidad, es recomendable

considerarlos en bloques incrementales, dada la dificultad de predecir la
carga real que tendr una aplicacin luego de implementada en produccin.

Probar en bloques incrementales significa por ejemplo primero probar con

niveles de demanda bajos, luego incrementar a niveles de demanda medios y
finalmente probar con altos niveles de carga. De esta manera se puede
determinar que tambin escala la aplicacin y los problemas que comienzan a
surgir en distintos niveles.

Para que los resultados sean confiables, los ambientes de prueba y su

configuracin deben mantenerse constantes.

9. - Pruebas de recuperacin

Las pruebas de recuperacin se realizan para verificar que tan rpido y que
tan bien se recupera una aplicacin luego de experimentar un fall de
hardware o software.

Por lo tanto, para realizar pruebas de recuperacin se requiere forzar la falla y

luego verificar si la recuperacin ocurre adecuadamente.

Por ejemplo, cuando una aplicacin est funcionando desconectar el cable de

red, o en una aplicacin mvil interrumpir la conexin con la red Wi-Fi o con
la operadora, para luego restablecer la conexin.

10. - Pruebas de mantenibilidad

Bsicamente consisten en evaluar que tan fcil es realizar el mantenimiento

de un sistema o aplicacin. Esto significa que tan fcil es analizar, cambiar y
probar estos cambios.

Para realizar esta prueba deben evaluarse la forma en que est

implementada la aplicacin, siguiendo buenas prcticas de ingeniera de
software. Es decir, que se estn siguiendo los patrones recomendados de
ingeniera de software y que no se estn introduciendo inadvertidamente anti
patrones, esto es, que no se estn cometiendo errores comunes de
programacin.
Ciclo de vida del 'software'
El trmino ciclo de vida del software describe el desarrollo de software,
desde la fase inicial hasta la fase final. El propsito de este programa es
definir las distintas fases intermedias que se requieren para validar el
desarrollo de la aplicacin, es decir, para garantizar que el softwarecumpla
los requisitos para la aplicacin y verificacin de los procedimientos de
desarrollo: se asegura de que los mtodos utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los

errores que se detectan tarde dentro de la fase de implementacin. El ciclo de
vida permite que los errores se detecten lo antes posible y, por lo tanto,
permite a los desarrolladores concentrarse en la calidad del software, en los
plazos de implementacin y en los costos asociados.

El ciclo de vida bsico de un software consta de los siguientes

procedimientos:

Definicin de objetivos: define la finalidad del proyecto y su papel en la

estrategia global.

Anlisis de los requisitos y su viabilidad: recopila, examina y formula los

requisitos del cliente y examina cualquier restriccin que se pueda aplicar.

Diseo general: requisitos generales de la arquitectura de la aplicacin.

Diseo en detalle: definicin precisa de cada subconjunto de la aplicacin.

Programacin (programacin e implementacin): implementacin de un

lenguaje de programacin para crear las funciones definidas durante la etapa
de diseo.

Prueba de unidad: prueba individual de cada subconjunto de la aplicacin

para garantizar que se implementaron de acuerdo con las especificaciones.

Integracin: garantiza que los diferentes mdulos se integren con la

aplicacin. Este es el propsito de la prueba de integracin que est
cuidadosamente documentada.

Prueba beta (o validacin): garantiza que el software cumple con las

especificaciones originales.

Documentacin: sirve para documentar informacin necesaria para los

usuarios del software y para desarrollos futuros.

Implementacin

Mantenimiento: comprende todos los procedimientos correctivos

(mantenimiento correctivo) y las actualizaciones secundarias
del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de

vida de una aplicacin dependen del tipo de modelo de ciclo de vida acordado
entre el cliente y el equipo de desarrolladores.