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 , agrupamiento de defectos, principio de Pareto y paradoja de pesticidas .
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.
El agrupamiento de defectos se basa en el " 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 los probadores pueden entender 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.
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, si bien es muy cauteloso durante la codificación en un módulo en particular (aquí en nuestro caso, el módulo " Sobregiro "), el desarrollador puede descuidar los otros módulos para codificarlo correctamente o los cambios realizados en ese módulo en particular pueden tienen 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 que los desarrolladores arreglen esos defectos, 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 plaguicidas como se muestra a continuación:
a) Escriba un nuevo conjunto de casos de prueba que se centrarán 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 agregue 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 evaluadores 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 poder 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 evaluadores 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 asegurará 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 resulta en más esfuerzos y tiempo requerido 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 unos pocos casos de prueba pueda cubrirse en otro caso de prueba de extremo a extremo y aquellos casos de prueba que tengan un flujo único se puedan eliminar.
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, en consecuencia, se puede tomar una decisión 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 garantizará que se reduzca el recuento total de casos de prueba, 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.
Aquí la lista de los 7 principios de Testing de acuerdo al libro de ISTQB.
1. Las pruebas muestran la presencia de defectos
El objetivo principal de llevar a cabo una prueba es para detectar defectos. Trabajando bajo la premisa de que cada producto contiene defectos de algún tipo, una prueba que revela los errores es generalmente mejor que una que no lo hace. Todas las pruebas por lo tanto, deben ser diseñados para revelar tantos errores como sea posible.
2. Las pruebas exhaustivas son imposibles
Las pruebas exhaustivas tratan de cubrir todas las combinaciones posibles de datos en el software, a fin de garantizar que ninguna situación puede surgir, una vez probado el software se ha liberado. Excepto en aplicaciones muy simples, el número de combinaciones posibles de datos es demasiado alta, es más eficaz y eficiente que los ingenieros de pruebas se centren en las funcionalidades de acuerdo a riesgos y prioridades.
3. Pruebas tempranas.
Un producto (incluyendo los documentos, tales como la especificación del producto) se puede probar tan pronto como se ha creado. ISTQB recomienda probar un producto tan pronto como sea posible, corregir los errores más rápidamente posible. Los estudios han demostrado que los errores identificados al final del proceso de desarrollo por lo general cuestan más para resolver.
Por ejemplo: un error encontrado en las especificaciones puede ser bastante sencillo de solucionar. Sin embargo, si ese error se transfiere a la codificación de software, una vez descubierto el error puede ser muy costoso y consume tiempo.
4. Agrupamiento de Defectos
Los estudios sugieren que los problemas en un elemento de software tienden a agruparse en torno a un conjunto limitado de módulos o áreas. Una vez que estas áreas han sido identificadas, los administradores eficientes de prueba son capaces de enfocar las pruebas en las zonas sensibles, mientras que siguen buscando a los errores en los módulos de software restantes. Me recuerda al 80/20.
5. La paradoja del "Pesticida"
Al igual que el sobre uso de un pesticida, un conjunto de pruebas que se utilizan repetidamente en el disminuirá en su eficacia. Usando una variedad de pruebas y técnicas expondrá una serie de defectos a través de las diferentes áreas del producto.
6. La prueba es dependiente del contexto
Las mismas pruebas no se deben aplicar en todos los ámbitos. Distintos productos de software tienen diferentes requisitos, funciones y propósitos. Una prueba diseñada para realizarse en un sitio web, por ejemplo, puede ser menos eficaz cuando se aplica a una aplicación de intranet. Una prueba diseñada para una forma de pago con tarjeta de crédito puede ser innecesariamente rigurosa si se realiza en un foro de discusión.
En general, cuanto mayor es la probabilidad y el impacto de los daños causados por el software fallado, mayor es la inversión en la realización de pruebas de software.
7. La falacia de ausencia de errores
Declarar que una prueba no ha descubierto ningún error no es lo mismo que declarar que el software es “libre de errores”. Con el fin de garantizar que los procedimientos adecuados de software de prueba se lleva a cabo en todas las situaciones, los evaluadores deben asumir que todo el software contiene algunos (aunque disimulada) errores.
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 eficaz 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.
Generalmente, el término principio significa las reglas o leyes que deben seguirse. Por lo tanto, todos en la industria de las pruebas de software deben seguir estos siete principios, y si alguien ignora alguno de estos principios, el proyecto puede costar mucho dinero.
Comentarios