Tipos y niveles de prueba

Si acabas de comenzar el viaje como tester, este artículo tiene la intención de darte algo de luz sobre un tema que puede parecer bastante confuso: los tipos y niveles de prueba. Al “googlear’’ tipos de pruebas te aparecen listas dónde no logras diferenciar entre tipo y nivel y llega a crear desconocimiento en un tema bastante fundamental en el mundo testing.

Hasta el momento hay dos listas de estándares internacionales que tratan de orientarnos sobre los tipos de pruebas:

• La ISO/IEC 25010 estándar que define ocho características de calidad y a partir de estas los tipos de pruebas para validarlas. La ISO 25010 no agrupa los tipos según el objetivo y tampoco nos ofrece niveles de prueba.

• El ISTQB (International Software Testing Qualifications Board) es el estándar internacional que se ha venido especializando en el campo de la certificación de pruebas, hace diferencia entre niveles y tipos y serán estos los ahondados en esta entrega.

Niveles de Prueba

“Son grupos de actividades de pruebas que se organizan y administran juntas; cada nivel es una instancia en el proceso de pruebas” (ISTQB-CTFL Syllabus 2018 v3.1.1, p. 30) y son 4:

Pruebas de Componentes

Conocidas cómo pruebas unitarias, son las que están enfocadas en componentes que pueden ser probados de forma separada y son hechas usualmente por los programadores. Son excelentes candidatas a automatizarse y hechas de forma separada del resto del sistema. Algunos de los objetos de pruebas en este nivel son: código, estructura de datos, clases, módulo de bases de datos.

Pruebas de Integración

Son las pruebas que están enfocadas en la interacción entre los componentes o los sistemas, por tanto se subdividen en:

1. Integración de componentes: prueba la interacción e interfaces entre los componentes, son hechas luego de las pruebas de componentes y son perfectas candidatas a automatizar.
2. Integración de sistemas: prueba la interacción e interfaz entre los sistemas, paquetes y microservicios. Además puede cubrir la interacción del sistema con interfaces que proveen sistemas externos. Estas pruebas se pueden hacer luego de las pruebas de sistemas o en paralelo.

Algunos de los objetos de prueba en este nivel son: subsistemas, base de datos, interfaces, API’s, microservicios. En estas pruebas nos debemos enfocar en la comunicación entre módulos o sistemas; por ejemplo: desajuste de la interfaz, datos incorrectos o faltantes, suposiciones incorrectas de términos o unidades de datos que se transmiten entre los sistemas.

Pruebas de Sistemas

Se centran en el funcionamiento y capacidades de un sistema/producto completo, se consideran todas las tareas que el sistema puede realizar y los comportamientos no funcionales que muestra mientras cumple con estas tareas. Entre los principales objetivos de las pruebas de sistema tenemos:

• reducir el riesgo,
• verificar si el comportamiento funcional y no funcional del sistema son los diseñados y especificados,
• encontrar defectos,
• validar que el sistema está completo y trabaja como se esperaba;
• y en dependencia del tipo de sistema se debe validar la calidad de los datos.

Los objetos de prueba son aplicaciones y sistemas enteros.

Pruebas de Aceptación

Al igual que las pruebas de sistema se centran en el comportamiento y capacidades de un sistema/producto completo y entre sus principales objetivos están: establecer confianza en la calidad del sistema completo, validar que el sistema está completo y trabaja como se esperaba. Estas pruebas producen la información para evaluar el despliegue y uso del cliente. Se pueden encontrar defectos pero no es el objetivo de estas pruebas, si se encuentran muchos defectos en este nivel se considera como un gran riesgo para el proyecto. Las formas más comunes de pruebas de aceptación son:

1. Pruebas de aceptación de usuario (UAT): se enfocan en validar si el sistema se adapta al usuario final en un entorno operativo real o simulado.
2. Pruebas de aceptación operacional: son hechas por los usuarios administradores del sistema en un ambiente simulado de producción. Se enfocan en aspectos operacionales cómo: probar el respaldo y recuperación; instalación, actualización y desinstalación; administración de usuario y tareas de mantenimiento. Pero el principal objetivo es darle confianza, a los operadores o administradores del sistema, de que este se mantendrá trabajando apropiadamente en una ambiente operacional con condiciones excepcionales e inesperadas.
3. Pruebas de aceptación contractuales y regulatorias: son realizadas contra los criterios de aceptación de un contrato para producir software hecho a medida, los criterios de aceptación deben ser definidos cuándo las partes están de acuerdo con el contrato.
4. Pruebas de aceptación Alfa y Beta: son usadas por programadores de software comercial listo para usarse; que desean obtener comentarios de los usuarios, clientes u operadores potenciales antes de poner el software en el mercado.
5. Los objetos de prueba en este nivel son, principalmente; sistemas en pruebas, procesos de negocio, reportes, entre otros. Las pruebas de aceptación son responsabilidad de los clientes/product owners.

Tipos de Pruebas

