Pruebas de software: plantilla de plan de prueba

Un plan de prueba es un documento elaborado que describe el enfoque, el propósito, el plan, la estimación, los resultados y los recursos necesarios para la prueba. Nos ayuda a regular el esfuerzo requerido para verificar la calidad de la aplicación bajo prueba. El plan de prueba actúa como un diseño para implementar actividades de prueba de software como un proceso definido que el administrador de prueba observa y supervisa de cerca.

¿Quién prepara la plantilla del plan de prueba?

El jefe de pruebas o el administrador de pruebas prepara la plantilla del plan de pruebas. Los evaluadores también participan en el procedimiento de redacción de plantillas de planes de prueba. Después de escribir el plan de prueba, los probadores escribirán escenarios de prueba y casos de prueba según el documento del plan de prueba.

Propósito del plan de prueba

El propósito clave de un plan de prueba es crear documentación que defina cómo el probador demostrará que el software funciona como debería. 

• El documento debe detallar qué requiere ser probado, cómo se probará y quién está a cargo de la prueba.
• Actúa como un diseño para implementar actividades de prueba de software como un proceso definido.
• Al elaborar un plan de prueba, todas las personas del equipo pueden trabajar juntas y comunicarse sus partes entre sí.

¿Cómo preparar una plantilla de plan de prueba eficaz?

Se deben considerar los siguientes pasos para escribir una buena plantilla de plan de prueba:

• Conozca claramente el producto.
• Crear una estrategia de prueba.
• Describa el alcance de la prueba.
• Cree un entorno de prueba.
• Identificar los tipos de pruebas.
• Describir los objetivos de las pruebas.
• Estimar los principales peligros y defectos.
• Definir roles y responsabilidades.
• Cálculo y Calendario.
• Configure los Entregables de prueba.

Formato de plantilla de plan de prueba

Se debe seguir la siguiente plantilla de plan de prueba:

(Nombre del software)

Preparado por: 
(Lista de nombres que prepararon esto)
(Fecha)

1. Introducción

Es una breve sinopsis del software que se está probando, las estrategias de prueba, los procedimientos, el flujo de trabajo y los métodos necesarios para el proyecto. Destaca todas y cada una de las funciones a un alto nivel.

1.1. Objetivos del plan de prueba

Describe todos los propósitos llevados a cabo por el Plan Maestro de Pruebas. Enumera todas y cada una de las tareas realizadas por este plan de prueba. Enumere todos los objetivos que pretende lograr con las pruebas manuales y de automatización. Algunos objetivos de probar su proyecto pueden ser:

• Asegúrese de que la aplicación bajo prueba cumpla con las condiciones funcionales y no funcionales.
• Asegúrese de que el AUT cumpla con las condiciones de calidad descritas por el cliente.
• Los errores o defectos se encuentran y corrigen antes de su puesta en marcha.

2. Alcance

El alcance describe los módulos, componentes funcionales o no funcionales del software que deben probarse. Fuera de alcance describe los módulos, componentes funcionales o no funcionales del software que no necesitan ser probados. Esta sección define qué se probará, qué característica es nueva para cada función de un producto en particular, sus interfaces actuales y la interconexión de todas las funciones.

Detalle aquí cómo terminará los elementos que ha enumerado en esta parte del Alcance.

2.1. Entrada de datos: es el proceso para ingresar detalles en este plan de prueba.

2.2. Transferencia de archivos de informes: Los informes en la sección de transferencia de archivos se mencionan aquí.

2.3. Transferencia de archivos: aquí los archivos se transfieren entre dos programas. Un archivo se mueve o copia de un software a otro software a través de una red.

2.4. Seguridad: Describe si el software es seguro o no.

3. Estrategia de prueba

• Definir toda la técnica para la prueba. Para todas y cada una de las clases importantes de condiciones o compuestos de características, nombre la técnica que garantizará que estos compuestos de condiciones se prueben lo suficiente.
• Nombre las tareas, los enfoques y las herramientas de prueba importantes que se necesitan para probar la clase de características diseñadas.
• Las técnicas deben definirse con los detalles adecuados para aceptar el reconocimiento de las claves clave de prueba y el cálculo del tiempo necesario para hacer todo.

3.1. Prueba del sistema

