Ejemplo de Plan de Pruebas

Introducción

El Plan de pruebas describe el alcance, el enfoque, los recursos y el cronograma de todas las actividades de prueba. Identifica los elementos y características que se van a probar, es decir, los tipos de pruebas. Contiene una estrategia detallada y ejecutable para la realización. Define el objetivo detallado de la prueba, específico de un sistema en particular, el enfoque de prueba, el entorno de prueba, las condiciones de prueba y el plan de prueba.

Alcance

El alcance de este plan de prueba es garantizar que se cumplan todos los requisitos técnicos, funcionales y comerciales. El propósito de este documento es describir el plan de prueba general y la estrategia para evaluar un sitio web. El enfoque descrito en este documento proporciona el marco para todas las pruebas relacionadas con los sitios web.

Este documento evolucionará según sea necesario con las actualizaciones de los requisitos. También debemos asegurarnos de que se obtengan todos los resultados esperados.

Objetivo de las pruebas

El objetivo general de las pruebas es validar la exactitud de la generación del archivo de datos de la interfaz, su contenido y cualquier condición de error. Los objetivos de calidad de las pruebas del sitio web son garantizar la validación completa de los requisitos comerciales y de software: 

  1. Verificar que los requisitos de software estén cubiertos y sean precisos. 
  2. Realizar una planificación detallada de las pruebas. 
  3. Identificar los estándares y procedimientos de prueba que se utilizarán. 
  4. Preparar y documentar escenarios de prueba y casos de prueba.
  5. Gestionar el proceso de seguimiento de defectos.
  6. Finalizar el proyecto para su lanzamiento.

Detalle de las pruebas y fases

A continuación, se mencionan las fases y metodologías de prueba detalladas. Siguiendo los diferentes protocolos de cada fase conseguiremos los mejores resultados.

  • Análisis de requisitos
  • Pruebas de diseño
  • Pruebas de funcionalidad
  • Pruebas de integración
  • Pruebas API
  • Pruebas de usabilidad
  • Pruebas de compatibilidad
  • Pruebas de rendimiento
  • Pruebas de seguridad
  • Pruebas de automatización 
  • Pruebas de humo
  • Pruebas beta

Análisis de los requisitos

El análisis de requisitos es fundamental para el éxito o el fracaso de un proyecto, por lo que tenemos que verificar, validar y confirmar cada requisito. 

Los requisitos deben validarse en base a la Experiencia de Usuario y la Interfaz de Usuario. Se debe comprobar que los requisitos están actualizados y asegurar que los principales escenarios y requisitos están incluidos en la documentación. 

Si durante el análisis de la documentación se detecta algún error, se deben añadir los requisitos que faltan y sugerir las posibles mejoras, si las hubiera. 

Pruebas de diseño

Estas pruebas validan que los diseños sean correctos y que cumplan los requisitos. Además, aseguran que los diseños sean compatibles en todos los idiomas y con los temas especificados.

Pruebas de funcionalidad

Garantizan los requisitos funcionales y aseguran que cada funcionalidad actúa de acuerdo con los requisitos y tareas definidas. Se deben validar todos los enlaces de la página web, verificar las conexiones de bases de datos, los formularios utilizados para enviar u obtener información del usuario y realizar las pruebas de cookies. Las pruebas funcionales incluyen los siguientes tipos de pruebas:

  • Enlaces externos de todas las páginas de un dominio específico
  • Enlaces internos
  • Enlaces de prueba que navegan en las mismas páginas
  • Enlaces de prueba utilizados para enviar el correo electrónico al administrador u otros usuarios desde páginas web
  • Comprobar que todas las páginas están indexadas
  • Validar que no haya enlaces rotos en todos los enlaces mencionados anteriormente

Los formularios son la parte esencial e integral de los sitios web. Se utilizan para obtener información de los usuarios y mantener la interacción con ellos. En ellos, se debe comprobar lo siguiente:

  • Validaciones generales en cada campo
  • Valores predeterminados de los campos
  • Entradas incorrectas en los campos
  • Opciones de crear, eliminar y/o modificar los formularios
  • Validar que no se puedan crear formularios vacíos
  • Validaciones específicas de campos, como el correo electrónico, la cuenta bancaria, fecha...
  • Realizar todas estas validaciones de forma manual o automática

Las cookies son pequeños archivos almacenados en la máquina de un usuario que se utilizan básicamente para mantener las sesiones. Para ello, se deben realizar las siguientes pruebas:

  • Habilitar y/o deshabilitar las cookies en las opciones del navegador
  • Cifrado de cookies antes de incluirlas en la máquina del usuario
  • Estado durante la sesión y tras su finalización
  • Seguridad de la aplicación al eliminar las cookies

La validación de HTML/CSS es especialmente importante para optimizar el sitio web en los motores de búsqueda. Para ello debemos asegurar que:

  • El Doctype está completo y es correcto
  • Utiliza un juego de caracteres
  • Utiliza un XHTML válido
  • Utiliza CSS válido
  • No tiene identificadores o clases innecesarias
  • Contiene un código bien estructurado
  • No existen enlaces rotos
  • Tiene enlaces claramente definidos

Las pruebas de bases de datos nos permiten verificar la integridad de los datos y los errores mientras se realizan diferentes operaciones en los formularios o en cualquier funcionalidad relacionada con la base de datos. Estas pruebas nos ayudan a garantizar que todas las consultas de la base de datos se ejecutan de forma correcta y que los datos se recuperan y actualizan correctamente. Para ello, es necesario que ejecutemos consultas en la base de datos.

Automatización de pruebas

