¿Qué es la prueba de regresión? Definición, herramientas, método y ejemplo

what is regression testing

¿Qué es la prueba de regresión?

La prueba de regresión es un tipo de prueba que se realiza para verificar que un cambio de código en el software no afecta la funcionalidad existente del producto. Esto es para asegurarse de que el producto funcione bien con nuevas funciones, correcciones de errores o cualquier cambio en la función existente. Los casos de prueba ejecutados previamente se vuelven a ejecutar para verificar el impacto del cambio.

=> Haga clic aquí para ver la serie completa de tutoriales del plan de prueba

La prueba de regresión es un tipo de prueba de software en la que los casos de prueba se vuelven a ejecutar para verificar si la funcionalidad anterior de la aplicación funciona bien y los nuevos cambios no han introducido ningún error nuevo.

Esta prueba se puede realizar en una nueva compilación cuando hay un cambio significativo en la funcionalidad original, incluso en una sola corrección de error.

Regresión significa volver a probar las partes sin cambios de la aplicación.

Lo que vas a aprender:

• Tutoriales cubiertos en esta serie
• Descripción general de la prueba de regresión
• ¿Cuándo realizar esta prueba?
• ¿Se pueden realizar manualmente las pruebas de regresión?
• Herramientas de prueba de regresión automatizadas
• ¿Por qué la prueba de regresión?
• Tipos de pruebas de regresión
  • # 1) Regresión unitaria
  • # 2) Regresión parcial
  • # 3) Regresión completa
• ¿Cuánta regresión se requiere?
• ¿Qué hacemos en la comprobación de regresión?
• Técnicas de prueba de regresión
  • # 1) Vuelva a probar todo
  • # 2) Selección de prueba de regresión
  • # 3) Priorización de casos de prueba
  • # 4) Híbrido
• ¿Cómo seleccionar un conjunto de pruebas de regresión?
• ¿Cómo realizar pruebas de regresión?
• Regresión en ágil
  • # 1) Regresión del nivel de sprint
  • # 2) Regresión de extremo a extremo
• Ventajas
• Desventajas
• Regresión de la aplicación GUI
• Diferencia entre regresión y nueva prueba
• Regression Test Plan Template (TOC)
  • # 1) Historial de documentos
  • # 2) Referencias
  • # 3) Plan de prueba de regresión
  • # 4) Aprobación / Aceptación
• Conclusión
• Lectura recomendada

Tutoriales cubiertos en esta serie

Tutorial #1: ¿Qué es la prueba de regresión? (Este tutorial)
Tutorial #2: Herramientas de prueba de regresión
Tutorial #3: Reprueba Vs prueba de regresión
Tutorial #4: Pruebas de regresión automatizadas en Agile

Descripción general de la prueba de regresión

La prueba de regresión es como un método de verificación. Los casos de prueba generalmente están automatizados, ya que se requiere que los casos de prueba se ejecuten una y otra vez y ejecutar los mismos casos de prueba una y otra vez de forma manual también requiere mucho tiempo y es tedioso.

Por ejemplo, Considere un producto X, en el que una de las funciones es activar la confirmación, la aceptación y los correos electrónicos enviados cuando se hace clic en los botones Confirmar, Aceptar y Despachar.

Se produce algún problema en el correo electrónico de confirmación y, para solucionarlo, se realizan algunos cambios de código. En este caso, no solo se deben probar los correos electrónicos de confirmación, sino que también se deben probar los correos electrónicos de aceptación y envío para asegurarse de que el cambio en el código no los haya afectado.

La prueba de regresión no depende de ningún lenguaje de programación como Java, C ++, C #, etc. Es un método de prueba que se utiliza para probar el producto en busca de modificaciones o actualizaciones. Verifica que cualquier modificación en un producto no afecta los módulos existentes del producto.

Verificar que los errores se hayan solucionado y que las funciones recién agregadas no hayan creado ningún problema en la versión de trabajo anterior del software.

Los probadores realizan pruebas funcionales cuando hay una nueva construcción disponible para verificación. La intención de esta prueba es verificar los cambios realizados en la funcionalidad existente y también en la funcionalidad recién agregada.

