Tiene una gran cantidad de casos de prueba con tiempo y recursos limitados. ¿Cómo se realizan las pruebas de regresión?

Hola,

En las empresas de pruebas de software , es muy importante realizar pruebas de regresión de la función que se está implementando en producción. Sin embargo, en algunos casos el tiempo no permite que los ingenieros de control de calidad realicen pruebas de regresión exhaustivas. En este tipo de situación, el equipo necesita trabajar de manera inteligente e identificar los casos de regresión aplicando cualquiera de los siguientes enfoques:

– Identifique las áreas afectadas y elija los casos de prueba correspondientes para las pruebas de regresión

– Elija los casos de prueba según la prioridad como alta / media / baja

– Se consideran casos de prueba que tienen un alto impacto según el negocio

Basado en cualquiera de los enfoques anteriores, el equipo puede elegir los casos de prueba de regresión importantes para la liberación respectiva y probarlos en el marco de tiempo apropiado con tiempo y recursos limitados. Esto también ayudaría a proporcionar la estabilidad de la liberación.

Gracias,

Sumit

Tiene una gran cantidad de casos de prueba con tiempo y recursos limitados. ¿Cómo se realizan las pruebas de regresión?

Siempre que las pruebas de regresión son el tema de conversación, la automatización generalmente se menciona en algún momento. Esta respuesta supone que la pregunta se refiere a la prueba de regresión manual.

En una situación como esta, el objetivo es realizar pruebas de manera efectiva mientras se mitiga el mayor riesgo posible. Un gerente de control de calidad querría primero inventariar los recursos disponibles y determinar cuánto tiempo está disponible. Digamos que los gerentes de control de calidad de dos compañías diferentes, A-Corp y BB, Inc., tienen dos probadores, 750 pruebas, 2 días (16 horas) y suficientes entornos de prueba. Además, cada probador promedia 35 pruebas por día.

• El gerente de control de calidad de A-Corp ha hecho que sus evaluadores asignen una prioridad a cada prueba y registren la duración promedio (incluida la configuración), y las pruebas se organizan en distintos grupos, como la configuración de la nueva cuenta y el carrito de compras.
• El gerente de control de calidad de BB, Inc. acaba de comenzar a actualizar la prioridad, pero la mayoría de las pruebas todavía están en la configuración predeterminada de Medio ; ninguna prueba tiene la duración establecida, y todas las pruebas se agrupan en un único conjunto

El estado de la suite de regresión determinará en gran medida cuán riesgoso será una ejecución de prueba abreviada.

• Si el equipo de control de calidad de A-Corp tiene 200 pruebas de alta prioridad, seleccionar 140 pruebas de alta prioridad y corta duración probablemente sería una solución satisfactoria. El gerente de control de calidad puede incluso sentir que seleccionar 120 pruebas y hacer que cada evaluador pase 2 horas exploratorias es una mejor solución.
• El gerente de control de calidad de BB, Inc. tendrá que determinar sobre la marcha qué pruebas son lo suficientemente altas como para ejecutarlas, y dado que no se registra la duración, no sabrá cuánto tiempo dura cada prueba

• Puede revisar los resultados de regresión anteriores, agregando pruebas fallidas de ejecuciones anteriores al conjunto de pruebas para esta ejecución; advertencia emptor se aplica aquí, ya que el rendimiento pasado no garantiza resultados futuros
• Probablemente también pueda asumir con seguridad que las pruebas de alta prioridad se actualizaron intencionalmente y marcar las que se ejecutarán.
• Finalmente, deberá revisar las pruebas de prioridad media restantes y esperar que las decisiones que tome sean buenas.

En cualquier caso, ambos gerentes de control de calidad querrían comunicar el riesgo de ejecutar un conjunto abreviado de pruebas. Durante cada ejecución de regresión, los evaluadores deben verificar la prioridad y confirmar que vale la pena ejecutar la prueba, ya que ambas pueden cambiar con el tiempo.

Harás tu mejor esfuerzo de manera inteligente.

Empiezas a analizar cuál sería el impacto con respecto al cambio. Para que sepa el alcance que debe cubrirse.

Del gran número de casos de prueba, debe poder priorizar los casos de prueba, ya que no todos tendrán la misma prioridad. Puede terminar con un conjunto de casos de prueba de alta prioridad, prioridad media y baja prioridad.

Es posible que desee ejecutar todos los casos de prueba, pero no será posible en esta situación donde hay limitaciones de tiempo y recursos.

Usted hace la estimación del tiempo y el esfuerzo necesarios para realizar cada conjunto de Casos de prueba. Entonces habrá pocos escenarios:

1. Si tiene tiempo para cubrir Prioridad alta y media. Son buenas noticias.
2. Si tiene tiempo para cubrir solo Alta prioridad. Todavía está bien
3. Si ni siquiera tiene tiempo para cubrir Alta prioridad, debe hablar con PM, el Gerente de prueba, el Gerente de entrega o cualquier persona que necesite tomar una decisión sobre la liberación para comunicar que realmente necesita tiempo para al menos finalizar la Ejecución de prueba para Casos de prueba de alta prioridad. De lo contrario, existe el riesgo de que la funcionalidad principal no funcione correctamente y afecte el entorno de producción cuando se implemente.

Si insisten en seguir adelante con la misma línea de tiempo, ya hizo su trabajo para proporcionar información y lo que sucederá es responsabilidad de todo el equipo.

Cuando no tiene mucha experiencia en Pruebas, todo es tan importante y debe probarse para asegurarse de que funcione.

Cuando tenga años de experiencia en Pruebas, sabrá que nunca tendremos suficiente tiempo para hacer el trabajo. El desafío será: ¿Cómo entregar lo mejor a tiempo dentro del tiempo y los recursos dados?

La clave es conocer los objetivos y metas. Nos guiará y se asegurará de que no nos perdamos.

Enfoque 1:

Revise qué ha cambiado, identifique áreas con riesgo / problemas potenciales y áreas que deben funcionar. Realice pruebas exploratorias basadas en sesiones para esas áreas. Según la cantidad de tiempo que tenga, asigne tiempo suficiente a las sesiones para las áreas en las que haya decidido enfocarse. Si sus pruebas de regresión están automatizadas, seleccione los flujos centrales y las áreas no cubiertas por su sesión de prueba exploratoria y ejecute esas pruebas, por separado. NB: necesita saber cómo hacer pruebas exploratorias para esto. Asegúrese de informar / compartir con su equipo lo que no estaba cubierto y los riesgos potenciales por no cubrirlos, así como lo que descubrió en las áreas que sí cubrió.

Enfoque 2:

Suponiendo que los casos de prueba ya han sido revisados ​​y son adecuados para la regresión. Aborde el problema de tiempo limitado y recursos de inmediato. Planifique cuánto tiempo llevará ejecutar las pruebas de regresión en función de los recursos disponibles. Prepare un caso para ayudar a obtener más recursos y más tiempo, también incluya posibles opciones y riesgos asociados con cada uno. Discuta esto con las partes interesadas apropiadas

Esta es una situación típica en proyectos ágiles: muy poco tiempo, no hay suficientes ingenieros de prueba y demasiados cambios en la aplicación. Esto a menudo resulta en pruebas insuficientes y, por lo tanto, errores que se arrastran a las versiones.

Sin embargo, los equipos ágiles experimentados tienen ciertas estrategias para equilibrar el tiempo y los esfuerzos limitados y, sorprendentemente, reducir el costo de las pruebas de software al óptimo.

La priorización de pruebas es una de esas estrategias.

Aplicando este enfoque, un equipo de control de calidad divide las pruebas de regresión en dos ciclos:

1. Regresión de iteración realizada al final de cada sprint. La regresión de iteración se concentra en las características y los cambios realizados en la iteración y las áreas de la aplicación que podrían verse afectadas.

2. Regresión completa realizada antes de las principales versiones y los hitos del proyecto para garantizar que la aplicación funcione como se esperaba.

Este enfoque, por simple que parezca, requiere una comunicación fluida dentro del equipo.

Existen otros enfoques de optimización de regresión, que pueden ser más adecuados para su proyecto.

Hay un buen enfoque en ‘Prueba de software de computadora’. Después de la prueba inicial, ¿dónde te enfocas?

Errores más probables

Probar el área del programa que ya tiene muchos errores

Errores más visibles

Concéntrese en las áreas a las que irán primero los clientes. ¿Cuál es una característica distintiva de su software?

Errores de programa más utilizados

Los errores en estas áreas son molestos

Área distintiva de su programa

¿Cuál es el área clave de distinción de su software? Eso tenía mejor trabajo correcto.

Área más difícil de arreglar

¿Hay un área que a los desarrolladores no les gusta tocar? Encuentra esos errores ahora en lugar de más tarde.

Más entendido por ti

Pruebe esto primero y su interacción con otras áreas. Le ayudará a mudarse a otra área.

Fuente

Página 216, Capítulo 12, Planificación de pruebas y documentación de pruebas, Dónde enfocarse a continuación, dónde agregar profundidad, Pruebas de software de computadora, Segunda edición, Cem Kaner, Jack Falk, Hung Quoc Nguyen

Ahora, un gran número de casos de prueba generalmente significa que algunos de ellos son ignorables o muchos de ellos dependen de la creación de su caso de prueba y el alcance del efecto de la función en el sistema que está probando.

