7 principios clave de prueba de ISTQB | #3 Primeros pasos en las pruebas de software

La realización de pruebas de software precisas y correctas sigue numerosos principios. La Junta Internacional de Calificaciones de Pruebas de Software distingue siete fundamentales, que vamos a discutir hoy. ¿Tienes curiosidad por averiguarlo? ¡Lea un artículo sobre los principios clave de las pruebas de ISTQB!

Principios de prueba de ISTQB - tabla de contenido:

1. Las pruebas revelan defectos pero no pueden probar su ausencia.
2. La prueba exhaustiva es imposible
3. Las pruebas tempranas ahorran tiempo y dinero
4. Mal funcionamiento efecto bola de nieve
5. Paradoja del pesticida
6. depende del contexto
7. La publicidad de software impecable es un no-go
8. Resumen

Las pruebas revelan defectos pero no pueden probar su ausencia.

Las pruebas aumentan la probabilidad de encontrar errores, lo que a su vez facilita las posibilidades de corregirlos. Sin embargo, no puede garantizar completamente que el software esté libre de todos los defectos, incluso si la gran mayoría se detecta y repara. Debido a la incapacidad de crear un software impecable, muchos consideran que el proceso es negativo por diseño, ya que nunca obtendrá un resultado positivo y siempre encontrará algo de "suciedad" en los programas.

La prueba exhaustiva es imposible

La regla empírica anterior establece que la detección de todos los fallos de funcionamiento del software es inútil. Sin embargo, eso no se aplica a los programas cortos simples. Esto, a su vez, indica que existe la posibilidad de ver todas las combinaciones de entradas y condiciones previas para probar algunos programas por completo. Al evaluar un software sofisticado, incluso la mejor IA no puede ejecutar todas las medidas necesarias, y mucho menos los probadores manuales. Los evaluadores automatizados ejecutarán las aplicaciones de manera más eficiente y precisa, pero aún no pueden garantizar un rendimiento impecable. Para hacerlo, debe embarcarse en tareas adicionales como la priorización, el análisis de riesgos, así como encontrar y ejecutar otras técnicas de prueba.

Las pruebas tempranas ahorran tiempo y dinero

Muchos profesionales también llaman a este principio "desplazamiento a la izquierda". Cuanto antes detecte los defectos, más fácilmente podrá solucionarlos, por lo que las pruebas estáticas y dinámicas deben comenzar lo antes posible. En una palabra:

• Pruebas estáticas : evaluar el producto sin ejecutar el código.
• Pruebas dinámicas : evaluación del código de un módulo o sistema durante su desempeño.

La detección de defectos en las primeras fases de implementación facilita el diagnóstico posterior. Pero cuando interactúan dos áreas de software, la corrección de defectos se vuelve problemática debido a la incapacidad de identificar la que tiene el error. En tales casos, se necesita más tiempo, esfuerzo y mano de obra para abordarlos. Con todo, es la respuesta rápida a los obstáculos de la superficie lo que puede evitar que las grietas se multipliquen.

Mal funcionamiento efecto bola de nieve

La mayoría de las fallas tienden a agruparse en la mayoría de los módulos críticos, por lo que su examen en profundidad revela y elimina suficientemente la mayoría. Estos grupos se convierten en el foco principal de la ejecución del análisis de riesgos para trazar y establecer la conducta futura de las acciones. La mayoría de las fallas surgen después de seguir los caminos que toman los usuarios, pero en estos casos, el conocimiento por sí solo no hace que los módulos sean impecables.

El principio de Pareto, dice que el 80% de los resultados se originan por sólo el 20% de las causas. En otras palabras, el 80% de los errores existen en el 20% de los módulos. Si encuentra numerosos fallos de funcionamiento en un módulo, siga investigando, ya que estarán allí.

Paradoja del pesticida

Ejecutar las mismas pruebas repetidamente puede fallar porque pueden haber sido diseñadas incorrectamente en primer lugar y nunca serán efectivas. Debe modificar y actualizar las pruebas para aumentar la posibilidad de encontrar nuevas fallas en el software.

Crear un sistema de diagnóstico completamente nuevo tampoco funcionará. Seguir las combinaciones anteriores puede detener el proceso de evaluación en el mismo nivel. Este principio se denomina 'paradoja de los pesticidas' porque los pesticidas que controlan las plagas también pierden efectividad después de una determinada cantidad de uso.

depende del contexto

La forma de ejecutar las pruebas depende de los sujetos examinados. Por lo tanto, probar un programa de contabilidad, un videojuego o una aplicación de redes sociales varía sustancialmente. También depende de la situación, por ejemplo, un análisis centrado en la practicidad de una aplicación, como comprobar su atractivo para los usuarios, la facilidad de uso, la capa visual, etc. también difiere de aquellas evaluaciones dirigidas a los atributos funcionales del programa, por ejemplo, el rendimiento cálculos correctos.

La publicidad de software impecable es un no-go

La aplicación de varios tipos de herramientas de diagnóstico no puede garantizar aplicaciones precisas. Muchos de los que afirman y anuncian sus aplicaciones como tales están equivocados, pero probablemente solo sea por los esfuerzos de marketing que hacen la afirmación. Puede ejecutar múltiples pruebas manuales y automatizadas para aumentar la probabilidad de descubrir y corregir tantos errores como sea posible, pero aun así, no hay garantía de un rendimiento perfecto. En algunos casos, los obstáculos se relacionan con el software operativo, por ejemplo, es posible que el programa no cumpla con todas las expectativas del usuario.

Principios de prueba de ISTQB: resumen

Así es como ISTQB, en un nivel básico, presenta siete principios de prueba ISTQB que debe seguir un probador de software. Primero, indican la inviabilidad del diagnóstico completo del software, por lo que es crucial, entre otras cosas, modificar las pruebas, así como realizar una búsqueda exhaustiva en los módulos clave. Estas acciones mejoran la búsqueda y eliminación de la mayoría de los defectos, disminuyendo la probabilidad de fallas en el futuro.

¿Qué es la prueba de software? ¡Ahora sabes la respuesta! ¡Mira nuestras otras series sobre Python y Javascript!

Si le gusta nuestro contenido, únase a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Robert Whitney

Experto en JavaScript e instructor que entrena a los departamentos de TI. Su objetivo principal es aumentar la productividad del equipo enseñando a otros cómo cooperar de manera efectiva mientras codifican.

Ver todas las publicaciones

Primeros pasos en las pruebas de software:

1. ¿Qué es la prueba de software?
2. 1 gran verdad sobre los errores de software
3. Siete principios clave de prueba ISTQB
4. 6 fases de STLC
5. Prueba vs. depuración
6. Verificación y validación en el proceso de pruebas de software