Cuando se realiza esta prueba, el evaluador debe verificar si la funcionalidad existente funciona como se esperaba y si los nuevos cambios no han introducido ningún defecto en la funcionalidad que funcionaba antes de este cambio.

La prueba de regresión debe ser parte del ciclo de liberación y debe considerarse en la estimación de la prueba.

¿Cuándo realizar esta prueba?

Las pruebas de regresión generalmente se realizan después de la verificación de cambios o nuevas funciones. Pero este no es siempre el caso. Para la versión que tarda meses en completarse, las pruebas de regresión deben incorporarse en el ciclo de prueba diario. Para las versiones semanales, las pruebas de regresión se pueden realizar cuando finaliza la prueba funcional para los cambios.

La comprobación de regresión es una variación de la repetición de la prueba (que consiste simplemente en repetir una prueba). Al volver a realizar la prueba, el motivo puede ser cualquier cosa. Digamos que estaba probando una función en particular y era el final del día; no podía terminar la prueba y tuvo que detener el proceso sin decidir si la prueba pasó / falló.

Al día siguiente, cuando regresa, realiza la prueba una vez más, eso significa que está repitiendo una prueba que realizó antes. El simple hecho de repetir una prueba es una nueva prueba.

La prueba de regresión en su esencia es una especie de repetición. Es solo para la ocasión especial que algo en la aplicación / código ha cambiado. Puede ser código, diseño o cualquier cosa que dicte el marco general del sistema.

Una nueva prueba que se realiza en esta situación para asegurarse de que dicho cambio no ha tenido un impacto en nada que ya estaba funcionando antes se llama Prueba de regresión. Las razones más comunes por las que esto podría llevarse a cabo son porque se han creado nuevas versiones del código (aumento en el alcance / requisito) o se han corregido errores.

¿Se pueden realizar manualmente las pruebas de regresión?

Estaba enseñando uno de estos días en mi clase y se me ocurrió una pregunta: '¿Se puede hacer la regresión manualmente?'

Respondí la pregunta y seguimos adelante en la clase. Todo parecía estar bien, pero de alguna manera esta pregunta me molestó durante bastante tiempo después.

En los muchos lotes, esta pregunta surge varias veces de varias formas diferentes. Algunos de ellos son:

• ¿Para realizar la ejecución de la prueba necesitamos una herramienta?
• ¿Cómo se realiza la prueba de regresión?
• Incluso después de una ronda completa de pruebas, a los recién llegados les resulta difícil discernir qué es exactamente la prueba de regresión.

Y por supuesto, la pregunta original:

• ¿Se pueden realizar estas pruebas manualmente?

Para empezar, Ejecución de pruebas es un simple acto de usar sus casos de prueba y realizar esos pasos en el AUT, proporcionar los datos de prueba y comparar el resultado obtenido en el AUT con el resultado esperado mencionado en sus casos de prueba.

Dependiendo del resultado de la comparación, establecemos el estado del caso de prueba pasa / falla. La ejecución de la prueba es tan simple como eso, no hay herramientas especiales necesarias para este proceso.

Herramientas de prueba de regresión automatizadas

La prueba de regresión automatizada es el área de prueba donde podemos automatizar la mayoría de los esfuerzos de prueba. Ejecutamos todos los casos de prueba ejecutados previamente en una nueva compilación.

Esto significa que tenemos un conjunto de casos de prueba disponible y ejecutar estos casos de prueba manualmente consume mucho tiempo. Conocemos los resultados esperados, por lo que la automatización de estos casos de prueba ahorra tiempo y es un método de prueba de regresión eficiente. El grado de automatización depende del número de casos de prueba que seguirán siendo aplicables con el tiempo.

Si los casos de prueba varían de vez en cuando, el alcance de la aplicación sigue aumentando y la automatización del procedimiento de regresión será una pérdida de tiempo.

La mayoría de las herramientas de prueba de regresión son de tipo grabación y reproducción. Registrará los casos de prueba navegando a través de AUT (aplicación bajo prueba) y verificará si los resultados esperados están llegando o no.

Instrumentos

