Pruebas de software: plan de prueba

En las pruebas de software , la documentación es muy importante. Las pruebas deben documentarse para proporcionar un monitoreo eficiente del control de recursos. Para una prueba exitosa, un plan de prueba juega un papel muy importante. Aquí, discutiremos los siguientes puntos:

1. Introducción al plan de prueba
2. Importancia del plan de prueba
3. Pautas del plan de prueba
4. Tipos de planes de prueba
5. Atributos del plan de prueba
6. ¿Qué pasa si no hay un plan de prueba?

1. Plan de prueba

Un plan de prueba es un documento que consta de todas las actividades futuras relacionadas con las pruebas. Se prepara a nivel de proyecto y, en general, define los productos de trabajo que se probarán, cómo se probarán y la distribución del tipo de prueba entre los probadores. Antes de comenzar las pruebas, habrá un administrador de pruebas que preparará un plan de pruebas. En cualquier empresa, cada vez que se emprende un nuevo proyecto antes de que el evaluador participe en la prueba, el gerente de prueba del equipo prepararía un Plan de prueba.

2. Importancia del plan de prueba

Los siguientes son algunos de los beneficios clave de hacer un plan de prueba:

• Actúa como una guía rápida para el proceso de prueba.
• Ayuda a evitar funcionalidades fuera de alcance.
• Determina el tiempo, el costo y el esfuerzo.
• Proporcionar un calendario para las actividades de prueba.
• Requerimiento de recursos y equipo.
• El documento del plan de prueba se puede utilizar para proyectos similares.
• Ayuda a entender los detalles de la prueba.
• Ayuda a determinar la calidad de las aplicaciones de software.

3. Pautas del plan de prueba

• Evite la superposición y la repetición.
• Evite párrafos extensos.
• Usa listas y tablas.
• Actualizar plano.
• No utilice documentos obsoletos.

4. Tipo de plan de prueba

Los siguientes son los tres tipos de planes de prueba:

• Plan de prueba maestro: en este tipo de plan de prueba, incluye múltiples estrategias de prueba y tiene múltiples niveles de prueba.
• Plan de prueba de fase : en este tipo de plan de prueba, énfasis en cualquier fase de prueba.
• Plan de prueba específico: en este tipo de plan de prueba, está diseñado para tipos específicos de prueba, especialmente pruebas no funcionales.

5. Atributos del plan de prueba

No existe una regla estricta y rápida para preparar un plan de prueba, pero tiene algunos 15 atributos estándar que siguen las empresas:

A. Objetivo: Describe el objetivo del plan de pruebas, cualquiera que sea el buen proceso y procedimiento que se va a seguir para entregar software de calidad a los clientes. El objetivo general de la prueba es encontrar tantos defectos como sea posible y hacer que el software esté libre de errores. El objetivo de la prueba debe dividirse en componentes y subcomponentes. En cada componente se deben realizar las siguientes actividades.

• Enumere toda la funcionalidad, el rendimiento que se probará.
• Establezca metas y objetivos en función de la función de la aplicación.

B. Estrategia de Pruebas: Es un documento crucial que debe ser realizado y generalmente diseñado por el Gerente de Pruebas. Ayuda a determinar el esfuerzo de prueba y el costo de prueba. La estrategia de prueba ayuda a determinar las características que se van a probar y las características que no se probarán. El alcance se puede dividir en dos partes:

• Dentro del alcance: Los módulos que se van a probar rigurosamente.
• Fuera de Alcance: Los módulos que no van a ser probados rigurosamente.

Ejemplo: En una aplicación se deben desarrollar las características A, B, C, D, pero la característica B ya ha sido diseñada por otras empresas. Entonces, el equipo de desarrollo comprará B de esa compañía y realizará solo pruebas integradas con A, B, C.

C. Metodología de prueba: Los métodos que se utilizarán para la prueba dependen de una aplicación a otra. La metodología de prueba se decide en función de las características y los requisitos de la aplicación.

Dado que los términos de prueba no son estándar, se debe definir qué tipo de prueba se utilizará en la metodología de prueba. Para que todos puedan entenderlo.

D. Enfoque: El enfoque de probar software diferente es diferente. Se ocupa del flujo de requests para futuras referencias. Tiene dos aspectos:

• Escenarios de alto nivel: Para probar características críticas, se escriben escenarios de alto nivel. Por ejemplo, inicie sesión en un sitio web, reserve desde un sitio web.
• El gráfico de flujo: se usa cuando uno quiere hacer que los beneficios como la convergencia y la fusión sean fáciles.

E. Supuestos: En esta fase, se realizarán ciertos supuestos.

Ejemplo:

• El equipo de prueba obtendrá el apoyo adecuado del equipo de desarrollo.
• El probador obtendrá la transferencia de conocimiento adecuada del equipo de desarrollo.
• La empresa asignará los recursos adecuados al departamento de pruebas.

F. Riesgo: Todos los riesgos que pueden ocurrir si se rompe el supuesto. Por ejemplo, en el caso de una estimación presupuestaria incorrecta, el costo puede excederse. Algunas razones que pueden conducir al riesgo son:

• Test Manager tiene habilidades de gestión deficientes.
• Es difícil completar el proyecto a tiempo.
• Falta de cooperacion.

G. Plan de respaldo/mitigación: si hay algún riesgo, la empresa debe tener un plan de respaldo, el propósito es evitar errores. Algunos puntos para resolver/evitar el riesgo:

• La prioridad de la prueba debe establecerse para cada actividad de prueba.
• Los gerentes deben tener habilidades de liderazgo.
• Curso de formación para los probadores.

H. Roles y Responsabilidades: Se deben registrar todas las responsabilidades y el rol de cada miembro en un equipo de prueba en particular.

Ejemplo:

• Gerente de prueba: administra el proyecto, toma un recurso apropiado y da dirección al proyecto.
• Probador: identifique la técnica de prueba, verifique el enfoque de prueba y ahorre costos del proyecto.

I. Programación: En esta se dejará constancia de la fecha de inicio y término de todas y cada una de las actividades relacionadas con las pruebas. Por ejemplo, escribir la fecha del caso de prueba y la fecha de finalización del caso de prueba.

J. Seguimiento de defectos: es un proceso importante en la ingeniería de software, ya que surgen muchos problemas cuando se desarrolla un sistema crítico para el negocio. Si se encuentra algún defecto durante la prueba, ese defecto debe entregarse al equipo de desarrolladores. Existen los siguientes métodos para el proceso de seguimiento de defectos:

• Captura de Información: En esta tomamos información básica para iniciar el proceso.
• Priorizar: la tarea se prioriza en función de la gravedad y la importancia.
• Comunicar: comunicación entre el identificador del error y el reparador del error.
• Entorno: Probar la aplicación en base a hardware y software.

Ejemplo: el error se puede identificar utilizando herramientas de seguimiento de errores como Jira, Mantis, Trac. 

K. Entorno de prueba : es el entorno que utilizará el equipo de prueba, es decir, la lista de hardware y software, mientras se prueba la aplicación, las cosas que se dice que se probarán se escribirán en esta sección. La instalación de software también se comprueba bajo esto.

Ejemplo:

• Configuración de software en diferentes sistemas operativos, como Windows, Linux, Mac, etc.
• La configuración del hardware depende de la memoria RAM, ROM, etc.

L. Criterios de Entrada y Salida: El conjunto de condiciones que deben cumplirse para iniciar cualquier nuevo tipo de prueba o para terminar cualquier tipo de prueba.

Condición de entrada:

• Los recursos necesarios deben estar listos.
• La solicitud debe estar preparada.
• Los datos de prueba deben estar listos.

Condición de salida:

• No debería haber ningún error importante.
• La mayoría de los casos de prueba deben ser aprobados.
• Cuando se ejecutan todos los casos de prueba.

Ejemplo: si el miembro del equipo informa que el 45 % de los casos de prueba fallaron, las pruebas se suspenderán hasta que el equipo de desarrolladores corrija todos los defectos.

M. Automatización de Pruebas: Consiste en las características que se van a automatizar y las que no se van a automatizar.

• Si la función tiene muchos errores, se clasifica como prueba manual.
• Si la función se prueba con frecuencia, se puede automatizar.

N. Entregables : es el resultado del equipo de prueba y se entregará a los clientes al final del proyecto.

Antes de la fase de prueba:

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

Durante la fase de prueba:

• Guiones de prueba.
• Datos de prueba.
• Registros de errores.

Después de la fase de prueba:

• Informes de las pruebas.
• Informe de defectos.
• Informe de instalación.

Contiene un plan de prueba, un informe de defectos, un informe de automatización, un informe de supuestos, herramientas y otros componentes que se han utilizado para desarrollar y mantener el esfuerzo de prueba.

O. Plantilla: Le sigue todo tipo de informe que va a preparar el equipo de pruebas.

6. ¿Qué pasa si no hay un plan de prueba?

A continuación se presentan algunas de las situaciones que pueden ocurrir si no existe un plan de prueba:

• Incomprensión de roles y responsabilidades.
• El equipo de prueba no tendrá un objetivo claro.
• No hay garantía cuando finaliza el proceso.
• El alcance de la prueba indefinido puede confundir a los probadores.