Menú

7 principios de las pruebas de software: agrupamiento de defectos y principio de Pareto

  • Principal
  • Otro
  • 7 principios de las pruebas de software: agrupamiento de defectos y principio de Pareto

7 principles software testing

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

Siete principios de las pruebas de software: incluidos más detalles sobre la agrupación de defectos, el principio de Pareto y la paradoja de los pesticidas.

Estoy seguro de que todo el mundo conoce el ' Siete principios de las pruebas de software ”.

Estos principios fundamentales de prueba ayudan a los equipos de prueba a utilizar su tiempo y esfuerzo para hacer que el proceso de prueba sea efectivo. En este artículo, aprenderemos en detalle sobre dos principios, es decir, Agrupación de defectos, principio de Pareto y paradoja de plaguicidas .

7 principios de las pruebas de software

Lo que vas a aprender:

Siete principios de las pruebas de software

Antes de profundizar en esos dos principios, comprendamos brevemente los siete principios de las pruebas de software.

¡¡Vamos a explorar!!

# 1) Las pruebas muestran la presencia de defectos

Cada aplicación o producto se lanza a producción después de una cantidad suficiente de pruebas por parte de diferentes equipos o pasa por diferentes fases como Pruebas de integración del sistema, Pruebas de aceptación del usuario y Pruebas beta, etc.

Asi que ¿Alguna vez ha visto o escuchado de algún miembro del equipo de pruebas que han probado el software completamente y que no hay defectos en el software? ? En lugar de eso, cada equipo de pruebas confirma que el software cumple con todos los requisitos comerciales y está funcionando según las necesidades del usuario final.

En la industria de las pruebas de software, nadie dirá que hay sin defectos en el software, lo cual es bastante cierto, ya que las pruebas no pueden probar que el software esté libre de errores o defectos.

Sin embargo, el objetivo de las pruebas es encontrar cada vez más defectos ocultos utilizando diferentes técnicas y métodos. Las pruebas pueden revelar defectos no descubiertos y, si no se encuentran defectos, no significa que el software esté libre de defectos.

Ejemplo 1 :

Considere una aplicación bancaria, esta aplicación se prueba a fondo y se somete a diferentes fases de prueba como SIT, UAT, etc. y actualmente no se identifican defectos en el sistema.

Sin embargo, puede existir la posibilidad de que en el entorno de producción, el cliente real pruebe una funcionalidad que rara vez se usa en el sistema bancario y los evaluadores pasaron por alto esa funcionalidad, por lo tanto, no se encontraron defectos hasta la fecha o los desarrolladores nunca han tocado el código. .

Ejemplo 2:

Hemos visto varios anuncios de jabones, pasta de dientes, lavado de manos o aerosoles desinfectantes, etc. en la televisión.

Considere un anuncio de lavado de manos que diga en la televisión que el 99% de los gérmenes se pueden eliminar si se usa ese lavado de manos específico. Esto demuestra claramente que el producto no está 100% libre de gérmenes. Por lo tanto, en nuestro concepto de prueba, podemos decir que ningún software está libre de defectos.

# 2) Pruebas tempranas

Los probadores deben involucrarse en una etapa temprana del ciclo de vida del desarrollo de software (SDLC). De esta forma se pueden identificar los defectos durante la fase de análisis de requisitos o cualquier defecto de documentación. El costo involucrado en la reparación de tales defectos es muy inferior en comparación con los que se encuentran durante las últimas etapas de la prueba.

Considere la siguiente imagen que muestra cómo aumenta el costo de la reparación de defectos a medida que las pruebas avanzan hacia la producción en vivo.

prueba temprana - costo de reparación de defectos

(imagen fuente )

La imagen de arriba muestra que el costo requerido para reparar un defecto encontrado durante el Análisis de Requisitos es menor y continúa aumentando a medida que avanzamos hacia la fase de Prueba o Mantenimiento.

Ahora la pregunta es ¿Qué tan temprano debe comenzar la prueba? ?

Una vez finalizados los requisitos, los probadores deben participar en las pruebas. Las pruebas deben realizarse en documentos de requisitos, especificaciones o cualquier otro tipo de documento para que, si los requisitos se definen incorrectamente, se puedan corregir de inmediato en lugar de corregirlos en la fase de desarrollo.

# 3) No es posible realizar pruebas exhaustivas

