+54 9 351 303-5806

Cómo clasificamos los diferentes tipos de pruebas de software

Un conjunto de actividades de pruebas suele orientarse a comprobar determinados aspectos de un software (o de una parte del mismo). De acuerdo a lo definido en las directrices del ISTQB, veremos los Tipos de Pruebas Software en función del objetivo en que se centran.

En primer lugar tenemos las Pruebas Software Funcionales. En este tipo de pruebas nos enfocaremos en “lo que debe hacer”. Típicamente esta información del comportamiento del sistema, subsistema o componente software se encontrará descrito en especificaciones de requisitos o casos de uso, aunque también puede no estar documentado, lo cual har{a el proceso de prueba más tedioso.

Pruebas de caja negra

Estas pruebas se definen a partir de funciones o características (como decimos, descritas en documentos o bien interpretadas por los probadores) y su interoperabilidad con sistemas específicos, pudiendo ejecutarse en todos los niveles de pruebas (componentes, integración, 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, Estrés, Usabilidad, Mantenibilidad, Fiabilidad o Portabilidad, entre otras. Por tanto se centran en características del software que establecen “cómo trabaja el sistema“.

Estas pruebas también pueden ejecutarse en todos los niveles de pruebas. Las características 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 número máximo de sesiones en pruebas de estrés.

Puesto que las Pruebas software no Funcionales normalmente consideran el comportamiento externo del sistema, en la mayoría de los casos se utilizan técnicas de Pruebas de Caja Negra.
A continuación, en tercer lugar, tenemos las Pruebas Software Estructurales. Nuevamente pueden ejecutarse en todos los niveles de pruebas (componentes, integración, sistema, etc.) y encajan muy bien si hemos utilizado técnicas de especificación de la estructura o arquitectura del Software. Es posible aplicar técnicas estáticas de análisis de código.

Para expresar el alcance que se ha tenido con un conjunto de pruebas (también llamado “test suite”) en la estructura o arquitectura en cuestión, se utiliza el concepto de Cobertura (“Coverage”), normalmente en forma de porcentaje.

Es especialmente habitual utilizar herramientas de apoyo para calcular la cobertura del código en el caso de Pruebas de Componentes o en Pruebas de Integración de Componentes (por ejemplo, trazando la jerarquía de llamadas entre elementos). Puesto que indagamos en el comportamiento interno, estas pruebas se denominan también Pruebas de Caja Blanca (“white-box testing”).

Finalmente, el cuarto tipo de pruebas que nos presenta el ISTQB son las pruebas derivadas de la realización de cambios: las Pruebas Software de Regresión 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 Regresión 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 algún otro componente. Se ejecutan cuando se cambia el software o su entorno. El criterio para decidir la extensión de estas Pruebas de Regresión está basado en el riesgo de no encontrar defectos en el software que anteriormente estaba funcionando correctamente.
Las Pruebas de Regresión se realizan sobre un componente ya probado, para verificar que no presenta nuevos defectos cuando se realiza una modificación después de dichas pruebas.
Este tipo de pruebas software deben ser repetibles si han de usarse para pruebas de confirmación (o aseguramiento) y regresión (como Sondas de Disponibilidad, por ejemplo). Los conjuntos de pruebas de regresión (“Regression test suites“) suelen ser bastante estables por lo que son muy buenos candidatos para actividades de automatización de pruebas software.
Quizá ya no os sorprenda que estas pruebas también puedan ejecutarse en todos los niveles de pruebas e incluyen casos de prueba de los tipos vistos anteriormente: Pruebas Funcionales, No Funcionales y Estructurales.

Related Posts

Leave a Reply!

You must be logged in to post a comment.