Nos permiten automatizar todas las funcionalidades implementadas del sitio web. Antes de realizar la automatización se deberán seguir los siguientes pasos:

  1. Analizar qué casos de prueba se deben automatizar
  2. Definir los casos de prueba y confirmarlos con el equipo
  3. Priorizarlos y añadirlos a un plan de pruebas
  4. Decidir cómo se van a ejecutar
  5. Realizar el script del caso de prueba con los datos y las configuraciones necesarias
  6. Definir las precondiciones y los pasos para la ejecución
  7. Ejecutar y verificar el resultado de la prueba

Pruebas de humo

Este tipo de pruebas, también llamado Smoke Testing, nos permite verificar si la compilación del software implementada es estable o no. Con ellas se garantiza que todas las funcionalidades críticas funcionan correctamente. 

Lo primero que se debe hacer es una lista de verificación y, después, se ejecutarán en dos etapas: cuando se añadan nuevas funcionalidades y antes de finalizar la compilación para el entorno productivo.

Pruebas Beta

Estas pruebas se realizan sobre una versión para usuarios específicos en un entorno controlado y les permite descubrir cualquier error o problema antes de un lanzamiento general.  Se puede decir que son las pruebas previas antes de lanzar un producto de forma masiva. 

El objetivo es descubrir en este entorno controlado tantos errores o problemas de usabilidad como sea posible.

Estrategia de pruebas

La estrategia general de esta iniciativa de prueba es la prueba manual de caja negra. En ella, se validan en detalle los datos, la parte de la interfaz y el sistema implementado. 

Las pruebas en la parte de la interfaz estarán cubiertas por las pruebas funcionales, de las que ya hemos hablado anteriormente.

Todos los tipos de pruebas están incluidas en este documento. Además, se incluyen todos los datos de prueba que deben configurarse en el entorno de prueba antes de ejecutar los casos de prueba.

Para cada nivel de prueba, se prepara un plan de prueba separado con el siguiente conjunto de entregables: 

  • Casos de prueba/escenarios de prueba 
  • Características y elementos a validar 
  • Criterios de aceptación
  • Ciclo de errores
  • Automatización
  • Resultados esperados
  • Resultados obtenidos

Calendario de pruebas

El cronograma de pruebas incluye las actividades de pruebas de aceptación y las fechas de entrega. Entre las que se encuentran las siguientes:

  • Análisis de requisitos
  • Pruebas de diseño
  • Definición de escenarios de prueba
  • Definición y creación de casos de prueba
  • Revisión de escenarios/casos de prueba para verificar su precisión, integridad y ejecución
  • Pruebas de integración
  • Pruebas API
  • Pruebas de regresión
  • Pruebas de funcionalidad
  • Pruebas de bases de datos
  • Especificación de prueba de integración
  • Pruebas de usabilidad
  • Pruebas de compatibilidad
  • Pruebas de rendimiento
  • Pruebas de seguridad
  • Pruebas UAT
  • Automatización de pruebas 
  • Pruebas de humo
  • Pruebas beta

Clasificación de severidad/criticidad

La criticidad identificada para cada problema implica una recompensa general por resolverlo y un riesgo general por no abordarlo en la versión actual:

  • Criticidad 1: problemas de bloqueo o de alto impacto que a menudo impiden que un usuario complete correctamente su experiencia
  • Criticidad 2: problemas de frecuencia moderada a alta con el impacto en la funcionalidad/UI o UX
  • Criticidad 3: problemas moderados con baja frecuencia o problemas bajos con frecuencia moderada; Estos son problemas de menor impacto que afectan a varios usuarios
  • Criticidad 4: problemas de bajo impacto que afectan a pocos usuarios; existe un riesgo bajo de no resolver estos problemas. La recompensa por la resolución suele manifestarse en una mayor satisfacción del usuario.

Criterios de Pasado o Fallado

En cada caso de prueba se deben incluir los resultados esperados para poder definir el estado tras la ejecución.

Entornos

Se debe contar con diferentes entornos para la realización de las pruebas. Inicialmente, se contará con un entorno de desarrollo en el que se garanticen las primeras pruebas durante el desarrollo. Posteriormente se tendrá un entorno en el que ejecutar las diferentes pruebas definidas y, finalmente, se contará con los entornos productivos en los que realizar las últimas pruebas.

En algunas ocasiones, se cuenta con un entorno intermedio entre el segundo y el tercero, siendo este un entorno espejo de lo que se entregará en el entorno productivo y en el que se podrán realizar pruebas con datos similares.

Casos de prueba y escenarios de pruebas

Los casos de prueba se deben detallar según los requisitos, el documento técnico y el plan de prueba. Para la creación de los casos de prueba se aconseja contar con una herramienta de testing, ya sea de pago u opensource, como Xray, Zephyr, TestLink...

Herramientas y seguimiento de defectos

Para realizar el reporte de los defectos también se aconseja contar con una herramienta que nos permita hacer el seguimiento. Igual que en el caso anterior, puede ser una herramienta de pago u opensource, como Jira, Mantis...

Informes de prueba

Durante todas las fases del proyecto se realizarán informes de prueba. Estos informes incluirán todos los elementos referentes a las pruebas: requisitos cubiertos, casos de pruebas realizados, datos de prueba utilizados, resultados de las pruebas ejecutadas, defectos detectados, conclusiones...

Criterios de Salida

Por último, es importante que se identifiquen correctamente los criterios de salida que se deben obtener tras las pruebas. Estos criterios deben cubrir y asegurar los requisitos definidos.



Siguiente Publicación