• Escriba lo que sabe acerca de las pruebas del sistema para el proyecto.
• Nombre las personas que realizarán las pruebas del sistema en el proyecto. Haga una lista de todas las personas responsables de esta prueba. 
• Definir cómo realizar pruebas del sistema. Nombre las personas que escribirán los scripts de prueba para las pruebas unitarias, cuál debería ser la serie de eventos de la prueba del sistema y cómo debería ser la tarea de prueba.

3.2. Prueba de rendimiento

• Escriba su comprensión de las pruebas de rendimiento para el proyecto.
• Nombre a las personas que realizarán las pruebas de rendimiento del proyecto. Tome nota de todas las personas responsables de esta tarea.
• Definir cómo realizar pruebas de rendimiento. Nombre las personas que escribirán los scripts de prueba, cuál debería ser la serie de eventos de la prueba de rendimiento y cómo debería ser la tarea de prueba.

3.3. Prueba de seguridad

• Este es un procedimiento para encontrar defectos en la aplicación de seguridad de un sistema de información que protege los datos y administra la funcionalidad según sea necesario.
• Nombre a las personas que realizarán las pruebas de seguridad en el proyecto. Tome nota de todas las personas responsables de esta tarea.
• Definir cómo realizar pruebas de seguridad. Nombre las personas que escribirán los scripts de prueba, cuál debería ser la serie de eventos de las pruebas de seguridad y cómo debería ser la tarea de prueba.

3.4. Prueba automatizada

• Esta prueba es la aplicación de herramientas de prueba para automatizar un procedimiento manual de verificación y validación de software.
• Nombre a las personas que realizarán las pruebas de automatización en el proyecto. Tome nota de todas las personas responsables de esta prueba.

3.5. Test de Estrés y Volumen

• La prueba de estrés es un tipo de prueba de rendimiento que sucederá cuando lleve su aplicación, API o software a los límites más altos de su capacidad. La prueba de volumen es un tipo de prueba de software que se realiza para probar una aplicación de software con una porción definida de datos.
• Definir cómo realizar pruebas de estrés y volumen. Nombre las personas que escribirán los guiones de prueba, cuál debería ser la serie de eventos de la prueba de estrés y volumen, y cómo debería ser la tarea de prueba.

3.6. Prueba de recuperación

• Es la tarea de probar qué tan bien se recuperará el software de bloqueos, colapsos de hardware y otros problemas similares. Es la derrota impuesta del software de numerosas maneras para validar que la recuperación se está realizando correctamente.
• Nombre a las personas que realizarán las pruebas de recuperación en el proyecto. Tome nota de todas las personas responsables de esta prueba.

3.7. Prueba de documentación

• Es una prueba no funcional. Son las pruebas de caja negra las que aseguran que la documentación, sobre cómo usar el software, coincida con lo que hace el software, dando evidencia de que las modificaciones y mejoras del software han sido documentadas.
• Nombre a las personas que harán las pruebas de documentación en el proyecto. Tome nota de todas las personas responsables de esta tarea. 

3.8. Prueba Beta

• La prueba beta es la última ronda de pruebas antes de lanzar el software a clientes más grandes.
• Es una oportunidad para que los usuarios finales reales usen el software en un entorno de producción para exponer cualquier error o defecto en una versión normal.

3.9. Prueba de aceptación del usuario

• El objetivo de la prueba de aceptación del usuario es verificar si el software está listo para su uso operativo o no. Durante esta prueba, los usuarios finales del software comparan el software con sus condiciones iniciales.
• Nombre a las personas que realizarán las pruebas de aceptación del usuario en el proyecto. Tome nota de todas las personas responsables de esta tarea.
• Defina cómo realizar las pruebas de aceptación del usuario. Nombre las personas que escribirán los scripts de prueba, cuál debería ser la serie de eventos para la prueba de aceptación del usuario y cómo debería ser la tarea de prueba.

4. Requisitos ambientales

4.1. Estaciones de trabajo de entrada de datos
Nombra los elementos esenciales mínimos de hardware que se utilizarán para probar la aplicación. El siguiente software es esencial, así como el software específico del cliente.

• Windows 8 y superior
• Oficina 2013 y superior
• Intercambio MS.

4.2 MainFrame
Especifica los elementos esenciales y los efectos deseados del entorno de prueba. El particular debe consistir en los atributos físicos del equipo, y también el hardware, el software de comunicaciones y del sistema, el modelo de uso y otro software o colecciones que son esenciales para realizar la prueba. Defina el nivel de seguridad que debe darse para el equipo de prueba, el software del sistema y los componentes exclusivos, como software, datos y hardware. Validar las herramientas de testing que se necesiten especialmente. Calcula la fuente de cada necesidad que no está en tu grupo en este momento.

