PLAN DE PRUEBA - PRUEBAS DE SOFTWARE

Un plan de prueba es un documento detallado que describe áreas y actividades de prueba de software. Describe la estrategia de prueba, los objetivos, el cronograma de pruebas, los recursos necesarios (recursos humanos, software y hardware), la estimación de la prueba y los resultados de la prueba.

El plan de pruebas es la base de las pruebas de cada software. Es la actividad más crucial que garantiza la disponibilidad de todas las listas de actividades planificadas en una secuencia adecuada.

El plan de prueba es una plantilla para realizar actividades de prueba de software como un proceso definido que es completamente monitoreado y controlado por el gerente de pruebas. El plan de pruebas lo prepara el jefe de pruebas (60%), el director de pruebas (20%) y el ingeniero de pruebas (20%).

Tipos de plan de prueba

Hay tres tipos de plan de prueba.

Plan Maestro de Pruebas
Plan de prueba de fase
Tipo de prueba Planes de prueba específicos

Plan Maestro de Pruebas

El Plan Maestro de Pruebas es un tipo de plan de prueba que tiene múltiples niveles de prueba. Incluye una estrategia de prueba completa.

Plan de prueba de fase

Un plan de prueba de fase es un tipo de plan de prueba que aborda cualquier fase de la estrategia de prueba. Por ejemplo, una lista de herramientas, una lista de casos de prueba, etc.

Planes de prueba específicos

Plan de pruebas específico diseñado para los principales tipos de pruebas, como pruebas de seguridad, pruebas de carga, pruebas de rendimiento, etc. En otras palabras, un plan de pruebas específico diseñado para pruebas no funcionales.

Cómo escribir un plan de prueba

Elaborar un plan de pruebas es la tarea más crucial del proceso de gestión de pruebas. Según IEEE 829, siga los siguientes siete pasos para preparar un plan de prueba.

Primero, analice la estructura y arquitectura del producto.
Ahora diseñe la estrategia de prueba.
Definir todos los objetivos de la prueba.
Definir el área de prueba.
Definir todos los recursos utilizables.
Programe todas las actividades de manera adecuada.
Determinar todos los entregables de la prueba.

Componentes o atributos del plan de pruebas

El plan de prueba consta de varias partes que nos ayudan a derivar toda la actividad de prueba.

Objetivos: Consiste en información sobre módulos, características, datos de prueba, etc., que indican el objetivo de la aplicación, es decir, el comportamiento de la aplicación, el objetivo, etc.

comunicación analógica

Alcance: Contiene información que debe probarse con la respectiva aplicación. El alcance se puede dividir a su vez en dos partes:

En alcance
Fuera de alcance

En alcance: Estos son los módulos que deben probarse rigurosamente (en detalle).

Fuera de alcance: Estos son los módulos que no necesitan ser probados rigurosamente.

Por ejemplo , Supongamos que tenemos una aplicación de Gmail para probar, donde características a probar como Redactar correo, Elementos enviados, Bandeja de entrada, Borradores y el características que no deben probarse como Ayuda , etc., lo que significa que en la etapa de planificación, decidiremos qué funcionalidad debe verificarse o no en función del límite de tiempo indicado en el producto.

Ahora ¿Cómo decidimos qué características no se probarán?

Tenemos los siguientes aspectos donde podemos decidir qué característica no probar:

Como vemos arriba Ayuda Las características no se probarán, ya que están escritas y desarrolladas por el redactor técnico y revisadas por otro redactor profesional.
Supongamos que tenemos una aplicación que tiene P, Q, R y S características que deben desarrollarse en función de los requisitos. Pero aquí, la función S ya ha sido diseñada y utilizada por otra empresa. Entonces, el equipo de desarrollo comprará S de esa empresa y lo integrará con funciones adicionales como P, Q y R.

Ahora, no realizaremos pruebas funcionales de la función S porque ya se ha utilizado en tiempo real. Pero haremos las pruebas de integración y las pruebas del sistema entre las funciones P, Q, R y S porque es posible que las nuevas funciones no funcionen correctamente con la función S, como podemos ver en la imagen a continuación:

