Tipos y etapas de las pruebas de software (Etapas del testing)

Etapas de pruebas

De acuerdo al ciclo de vida de las pruebas del Modelo General V propuesto por (Barry W., 1979), existen 4 etapas de en las cuales se pueden aplicar pruebas de acuerdo al grado de avance del proyecto de manera secuencial.

En cada etapa se pueden aplicar los diferentes tipos de pruebas indicados en el punto 2.6 sin embargo, esto depende del tipo de marco de referencia que se quiera aplicar, el tipo de software, la cultura organizacional del grupo de desarrollo y sobre todo el presupuesto asignado al proyecto.

Pruebas de componentes.

También llamadas pruebas unitarias, se ejecutan en la primera etapa donde los desarrolladores ya cuentan con los componentes del sistema desarrollados. Regularmente cada desarrollador prueba que sus componentes funcionen de acuerdo a lo esperado. Los componentes pueden ser dependiendo del lenguaje que se esté usando: módulos, unidades y clases en el caso de programación orientada a objetos.

Para estas pruebas regularmente se usan herramientas de depuración donde el programador va revisando línea a línea el comportamiento del código, al momento de detectar algún defecto procede a analizarlo y a resolverlo.

Las pruebas de componentes son las primeras pruebas a las que se somete el software.

Pruebas de integración

Se ejecutan una vez concluidas las pruebas de componentes se ejecutan pruebas teniendo todos o la mayor parte de componente integrados, para verificar que todos operen correctamente de manera conjunta. Se valida el software a través de varias interfaces y casos de uso tomando en cuenta que la salida de un componente es la entrada de otro.

En sistemas de tamaño medio a grande, estas pruebas regularmente son ejecutadas por los especialistas en pruebas con apoyo de los desarrolladores, requieren de una entidad que juegue el papel de mediador entre los diversos grupos que participan en estas pruebas.

A diferencia de las pruebas unitarias, las pruebas de integración, requieren una mejor estructura y organización, requiere al menos de un plan de pruebas.

Pruebas de sistema

Sirven para validar que todas las funciones y componentes del sistema colaboran correctamente. Estas pruebas se ejecutan una vez concluidas las pruebas de componentes y las de integración, a diferencia de estas 2 pruebas, las pruebas de sistemas se realizan desde el punto de vista del usuario y validan en su totalidad los requerimientos del usuario especificados e incluso aquellos no especificados u olvidados que afectan el funcionamiento del sistema.

Según (Bourne, 1997), al inicio de las pruebas de sistema sólo se han completado la mitad de los trabajos de control de calidad y pruebas, en especial cuando se habla de un sistema cliente-servidor. Esto da evidencia de la necesidad de estas pruebas.

Pruebas de aceptación

Antes de la liberación del software en el ambiente productivo es altamente recomendable que el usuario final valide el producto. El objetivo de estas pruebas es validar que el proveedor entendió y desarrolló lo que el usuario solicitó.

De acuerdo con (Spillner, Linz, & Schaefer, 2014) existen 4 tipos de pruebas de aceptación:

Pruebas de aceptación de contrato

El cliente prueba junto con el proveedor del sistema y con ello se decide si el sistema está listo para su liberación a producción o si requiere alguna modificación o corrección. Los criterios de aceptación sólo son los incluidos en el contrato del desarrollo pactado entre el proveedor del sistema y el cliente. Estas pruebas se deben de ejecutar en el ambiente real (productivo).

Pruebas de aceptación de usuario

Se recomienda cuando el usuario es diferente al cliente. El cliente suele organizar esta prueba y seleccionar los escenarios de uso típico. Se toma en cuenta el punto crítico del usuario.

Pruebas de aceptación operativa

Busca la aceptación del sistema por parte de los administradores que le darán soporte. Se pueden validar la generación y restauración de copias de seguridad, recuperación de desastres, gestión de usuarios y controles de seguridad.

Pruebas de campo (también llamadas pruebas alfa o beta)

Se consideran pruebas de campo controladas y son usadas especialmente cuando existen diferentes entornos de usuarios incluso algunos de ellos inexplorados previamente. Se recomienda cuando el sistema está pensado para el mercado en general por ejemplo las aplicaciones de dispositivos móviles disponibles para todo el público. Un grupo selecto de usuarios utilizan el sistema o la aplicación y reportan los problemas que se les van presentando.

Tipos de pruebas de software

Como se vio en el punto 2.1.1 existen diversos tipos de pruebas los cuales se aplican de acuerdo al proyecto, en un mundo ideal deberíamos aplicar siempre todos los tipos de prueba, sin embargo, estos se deberán de seleccionar de acuerdo al tipo de proyecto.