En primer lugar, buscará los casos principales en regresión si pasan o no, intentará verificar que las cosas no exploten al ejecutar cosas importantes. Eso puede compilar entre el 20 y el 30% de sus pruebas. Luego, pasará a casos semi-principales que pueden tener un efecto directo o indirecto en la eficiencia del sistema. Por lo tanto, puede realizar una prueba del 50 al 60% e intentarlo.

Los principales casos de prueba se refieren a las principales funcionalidades del sistema.

Semi importante se refiere a funcionalidades que dependen de las funcionalidades principales o que son importantes para la eficiencia del cliente o del sistema.

Eso es lo que sugiero. Pero depende totalmente de la situación, no puedo darle un consejo directo para esto.

Probablemente necesite tener una conversación con los altos directivos de su organización sobre el nivel de importancia que se le da a las pruebas de software. Con demasiada frecuencia, las pruebas se consideran una tarea al final para proporcionar un ‘cierre de sesión’. Si puede pasar a una situación en la que los evaluadores son vistos como una parte integral de la entrega de software de calidad que contribuyen activamente, puede aprovechar mucho más en estas discusiones. Desplazar a la izquierda es un poco cliché en estos días, pero no lo hace menos válido.

Ya hay algunas respuestas excelentes que brindan soluciones pragmáticas. Solo tenga cuidado de que al hacer esto y ‘realizar las pruebas’, puede habilitar el comportamiento organizacional que condujo a la situación en la que se encuentra.

La falta de tiempo y recursos asignados a las pruebas rara vez se recuerda cuando las pruebas permiten que un error pase a la vida …

Divida el banco de pruebas en flujos de trabajo. En general, los casos de regresión están diseñados para probar pruebas funcionales. En lugar de probar solo el botón o algunas características. Divida todo el banco de pruebas en flujos de trabajo, incluidos esos casos también. Para dar un ejemplo amazon. Flujo de trabajo: el usuario más fumador selecciona algunos elementos (incluye más elementos, intenta editar, eliminar, etc.), por lo tanto, selecciona eso también. Subtotal de verificación del carrito, cantidad -> página de dirección de entrega (agregue también la nueva dirección) -> página de pago intente todas las opciones en un flujo como bacalao, netbankinh, ui -> coloque la página de pedido. Verifique mensajes y ui al mismo tiempo. -> página de confirmación-> correos electrónicos-> backend.

Cree mayores escenarios y queme la regresión completa a solo 200 flujos de trabajo de casos de prueba

En segundo lugar, se centran en las principales áreas afectadas. Ayudará a reducir el esfuerzo de tiempo y el trabajo de calidad. Divida entre los flujos de trabajo del equipo 10 cada día. Considerando 3 miembros del equipo. Se hace en 3–4 días.

¡Espero que esto ayude!

Verifica tu cobertura. Si tienes 3 pruebas; A, B y C; ¿Los casos de prueba A y B cubren el 90% o más del caso de prueba C? Si es así, ¿puede eliminar el caso de prueba C? ¿Sería bastante fácil agregar un poco de funcionalidad para probar el caso A o B para cubrir las brechas? Eliminar cualquier redundancia.

Otra técnica es la prueba de “telenovela”. Aquí es donde diseñas una prueba para lanzar la mayor cantidad de combinaciones posibles en una función o forma, sin importar cuán extraño sea. Use tantos campos en un formulario como sea posible. Tenga en cuenta, por definición, que esto también podría cubrir pruebas negativas. Por ejemplo, si marca uno para sexo como “masculino” y en otro cuadro tiene una respuesta de “sí” para embarazadas, esto no debería permitirse o lanzar una excepción (que la IU debe manejar con gracia).

Escenario muy obvio y frente a esto casi todos los proyectos. Dos caminos:

1. Seleccione tcs de prioridad comercial (bloqueador) y ejecútelo. Eso es cuando la integración continua o la práctica ágil juegan un papel vital en la automatización de la prueba de regresión

2. Trabaje en estrecha colaboración con el equipo de ingeniería y conozca los cambios exactos (áreas) realizados en el producto y prepare una suite con bloqueador + tcs críticos

gracias por a2a

Hola, el mismo problema se está ejecutando conmigo la mayor parte del tiempo. lo que hago … sé cuál es mi funcionalidad crucial o no.

así que cuando el tiempo es menor, intente realizar la mayoría de las cosas primero e informe a su líder de prueba que solo pruebo mucho y solo realizo esto. para que lo notifiquen.

Eso es lo que hago.

para más consulta – 8003070864

Los casos de prueba que tienen más prioridad se prueban … Y comprueba si hay defectos importantes.

comprobaremos el camino feliz, es decir, pruebas de alto nivel.