• Selenio
• Estudio de catálogo
• AdventNet QEngine
• Probador de regresión
• vTest
• agua
• actiWate
• Probador funcional racional
• SilkTest
• TimeShiftX

La mayoría de estas son herramientas de prueba funcionales y de regresión.

Lectura recomendada => Consulte aquí la lista de las mejores herramientas de regresión

Agregar y actualizar casos de prueba de regresión en un conjunto de pruebas de automatización es una tarea engorrosa. Al seleccionar una herramienta de automatización para las pruebas de regresión, debe verificar si la herramienta le permite agregar o actualizar los casos de prueba fácilmente.

convertir videos de youtube a mp4 gratis

En la mayoría de los casos, necesitamos actualizar los casos de prueba de regresión automatizados con frecuencia debido a los cambios frecuentes en el sistema.

VER EL VÍDEO

Para obtener una explicación más detallada de la definición con un ejemplo, consulte lo siguienteVideo de prueba de regresión:

¿Por qué la prueba de regresión?

La regresión se inicia cuando un programador corrige cualquier error o agrega un nuevo código para una nueva funcionalidad al sistema.

Puede haber muchas dependencias en la funcionalidad recién agregada y existente.

Es una medida de calidad comprobar si el nuevo código cumple con el antiguo para que el código no modificado no se vea afectado. La mayoría de las veces, el equipo de pruebas tiene la tarea de verificar los cambios de última hora en el sistema.

En tal situación, es necesario probar solo el área de aplicación afectada para completar el proceso de prueba a tiempo cubriendo todos los aspectos principales del sistema.

Esta prueba es muy importante cuando se agrega un cambio / mejora continua en la aplicación. La nueva funcionalidad no debería afectar negativamente al código probado existente.

Se requiere una regresión para encontrar los errores que ocurrieron debido a un cambio en el código. Si no se realiza esta prueba, el producto puede tener problemas críticos en el entorno en vivo y eso, de hecho, puede causar problemas al cliente.

Al probar cualquier sitio web en línea, un evaluador informa un problema de que el precio del producto no se muestra correctamente, es decir, muestra un precio menor que el precio real del producto, y debe solucionarse pronto.

Una vez que el desarrollador soluciona el problema, es necesario volver a probarlo y también se requiere la prueba de regresión, ya que la verificación del precio en la página informada se habría corregido, pero podría mostrar un precio incorrecto en la página de resumen donde se muestra el total. con los demás cargos o el correo enviado al cliente todavía tiene el precio incorrecto.

Ahora, en este caso, el cliente tendrá que asumir la pérdida si no se realiza esta prueba ya que el sitio calcula el costo total con el precio incorrecto y el mismo precio va a un cliente por correo electrónico. Una vez que el cliente acepta, el Producto se vende en línea a un precio más bajo, será una pérdida para el cliente.

Por lo tanto, esta prueba juega un papel importante y es muy necesaria e importante también.

Tipos de pruebas de regresión

A continuación se muestran los distintos tipos de regresión:

• Regresión unitaria
• Regresión parcial
• Regresión completa

# 1) Regresión unitaria

La regresión unitaria se realiza durante la Examen de la unidad La fase y el código se prueban de forma aislada, es decir, cualquier dependencia de la unidad que se va a probar se bloquea para que la unidad se pueda probar individualmente sin ninguna discrepancia.

# 2) Regresión parcial

La regresión parcial se realiza para verificar que el código funciona bien incluso cuando los cambios se han realizado en el código y esa unidad está integrada con el código sin cambios o ya existente.

# 3) Regresión completa

La regresión completa se realiza cuando se realiza un cambio en el código en varios módulos y también si el impacto del cambio de un cambio en cualquier otro módulo es incierto. El producto en su conjunto se retrocede para verificar cualquier cambio debido al código modificado.

¿Cuánta regresión se requiere?

Esto depende del alcance de las funciones recién agregadas.

Si el alcance de una solución o función es demasiado grande, entonces el área de aplicación que se ve afectada también es bastante grande y las pruebas deben realizarse a fondo, incluidos todos los casos de prueba de aplicaciones. Pero esto se puede decidir de manera efectiva cuando el evaluador recibe información de un desarrollador sobre el alcance, la naturaleza y la cantidad de cambio.