No es posible probar todas las funcionalidades con todas las combinaciones válidas e inválidas de datos de entrada durante la prueba real. En lugar de este enfoque, se considera que la prueba de algunas combinaciones se basa en la prioridad utilizando diferentes técnicas.

Las pruebas exhaustivas requerirán esfuerzos ilimitados y la mayoría de esos esfuerzos son ineficaces. Además, los cronogramas del proyecto no permitirán probar tantas combinaciones. Por lo tanto, se recomienda probar los datos de entrada utilizando diferentes métodos como el Particionamiento de Equivalencia y el Análisis de Valor Límite.

Por ejemplo ,Supongamos que tenemos un campo de entrada que acepta alfabetos, caracteres especiales y números del 0 al 1000 únicamente. Imagínese cuántas combinaciones aparecerían para probar, no es posible probar todas las combinaciones para cada tipo de entrada.

Los esfuerzos de prueba necesarios para probar serán enormes y también afectarán el cronograma y el costo del proyecto. Por eso siempre se dice que prácticamente no es posible realizar pruebas exhaustivas.

# 4) Las pruebas dependen del contexto

Hay varios dominios disponibles en el mercado como banca, seguros, médicos, viajes, publicidad, etc. y cada dominio tiene una serie de aplicaciones. Además, para cada dominio, sus aplicaciones tienen diferentes requisitos, funciones, diferentes propósitos de prueba, riesgo, técnicas, etc.

Los diferentes dominios se prueban de manera diferente, por lo que la prueba se basa exclusivamente en el contexto del dominio o la aplicación.

Por ejemplo ,probar una aplicación bancaria es diferente a probar cualquier aplicación de publicidad o comercio electrónico. El riesgo asociado con cada tipo de aplicación es diferente, por lo que no es efectivo utilizar el mismo método, técnica y tipo de prueba para probar todos los tipos de aplicación.

# 5) Agrupación de defectos

Durante las pruebas, puede suceder que la mayoría de los defectos encontrados estén relacionados con una pequeña cantidad de módulos. Puede haber varias razones para esto, como que los módulos pueden ser complejos, la codificación relacionada con dichos módulos puede ser complicada, etc.

Este es el Principio de Pareto de las pruebas de software donde el 80% de los problemas se encuentran en el 20% de los módulos. Aprenderemos más sobre la agrupación de defectos y el principio de Pareto más adelante en este artículo.

# 6) La paradoja de los pesticidas

El principio de la paradoja de plaguicidas dice que si el mismo conjunto de casos de prueba se ejecuta una y otra vez durante el período de tiempo, entonces este conjunto de pruebas no son lo suficientemente capaces de identificar nuevos defectos en el sistema.

Para superar esta “paradoja de los plaguicidas”, el conjunto de casos de prueba debe revisarse y revisarse periódicamente. Si es necesario, se puede agregar un nuevo conjunto de casos de prueba y los casos de prueba existentes se pueden eliminar si no pueden encontrar más defectos en el sistema.

# 7) Ausencia de error

Si el software se prueba completamente y si no se encuentran defectos antes del lanzamiento, podemos decir que el software está libre de defectos en un 99%. Pero, ¿qué pasa si este software se prueba con requisitos incorrectos? En tales casos, incluso encontrar defectos y arreglarlos a tiempo no ayudaría ya que las pruebas se realizan en requisitos incorrectos que no se ajustan a las necesidades del usuario final.

Por ejemplo, Supongamos que la aplicación está relacionada con un sitio de comercio electrónico y los requisitos de la funcionalidad 'Carrito de compras o Carrito de compras' se interpretan y prueban incorrectamente. Aquí, incluso encontrar más defectos no ayuda a mover la aplicación a la siguiente fase o al entorno de producción.

Estos son los siete principios de las pruebas de software.

Ahora exploremos Agrupación de defectos, principio de Pareto y paradoja de plaguicidas en detalle .

Agrupación de defectos

Al probar cualquier software, los probadores se encuentran principalmente con una situación en la que la mayoría de los defectos encontrados están relacionados con alguna funcionalidad específica y el resto de las funcionalidades tendrán un número menor de defectos.

La agrupación de defectos significa una pequeña cantidad de módulos que contienen la mayoría de los defectos. Básicamente, los defectos no se distribuyen uniformemente en toda la aplicación, sino que los defectos se concentran o centralizan en dos o tres funcionalidades.

