Cuándo detener las pruebas (criterios de salida en las pruebas de software)

when stop testing

Criterios de salida en pruebas:

“Bien comenzado está a medio hacer”: se aplica en todas partes, incluso en las pruebas de software.

A menudo vemos probadores de software muy entusiastas al comienzo del proyecto. Nosotros creamos documentos de prueba como Estrategia de prueba, Plan de prueba o Casos de prueba con entusiasmo y entusiasmo.

Luego llegamos a probar el software con un ¡BANG! Esto solo se ve amplificado por los interesantes defectos que encontramos al comienzo del proyecto. Resolverlos solo contribuirá a nuestro logro.

A medida que encontramos muchos defectos y completamos la primera ejecución, pasamos a la siguiente fase. Cuando llegamos a la segunda carrera, nos relajamos y, como es la tendencia humana general de aburriéndose de probar lo mismo en la segunda ejecución.

implementando una pila c ++

Muchos evaluadores sienten que se vuelve trabajo monótono en ejecuciones posteriores y empiece a perder interés en probar el mismo software una y otra vez. Cuando llegamos, tal vez a la tercera ejecución, una pregunta comienza a atormentarnos y es '¿Cuándo dejar de probar el software?'

Apuesto a que debe haberse sentido de la misma manera y preguntado, '¿Cuándo dejar de hacer la prueba?', Al menos una vez. Yo diría que la pregunta es '¿Cuándo, dónde y cómo dejar de realizar pruebas?' :)

Conceptualmente hemos leído y muchos evaluadores creen que no puede haber una condición o ecuación específica para decidir '¿Cuándo dejar de probar?' Hay una serie de factores a considerar antes de concluir sobre esta cuestión.

En el artículo de hoy, me gustaría compartir mis pensamientos sobre cómo concluir las actividades de prueba cuando llegamos a un punto en nuestro ciclo de prueba en el que podemos decir que esta prueba es suficiente. Haremos esto con la ayuda de algunos ejemplos de la vida real en un ciclo de prueba típico.

Lo que vas a aprender:

• ¿Cuándo son suficientes las pruebas?
• Detenerse cuando se encuentran todos los defectos: ¿es posible?
• Decisión de detener la prueba: criterios de salida
• ¿Qué son los criterios de finalización o salida?
• ¿Qué debería estar presente en los criterios de salida?
• Las pruebas se pueden detener cuando:
• Conclusión:
• Lectura recomendada

¿Cuándo son suficientes las pruebas?

¿Cuándo podemos decir que tantas pruebas son suficientes? ¿Se pueden completar las pruebas?

Para responder a estas preguntas, tendremos que analizar las actividades de prueba de principio a fin. Tenga en cuenta que, voy a definir estas actividades en términos profanos, no de una manera técnica elegante.

Consideremos que está comenzando a probar un nuevo proyecto.

Actividades iniciales:

• El equipo de pruebas recibe requisitos.
• El equipo de pruebas comienza planificación y diseñando.
• Los documentos de la prueba inicial están listos y revisados.

Prueba de ejecución n. ° 1)

• El equipo de prueba inicia la ejecución de la prueba una vez que reciben el producto desarrollado.
• Durante la fase de prueba, ejecutan varios escenarios para romper el software y encontrar muchos defectos. (Además, la tasa de defectos aquí es mayor porque la aplicación es nueva y se está evaluando por primera vez).
• Los desarrolladores solucionan los defectos y los devuelven al equipo de prueba para volver a probarlos.
• El equipo de pruebas realiza una nueva prueba de los defectos y ejecuta la regresión.
• Una vez que se resuelven la mayoría de los defectos de alta gravedad y el software parece estable, El equipo de desarrollo lanza la próxima versión.

Prueba de ejecución n. ° 2)

• El equipo de pruebas comienza la segunda ejecución de pruebas y se ejecutan actividades similares como Ejecución 1.
• En este proceso, durante la segunda ejecución de prueba, se detectan algunos defectos más.
• Los desarrolladores solucionan los defectos y los devuelven al equipo de pruebas para que los repita.
• El equipo de pruebas vuelve a probar los defectos y realiza regresión .