Como se trata de pruebas repetitivas, los casos de prueba se pueden automatizar para que un conjunto de casos de prueba solo se pueda ejecutar fácilmente en una nueva compilación.

Los casos de prueba de regresión deben seleccionarse con mucho cuidado para que se cubra la máxima funcionalidad en un conjunto mínimo de casos de prueba. Este conjunto de casos de prueba necesita mejoras continuas para la funcionalidad recién agregada.

Se vuelve muy difícil cuando el alcance de la aplicación es muy grande y hay incrementos continuos o parches en el sistema. En tales casos, es necesario ejecutar pruebas selectivas para ahorrar costos y tiempo de prueba. Estos casos de prueba selectivos se seleccionan en función de las mejoras realizadas en el sistema y las partes en las que puede afectar más.

¿Qué hacemos en la comprobación de regresión?

• Vuelva a ejecutar las pruebas realizadas anteriormente
• Compare los resultados actuales con los resultados de las pruebas ejecutadas anteriormente

Este es un proceso continuo que se realiza en varias etapas a lo largo del ciclo de vida de las pruebas de software.

Una mejor práctica es realizar una prueba de regresión después de la Pruebas de cordura o humo y al final de las pruebas funcionales para una versión breve.

Para realizar pruebas efectivas, la regresión Plan de prueba debe ser creado. Este plan debe describir la estrategia de prueba de regresión y los criterios de salida. La prueba de rendimiento también forma parte de esta prueba para asegurarse de que el rendimiento del sistema no se vea afectado debido a los cambios realizados en los componentes del sistema.

Mejores prácticas : Ejecute casos de prueba automatizados todos los días por la noche para que cualquier efecto secundario de regresión se pueda solucionar en la compilación del día siguiente. De esta manera, reduce el riesgo de liberación al cubrir casi todos los defectos de regresión en una etapa temprana en lugar de encontrarlos y corregirlos al final del ciclo de liberación.

Técnicas de prueba de regresión

A continuación se presentan las diversas técnicas.

• Vuelva a probar todo
• Selección de prueba de regresión
• Priorización de casos de prueba
• Híbrido

# 1) Vuelva a probar todo

Como sugiere el propio nombre, todos los casos de prueba en el conjunto de pruebas se vuelven a ejecutar para garantizar que no haya errores que hayan ocurrido debido a un cambio en el código. Este es un método costoso ya que requiere más tiempo y recursos en comparación con las otras técnicas.

# 2) Selección de prueba de regresión

En este método, los casos de prueba se seleccionan del conjunto de pruebas para volver a ejecutarlos. No se vuelve a ejecutar toda la suite. La selección de casos de prueba se realiza sobre la base del cambio de código en el módulo.

Los casos de prueba se dividen en dos categorías, uno es casos de prueba reutilizables y otro es casos de prueba obsoletos. Los casos de prueba reutilizables se pueden usar en futuros ciclos de regresión, mientras que los obsoletos no se usan en los próximos ciclos de regresión.

# 3) Priorización de casos de prueba

Los casos de prueba con prioridad alta se ejecutan primero que los de prioridad media y baja. La prioridad del caso de prueba depende de su criticidad y su impacto en el producto y también de la funcionalidad del producto que se utiliza con más frecuencia.

# 4) Híbrido

La técnica híbrida es una combinación de selección de prueba de regresión y priorización de casos de prueba. En lugar de seleccionar todo el conjunto de pruebas, seleccione solo los casos de prueba que se vuelven a ejecutar según su prioridad.

¿Cómo seleccionar un conjunto de pruebas de regresión?

La mayoría de los errores que se encuentran en el entorno de producción se deben a los cambios que se produjeron o los errores se solucionaron en la undécima hora, es decir, los cambios realizados en una etapa posterior. La corrección de errores en la última etapa puede crear otros problemas / errores en el Producto. Es por eso que la verificación de regresión es muy importante antes de lanzar un producto.

A continuación, se muestra una lista de casos de prueba que se pueden utilizar al realizar esta prueba:

• Funcionalidades que se utilizan con frecuencia.
• Casos de prueba que cubren el módulo donde se han realizado los cambios.
• Casos de prueba complejos.
• Casos de prueba de integración que incluyen todos los componentes principales.
• Casos de prueba para la funcionalidad o característica principal del Producto.
• Deben incluirse los casos de prueba de Prioridad 1 y Prioridad 2.
• Se encontraron casos de prueba que fallan con frecuencia o defectos de prueba recientes en el mismo.

¿Cómo realizar pruebas de regresión?

Ahora que hemos establecido lo que significa la regresión, es evidente que también está probando, simplemente repitiendo en una situación específica por una razón específica. Por lo tanto, podemos deducir con seguridad que el mismo método se aplica a las pruebas, en primer lugar, también se puede aplicar a esto.

Por lo tanto, si las pruebas se pueden realizar manualmente, las pruebas de regresión también se pueden hacer. No es necesario el uso de una herramienta. Sin embargo, a medida que pasa el tiempo, las aplicaciones se acumulan con más y más funcionalidades, lo que sigue aumentando el alcance de la regresión. Para aprovechar al máximo el tiempo, esta prueba es más a menudo automatizado .

A continuación se muestran los diversos pasos involucrados en la realización de esta prueba.

• Prepare un conjunto de pruebas para la regresión considerando los puntos mencionados en '¿Cómo seleccionar el conjunto de pruebas de regresión'?
• Automatice todos los casos de prueba del conjunto de pruebas.
• Actualice la suite de regresión siempre que sea necesario, como si se encontrara algún defecto nuevo que no esté cubierto en el caso de prueba, y se debe actualizar un caso de prueba para el mismo en la suite de prueba para que la prueba no se pierda la próxima vez. . El conjunto de pruebas de regresión debe gestionarse correctamente mediante la actualización continua de los casos de prueba.
• Ejecute los casos de prueba de regresión siempre que haya algún cambio en el código, se corrija el error, se agregue una nueva funcionalidad, se realice una mejora a la funcionalidad existente, etc.
• Cree un Informe de ejecución de la prueba que incluya el estado de Pasa / No pasa de los casos de prueba ejecutados.

Por ejemplo:

Déjame explicarte esto con un ejemplo. Examine la siguiente situación:

Las siguientes son las observaciones que podemos hacer de la situación anterior:

• A medida que crecen las versiones, crece la funcionalidad.
• El tiempo de desarrollo no necesariamente aumenta con las versiones, pero el tiempo de prueba sí
• Ninguna empresa / su dirección estará dispuesta a invertir más tiempo en pruebas y menos en desarrollo
• Ni siquiera podemos reducir el tiempo que lleva realizar la prueba aumentando el tamaño del equipo de prueba porque más personas significa más dinero y gente nueva también significa mucha capacitación y tal vez también un compromiso en la calidad, ya que las personas nuevas pueden no estar a la par con los conocimientos requeridos. niveles inmediatamente.
• La otra alternativa claramente es reducir la cantidad de regresión. Pero eso podría ser riesgoso para el producto de software.

Por todas estas razones, la prueba de regresión es un buen candidato para la prueba de automatización, pero no tiene que hacerse solo de esa manera.

Pasos básicos para realizar pruebas de regresión

Cada vez que el software sufre un cambio y aparece una nueva versión / release, los siguientes son los pasos que puede seguir para realizar este tipo de pruebas:

• Comprender qué tipo de cambios se han realizado en el software.
• Analizar y determinar qué módulos / partes del software podrían verse afectados: los equipos de desarrollo y BA pueden ser fundamentales para proporcionar esta información.
• Eche un vistazo a sus casos de prueba y determine si tendrá que hacer una regresión total, parcial o unitaria. Identifique los que se adaptarán a su situación
• ¡Programe el tiempo y pruebe!

Regresión en ágil

Ágil es un enfoque adaptativo que sigue un método iterativo e incremental. El producto se desarrolla en iteraciones cortas llamadas sprint que dura de 2 a 4 semanas. En ágil, hay una serie de iteraciones, por lo que esta prueba juega un papel importante ya que la nueva funcionalidad o el cambio de código se realiza en las iteraciones.