Supongamos en la primera versión del producto, los elementos que se han desarrollado, como P, Q, R, S, T, U, V, W…..X, Y, Z . Ahora el cliente proporcionará los requisitos para las nuevas funciones que mejoran el producto en la segunda versión y las nuevas funciones son A1, B2, C3, D4 y E5.

Después de eso, escribiremos el alcance durante el plan de prueba como

Alcance

Características a probar

A1, B2, C3, D4, E5 (nuevas funciones)

P, Q, R, S, T

Funciones que no se deben probar

W X Y Z

Por lo tanto, primero verificaremos las nuevas características y luego continuaremos con las antiguas porque podrían verse afectadas después de agregar las nuevas características, lo que significa que también afectará las áreas de impacto, por lo que haremos una ronda de pruebas de regresión para P, Q. , R…, T características.

Metodología de prueba:

Contiene información sobre cómo realizar diferentes tipos de pruebas, como pruebas funcionales, pruebas de integración y pruebas del sistema, etc., en la aplicación. En esto decidiremos qué tipo de prueba; Realizaremos las diversas funciones según los requisitos de la aplicación. Y aquí, también debemos definir qué tipo de pruebas usaremos en las metodologías de prueba para que todos, como la gerencia, el equipo de desarrollo y el equipo de pruebas, puedan entender fácilmente porque los términos de prueba no son estándar.

Por ejemplo, para aplicaciones independientes como Adobe Photoshop , realizaremos los siguientes tipos de pruebas:

Pruebas de humo → Pruebas funcionales → Pruebas de integración → Pruebas de sistema → Pruebas ad hoc → Pruebas de compatibilidad → Pruebas de regresión → Pruebas de globalización → Pruebas de accesibilidad → Pruebas de usabilidad → Pruebas de confiabilidad → Pruebas de recuperación → Pruebas de instalación o desinstalación

Y supongamos que tenemos que probar el https://www.jeevansathi.com/ aplicación, por lo que realizaremos los siguientes tipos de pruebas:

Prueba de humo	Pruebas funcionales	Pruebas de integración
Pruebas del sistema	Pruebas ad hoc	Pruebas de compatibilidad
Pruebas de regresión	Pruebas de globalización	Pruebas de accesibilidad
Pruebas de usabilidad	Pruebas de rendimiento

Acercarse

Este atributo se utiliza para describir el flujo de la aplicación mientras se realizan pruebas y para referencia futura.

Podemos comprender el flujo de la aplicación con la ayuda de los siguientes aspectos:

Escribiendo los escenarios de alto nivel. Escribiendo el diagrama de flujo

Escribiendo los escenarios de alto nivel.

Por ejemplo , supongamos que estamos probando el Gmail solicitud:

Inicie sesión en Gmail: envía un correo electrónico y comprueba si está en la página Elementos enviados
Iniciar sesión en …….
……
…....

Escribimos esto para describir los enfoques que se deben adoptar para probar el producto y solo para las características críticas donde escribiremos los escenarios de alto nivel. Aquí, no nos centraremos en cubrir todos los escenarios porque el ingeniero de pruebas en particular puede decidir qué características deben probarse o no.

Escribiendo el diagrama de flujo

El gráfico de flujo se escribe porque escribir los escenarios de alto nivel es un proceso que lleva poco tiempo, como podemos ver en la siguiente imagen:

Estamos creando diagramas de flujo para lograr los siguientes beneficios, tales como:

La cobertura es fácil
Fusionarse es fácil

El enfoque se puede clasificar en dos partes que son las siguientes:

Enfoque de arriba a abajo
Enfoque de abajo hacia arriba

Suposición

Contiene información sobre un problema o cuestión que tal vez ocurrió durante el proceso de prueba y cuando escribimos los planes de prueba, se harán las suposiciones aseguradas como recursos y tecnologías, etc.

Riesgo

Estos son los desafíos que debemos enfrentar para probar la aplicación en la versión actual y, si las suposiciones fallan, entonces existen riesgos.

Por ejemplo, Para efectos de una solicitud, la fecha de publicación queda pospuesta.