A veces, es posible debido a la complejidad de la aplicación, la codificación puede ser compleja o engañosa, un desarrollador puede cometer un error que podría afectar solo a una funcionalidad o módulo específico.

La agrupación en clústeres de defectos se basa en ' Principio de Pareto ”Que también se conoce como Regla 80-20 . Significa que el 80% de los defectos encontrados se deben al 20% de los módulos de la aplicación. El concepto de Principio de Pareto fue definido inicialmente por un economista italiano - Vilfrodo Pareto .

Si los evaluadores miran 100 defectos, entonces no estará claro si hay algún significado subyacente contra esos 100 defectos. Pero si esos 100 defectos se clasifican según algunos criterios específicos, entonces es posible que los probadores comprendan que una gran cantidad de defectos pertenecen solo a unos pocos módulos específicos.

Por ejemplo ,Consideremos la siguiente imagen que se prueba para una de las aplicaciones bancarias y muestra que la mayoría de los defectos están relacionados con la funcionalidad de 'Sobregiro'. El resto de funcionalidades como Resumen de cuenta, Transferencia de fondos, Instrucción permanente, etc., tienen un número limitado de defectos.

Agrupación de defectos

(imagen fuente )

La imagen de arriba indica que hay 18 defectos en la funcionalidad de Sobregiro de un total de 32 defectos, lo que significa que el 60% de los defectos se encuentran en el módulo de “Sobregiros”.

Por lo tanto, los probadores se concentran principalmente en esta área durante la ejecución para encontrar más y más defectos. Se recomienda que los probadores tengan un enfoque similar en los otros módulos también durante las pruebas.

Cuando se prueba un mismo código o módulo, una y otra vez, utilizando un conjunto de casos de prueba que durante las iteraciones iniciales, entonces el número de defectos es alto; sin embargo, después de algunas iteraciones, el recuento de defectos se reducirá significativamente. La agrupación de defectos indica que el área propensa a defectos se debe probar a fondo durante la prueba de regresión.

Paradoja del pesticida

Cuando se encuentra que uno de los módulos tiene más defectos, los probadores hacen algunos esfuerzos adicionales para probar ese módulo.

Después de algunas iteraciones de prueba, la calidad del código mejora y el recuento de defectos comienza a disminuir, ya que el equipo de desarrollo corrige la mayoría de los defectos, ya que los desarrolladores también son cautelosos al codificar un módulo en particular donde los probadores encontraron más defectos.

Por lo tanto, en un momento dado, la mayoría de los defectos se descubren y se corrigen para que no se encuentren nuevos defectos en ese módulo.

Sin embargo, a veces puede suceder que, aunque tengamos mucho cuidado durante la codificación de un módulo en particular (aquí, en nuestro caso, el ' Sobregiro ”), El desarrollador puede descuidar los otros módulos para codificarlo correctamente o los cambios realizados en ese módulo en particular pueden tener un impacto negativo en las otras funcionalidades como Resumen de cuenta, Transferencia de fondos e Instrucciones permanentes.

Cuando los probadores usan el mismo conjunto de casos de prueba para ejecutar el módulo donde se encuentran la mayoría de los defectos (módulo de sobregiro), luego de corregir esos defectos por los desarrolladores, esos casos de prueba no son muy efectivos para encontrar nuevos defectos. Como el flujo de extremo a extremo del Sobregiro, el módulo se prueba a fondo y los desarrolladores también han escrito el código para ese módulo con cautela.

Es necesario revisar y actualizar estos casos de prueba. También es una buena idea agregar nuevos casos de prueba para que se puedan encontrar nuevos y más defectos en diferentes áreas de software o aplicación.

Métodos preventivos de la paradoja de los plaguicidas

Hay dos opciones a través de las cuales podemos prevenir la paradoja de los pesticidas como se muestra a continuación:

a) Escriba un nuevo conjunto de casos de prueba que se centren en diferentes áreas o módulos (distintos del módulo anterior propenso a defectos - Ejemplo: “Sobregiro”) del software.

b) Prepare nuevos casos de prueba y agréguelos a los casos de prueba existentes.

En el ' método A ”, Los probadores pueden encontrar más defectos en los otros módulos en los que no se enfocaron durante las pruebas anteriores o los desarrolladores no fueron más cautelosos durante la codificación.