Esto puede continuar para siempre. Ejecute 3, Ejecute 4 en adelante hasta que se encuentren todos los defectos en el software y el software esté libre de errores.

Si queremos dibujar un diagrama de flujo para estas actividades, se verá más o menos a continuación:

A partir del diagrama de flujo anterior, podemos concluir claramente que las pruebas pueden continuar hasta que se encuentren todos los defectos en el software.

Pero la pregunta es: ¿es posible encontrar todos los defectos del software? Intentemos encontrar la respuesta a esta pregunta del millón de dólares :).

Detenerse cuando se encuentran todos los defectos: ¿es posible?

La mayor parte del software es complejo y tiene un alcance de prueba enorme. No es imposible encontrar todos los defectos en el software, pero llevará una eternidad.

Incluso después de encontrar muchos errores en el software, nadie puede garantizar realmente que el software esté libre de defectos ahora. No puede haber una situación en la que podamos decir con confianza que hemos completado las pruebas, hemos encontrado todos los defectos en el software y no tiene más errores.

Además, el propósito de las pruebas no es encontrar todos y cada uno de los defectos del software. La intención de las pruebas de software es demostrar que el software funciona según lo previsto al romperlo o encontrar una desviación entre su comportamiento actual y el comportamiento esperado.

Hay defectos ilimitados en el software y, por lo tanto, no es práctico probarlo hasta que se encuentren todos los defectos, ya que nunca podemos saber cuál es el último. La verdad es que no podemos depender de encontrar todos los defectos en el software para concluir nuestras pruebas.

Honestamente hablando, las pruebas son infinitas y los ciclos de pruebas continuarán hasta que se tome una decisión sobre cuándo y dónde detenerse. Ahora se vuelve aún más complicado tomar la decisión de dejar de realizar pruebas. Si 'detenerse cuando se encuentran todos los defectos' no es el criterio para detener las pruebas, ¿sobre qué base se debe decidir?

Decisión de detener la prueba: Criterio de salida

Intentemos ahora comprender: ¿Cuáles son los factores más importantes que deben tenerse en cuenta al concluir las actividades de prueba? Siento que la decisión de dejar de hacer las pruebas depende principalmente de Tiempo, presupuesto y alcance de las pruebas.

El enfoque más común es detenerse cuando se agota el tiempo / presupuesto o se ejecutan todos los escenarios de prueba. Sin embargo, con este enfoque, estaremos comprometiendo la calidad de las pruebas y esto no dará suficiente confianza sobre el software; ¿Cómo?

Veamos con unejemplo.

Escenario de prueba:

Suponga que está probando un módulo de software. Se le ha asignado cierto presupuesto para cubrirlo. Los plazos del proyecto son por un mes. Los escenarios de prueba totales son 200. Usted es el único que prueba este módulo.

Escenario 1)

Semana 1: Encuentra el defecto showstopper / severity 1 el día 1 y toda la prueba se bloquea durante 3 días. Por lo tanto, no podrá ejecutar ninguno de los escenarios hasta que se resuelva el defecto de gravedad 1. Después de perder 3 días, el bloqueador se resuelve y continúa con su ejecución.

Al final de la semana, completa 20 escenarios con algunos altos más importantes defectos de prioridad .

Semana 2: Empieza a probar el software poniendo más énfasis en la búsqueda de defectos. Abre algunos defectos más de Severidad 1, Severidad 2 y Severidad 3 durante la segunda semana y al final de la semana, puede cubrir 70 Escenarios.

Semana 3: Al comienzo de la 3^rdsemana, se resuelven todos los defectos de alta prioridad, por lo que, junto con la ejecución de escenarios pendientes, ahora tiene que volver a probar todos los defectos que han aterrizado en el grupo de pruebas. Continuando con el buen progreso, cubre 120 escenarios con defectos adicionales.