Todos los tipos de prueba pueden aplicarse en las etapas mencionadas anteriormente pero no es obligatorio aplicarlas todas dado que su ejecución depende de:

• Tipo de proyecto considerando el cometido del sistema, la criticidad de su operación, el tipo de usuarios y el umbral de tolerancia a fallos permitido.
• Disponibilidad de datos en el ambiente de pruebas.
• Hardware disponible en el ambiente de pruebas.
• Presupuesto del proyecto.
• Disponibilidad de especialistas para ejecutar las pruebas.

Los principales tipos de pruebas de acuerdo a su tipo y subtipo son los siguientes:

Pruebas funcionales

Validan que los requerimientos funcionales especificados se cumplan y operen conforme a lo esperado.

Funcionalidad del sistema

Validan funcionalidades específicas con base a las reglas de negocio. Estas pruebas se ejecutan interactuando con la aplicación mediante una interfaz de usuario y validando las entradas contra las salidas obtenidas. Son el tipo de pruebas más común.

Configuración

Evalúan que la aplicación se ejecute correctamente en diferentes configuraciones de hardware y software. Por ejemplo, diferentes sistemas operativos, navegadores de internet, resoluciones de pantalla.

Instalación/Desinstalación

Verifican que la aplicación pueda ser instalada y actualizada correctamente y valida que no se produzcan fallos al tener condiciones anormales, como falta de espacio, falta de permisos. También se incluye la validación de rutinas de desinstalación. Regularmente estas pruebas aplican para aplicaciones que se distribuyen para que el usuario final las instales en sus dispositivos, no aplica en aplicaciones basadas en la web.

Caída y recuperación

Validan que la aplicación se recupera exitosamente de una variedad de problemas de hardware, software y red sin perder datos o su integridad, garantizando así la alta disponibilidad del servicio que brinda la aplicación.

Seguridad y control de acceso

Se realizan para disminuir el riesgo de sufrir un ataque de usuario malintencionados. Generalmente este tipo de pruebas son ejecutadas por compañías especializadas que cuentan con herramientas y listas de vulnerabilidades.

Datos

Validan que las rutinas programadas en la base de datos o APIs funcionen correctamente, de manera independiente de la interface que las explote.

Pruebas de Desempeño

Validan que se cumplan todos los requerimientos no funcionales relacionados al rendimiento de la aplicación, para ejecutar estas pruebas se requiere el uso de herramientas que ayuden a simular las condiciones a validar.

Pruebas de concurrencia

Es una prueba de desempeño que somete al sistema a cargas variables para medir y evaluar su desempeño y su habilidad para continuar funcionando adecuadamente bajo diferentes cargas de trabajo. El objetivo es determinar y asegurar que el sistema funciona correctamente más allá de la carga máxima esperada para el sistema. Adicionalmente, evalúa las características de desempeño como: tiempos de respuesta, flujo de transacciones y otros aspectos sensibles al tiempo.

Pruebas de estrés

Es un tipo de prueba de desempeño implementada y ejecutada para encontrar errores debidos a la falta de recursos o la competencia por ellos. La falta de memoria, espacio en disco o uso de CPU, pueden revelar defectos en el sistema que bajo condiciones normales pueden no ser evidentes. Otros defectos pueden resultar de la competencia por recursos compartidos como el ancho de banda o accesos simultáneos a los mismos registros de la base de datos. Se puede también utilizar para identificar la máxima carga que puede soportar el sistema. A diferencia de las pruebas de concurrencia, en las pruebas de estrés se varían las condiciones del ambiente donde se encuentra el sistema.

Pruebas de volumen

Somete al sistema a grandes cantidades de datos para determinar que continúe operando correctamente. En algunos manejadores de base de datos se presentan problemas de rendimiento cuando existen cientos o miles de registros cargados previamente. Por ejemplo, si el sistema está procesando un conjunto de registros para generar un reporte, una prueba de volumen usa un conjunto de datos grande y verifica que el sistema se comporta normalmente y produce el reporte correcto en el tiempo indicado.

Pruebas de resistencia

Somete al sistema durante un determinado tiempo una carga constante de transacciones la cual puede ser una carga moderada o la carga máxima identificada en las pruebas de concurrencia. Estás pruebas pueden durar más de 24 horas en ejecutarse, permiten identificar problemas que degradan el rendimiento de la aplicación con el tiempo como el uso de memoria y liberación de recursos.

Pruebas de usabilidad o interfaz de usuario

Validan que las interfaces proporcionan al usuario la navegación y el confort necesario para todas y cada una de las funcionalidades de la aplicación, en estas pruebas se incluyen validaciones para evitar que el usuario cometa errores por ejemplo que ingrese letras en un campo donde sólo se pueden aceptar números.