Realizar pruebas de software precisas y correctas sigue numerosos principios. La Junta Internacional de Cualificaciones de Pruebas de Software distingue siete fundamentales, que vamos a discutir hoy. ¿Curioso por descubrirlo? ¡Lee un artículo sobre los principios clave de pruebas ISTQB!
Principios de pruebas ISTQB – tabla de contenido:
- Las pruebas revelan defectos pero no pueden probar su ausencia
- Las pruebas exhaustivas son imposibles
- Las pruebas tempranas ahorran tiempo y dinero
- Efecto bola de nieve de mal funcionamiento
- Paradoja del pesticida
- Depende del contexto
- Publicitar software impecable es un error
- 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 pueden garantizar completamente que el software esté libre de todos los defectos, incluso si la gran mayoría se detectan y corrigen. Debido a la incapacidad de crear software impecable, muchos consideran el proceso como negativo por diseño, ya que nunca obtendrás un resultado positivo y siempre encontrarás algo de “suciedad” en los programas.
Las pruebas exhaustivas son imposibles
La regla general anterior establece que detectar todas las fallas del software es inútil. Sin embargo, eso no se aplica a programas cortos y simples. Esto, a su vez, indica que hay una posibilidad de ver todas las combinaciones de entradas y precondiciones para probar algunos programas completamente. Al evaluar software sofisticado, incluso la mejor IA no puede ejecutar todas las mediciones necesarias, y mucho menos los testers manuales. Los evaluadores automatizados recorrerán las aplicaciones de manera más eficiente y precisa, pero aún no pueden garantizar un rendimiento impecable. Para hacerlo, debes embarcarte en tareas adicionales como priorizar, 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 detectes los defectos, más fácil podrás corregirlos, por lo que las pruebas estáticas y dinámicas deben comenzar lo antes posible. En resumen:
- Pruebas estáticas – evaluación del producto sin ejecutar el código.
- Pruebas dinámicas – evaluación del código de un módulo o sistema durante su rendimiento
Detectar defectos en las primeras fases de implementación facilita un diagnóstico posterior. Pero cuando dos áreas de software interactúan, enmendar defectos se vuelve problemático debido a la incapacidad de identificar cuál tiene el error. En tales casos, se requiere tiempo, esfuerzo y mano de obra adicionales para abordarlo. En general, es la respuesta rápida a los obstáculos que surgen lo que puede prevenir que las grietas se multipliquen.
Efecto bola de nieve de mal funcionamiento
La mayoría de los fallos tienden a agruparse en los módulos más críticos, por lo que su examen en profundidad revela y elimina suficientemente la mayoría. Estos grupos se convierten en el enfoque principal del análisis de riesgos para mapear y establecer la futura conducta de acciones. La mayoría de los defectos surgen al seguir los caminos que toman los usuarios, pero en estos casos, el conocimiento por sí solo no garantiza que los módulos sean impecables.
El principio de Pareto dice que el 80% de los resultados provienen solo del 20% de las causas. En otras palabras, el 80% de los errores existen en el 20% de los módulos. Si encuentras numerosos fallos en un módulo, sigue 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 demostrarán ser efectivas. Debes modificar y actualizar las pruebas para aumentar la probabilidad de encontrar nuevos fallos en el software.
Crear un sistema completamente nuevo de diagnóstico tampoco funcionará. Seguir las combinaciones anteriores puede detener el proceso de evaluación en el mismo nivel. Este principio se denomina ‘paradoja del pesticida’ porque los pesticidas que controlan plagas también pierden efectividad después de un cierto uso.
Depende del contexto
La forma de ejecutar las pruebas depende de los sujetos examinados. Así, 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 verificar su atractivo para los usuarios, facilidad de uso, capa visual, etc., también difiere de aquellas evaluaciones dirigidas a atributos funcionales del programa, por ejemplo, realizar cálculos correctos.
Publicitar software impecable es un error
Aplicar varios tipos de herramientas de diagnóstico no puede garantizar aplicaciones precisas. Muchos que afirman y publicitan sus aplicaciones como tales están equivocados, aunque probablemente sea solo por los esfuerzos de marketing que hacen la afirmación. Puedes ejecutar múltiples pruebas manuales y automatizadas para aumentar la probabilidad de descubrir y corregir tantos errores como sea posible, pero aún así, no hay garantía de un rendimiento perfecto. En algunos casos, los obstáculos se refieren al software operativo, por ejemplo, el programa puede no cumplir con todas las expectativas del usuario.
Principios de pruebas ISTQB – resumen
Así es como ISTQB, a un nivel básico, presenta siete principios de pruebas ISTQB que un tester de software debe seguir. Primero, indican la imposibilidad de un 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 fallos en el futuro.
¿Qué es la prueba de software? ¡Ahora sabes la respuesta! ¡Consulta nuestras otras series sobre Python y Javascript!
Si te gusta nuestro contenido, únete a nuestra comunidad de abejas ocupadas en Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Robert Whitney
Experto en JavaScript e instructor que capacita a departamentos de TI. Su objetivo principal es aumentar la productividad del equipo enseñando a otros cómo cooperar de manera efectiva mientras programan.