Los niveles de pruebas definen grupos de actividades que se deberán realizar sobre el software, siguiendo su ciclo de construcción y desde la perpectiva del objeto o artefacto que está bajo verificación (si es una clase, un conjunto de clases, o un subsistema).

Ejemplos de niveles de pruebas son: las pruebas de componente (o unitarias), las pruebas de integración, las pruebas de sistema y pruebas de aceptación de usuario. Para cada proyecto de software se debe definir una estrategia de pruebas y dicha estrategia debe contemplar los diferentes niveles de pruebas a realizar.

Los objetivos de los diferentes niveles de prueba son:

• Pruebas de componente (o unitarias): El foco de dichas pruebas es verificar las funcionalidades de cada componente (puede ser una clase, un conjunto de clases, un método, una función, etc) de forma aislada del resto del sistema, considerando el comportamiento que el mismo debe tener según su especificación.
• Pruebas de integración: El objetivo es verificar que la comunicación e interacción de los componentes es adecuada. El foco principal de la integración es evaluar la comunicación (intercambio de información) entre los diferentes componentes prestando atención a las interfaces entre ellos y que el funcionamiento en conjunto sea el correcto. También en este caso se verifica la comunicación con otros sistemas (sistemas externos).
• Pruebas de sistema: En estas pruebas se verifica el sistema como un todo (con todos sus componentes ya integrados) y también en comunicación con otros sistemas (externos).
• Pruebas de aceptación de usuario (UAT): Son pruebas que se realizan con el objetivo de validar el software. El foco es comprobar que el software se comporte como el usuario espera que lo haga y cumpla con sus necesidades. Estas pruebas es recomendable que sean ejecutadas por el cliente/usuarios.

 La siguiente imagen es una representación de cómo se agrupan los principales niveles de pruebas mencionados:

Es necesario definir en el plan de pruebas qué niveles de pruebas se van a cubrir (van a estar contempladas) y cuáles no. Un aspecto importante a definir para cada nivel de pruebas es el criterio de parada (o de terminación) de las pruebas.

Al definir los niveles de prueba, es necesario definir los ambientes en donde se realizarán dichas pruebas. Para esto, sugerimos revisar la Guia para la definición de ambientes.

Existen diferentes tipos de prueba que se pueden realizar sobre los productos de software. Estos tipos de prueba se pueden realizar a distintos niveles (unitario, de integración o de sistema) y con diferente grado de profundidad.

Es necesario definir los tipos de prueba a realizar en base a los requerimientos (funcionales y no funcionales) del sistema y los aspectos de calidad críticos definidos para el software a construir. En la plantilla de Plan de Verificación y Pruebas se presentan varios tipos de pruebas (de esfuerzo, de seguridad, de usabilidad, entre otras) entre los cuales se puede elegir cuáles aplican y cuales no al proyecto.

Algunos tipos son los siguientes:

• Pruebas de humo: Corresponden a un conjunto acotado de pruebas que son imprescindibles para verficar que el sistema no tiene defectos bloqueantes que impidan una correcta verificación del mismo en su totalidad. En general estas pruebas se realizan por el equipo de verificación cuando una nueva versión es liberada, para comprobar que el sistema tiene la calidad mínima necesaria como para no entorpecer en gran medida el proceso de pruebas.
• Pruebas funcionales: El objetivo es verificar el correcto funcionamiento de las distintas funcionalidades que debe proveer el sistema, ya sea de forma individual o en conjunto.
• Pruebas no funcionales:
• Pruebas de performance: En este tipo de pruebas se mide y evalúa el rendimiento del sistema. En general puede incluir: los tiempos de respuesta, de procesamiento y otros requerimientos sensitivos al tiempo. El objetivo de la prueba es verificar que se logren los niveles esperados de rendimiento del sistema.
• Pruebas de seguridad: Las pruebas de seguridad se enfocan en evaluar el sistema en dos aspectos:
  • Seguridad en el ámbito de aplicación, incluyendo el acceso a los datos y a las funciones de negocios: en base a la seguridad deseada, se verifica que los actores estén restringidos a funciones o casos de uso específicos o limitados en los datos que están disponibles para ellos.
  • Seguridad en el ámbito de sistema, incluyendo conexión, o acceso remoto al sistema: la seguridad en el ámbito de aplicación asegura que solo los usuarios con derecho a acceder al sistema son capaces de acceder a las aplicaciones únicamente a través de los puntos de ingresos apropiados.