El conjunto de pruebas de regresión debe prepararse desde la fase inicial y debe actualizarse con cada sprint.

En Agile, la comprobación de regresión se cubre en dos categorías:

• Regresión de nivel de sprint
• Regresión de extremo a extremo

# 1) Regresión del nivel de sprint

La regresión de nivel de sprint se realiza principalmente para la nueva funcionalidad o la mejora que se realiza en el último sprint. Los casos de prueba del conjunto de pruebas se seleccionan según la funcionalidad recién agregada o la mejora realizada.

# 2) Regresión de extremo a extremo

La regresión de extremo a extremo incluye todos los casos de prueba que se volverán a ejecutar para probar el producto completo de extremo a extremo, cubriendo todas las funcionalidades básicas del producto.

Como Agile tiene sprints cortos y continúa, es muy necesario automatizar el conjunto de pruebas, los casos de prueba se ejecutan nuevamente y eso también debe completarse en un corto período de tiempo. La automatización de los casos de prueba reduce el tiempo de ejecución y el deslizamiento de defectos.

Ventajas

A continuación se muestran las diversas ventajas de la prueba de regresión.

• Mejora la calidad del Producto.
• Garantiza que cualquier corrección de error o mejora que se realice no afecte la funcionalidad existente del Producto.
• Se pueden utilizar herramientas de automatización para esta prueba.
• Se asegura de que los problemas que ya están solucionados no vuelvan a ocurrir.

Desventajas

Aunque existen varias ventajas, también existen algunas desventajas. Son:

• También debe hacerse para un pequeño cambio en el código porque incluso un pequeño cambio en el código puede crear problemas en la funcionalidad existente.
• Si, en caso de que no se utilice la automatización en el Proyecto para esta prueba, será una tarea tediosa y que llevará mucho tiempo ejecutar los casos de prueba una y otra vez.

Regresión de la aplicación GUI

Es difícil realizar una prueba de regresión GUI (interfaz gráfica de usuario) cuando la estructura de la GUI es modificado. Los casos de prueba escritos en la GUI antigua se vuelven obsoletos o deben modificarse.

La reutilización de los casos de prueba de regresión significa que los casos de prueba de la GUI se modifican de acuerdo con la nueva GUI. Pero esta tarea se vuelve engorrosa si tiene un gran conjunto de casos de prueba de GUI.

Diferencia entre regresión y nueva prueba

Se realiza una nueva prueba para los casos de prueba que fallan durante la ejecución y el error planteado para el mismo se ha corregido, mientras que la verificación de regresión no se limita a la corrección del error, ya que cubre otros casos de prueba también para garantizar que la corrección del error no se haya realizado. afectado cualquier otra funcionalidad del Producto.

Regression Test Plan Template (TOC)

1. Historial de documentos

2. Referencias

3. Plan de prueba de regresión

3.1. Introducción

3.2. Objetivo

3.3. Estrategia de prueba

3.4. Característica a probar

3.5. Requisito de recursos

3.5.1. Requisito de hardware

3.5.2. Requisito de software

3.6. Calendario de pruebas

3.7. Solicitud de cambio

3.8. Criterios de entrada / salida

3.8.1. Criterios de entrada para esta prueba

3.8.2. Criterios de salida para esta prueba

3.9. Suposición / restricciones

3.10. Casos de prueba

3.11. Riesgo / Supuestos

3.12. Instrumentos

4. Aprobación / Aceptación

Echemos un vistazo a cada uno de ellos en detalle.

# 1) Historial de documentos

El historial del documento consiste en un registro del primer borrador y todos los actualizados en el formato que se proporciona a continuación.

# 2) Referencias

La columna de referencias lleva un registro de todos los documentos de referencia utilizados o requeridos para el proyecto mientras crea un plan de prueba.

# 3) Plan de prueba de regresión

3.1. Introducción

Este documento describe el cambio / actualización / mejora en el Producto que se probará y el enfoque utilizado para esta prueba. Todos los cambios de código, mejoras, actualizaciones, características agregadas se describen para ser probados. Los casos de prueba utilizados para las pruebas unitarias y de integración se pueden utilizar para crear un conjunto de pruebas para la regresión.