En nuestro ejemplo anterior, los evaluadores pueden encontrar más defectos en los módulos Resumen de cuenta, Transferencia de fondos o Instrucciones permanentes utilizando el nuevo conjunto de casos de prueba.

Pero puede suceder que los probadores descuiden el módulo anterior ( Ejemplo: “Sobregiro”) donde la mayoría de los defectos se encontraron en la iteración anterior y esto podría ser un riesgo ya que este módulo (Sobregiro) podría haber sido inyectado con los nuevos defectos después de codificar los otros módulos.

En el ' método B ”, Se preparan nuevos casos de prueba para que se puedan encontrar nuevos defectos potenciales en el resto de módulos.

Aquí, en nuestro ejemplo, los casos de prueba recién creados podrán ayudar a identificar defectos en los módulos como Resumen de cuenta, Transferencia de fondos e Instrucción permanente. Sin embargo, los probadores no pueden ignorar los módulos anteriores propensos a defectos ( Ejemplo: “Sobregiro”) ya que estos nuevos casos de prueba se fusionan con los casos de prueba existentes.

Los casos de prueba existentes se centraron más en el módulo 'Sobregiro' y los nuevos casos de prueba se centraron en los otros módulos. Por lo tanto, todo el conjunto de casos de prueba se ejecuta al menos una vez que incluso ocurre un cambio de código en cualquier módulo. Esto garantizará que se ejecute la regresión adecuada y que se pueda identificar el defecto debido a este cambio de código.

Con el segundo enfoque, el recuento total de casos de prueba aumenta significativamente y se traduce en más esfuerzos y tiempo necesarios para la ejecución. Obviamente, esto tendrá un impacto en los plazos del proyecto y, lo que es más importante, también en el presupuesto del proyecto.

Por lo tanto, para superar este problema, los casos de prueba redundantes se pueden revisar y luego eliminar. Hay muchos casos de prueba que se vuelven inútiles después de agregar nuevos casos de prueba y modificar los casos de prueba existentes.

Es necesario verificar qué casos de prueba fallaron para identificar los defectos en las últimas 5 iteraciones (supongamos 5 iteraciones) y qué casos de prueba no son muy importantes. También puede darse el caso de que el flujo único cubierto en algunos casos de prueba pueda cubrirse en otro caso de prueba de extremo a extremo y aquellos casos de prueba que tengan un flujo único puedan eliminarse.

Esto, a su vez, reducirá el recuento total de casos de prueba.

Por ejemplo ,tenemos 50 casos de prueba para cubrir un módulo en particular y hemos visto que de estos 50 casos de prueba, 20 casos de prueba no pudieron detectar un nuevo defecto en las últimas iteraciones de prueba (supongamos 5 iteraciones). Por lo tanto, estos 20 casos de prueba deben revisarse a fondo y debemos verificar qué tan importantes son estos casos de prueba y se puede tomar una decisión en consecuencia sobre si conservar los 20 casos de prueba o eliminarlos.

Antes de eliminar cualquier caso de prueba, verifique que el flujo de funcionalidad cubierto en esos casos de prueba esté cubierto en otro caso de prueba. Este proceso debe seguirse en todos los módulos para que el recuento total de casos de prueba se reduzca significativamente. Esto asegurará que el recuento total de casos de prueba se reduzca, pero todavía hay una cobertura de requisitos del 100%.

Significa que todos los casos de prueba restantes cubren todos los requisitos comerciales, por lo que no se compromete la calidad.

Conclusión

La prueba de software es un paso esencial en SDLC, ya que verifica si el software está funcionando según las necesidades del usuario final o no.

Las pruebas identifican tantos defectos como sea posible. Por lo tanto, para realizar pruebas de manera efectiva y eficiente, todos deben conocer y comprender claramente los siete principios de las pruebas de software y se los conoce como los pilares de las pruebas.

La mayoría de los probadores han implementado y experimentado estos principios durante las pruebas reales.

¿Cómo se reproducen los archivos SWF?

Generalmente, el término principio significa las reglas o leyes que deben seguirse. Por lo tanto, todos en la industria de pruebas de software deben seguir estos siete principios, y si alguien ignora alguno de estos principios, puede costarle enormemente al proyecto.

¡¡Feliz lectura!!

Lectura recomendada

^