• Pruebas de regresión: Permiten corroborar que luego de realizar cambios en el sistema (corregir defectos o agregar nuevas funcionalidades), el resto del sistema continúa comportandose correctamente (no se rompió nada que antes funcionaba).
• Pruebas automatizadas: pueden ser de varios tipos y corresponder a múltiples niveles. Son pruebas en las cuales no hay una ejecución manual realizada por una persona, donde las mismas se implementan utilizando algún lenguaje de programación (o utilizando alguna biblioteca específica para un determinado lenguaje, como ser JUnit, NUnit o similar) y se ejecutan en algún software de apoyo para ejecución automatizada de pruebas (ej: Jmeter) . Es imporante que al momento de decidir qué pruebas automatizar se evalue el costo/beneficio de hacerlo, ya que requieren mantenimiento como cualquier proyecto de software. Este tipo de pruebas se recomiendan generalmente para pruebas de performance y de regresión (unitarias, de integración y de sistema).

De cada tipo de prueba definida a realizar y que aplica a la solución a construir, se debe definir:

• Técnicas y herramientas a utilizar
• Niveles en los cuales aplica este tipo de prueba y sobre qué partes de la solución
• Criterios de terminación (o parada) para las pruebas (se puede definir un determinado grado de cobertura por ejemplo)
• Otras informaciones adicionales dependiendo del tipo de prueba a realizar

En relación a las técnicas para la especificación (diseño) de pruebas, éstas facilitan la identificación y definición de los escenarios de pruebas necesarios. Las siguientes técnicas de diseño son recomendadas por el estándar internacional ISTQB:

• Clases de Equivalencia o Partición de Equivalencia: Esta técnica permite definir los valores válidos y no válidos que son necesarios para la ejecución de un determinado escenario de prueba. Esta técnica le da al Probador de software, dominio de los datos y contexto de entrada.
• Valores Límites: Esta técnica está directamente asociada a las clases de equivalencia. Para cada clase de equivalencia válida o inválida se analizan los valores que están en el límite, por encima y por debajo del límite. Está demostrado que muchos defectos se encuentran en los límites de las clases de equivalencia del dominio.
• Tablas de Decisión: Esta técnica se usa para representar reglas complejas del negocio. Se identifican todas las posibles condiciones (entradas) y posibles acciones (salidas) y sus posibles combinaciones. Debe existir una regla para cada posible combinación de condiciones.
• Diagramas de Transición de Estado: Esta técnica es usada para diseñar las pruebas a partir de máquinas de estado. Permite ilustrar la secuencia de funciones en un orden válido y encontrar el orden correcto para la ejecución de los casos de prueba ya que el comportamiento posterior de un caso de prueba, depende del comportamiento del caso anterior.
• Basadas en la Experiencia: Se basa en la habilidad, la experiencia y la intuición del Probador de software. No tiene un método o proceso a seguir (no se realiza de forma sistemática. Se utiliza fuertemente la predicción de errores, basados en el histórico de pruebas y comportamiento del sistema.

Se recomienda fuertemente considerar y aplicar algunas de las técnicas antes mencionadas. Éstas colaborarán en un resultado exitoso del proceso de pruebas, en el logro de los objetivos, y en la satisfacción, confianza y seguridad del cliente en el uso de la solución tecnológica.

Es necesario definir el proceso de reporte de incidencias, cómo una incidencia o potencial error debe ser reportado y las diferentes fases o etapas por las cuales pasa el incidente hasta ser resuelto. También las jerarquías y permisos para cambiar una incidencia de estado o cerrarla. Un ejemplo de estados por los que puede pasar una incidencia son los siguientes:

También es necesario definir diferentes niveles de gravedad de las incidencias reportadas, entre otros datos o información relevante.

Lo que se recomienda fuertemente es el uso de una herramienta de gestión de incidentes o de gestión de tareas. Algunas opciones gratuitas pueden ser: Bugzilla, Mantis, Request Tracker (RT), o similares.

Los recursos a definir en general son de dos tipos: humanos y de sistema.

Para los recursos humanos es necesario definir los roles que deberán participar, la cantidad de recursos necesarios para ese rol y las responsabilidades.

Como último paso, se deberá validar el plan de pruebas. En la Guia para verificar el plan de pruebas se puede encontrar un procedimiento sugerido para realizar esta actividad.