Plan de Mitigación o Plan de Contingencia

Es un plan de respaldo que está preparado para superar los riesgos o problemas.

Veamos un ejemplo de asunción, riesgo y plan de contingencia juntos porque están correlacionados entre sí.

En cualquier producto, el suposición Lo que haremos es que los 3 ingenieros de pruebas estarán allí hasta que se complete el producto y a cada uno de ellos se le asignarán diferentes módulos, como P, Q y R. En este escenario particular, el riesgo podría ser eso si el ingeniero de pruebas dejara el proyecto a la mitad.

Por lo tanto, la plan de contingencia Se le asignará un propietario principal y uno subordinado a cada característica. Entonces, si un ingeniero de pruebas se va, el propietario subordinado se hace cargo de esa característica específica y también ayuda al nuevo ingeniero de pruebas, para que pueda comprender los módulos asignados.

Los supuestos, riesgos y planes de mitigación o contingencia siempre son precisos sobre el producto en sí. Los distintos tipos de riesgos son los siguientes:

Perspectiva del cliente
Enfoque de recursos
Opinión técnica

rol y responsabilidad

Define la tarea completa que debe realizar todo el equipo de pruebas. Cuando llega un gran proyecto, entonces el Gerente de pruebas Es una persona que escribe el plan de prueba. Si hay entre 3 y 4 proyectos pequeños, el director de pruebas asignará cada proyecto a cada líder de pruebas. Y luego, el líder de pruebas escribe el plan de pruebas para el proyecto que se le asigna.

Veamos un ejemplo en el que comprenderemos las funciones y responsabilidades del director de pruebas, el líder de pruebas y los ingenieros de pruebas.

Rol: Gerente de pruebas

Nombre: Ryan

sistema.out.println

Responsabilidad:

Preparar (escribir y revisar) el plan de prueba.
Realizar la reunión con el equipo de desarrollo.
Realizar la reunión con el equipo de pruebas.
Realizar la reunión con el cliente.
Realizar una reunión mensual de pie.
Cerrar nota de lanzamiento
Manejo de escalaciones y problemas

Rol: Líder de pruebas

Nombre: Harvey

convertir cadena a int java

Responsabilidad:

Preparar (escribir y revisar) el plan de prueba.
Llevar a cabo una reunión diaria de pie.
Revisar y aprobar el caso de prueba.
Preparar el RTM y los informes.
Asignar módulos
Calendario de manipulación

Rol: Ingeniero de pruebas 1, Ingeniero de pruebas 2 e Ingeniero de pruebas 3

Nombre: Louis, Jessica, Donna

Asignar módulos: M1, M2 y M3

Responsabilidad:

Escribir, revisar y ejecutar los documentos de prueba que constan de casos de prueba y escenarios de prueba.
Leer, revisar, comprender y analizar el requisito.
Escribe el flujo de la aplicación.
Ejecutar el caso de prueba
RTM para los módulos respectivos
Seguimiento de defectos
Elaborar el informe de ejecución de la prueba y comunicarlo al Jefe de Prueba.

Cronograma

¿Se utiliza para explicar el momento del trabajo, qué se debe hacer o este atributo cubre cuándo exactamente debe comenzar y finalizar cada actividad de prueba? Y también se mencionan los datos exactos para cada actividad de prueba para la fecha particular.

Por lo tanto, como podemos ver en la imagen a continuación, para la actividad en particular, habrá una fecha de inicio y una fecha de finalización; para cada prueba de una compilación específica, habrá una fecha especificada.

Por ejemplo

Escribir casos de prueba
Proceso de ejecución

Seguimiento de defectos

Generalmente se hace con la ayuda de herramientas porque no podemos rastrear el estado de cada error manualmente. Y también comentamos cómo comunicamos los errores que se identifican durante el proceso de prueba y se los enviamos al equipo de desarrollo y cómo responderá el equipo de desarrollo. Aquí también mencionamos la prioridad de los errores como alta, media y baja.

A continuación se detallan varios aspectos del seguimiento de defectos:

Bloqueador o espectacular

Por ejemplo

Crítico

Importante

Menor

Alto-P1