En este momento, todos los defectos de alta prioridad ya se encuentran y se notifican. Entonces, ahora solo le quedan defectos de Severidad 3 por encontrar.

Semana 4: Para la semana 4, debe volver a probar la mayoría de los defectos abiertos y los 80 escenarios restantes. Con esto, al final de la semana 4, puede completar hasta 180 escenarios con todos los defectos de prioridad alta y media corregidos y volver a probar.

Poniendo esta información en forma tabular:

¿Deberías parar aquí?

La razón por la que te has agotado Tiempo de prueba completo y han informado y solucionado la mayoría de los defectos de alta prioridad. ¿Detenerse en este punto le dará confianza sobre el software? Realmente no debido a las siguientes razones:

• Los escenarios no se ejecutan por completo.
• Pocos flujos ni siquiera se prueban una vez.
• Todos los escenarios cubiertos se ejecutan una sola vez.
• El software todavía tiene defectos.
• La regresión no está cubierta.

Escenario n. ° 2)

Semana 1: Encuentra un defecto de Severidad 1 el día 1 y la prueba completa se bloquea durante 3 días. Por lo tanto, no podrá ejecutar ninguno de los escenarios hasta que se resuelva el defecto de gravedad 1. Luego de perder 3 días el bloqueador se resuelve y continúas con tu ejecución.

Al final de la semana, completa 20 escenarios con algunos defectos más. Esta semana sigue siendo la misma que el escenario 1.

Semana 2: Abre algunos defectos más de Severidad 1, Severidad 2 y Severidad 3 durante la segunda semana, pero el enfoque es cubrir más escenarios para cubrir el retraso de la semana 1. Al final de la semana, puede cubrir 120 Escenarios.

Semana 3: Al comienzo de la 3^rdsemana, se resuelven todos los defectos abiertos, por lo que, junto con la ejecución de los escenarios pendientes, ahora debe volver a probar todos los defectos que se encuentran en un depósito de prueba. Continuando con un buen progreso al final, el número de escenarios completados se convierte en 200 con defectos adicionales.

Ahora solo puede informar defectos de Severidad 2 y Severidad 3.

Poniendo esta información en forma tabular:

¿Deberías parar aquí?

Tú tienes cubrió todos los escenarios de prueba por completo una vez y han abierto algunos defectos importantes. ¿Detenerse en este punto le dará confianza sobre el software?

Realmente no debido a las siguientes razones:

• Todos los escenarios se ejecutan solo una vez.
• El software todavía tiene muchos defectos importantes.
• La regresión no está cubierta.

Podemos ver que la calidad se ve comprometida en ambos escenarios. El mejor enfoque será encontrar un punto donde todos los factores del escenario 1 y el escenario 2 estén cubiertos y la calidad tampoco se vea comprometida. Para lograrlo tendremos que definir ciertos criterios al inicio de las pruebas.

Estos criterios se denominan criterios de finalización o salida. Es la respuesta a nuestra pregunta: “¿Cuándo dejar de realizar pruebas?”.

¿Qué son los criterios de finalización o salida?

Los criterios de salida se evalúan al final del ciclo de prueba y se definen en el Plan de prueba. Es el conjunto de condiciones o actividades que se deben cumplir para concluir las pruebas.

Los criterios de salida definen cuántas pruebas son suficientes y cuándo se pueden declarar completas las actividades de prueba. Cobertura y los criterios de finalización se combinan para definir los criterios de salida para las pruebas.

¿Qué debería estar presente en los criterios de salida?

Idealmente, los criterios de salida o parada se definen combinando varios factores y, por lo tanto, son únicos en todos los proyectos. Depende de los requisitos del proyecto y, por lo tanto, debe definirse durante la planificación de pruebas; al inicio del proyecto. Los parámetros definidos en él deben cuantificarse tanto como sea posible.

A continuación se presentan algunos consejos que se deben considerar al definir los criterios de salida en caso de pruebas funcionales o del sistema. Puede combinar algunos o todos los factores a continuación mientras decide dónde dejar de probar según las necesidades de su proyecto.