“Un tipo de prueba es un grupo de actividades de prueba destinadas a probar características específicas de un sistema de software, o una parte de un sistema, en función de objetivos de prueba específicos.” (ISTQB-CTFL Syllabus 2018 v3.1.1, p. 39). Entre los principales objetivos de los tipos de prueba están: evaluar la calidad de las características funcionales y no funcionales; evaluar si la estructura o arquitectura del componente/sistema está completa y conforme las especificaciones; evaluar los efectos de los cambios así como validar que los defectos encontrados fueron corregidos. Los tipos de pruebas son:

Pruebas Funcionales

Podríamos decir que son las más conocidas y mencionadas en el mundo testing, básicamente son las pruebas que validan las funciones que el sistema debe hacer. Las pruebas funcionales, esencialmente, validan el “qué” debe hacer el componente/sistema. Se deberían hacer en todos los niveles de prueba, aunque el foco es distinto en cada uno.

Pruebas no Funcionales

Las pruebas no funcionales de un sistema evalúan las características cómo usabilidad, rendimiento, eficiencia o seguridad. Las pruebas no funcionales son las encargadas de validar el “qué tan bien” el sistema se comporta. Contrario a lo que se piensa las pruebas no funcionales deben hacerse en todos los niveles de prueba y realizarse lo antes posible. Las pruebas no funcionales podrían requerir conocimientos especiales para poder ejecutarlas.

Pruebas de Caja Blanca

Las pruebas de caja blanca son las que validan la estructura interna del sistema. Esta estructura interna puede incluir el código, arquitectura, flujo de trabajo y flujo de datos dentro del sistema. En el nivel de Componente de Pruebas la cobertura de código está basada en el porcentaje de componentes que han sido probados. Para diseñar y ejecutar las pruebas de caja blanca es necesario tener conocimiento sobre cómo fue construido el código, cómo están guardados los datos, entre otros.

Pruebas Asociadas al Cambio

Cuándo son hechos cambios al sistema, ya sea por corregir un defecto o por una nueva o cambiante funcionalidad se deben hacer pruebas para verificar que los cambios han corregido el defecto o han implementado correctamente la funcionalidad y que no han causado consecuencias adversas.

1. Pruebas de Confirmación: Luego que un defecto es corregido, el sistema se debe probar ejecutando todos los casos de prueba fallidos asociados al defecto; estos deben ser reprobados en la nueva versión del software. El propósito de las pruebas de confirmación es validar que el defecto original ha sido corregido de forma exitosa.
2. Pruebas de regresión: Es posible que los cambios hechos en una parte del código, ya sea una corrección u otro tipo de cambio, accidentalmente podrían cambiar el comportamiento de otras partes del software ya sea dentro del mismo componente, otros componentes del sistema e incluso en otros sistemas. Las pruebas de regresión validan que no se generaron nuevos defectos. Estas pruebas suelen ejecutarse luego de un traslado de ambiente (producción o pruebas), nueva versión del sistema operativo o incluso si el programador comunica que el cambio realizado podría afectar otros módulos ya probados. Podemos ejecutar un set de casos de pruebas específico para estos escenarios, ejecutar los mismos que se ejecutaron previamente o seleccionar los que abarcan las funcionalidades importantes del componente/sistema, esto se especificará más adelante.

Las pruebas de confirmación y regresión se deberían ejecutar en todos los niveles de prueba, especialmente en ciclos de desarrollo incrementales e interactivos, estas pruebas son excelentes candidatas para automatizar.

Es importante hacer mención a las pruebas de humo y sanidad que muchas veces las encontramos listadas como tipos de pruebas, pero basados en el listado que ofrece el ISTQB no son un tipo particular de pruebas, ambas son pruebas rápidas para verificar la estabilidad de una versión del software; están dentro de las calificaciones dadas.

Las pruebas de humo son pruebas funcionales que consisten en hacer una validación inicial de la calidad del producto; pasando por las funcionalidades básicas/importantes dónde se prueba de todo un poco de forma rápida, una vez validamos está estable la versión se procede con la ejecución de todos los casos de prueba planeados.

Las pruebas de sanidad son pruebas asociadas a cambios; que se encargan de validar de forma rápida pero certera que ciertas funcionalidades nuevas o que han sufrido cambios están funcionando correctamente. Si en el proyecto se tiene el alcance de hacer pruebas en producción, luego de un despliegue, se validan las nuevas funcionalidades que se trabajaron en la iteración y luego se hace una “barrida” al resto de funcionalidades básicas de la aplicación.

Estos son los tipos y niveles de pruebas que plantea el ISTQB, cómo un referente del testing internacional; tratan de llenar el vacío que ha generado este tema a lo largo de los años en que se ha venido descubriendo y desarrollando el área de pruebas de software. No distan mucho de los que menciona la norma ISO 25010, que de hecho están contenidos en los tipos de pruebas funcionales y no funcionales.

Cuéntame ¿Cuáles de estos tipos o niveles ya conocías? ¿Cuáles son los que has elaborado? ¿Crees que la clasificación dada está completa?