Medio-P2

Bajo-P3

Por lo tanto, según la prioridad de errores como alta, media y baja, los clasificaremos como P1, P2, P3 y P4.

Entornos de prueba

Estos son los entornos donde probaremos la aplicación, y aquí tenemos dos tipos de entornos, que son de software y hardware configuración.

El configuración de software significa los detalles sobre diferentes Sistemas operativos como Windows, Linux, UNIX y Mac Y varios Navegadores como Google Chrome, Firefox, Opera, Internet Explorer , etcétera.

Y el Configuración de hardware significa la información sobre diferentes tamaños de RAM, ROM y los procesadores .

Por ejemplo

El Software incluye lo siguiente:

Servidor

Sistema operativo	linux
Servidor web	gato apache
Servidor de aplicaciones	Webesfera
Servidor de base de datos	Servidor Oracle o MS-SQL

Nota: Los servidores anteriores son los que utiliza el equipo de pruebas para probar la aplicación.

Cliente

Sistema operativo	Window XP, Vista 7
Navegadores	Mozilla Firefox, Google Chrome, Internet Explorer, Internet Explorer 7 e Internet Explorer 8

Nota: Los detalles anteriores proporcionan los distintos sistemas operativos y navegadores en los que el equipo de pruebas probará la aplicación.

El Hardware incluye lo siguiente:

Servidor : Sol StarCat 1500

El equipo de pruebas puede utilizar este servidor en particular para probar su aplicación.

Cliente:

Tiene la siguiente configuración, que es la siguiente:

Procesador	Intal2GHz
RAM	2GB
….	….

Nota: Proporcionará la configuración de los sistemas de los ingenieros de pruebas que son el equipo de pruebas.

El equipo de desarrollo proporcionará la configuración de cómo instalar el software. Si el equipo de desarrollo aún no proporciona el proceso, lo escribiremos como Desarrollo basado en tareas (TBD) en el plan de prueba.

Criterios de entrada y salida

Es una condición necesaria que debe cumplirse antes de iniciar y detener el proceso de prueba.

java convierte caracteres a cadenas

Criterio para entrar

Los criterios de entrada contienen las siguientes condiciones:

Las pruebas de caja blanca deberían finalizar.
Comprender y analizar el requisito y preparar los documentos de prueba o cuando los documentos de prueba estén listos.
Los datos de prueba deberían estar listos.
La compilación o la aplicación deben estar preparadas.
Es necesario asignar módulos o funciones a los diferentes ingenieros de pruebas.
El recurso necesario debe estar listo.

Criterio de salida

Los criterios de salida contienen las siguientes condiciones:

Cuando se ejecutan todos los casos de prueba.
La mayoría de los casos de prueba deben ser aprobado .
Depende de la gravedad de los errores, lo que significa que no debe haber ningún bloqueador o error importante, aunque existen algunos errores menores.

Antes de comenzar a realizar pruebas funcionales, todo lo anterior Criterio para entrar debe ser seguido. Después de realizar pruebas funcionales y antes de realizar pruebas de integración, entonces el Criterios de salida de Se deben seguir las pruebas funcionales porque el porcentaje de criterios de salida se decide mediante la reunión con el gerente de desarrollo y de pruebas porque su colaboración puede lograr el porcentaje. Pero si no se siguen los criterios de salida de las pruebas funcionales, entonces no podemos continuar con las pruebas de integración.

Aquí basado en la gravedad del error significa que el equipo de pruebas habría decidido continuar con las siguientes fases.

Automatización de pruebas

En este, decidiremos lo siguiente:

¿Qué característica debe automatizarse y qué no?
¿Qué herramienta de automatización de pruebas vamos a utilizar en qué marco de automatización?

Automatizamos el caso de prueba solo después del primer lanzamiento.

Aquí surge la pregunta de ¿sobre qué base? nosotros voluntad ¿Decidir qué características deben probarse?

En la imagen de arriba, como podemos ver, las funciones más utilizadas deben probarse una y otra vez. Supongamos que tenemos que verificar la aplicación Gmail donde están las funciones esenciales. Redactar correo, elementos enviados y bandeja de entrada . Por lo tanto, probaremos estas funciones porque, al realizar pruebas manuales, lleva más tiempo y también se convierte en un trabajo monótono.