5. Calendario de pruebas

Todos y cada uno de los hitos de prueba que se encuentran en el Programa del proyecto de software y también cada evento de transmisión de la unidad se incluyen aquí. 

• Describa cualquier hito de prueba adicional que sea necesario. 
• Calcule el tiempo necesario para terminar cada tarea de prueba. 
• Defina el cronograma para cada trabajo de prueba y punto de referencia de la prueba. Para todas y cada una de las instalaciones de prueba, describa su duración de uso.

6. Procedimientos de Control

6.1 Revisiones
Una revisión es una inspección paso a paso de un documento por parte de una o más personas con el objetivo principal de identificar y solucionar defectos en las etapas iniciales del ciclo de vida del desarrollo del software. Las revisiones se utilizan para validar documentos como requisitos, diseños de sistemas, código, planes de prueba y casos de prueba.

6.2 Reuniones
de revisión de errores Una reunión de revisión de errores es una reunión oficial en la que se informa y resuelve todos los errores del módulo existente. Esta reunión normalmente reúne a las principales partes interesadas que representan a los diversos grupos involucrados en el desarrollo ágil de software, la ingeniería, el control de calidad, el soporte, el propietario del producto y el scrum master.

6.3 Solicitud de cambio
Detalle el procedimiento de cambios al software en un documento. Asigne quién trabajará en las modificaciones y cuál será la base para agregar las modificaciones al software existente. Supongamos que las modificaciones están afectando los programas actuales, entonces estos módulos deben ser verificados.

6.4 Reporte
de Defectos Detallar el proceso a seguir cuando ocurrió un incidente durante el procedimiento de prueba en un documento. Si está utilizando un formulario estándar, se debe adjuntar una copia en blanco como un «Apéndice» al Plan de prueba. Anote el proceso, si está utilizando un sistema de registro de incidentes automatizado en la prueba. Se deben proporcionar herramientas de informe de defectos a los evaluadores.

7. Funciones a probar

Verifique todos y cada uno de los atributos del software y la combinación de los módulos de software que deben probarse.

8. Recursos y Responsabilidades

8.1. Recursos: Se utilizarán los siguientes recursos:

• Servidor: requiere un servidor de base de datos que instale el servidor MySQL y un servidor web que instale el servidor Apache.
• Herramienta de prueba: Cree una herramienta de prueba que generará automáticamente la salida de la prueba en el formulario destinado y el rendimiento de la prueba automatizada.
• Red: crea una red con una LAN gigabit y 1 línea de internet con una velocidad de al menos 5 Mb/s.
• Computadora: Al menos cuatro computadoras que se ejecutarán en Windows 7, Ram 2GB, CPU 3.4GHZ.

8.2. Responsabilidades

Tome nota de todos los miembros del personal que están en este proyecto de prueba y cuáles son sus roles. Nombre los grupos para administrar, diseñar, preparar, ejecutar y resolver las actividades de prueba y también los problemas relevantes. Nombre de las personas para proporcionar el entorno de prueba. Pueden incluir desarrolladores, probadores, personal de operaciones y servicios de prueba.

Detalle las tareas de varios miembros del equipo como:

• Analista de control de calidad.
• Gerente de prueba.
• Administrador de configuración.
• Desarrolladores.

El equipo de instalación tiene que ser mencionado aquí.

Las tareas se definen como:

• Test Manager: Supervisa el proyecto completo, describe las formas del proyecto y obtiene los recursos correctos.
• Prueba: nombrando y definiendo técnicas o herramientas de prueba apropiadas o marco de automatización, validando y evaluando el enfoque de prueba, realizando las pruebas, registrando los resultados e informando los errores.
• Desarrollador en Prueba: Realización de casos de prueba, programa de prueba y conjunto de pruebas.
• Administrador de prueba: desarrolla y se asegura de que el entorno de prueba y los activos estén supervisados ​​y administrados, y apoya a los evaluadores para que usen el entorno de prueba para la ejecución de la prueba.
• Miembros de SQA: están a cargo del control de calidad, se asegurarán de que el proceso de prueba cumpla con los requisitos especificados.

9. Entregables

Reconocer los principales documentos entregables. Detallar todos los entregables de prueba durante varias etapas de la prueba. Los entregables simples son el plan de prueba, los casos de prueba, la array de trazabilidad de requisitos, los informes de defectos, la estrategia de prueba, las métricas de prueba y la aprobación del usuario. Los entregables de prueba se proporcionan a continuación:

Antes de la fase de prueba

• Documento del plan de prueba
• Documento de casos de prueba
• Especificación de diseño de prueba

Durante la fase de prueba

• Simuladores de herramientas de prueba
• Datos necesarios para la prueba
• Trazabilidad Array de pruebas
• Registros de defectos y registros de rendimiento.

Después de completar el ciclo de prueba

• Resultados o informes de las pruebas
• Informe de errores
• Pautas para el proceso de instalación o prueba
• Documentos de liberación

10. Criterios de suspensión/salida

Estos criterios describen los criterios que se utilizarán para retrasar una parte del proceso de prueba.

11. Criterios de reanudación

Estos criterios definen cuándo se pueden reiniciar las pruebas después de haber estado en espera.

12. Dependencias

Aquí, los requisitos de la aplicación se examinan antes del software actual, las primeras etapas para probar la funcionalidad correcta. Reconocer las limitaciones notables en las pruebas, como la disponibilidad de elementos de prueba, la disponibilidad de recursos de prueba y los plazos. Además, identifique el personal, el software, el hardware, los datos de prueba y las dependencias de la base de datos.

12.1 Dependencias del personal: los requisitos dependen de las personas en un equipo de prueba.

12.2 Dependencias del software: Los requisitos dependen del software o producto aquí.

12.3 Dependencias de hardware: aquí, los requisitos dependen de los componentes de hardware aquí.

12.3 Datos de prueba y base de datos: la prueba aquí depende de los datos que se van a probar y de la base de datos.

13. Riesgos

Definimos las posibilidades de los riesgos y las posibilidades de evitar esos riesgos. Reconocer los cálculos de riesgo mayor en el plan de prueba. Identificar posibles planes para cada uno. (Supongamos que, si hay un retraso en la entrega de los elementos de prueba, se requiere trabajar en las noches y los fines de semana para cumplir con la fecha de entrega).

13.1. Programación: la fecha de lanzamiento del proyecto pasa cuando los riesgos y las tareas no se calculan correctamente. Esto afectará el proyecto y puede conducir al fracaso del proyecto y marcas en las finanzas de la empresa. Los riesgos de cronograma ocurren debido a las siguientes razones:

• El tiempo de entrega se calcula de manera incorrecta.
• El rastreo de recursos no se realiza correctamente. Estos recursos consisten en software, personal y las habilidades del empleado.
• Las tareas compuestas no se calculan correctamente. Por lo tanto, el cálculo del tiempo no se realiza correctamente.

13.2. Técnico: Por la escasez de rendimiento y ejecución de funcionalidades, se producen riesgos técnicos. Los factores que causan los riesgos técnicos son:

• Mejoras continuas en los requisitos del software.
• El desarrollo de tecnología no está disponible.
• Proceso de software compuesto.
• La integración de componentes es difícil.

13.3. Gestión: Causas de los riesgos de gestión:

• Deficiencia de recursos
• No hay una adecuada planificación de los recursos.
• No hay comunicación dentro del equipo.

13.4. Personal: Causas de los riesgos del personal:

• Fracaso en el tratamiento de disputas de prioridad.
• Falta de resolución de cargas.
• No hay entrenamiento correcto del sujeto.

13.5 Requisitos: Causas de los riesgos de los requisitos:

• Requisitos que no están claros
• Requisitos que no están completos
• Requisitos contradictorios
• Requisitos poco prácticos
• Verificación insuficiente
• Supuestos que no son válidos

14. Herramientas

Identifique las herramientas de prueba que va a utilizar en el proyecto. Nombre también las herramientas de seguimiento de errores.

15. Documentación

Los requisitos, diseños, condiciones comerciales, configuraciones, cambios de software, planes de prueba, casos de prueba, informes de defectos y manuales de usuario pueden documentarse aquí.

16. Aprobaciones

Enumere los nombres y cargos de todos los miembros que deben aceptar este plan. Deje suficiente espacio para las firmas y las fechas.

Name  Signature  Date:
1.
2.

Cierre:

Un plan de prueba convincente es una parte muy importante de la preparación del proyecto de desarrollo. El documento del plan de prueba debe ser claro, breve y modificarse según los cambios en el plan o el entorno. Esto asegurará que cada miembro de su equipo se esfuerce por alcanzar el mismo objetivo y que nada se pierda en el camino.