cómo encontrar la llave de seguridad para wifi

Las pruebas se pueden detener cuando:

Requisitos:

• Se alcanza el 100% de cobertura de Requisitos.

Defectos:

• Se alcanza el recuento de defectos definidos / deseados.
• Todos los defectos o bloqueadores de Show Stopper están corregidos y ningún defecto conocido Crítico / Severidad 1 está en estado Abierto.
• Todos los defectos de alta prioridad se identifican y solucionan.
• La tasa de defectos cae por debajo de la tasa aceptable definida.
• Muy pocos defectos de prioridad media están abiertos y tienen una solución alternativa.
• Muy pocos defectos abiertos de baja prioridad que no afecten el uso del software.
• Todos los defectos de alta prioridad se vuelven a probar y se cierran y los escenarios de regresión correspondientes se ejecutan con éxito.

Cobertura de prueba:

• La cobertura de la prueba debe alcanzarse en un 95%.
• La tasa de aprobación del caso de prueba debe ser del 95%. Esto se puede calcular por fórmula
  • (No total de TC aprobadas / Número total de TC) * 100.
• Se pasan todos los casos de prueba críticos.
• 5% Los casos de prueba pueden fallar, pero los casos de prueba fallidos son de baja prioridad.
• Se logra una cobertura funcional completa.
• Todos los principales flujos funcionales / comerciales se ejecutan con éxito con varias entradas y funcionan bien.

Plazos:

• Se alcanzó la fecha límite del proyecto o la fecha límite de finalización de la prueba.

Documentos de prueba:

• Todos los documentos de prueba / entregables (ejemplo: Informe de resumen de la prueba ) se preparan, revisan y publican.

Presupuesto:

• El presupuesto de prueba completo está agotado.

Reuniones 'Go / No Go':

• “ Ir no ir ” reunión se ha realizado con las partes interesadas y se decide si el proyecto debe pasar a producción o no.

Conclusión:

Hagámoslo muy simple al final.

Responda las preguntas con un simple Sí o No.

Si obtiene la mayoría de las respuestas como Sí, significa que puede dejar de realizar la prueba en este punto. Si la mayoría de las respuestas son No, eso significa que debe verificar lo que falta en las pruebas y esto puede ayudarlo a encontrar un defecto de producción que se escapa :)

• ¿Se ejecutan todos los casos de prueba al menos una vez?
• ¿La tasa de aprobación de casos de prueba es la definida?
• ¿Se alcanza una cobertura de prueba completa?
• ¿Se ejecutan todos los flujos funcionales / comerciales al menos una vez?
• ¿Se alcanza el recuento de defectos decidido?
• ¿Se corrigen y cierran todos los defectos importantes de alta prioridad?
• ¿Se han vuelto a probar y se han cerrado todos los defectos?
• ¿Se ha realizado una regresión para todos los defectos abiertos?
• ¿Ha agotado el presupuesto de prueba?
• ¿Ha llegado la hora de finalización de la prueba?
• ¿Se revisan y publican todos los entregables de prueba?

Sobre el Autor: Este es un artículo invitado de Renuka K. Tiene más de 11 años de experiencia en pruebas de software.

Espero que este artículo te haya sido útil. También me gustaría escuchar sus pensamientos / comentarios sobre el tema.

¡Feliz prueba!

Lectura recomendada

• Mejores herramientas de prueba de software 2021 (Herramientas de automatización de pruebas de control de calidad)
• Trabajo de asistente de control de calidad de pruebas de software
• Programa del curso de pruebas de software: plan de formación detallado del curso en línea
• Curso de pruebas de software: ¿A qué instituto de pruebas de software debo unirme?
• Elegir las pruebas de software como carrera
• Prueba de software Escritor de contenido técnico Trabajo autónomo
• Algunas preguntas interesantes de la entrevista sobre pruebas de software
• Comentarios y revisiones del curso de pruebas de software