Ahora, ¿Cómo decidimos qué funciones no se van a probar?

Suponer la ayuda La función de la aplicación Gmail no se prueba una y otra vez porque estas funciones no se utilizan con regularidad, por lo que no es necesario comprobarla con frecuencia.

Pero si algunas características son inestables y tienen muchos errores , lo que significa que no probaremos esas funciones porque hay que probarlas una y otra vez mientras se realizan pruebas manuales.

Si Hay una característica que debe probarse con frecuencia. , pero esperamos el cambio de requisitos para esa característica, por lo que no la verificamos porque cambiar los casos de prueba manuales es más cómodo en comparación con el cambio en el script de prueba de automatización.

Estimación del esfuerzo

En esto, planificaremos el esfuerzo que debe aplicar cada miembro del equipo.

Entregable de la prueba

Estos son los documentos que son el resultado del equipo de pruebas, que entregamos al cliente junto con el producto. Incluye lo siguiente:

Plan de prueba Casos de prueba Guiones de prueba RTM (Matriz de trazabilidad de requisitos) Informe de defectos Informe de ejecución de pruebas Gráficos y métricas Notas de lanzamiento

Gráficos y métricas

Grafico

En este, discutiremos sobre los tipos de graficos le enviaremos y también le proporcionaremos una muestra de cada gráfico.

Como podemos ver, tenemos cinco gráficos diferentes que muestran los distintos aspectos del proceso de prueba.

Gráfico 1: En esto, mostraremos cuántos defectos se han identificado y cuántos defectos se han solucionado en cada módulo.

Gráfico 2: La figura uno muestra cuántos defectos críticos, mayores y menores se han identificado para cada módulo y cuántos se han solucionado para sus respectivos módulos.

Gráfico3: En este gráfico en particular, representamos el construir un gráfico inteligente , lo que significa que en cada compilación cuántos defectos se han identificado y solucionado para cada módulo. Según el módulo, hemos determinado los errores. agregaremos R para mostrar el número de defectos en P y Q, y también sumamos S para mostrar los defectos en P, Q y R.

Gráfico4: El líder de prueba diseñará el Análisis de tendencias de errores gráfico que se crea cada mes y enviarlo también a la Dirección. Y es como una predicción que se realiza al final del producto. Y aquí también podemos califica las correcciones de errores como podemos observar que arco tiene un tendencia alcista en la imagen de abajo.

Gráfico5: El Gerente de pruebas ha diseñado este tipo de gráfico. Este gráfico tiene como objetivo comprender la brecha en la evaluación de errores y los errores reales que se han producido, y este gráfico también ayuda a mejorar la evaluación de errores en el futuro.

Métrica

Como se indicó anteriormente, creamos el gráfico de distribución de errores, que se encuentra en la figura 1, y con la ayuda de los datos mencionados anteriormente, también diseñaremos las métricas.

Por ejemplo

En la figura anterior, conservamos los registros de todos los ingenieros de pruebas en un proyecto en particular y cuántos defectos se identificaron y solucionaron. También podemos utilizar estos datos para análisis futuros. Cuando surge un nuevo requisito, podemos decidir a quién proporcionar la característica desafiante para realizar pruebas en función de la cantidad de defectos que hayan encontrado anteriormente de acuerdo con las métricas anteriores. Y estaremos en una mejor situación para saber quién puede manejar muy bien las características problemáticas y encontrar el máximo número de defectos.

Nota de versión: Es un documento que se prepara durante el lanzamiento del producto y firmado por el Responsable de Pruebas.

En la imagen a continuación, podemos ver que el producto final se desarrolla y se implementa para el cliente, y el nombre de la última versión es Beta .

El Nota de lanzamiento consta de lo siguiente:

Manual de usuario.
Listado de defectos pendientes y abiertos.
Lista de funciones agregadas, modificadas y eliminadas.
Listado de la plataforma (Sistema Operativo, Hardware, Navegadores) en la que se prueba el producto.
Plataforma en la que no se prueba el producto.
Lista de errores corregidos en la versión actual y lista de errores corregidos en la versión anterior.
Proceso de instalación
Versiones del software