3.2. Objetivo

El propósito del plan de prueba de regresión es describir qué exactamente y cómo se realizarían las pruebas para lograr los resultados. La comprobación de regresión se realiza para garantizar que ninguna otra funcionalidad del producto se vea obstaculizada por el cambio de código.

3.3. Estrategia de prueba

La estrategia de prueba describe el enfoque que se utilizará para realizar esta prueba y que incluye la técnica que se utilizará, cuáles serán los criterios de finalización, quién realizará qué actividad, quién escribirá los guiones de prueba, qué herramienta de regresión se utilizará , pasos para cubrir los riesgos como escasez de recursos, retraso en la producción, etc.

3.4. Características a probar

Aquí se enumeran las características / componentes del producto que se va a probar. En la regresión, todos los casos de prueba se vuelven a ejecutar o los que afectan a la funcionalidad existente se eligen según la corrección / actualización o mejora realizada.

3.5. Requisito de recursos

3.5.1. Requisito de hardware:

Los requisitos de hardware se identifican aquí como computadoras, computadoras portátiles, módems, libros Mac, teléfonos inteligentes, etc.

3.5.2. Requisito de software:

El requisito de software se identifica como el sistema operativo y los navegadores que se requerirán.

3.6. Calendario de pruebas

El programa de prueba define el tiempo estimado para realizar las actividades de prueba.

Por ejemplo ¿Cuántos recursos realizarán una actividad de prueba y también en cuánto tiempo?

3.7. Solicitud de cambio

Se mencionan los detalles de CR para los que se realizaría la regresión.

3.8. Criterios de entrada / salida

3.8.1. Criterios de entrada para esta prueba:

Se definen los criterios de entrada para que el Producto inicie la comprobación de regresión.

Por ejemplo:

• Se deben completar los cambios de codificación / mejora / adición de nuevas funciones.
• Se debe aprobar el plan de prueba de regresión.

3.8.2. Criterios de salida para esta prueba:

Aquí se definen los criterios de salida para la regresión.

Por ejemplo:

• Se deben completar las pruebas de regresión.
• Se debe cerrar cualquier error crítico nuevo encontrado durante esta prueba.
• El informe de prueba debería estar listo.

3.9. Casos de prueba

Los casos de prueba de regresión se definen aquí.

3.10. Riesgo / Supuestos

Se identifica cualquier riesgo y suposición y se prepara un plan de contingencia para el mismo.

3.11. Instrumentos

Se identifican las herramientas que se utilizarán en el Proyecto. Como:

• Herramienta de automatización
• Herramienta de informe de errores

# 4) Aprobación / Aceptación

Los nombres y la designación de las personas se enumeran aquí:

Conclusión

La prueba de regresión es uno de los aspectos importantes, ya que ayuda a entregar un producto de calidad al asegurarse de que cualquier cambio en el código, ya sea pequeño o grande, no afecte la funcionalidad existente o anterior.

Hay muchas herramientas de automatización disponibles para automatizar los casos de prueba de regresión; sin embargo, se debe seleccionar una herramienta según los requisitos del proyecto. Una herramienta debe tener la capacidad de actualizar el conjunto de pruebas, ya que el conjunto de pruebas de regresión debe actualizarse con frecuencia.

Con eso, terminamos este tema y esperamos que haya mucha más claridad sobre el tema de ahora en adelante.

Háganos saber sus preguntas y comentarios relacionados con la regresión. ¿Cómo abordó sus tareas de pruebas de regresión?

=> Visite aquí para ver la serie completa de tutoriales del plan de prueba

Lectura recomendada

• Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
• Las 10 herramientas de prueba de regresión más populares en 2021
• Qué son las pruebas de confiabilidad: definición, método y herramientas
• Las 11 mejores herramientas de automatización para probar aplicaciones de Android (herramientas de prueba de aplicaciones de Android)
• Pruebas de regresión automatizadas: desafíos, procesos y pasos
• Descarga del libro electrónico Testing Primer
• Diferencia entre la repetición de pruebas y las pruebas de regresión con ejemplo
• Las 10 mejores herramientas de prueba de SAP (herramientas de automatización de SAP)