difference between test plan
Aprenda cuál es la diferencia entre plan de prueba, estrategia de prueba, caso de prueba, guión de prueba, escenario de prueba y condición de prueba con ejemplos:
Las pruebas de software incluyen varios conceptos básicos e importantes que todo probador de software debe conocer.
Este artículo explicará los distintos conceptos de pruebas de software junto con su comparación.
Plan de prueba frente a estrategia de prueba, caso de prueba frente a script de prueba, escenario de prueba frente a condición de prueba y procedimiento de prueba frente a conjunto de pruebas se explican en detalle para su fácil comprensión.
=> Haga clic aquí para ver la serie completa de tutoriales del plan de prueba
cuál es el mejor sistema operativo de computadoraPregunta: “Casi tenemos una sobrecarga de términos técnicos cuando trabajamos en un entorno de TI. Hay procesos, documentos, tareas y todo lo demás que se aborda con su propio nombre técnico. Ahora, ¿cómo vamos a recordarlos, comprenderlos y usarlos en el contexto correcto cada vez? '
La pregunta anterior hecha por Sasi C. es la pregunta más frecuente en nuestro Clase de pruebas de software y siempre les digo a nuestros participantes que con la experiencia apenas notamos estas palabras y que pasan a formar parte de nuestro vocabulario.
Pero a menudo, la confusión rodea estos y en este artículo, estoy tratando de definir algunos términos de uso común.
Varios conceptos de pruebas de software
A continuación se enumeran los diversos conceptos de pruebas de software junto con su comparación.
¡¡Empecemos!!
Lo que vas a aprender:
- Diferencia entre plan de prueba y estrategia de prueba
- Plan de prueba
- Documento del plan de prueba
- Estrategia de prueba
- Documento de estrategia de prueba
- # 1) Descripción general del proyecto
- # 2) Alcance de los requisitos
- # 3) Plan de prueba de alto nivel
- # 4) Enfoque de prueba
- # 5) Cobertura de prueba
- # 6) Entorno de prueba
- # 7) Entregables y Métricas de QA
- # 8) Gestión de defectos
- # 9) Gestión de la comunicación
- # 10) Supuestos, riesgos y dependencias
- # 11) Apéndice
- Plan de prueba Vs Estrategia de prueba
- Diferencia entre caso de prueba y script de prueba
- Diferencia entre el escenario de prueba y la condición de prueba
- Diferencia entre el procedimiento de prueba y el conjunto de pruebas
- Conclusión
Diferencia entre plan de prueba y estrategia de prueba
La estrategia de prueba y el plan de prueba son dos documentos importantes en el ciclo de vida de prueba de cualquier proyecto. Aquí estamos tratando de brindarle un conocimiento profundo de la estrategia de prueba y los documentos del plan de prueba.
Plan de prueba
Un plan de prueba se puede definir como un documento que define el alcance, el objetivo y el enfoque para probar la aplicación de software. El plan de prueba es un plazo y un entregable.
El plan de prueba es un documento que enumera todas las actividades de un proyecto de control de calidad, las programa, define el alcance del proyecto, roles y responsabilidades, riesgos, criterios de entrada y salida, objetivo de la prueba y cualquier otra cosa que se le ocurra.
El plan de prueba es como me gusta llamar un 'superdocumento' que enumera todo lo que hay que saber y necesitar. Por favor revisa este enlace para obtener más información y una muestra.
El plan de prueba se diseñará en función de los requisitos. Al asignar trabajo a los ingenieros de pruebas, debido a algunas razones, uno de los probadores es reemplazado por otro. Aquí, el plan de prueba se actualiza.
La estrategia de prueba describe el enfoque de prueba y todo lo demás que lo rodea. Es diferente del plan de prueba, en el sentido de que una estrategia de prueba es solo un subconjunto del plan de prueba. Es un documento de prueba duro que es hasta cierto punto genérico y estático. También hay una discusión sobre a qué niveles se usa la estrategia o el plan de prueba, pero realmente no veo ninguna diferencia discernible.
Ejemplo: El plan de pruebas proporciona información sobre quién va a realizar la prueba a qué hora. Por ejemplo, El módulo 1 será probado por 'X tester'. Si el probador Y reemplaza a X por alguna razón, el plan de prueba debe actualizarse.
Documento del plan de prueba
El plan de prueba es un documento que proporciona información completa sobre las tareas de prueba relacionadas con un proyecto de software. Proporciona detalles como el alcance de la prueba, tipos de prueba, objetivos, metodología de prueba, esfuerzo de prueba, riesgos y contingencias, criterios de publicación, entregables de prueba, etc. Realiza un seguimiento de las posibles pruebas que se ejecutarán en el sistema después de la codificación.
Obviamente, el plan de prueba va a cambiar. Inicialmente, se desarrollará un borrador de plan de prueba basado en la claridad del proyecto en ese momento. Este plan inicial se irá modificando a medida que avance el proyecto. Test team Manager o Test Lead puede preparar el documento del plan de prueba. Describe las especificaciones y está sujeto a cambios en función de las mismas.
Qué probar, cuándo probar, quién probará y cómo probarlo se definirá en el plan de prueba. Test Plan clasificará una lista de problemas, dependencias y riesgos subyacentes.
Tipos de plan de prueba
Los planes de prueba pueden ser de diferentes tipos según la etapa de prueba. Inicialmente, habrá un plan maestro de pruebas para toda la ejecución del proyecto. Se pueden crear planes de prueba separados para tipos de prueba específicos como pruebas de sistemas, pruebas de integración de sistemas, pruebas de aceptación de usuarios, etc.
Otro enfoque es tener planes de prueba separados para pruebas funcionales y no funcionales. En este enfoque de rendimiento, las pruebas tendrán un plan de prueba independiente.
Contenido del documento del plan de prueba ( Estructura del plan de prueba IEEE-829 )
Es difícil trazar un formato claro para el plan de prueba. El formato del plan de prueba puede variar según el proyecto en cuestión. IEEE ha definido un estándar para los planes de prueba que se describen como la estructura del plan de prueba IEEE-829.
A continuación, encontrará las recomendaciones de IEEE para el contenido de un plan de prueba estándar:
descarga de la biblioteca estándar de c ++
- Identificador del plan de prueba
- Introducción
- Elementos de prueba
- Problemas de riesgo de software
- Características a probar
- Características que no deben probarse
- Acercarse
- Criterios de aprobación / reprobación del artículo (o) Criterios de aceptación
- Criterios de suspensión y requisitos de reanudación
- Entregables de prueba
- Tareas de prueba
- Requisitos medioambientales
- Necesidades de personal y formación
- Responsabilidades
- Calendario
- Aprobaciones
Lectura sugerida => Tutorial del plan de prueba: una guía perfecta
Estrategia de prueba
La estrategia de prueba es un conjunto de pautas que explican el diseño de la prueba y determinan cómo se deben realizar las pruebas.
Ejemplo: Una estrategia de prueba incluye detalles como 'Los miembros del equipo de prueba deben probar los módulos individuales'. En este caso, no importa quién lo pruebe, por lo que es genérico y el cambio en el miembro del equipo no tiene que actualizarse, manteniéndolo estático.
Documento de estrategia de prueba
El propósito de la estrategia de prueba es definir el enfoque de prueba, los tipos de pruebas, los entornos de prueba y las herramientas que se utilizarán para las pruebas y los detalles de alto nivel de cómo la estrategia de prueba se alineará con otros procesos. El documento de estrategia de prueba está destinado a ser un documento dinámico y se actualizará ** cuando tengamos más claridad sobre los requisitos, los parámetros de SLA, el entorno de prueba y el enfoque de gestión de la construcción, etc.
La estrategia de prueba está destinada a todo el equipo del proyecto que comprende los patrocinadores del proyecto, las pymes comerciales, el desarrollo de aplicaciones / integración, los socios de integración de sistemas, los equipos de conversión de datos, los equipos de gestión de compilación / lanzamiento como los líderes técnicos, los líderes de arquitectura y los equipos de implementación e infraestructura.
** Algunos argumentan que la estrategia de prueba, una vez definida, nunca debería actualizarse. En la mayoría de los proyectos de prueba, por lo general, se actualiza a medida que avanza el proyecto.
A continuación se muestran las secciones importantes que debe tener un documento de estrategia de prueba:
# 1) Descripción general del proyecto
Esta sección puede comenzar con una descripción general de la organización seguida de una breve descripción del proyecto en cuestión. Puede incluir los siguientes detalles
- ¿Cuál fue la necesidad del proyecto?
- ¿Qué objetivos alcanzará el proyecto?
Tabla de acrónimos: Es mejor incluir una tabla con los acrónimos que el lector de documentos pueda encontrar al consultar el documento.
# 2) Alcance de los requisitos
El alcance del requisito puede incluir el alcance de la aplicación y el alcance funcional
Ámbito de aplicación define el sistema bajo prueba y el impacto en el sistema debido a una funcionalidad nueva o modificada. También se pueden definir sistemas relacionados.
| Sistema | Impacto (funcionalidad nueva o modificada) | Sistema relacionado |
|---|---|---|
| Describe cómo realizar la prueba, cuándo realizar la prueba, quién realizará la prueba y qué probar. | Describe qué tipo de técnica seguir y qué módulo probar. | |
| Sistema A | Nuevas mejoras y correcciones de errores | • Sistema B • Sistema C |
Alcance funcional define el impacto en diferentes módulos dentro del sistema. Aquí se explicará cada sistema relacionado con respecto a la funcionalidad.
| Sistema | Módulo | Funcionalidad | Sistema relacionado |
|---|---|---|---|
| Sistema C | Módulo 1 | Funcionalidad 1 | Sistema B |
| Funcionalidad 2 | Sistema C |
# 3) Plan de prueba de alto nivel
El plan de prueba es un documento separado. En la estrategia de prueba, se puede incluir un plan de prueba de alto nivel. Un plan de prueba de alto nivel puede incluir objetivos de prueba y alcance de prueba. El alcance de la prueba debe definir tanto las actividades dentro como fuera del alcance.
# 4) Enfoque de prueba
Esta sección describe el enfoque de prueba que se seguirá durante el ciclo de vida de prueba.
Según el diagrama anterior, las pruebas se llevarán a cabo en dos fases, es decir, estrategia y planificación de pruebas y ejecución de pruebas. La fase de estrategia y planificación de la prueba será única para un programa general, mientras que las fases de ejecución de la prueba se repetirán para cada ciclo del programa general. El diagrama anterior muestra diferentes etapas y entregables (resultado) en cada fase del enfoque de ejecución.
El enfoque de prueba debe incluir las siguientes subsecciones
a) Programa de prueba: Explique el cronograma del proyecto propuesto en esta subsección.
b) Enfoque de prueba funcional: El uso de esta subsección proporciona una descripción general de cada fase y los respectivos criterios de entrada y salida. Las diferentes fases de prueba son las pruebas unitarias, las pruebas del sistema, las pruebas de integración del sistema, las pruebas de aceptación del usuario y las pruebas de un extremo a otro.
c) Prueba de indicadores clave de desempeño:
- Priorización de casos de prueba: Defina el enfoque de priorización de casos de prueba para que, en caso de limitaciones de tiempo, el equipo de prueba pueda ejecutar escenarios de alta prioridad. Debe existir un acuerdo entre las partes interesadas del proyecto sobre los posibles riesgos que implica no ejecutar todos los escenarios planificados.
- Priorización de defectos: La estrategia de priorización de defectos es el siguiente tema a cubrir aquí. Defina el nivel de prioridad y dé la descripción de cada nivel como crítico, alto, medio, etc. También
- Tiempo de respuesta del defecto: El tiempo de respuesta del defecto se define como el tiempo entre el momento en que el defecto se planteó por primera vez y el momento en que el defecto se soluciona y se vuelve a probar. La respuesta rápida garantiza pruebas rápidas y el cumplimiento del cronograma del proyecto. Para cada nivel de prioridad de defecto, defina el tiempo de respuesta.
| Nivel de prioridad | Tiempo de respuesta de defectos |
|---|---|
| 1 - Crítico | Tiempo de respuesta: 2 horas o menos Arreglar listo para la migración: 1 día hábil o menos |
# 5) Cobertura de prueba
Esta sección describe los procesos que seguirá el equipo de QA para optimizar la cobertura de los requisitos funcionales / comerciales en escenarios de prueba y casos de prueba. Matriz de trazabilidad de requisitos: (RTM) se puede utilizar para rastrear todos los requisitos con los respectivos escenarios de prueba y casos de prueba.
# 6) Entorno de prueba
Defina los diferentes entornos de control de calidad disponibles. Mencione qué pruebas se realizarán en qué entorno y por quién. Cree un plan de respaldo ambiental para atender emergencias. El acceso a cada entorno debe regularse y denunciarse con claridad.
Las herramientas de prueba que se utilizarán también se pueden mencionar en esta sección.
| Actividad | Herramienta | Observaciones |
|---|---|---|
| Gestión de pruebas | HP ALM | Mencione el motivo por el que utiliza esta herramienta |
| Gestión de defectos | JIRA | Mencione el motivo por el que utiliza esta herramienta |
# 7) Entregables y Métricas de QA
Enumere todos los entregables de QA
| S. No. | Entregables |
|---|---|
| 1 | Documento de estrategia de prueba |
| 2 | Matriz de trazabilidad de requisitos |
| 3 | Guiones de prueba ST |
| 4 | Informe de resumen de la prueba |
| 5 | Lista de escenarios elegibles de automatización |
Enumere todas las métricas de control de calidad
| # | Nombre de métrica | Definición métrica | Fórmula métrica | Unidad métrica de medida | Informes en los que se utilizarán las métricas |
|---|---|---|---|---|---|
| 1 | Métricas de cobertura de requisitos (RCM) | La cobertura de requisitos por QA | Relación entre el número de requisitos probados y el número de requisitos identificados | % | Informe de estado de control de calidad semanal, Informe de resumen de la prueba |
| 2 | Cobertura de prueba | La cobertura del caso de prueba ejecutado | Relación de número de casos de prueba ejecutados / número de casos de prueba planificados | % | Informe de ejecución diario, Informe de estado de control de calidad semanal, Informe de resumen de la prueba |
# 8) Gestión de defectos
Defina claramente una estrategia de gestión de defectos mediante la creación de un flujo de trabajo de defectos, una metodología de seguimiento de defectos y un proceso de clasificación de defectos. Mencione la responsabilidad por defectos de los roles de cada evaluador. El análisis periódico de defectos y el análisis de la causa raíz mejorarán la calidad general de las pruebas
# 9) Gestión de la comunicación
Establezca pautas para informes de estado, reuniones de estado y comunicación en el sitio y en el extranjero.
# 10) Supuestos, riesgos y dependencias
Describa los supuestos en los que se basa el proyecto. Estos pueden incluir tiempos, recursos y capacidades del sistema. Describa cualquier dependencia como otros proyectos, disponibilidad de recursos temporales, otros plazos que puedan afectar el proyecto.
# 11) Apéndice
Incluya cosas como roles y responsabilidades, zona horaria de trabajo y referencias en esta sección
Otras lecturas=> Guía para redactar un buen documento de estrategia de prueba .
Plan de prueba Vs Estrategia de prueba
| PLAN DE PRUEBA | ESTRATEGIA DE PRUEBA |
|---|---|
| Se deriva de la especificación de requisitos de software (SRS). | Se deriva del documento de requisitos comerciales (BRS). |
| Lo prepara el director de prueba o el gerente. | Lo desarrolla el director del proyecto o el analista de negocios. |
| La identificación del plan de prueba, las características a probar, las técnicas de prueba, las tareas de prueba, los criterios de aprobación o falla de las características, los entregables de la prueba, las responsabilidades y el cronograma, etc.son los componentes del plan de prueba. | Los objetivos y alcance, los formatos de documentación, los procesos de prueba, la estructura de informes del equipo, la estrategia de comunicación con el cliente, etc. son los componentes de la estrategia de prueba. |
| Si se produce una nueva característica o un cambio en el requisito, se actualiza el documento del plan de prueba. | La estrategia de prueba mantiene los estándares mientras se prepara el documento. También se denomina documento estático. |
| Podemos preparar el plan de prueba individualmente. | En proyectos más pequeños, la estrategia de prueba a menudo se encuentra como una sección de un plan de prueba. |
| Podemos preparar un plan de prueba a nivel de proyecto. | Podemos utilizar la estrategia de prueba en múltiples proyectos. |
| Podemos describir las especificaciones utilizando un plan de prueba. | La estrategia de prueba describe los enfoques generales. |
| El plan de prueba cambiará a lo largo del proyecto. | La estrategia de prueba generalmente no cambiará una vez aprobada. |
| El plan de prueba se redacta después de la aprobación de los requisitos. | La estrategia de prueba se realiza antes del plan de prueba. |
| Los planes de prueba pueden ser de diferentes tipos. Habrá un plan de prueba maestro y un plan de prueba separado para diferentes tipos de pruebas, como plan de prueba del sistema, plan de prueba de rendimiento, etc. | Solo habrá un documento de estrategia de prueba para un proyecto. |
| El plan de prueba debe ser claro y conciso. | La estrategia de prueba proporciona una guía general para el proyecto en curso. |
La diferencia entre estos dos documentos es sutil. Una estrategia de prueba es un documento estático de alto nivel sobre el proyecto. Por otro lado, el plan de prueba especificará qué probar, cuándo probar y cómo probar.
Diferencia entre caso de prueba y script de prueba
En mi opinión, estos dos términos se pueden usar indistintamente. Sí, digo que no hay diferencia. El caso de prueba es una secuencia de pasos que nos ayudan a realizar una determinada prueba en la aplicación. El script de prueba también es lo mismo.
Ahora, hay una escuela de pensamiento que dice que un caso de prueba es un término que se usa en el entorno de prueba manual y que el script de prueba se usa en un entorno de automatización. Esto es parcialmente cierto, debido al nivel de comodidad de los probadores en los campos respectivos y también a cómo las herramientas se refieren a las pruebas (algunos llaman a los scripts de prueba y otros los llaman a casos de prueba).
Entonces, en efecto, el script de prueba y el caso de prueba son pasos que se deben realizar en una aplicación para validar su funcionalidad, ya sea manualmente o mediante la automatización.
Otras lecturas=> ¿Cómo escribir casos de prueba efectivos? y Plantilla de ejemplo de caso de prueba .
| CASO DE PRUEBA | GUIÓN DE PRUEBA |
|---|---|
| Es el formulario básico para probar una aplicación en secuencia. | Una vez que lo desarrollemos, el script lo ejecutará varias veces hasta que se cambie el requisito. |
| Es un procedimiento paso a paso que se utiliza para probar una aplicación. | Es un conjunto de instrucciones para probar una aplicación automáticamente. |
| El término Caso de prueba se utiliza en el entorno de prueba manual. | El término Test Script se utiliza en el entorno de pruebas de automatización. |
| Se hace manualmente. | Se realiza mediante formato de script. |
| Está desarrollado en forma de plantillas. | Se desarrolla en forma de scripting. |
| La plantilla de caso de prueba incluye ID de traje de prueba, datos de prueba, procedimiento de prueba, resultados reales, resultados esperados, etc. | En Test Scrip, podemos usar diferentes comandos para desarrollar un script. |
| Se utiliza para probar una aplicación. | También se utiliza para probar una aplicación. |
| Ejemplo: necesitamos verificar el botón de inicio de sesión en una aplicación, Los pasos incluyen: a) Inicie la aplicación. b) Verifique si el botón de inicio de sesión se muestra o no. | Ejemplo: queremos hacer clic en un botón de imagen en una aplicación. El guión incluye: a) Haga clic en el botón Imagen. |
Diferencia entre el escenario de prueba y la condición de prueba
Escenario de prueba: Es una forma de definir todas las formas posibles de probar una aplicación. Es una declaración única para cubrir todas las formas posibles de probar una aplicación.
Condición de prueba: La condición de prueba es la especificación que debe seguir un probador para probar una aplicación.
Este es un puntero de una línea que los probadores crean como un paso de transición inicial hacia la fase de diseño de la prueba. Esta es principalmente una definición de una línea de 'Qué' vamos a probar con respecto a una determinada característica. Por lo general, los escenarios de prueba se ingresan para la creación de casos de prueba.
En proyectos ágiles, los escenarios de prueba son los únicos resultados del diseño de prueba y no se escriben casos de prueba a continuación. Un escenario de prueba puede resultar en múltiples pruebas.
Ejemplos de escenarios de prueba:
- Validar si el administrador puede agregar un nuevo país
- Validar si el administrador puede eliminar un país existente
- Validar si se puede actualizar un país existente
Las condiciones de prueba, por otro lado, son más específicas. Puede definirse a grandes rasgos como el objetivo de una determinada prueba.
Ejemplo de condición de prueba: En el ejemplo anterior, si probamos el escenario 1, podemos probar las siguientes condiciones:
- Ingrese el nombre del país como 'India' (válido) y verifique la adición del país
- Ingrese un espacio en blanco y verifique si se agrega el país.
- En cada caso, se describen los datos específicos y el objetivo de la prueba es mucho más preciso.
Otras lecturas=> Más de 180 escenarios de prueba de muestra para probar aplicaciones web y de escritorio.
| ESCENARIO DE PRUEBA | CONDICIÓN DE PRUEBA |
|---|---|
| Estas son declaraciones de una línea para explicar lo que vamos a probar. | Condición de prueba describe el objetivo principal de probar una aplicación. |
| Es un proceso para probar una aplicación con todas las formas posibles. | Las condiciones de prueba son las reglas estáticas que se deben seguir para probar una aplicación. |
| Los escenarios de prueba son una entrada para la creación de casos de prueba. | Da el objetivo principal de probar una aplicación. |
| El escenario de prueba cubre todos los casos posibles para probar una aplicación. | La condición de prueba es muy específica. |
| Reduce la complejidad. | Hace que un sistema esté libre de errores. |
| El escenario de prueba puede ser uno o un grupo de casos de prueba. | Es el objetivo de los casos de prueba. |
| Al escribir escenarios, será fácil comprender la funcionalidad de una aplicación. | La condición de prueba es muy específica. |
| Ejemplos de escenarios de prueba: # 1) Valide si el administrador puede agregar un nuevo país. # 2) Valide si el administrador puede eliminar un país existente. # 3) Valide si se puede actualizar un país existente. | Ejemplos de condiciones de prueba: # 1) Ingrese el nombre del país como 'India' y verifique la adición del país. # 2) Deje los campos en blanco y verifique si se agrega el país. |
Diferencia entre el procedimiento de prueba y el conjunto de pruebas
El procedimiento de prueba es una combinación de casos de prueba basados en una determinada razón lógica, como ejecutar una situación de un extremo a otro o algo por el estilo. El orden en el que se ejecutarán los casos de prueba es fijo.
Procedimiento de prueba: No es más que el ciclo de vida de la prueba. Hay 10 pasos en el ciclo de vida de las pruebas.
Son:
- Estimación del esfuerzo
- Iniciación del proyecto
- Estudio del sistema
- Plan de prueba
- Caso de prueba de diseño
- Automatización de pruebas
- Ejecutar casos de prueba
- Informar defectos
- Pruebas de regresión
- Informe de análisis y resumen
Por ejemplo , si tuviera que probar el envío de un correo electrónico desde Gmail.com, el orden de los casos de prueba que combinaría para formar un procedimiento de prueba sería:
- La prueba para comprobar el inicio de sesión
- La prueba para redactar un correo electrónico
- La prueba para adjuntar uno o más archivos adjuntos
- Formatear el correo electrónico de la forma requerida utilizando varias opciones
- Agregar contactos o direcciones de correo electrónico a los campos Para, CCO, CC
- Enviar un correo electrónico y asegurarse de que se muestre en la sección 'Correo enviado'
Todos los casos de prueba anteriores están agrupados para lograr un determinado objetivo al final de ellos. Además, los procedimientos de prueba tienen algunos casos de prueba combinados en cualquier momento.
El conjunto de pruebas, por otro lado, es la lista de todos los casos de prueba que deben ejecutarse como parte de un ciclo de prueba o una fase de regresión, etc. No existe una agrupación lógica basada en la funcionalidad. El orden en el que se ejecutan los casos de prueba constituyentes puede ser importante o no.
Banco de pruebas: Test Suite es un contenedor que tiene un conjunto de pruebas que ayudan a los probadores a ejecutar y reportar el estado de ejecución de la prueba. Puede tomar cualquiera de los tres estados, es decir, activo, en progreso y completado.
Ejemplo de la suite de pruebas : Si la versión actual de una aplicación es 2.0. La versión anterior 1.0 podría haber tenido 1000 casos de prueba para probarla por completo. Para la versión 2, hay 500 casos de prueba para probar la nueva funcionalidad que se agrega en la nueva versión.
Entonces, el conjunto de pruebas actual sería 1000 + 500 casos de prueba que incluyen tanto la regresión como la nueva funcionalidad. La suite también es una combinación, pero no estamos tratando de lograr una función objetivo.
Los conjuntos de pruebas pueden contener cientos o incluso miles de casos de prueba.
| PROCEDIMIENTO DE PRUEBA | BANCO DE PRUEBAS |
|---|---|
| La creación de procedimientos de prueba se basa en el flujo de prueba de extremo a extremo. | Los conjuntos de pruebas se crean en función del ciclo o en función del alcance. |
| Es una combinación de casos de prueba para probar una aplicación. | Es un grupo de casos de prueba para probar una aplicación. |
| Es una agrupación lógica basada en la funcionalidad. | No existe una agrupación lógica basada en la funcionalidad. |
| Los procedimientos de prueba son productos que se pueden entregar en el proceso de desarrollo de software. | Se ejecuta como parte del ciclo de prueba o regresión. |
| El orden de ejecución es fijo. | El orden de ejecución puede no ser importante. |
| El procedimiento de prueba contiene casos de prueba de extremo a extremo. | El conjunto de pruebas contiene todas las funciones nuevas y casos de prueba de regresión. |
| Los procedimientos de prueba están codificados en un nuevo idioma llamado TPL (lenguaje de procedimientos de prueba). | El conjunto de pruebas contiene casos de prueba manuales o scripts de automatización. |
Conclusión
Los conceptos de pruebas de software juegan un papel importante en el ciclo de vida de las pruebas de software.
Una comprensión clara de los conceptos discutidos anteriormente junto con su comparación es muy importante para que todos los probadores de software lleven a cabo el proceso de prueba de manera efectiva.
cómo abrir un archivo jar con el entorno de ejecución de Java
Por lo general, artículos como estos son excelentes puntos de partida para discusiones más profundas. Por lo tanto, contribuya con sus pensamientos, acuerdos, desacuerdos y cualquier otra cosa, en los comentarios a continuación. Esperamos sus comentarios.
También agradecemos sus preguntas sobre pruebas de software en general o cualquier tema relacionado con su carrera de pruebas. Los abordaremos con más detalle en nuestras próximas publicaciones de la misma serie.
¡¡Feliz lectura!!
=> Visite aquí para ver la serie completa de tutoriales del plan de prueba
PREV Tutorial | SIGUIENTE Tutorial
Lectura recomendada
- Tutorial del plan de prueba: una guía para escribir un documento de plan de prueba de software desde cero
- Cómo escribir un documento de estrategia de prueba (con una plantilla de estrategia de prueba de muestra)
- Cómo prepararse para la redacción de casos de prueba (Consejos de productividad)
- Qué es el escenario de prueba: plantilla de escenario de prueba con ejemplos
- Diferencia entre el plan de prueba de rendimiento y la estrategia de prueba de rendimiento
- Cómo escribir casos de prueba: la guía definitiva con ejemplos
- Plantilla de plan de prueba de software de muestra con formato y contenido
- Escenario de prueba versus caso de prueba: ¿Cuál es la diferencia entre estos?