Por ejemplo

Suponer que Beta es la segunda versión de la aplicación después de la primera Alfa en lanzamiento. Algunos de los defectos identificados en la primera publicación y que se han solucionado en la publicación posterior. Y aquí, también señalaremos la lista de funciones recientemente agregadas, modificadas y eliminadas desde la versión alfa hasta la versión beta.

Plantilla

Esta parte contiene todas las plantillas para los documentos que se utilizarán en el producto y todos los ingenieros de pruebas utilizarán solo estas plantillas en el proyecto para mantener la coherencia del producto. Aquí tenemos diferentes tipos de plantilla que se utilizan durante todo el proceso de prueba, como por ejemplo:

Plantilla de caso de prueba
Plantilla de revisión de casos de prueba
Plantilla RTM
Plantilla de informe de errores
Informe de ejecución de pruebas

Veamos una muestra del documento del plan de prueba.

Página 1

Página3-página18

Página-20

En la página 1, principalmente completamos solo el Versiones, autor, comentarios y revisado por campos, y después de que el gerente lo apruebe, mencionaremos los detalles en el Aprobado por y fecha de aprobación campos.

Básicamente, el plan de pruebas lo aprueba el director de pruebas y los ingenieros de pruebas solo lo revisan. Y cuando lleguen las nuevas funciones, modificaremos el plan de prueba y haremos las modificaciones necesarias en Versión y luego se enviará nuevamente para su posterior revisión, actualización y aprobación por parte del administrador. El plan de pruebas debe actualizarse cada vez que se produzca algún cambio. En la página 20, el Referencias especifique los detalles sobre todos los documentos que vamos a utilizar para escribir el documento del plan de prueba.

Nota:

¿Quién escribe el plan de prueba?

Cable de prueba→60%
Gerente de pruebas→20%
Ingeniero de pruebas→20%

Por lo tanto, como podemos ver desde arriba, en el 60% del producto, el plan de prueba lo escribe el líder de prueba.

¿Quién revisa el plan de pruebas?

Cable de prueba
Gerente de pruebas
Ingeniero de pruebas
Cliente
Equipo de desarrollo

El ingeniero de pruebas revisa el plan de pruebas desde la perspectiva de su módulo y el administrador de pruebas revisa el plan de pruebas según la opinión del cliente.

¿Quién aprueba el Plan de pruebas?

Cliente
Gerente de pruebas

¿Quién escribe el caso de prueba?

Cable de prueba
Ingeniero de pruebas

¿Quién revisa el caso de prueba?

cadena a json java

Ingeniero de pruebas
Cable de prueba
Cliente
Equipo de desarrollo

¿Quién aprueba los casos de prueba?

Gerente de pruebas
Cable de prueba
Cliente

Directrices del plan de pruebas

Contraiga su plan de prueba.
Evite superposiciones y redundancias.
Si cree que no necesita una sección que ya se mencionó anteriormente, elimine esa sección y continúe.
Se específico. Por ejemplo, cuando especifica un sistema de software como parte del entorno de prueba, mencione la versión del software en lugar de solo el nombre.
Evite párrafos largos.
Utilice listas y tablas siempre que sea posible.
Actualizar el plan cuando sea necesario.
No utilice un documento desactualizado y sin usar.

Importancia del plan de prueba

El plan de prueba da dirección a nuestro pensamiento. Esto es como un libro de reglas que hay que seguir.
El plan de prueba ayuda a determinar los esfuerzos necesarios para validar la calidad de la aplicación de software bajo prueba.
El plan de prueba ayuda a aquellas personas a comprender los detalles de la prueba relacionados con el exterior, como desarrolladores, gerentes comerciales, clientes, etc.
Aspectos importantes como el cronograma de pruebas, la estrategia de prueba, el alcance de la prueba, etc., se documentan en el plan de prueba para que el equipo de gestión pueda revisarlos y reutilizarlos para otros proyectos similares.