1. La prueba muestra la presencia de defectos, no su ausencia.
Explicación: La prueba de software no puede garantizar la ausencia total de defectos, ya que es imposible probar exhaustivamente todas las combinaciones y situaciones posibles, es decir un 100%. En cambio, el objetivo de las pruebas es encontrar la presencia de defectos para que puedan ser corregidos y mejorados. Cuanto más conocimiento y experiencia tengas en el área de negocio que estés testeando, mayor será la probabilidad de detección de defectos.
Ejemplo 1: Un equipo de pruebas realiza pruebas exhaustivas en un módulo de un sistema de gestión de inventario. A pesar de haber ejecutado una amplia variedad de casos de prueba, se descubre un defecto en la generación de informes que no se había detectado previamente. Esto demuestra que, incluso con pruebas exhaustivas, siempre existe la posibilidad de que aparezcan defectos no detectados. ¿Te pusiste a pensar que para estos casos la ayuda/colaboración de parte del usuario final es importante?
Ejemplo 2: Durante las pruebas de una aplicación móvil, se descubre un error en la funcionalidad de inicio de sesión. Aunque el equipo de pruebas había ejecutado múltiples escenarios de prueba, el defecto solo se manifestó en un caso específico donde se utilizaba un dispositivo con un sistema operativo menos común. Esto resalta que las pruebas no pueden garantizar la ausencia completa de defectos. Para este caso habrá que considerar tipos de dispositivos, versiones de sistemas operativos, pero por sobre todas las cosas, comunicarse con el usuario final para conocer su opinión y parecer. No lo olvides.
2. La prueba exhaustiva es imposible.
Explicación: Es imposible probar exhaustivamente un sistema de software en todas sus combinaciones posibles de entradas y condiciones. Los recursos y el tiempo disponibles son limitados, lo que impide una cobertura completa. En cambio, se deben utilizar técnicas de prueba efectivas y centrarse en las áreas críticas del sistema. Recuerda que debes seguir lo definido en los criterios de aceptación de la historia de usuario que se esté desarrollando y que ha dado lugar a la generación del o de los diferentes escenarios a ser testeados.
Ejemplo 1: Una aplicación de comercio electrónico tiene una amplia gama de productos, opciones de envío y métodos de pago. Probar exhaustivamente cada combinación posible de productos, opciones de envío y métodos de pago sería prácticamente imposible debido a la gran cantidad de posibilidades. En su lugar, se aplica una estrategia de prueba basada en la priorización de características y la cobertura de los casos de prueba más relevantes y críticos. Insisto, para la priorización como para otras actividades, te recomiendo un espacio de diálogo con el usuario final para conocer su opinión y parecer.
Ejemplo 2: En un proyecto de desarrollo de software con plazos ajustados, el equipo de pruebas no dispone de suficiente tiempo para ejecutar pruebas exhaustivas en todas las funcionalidades. En lugar de eso, se realiza un análisis de riesgos y se priorizan las pruebas en las áreas críticas del sistema o en las que se han identificado mayores riesgos potenciales. Para este caso se menciona el término riesgos y aquí hay todo un campo de acción y que da lugar a la práctica del diseño de casos de prueba bajo riesgos.
3. La prueba temprana ahorra tiempo y dinero.
Explicación: Realizar pruebas desde las etapas iniciales del desarrollo permite detectar y corregir defectos antes de que se propaguen y se vuelvan más costosos y difíciles de solucionar. La detección temprana de errores ayuda a evitar retrasos y costos adicionales en etapas posteriores del proyecto. Aplicar pruebas tempranas durante el sprint es muy necesario y hasta sano ya que se puede partir de la historia de usuario.
Ejemplo 1: En un proyecto de desarrollo de software, se realiza una revisión de diseño y se identifican posibles problemas de usabilidad y flujo de la interfaz de usuario. Estos problemas se corrigen rápidamente antes de la implementación y la etapa de pruebas, lo que evita costos adicionales y retrabajos en etapas posteriores. Recuerda que cuando se menciona la palabra ‘usabilidad’ estamos involucrando al usuario final.
Ejemplo 2: Durante el desarrollo de un sistema de reserva de vuelos, se realiza una prueba de concepto temprana para validar la integración de diferentes componentes del sistema. Se descubre un problema de comunicación entre el sistema de reservas y el sistema de pagos, lo que permite abordar el problema a tiempo y evitar mayores complicaciones durante las pruebas finales y la puesta en producción.
4. Los defectos se agrupan.
Explicación: Los defectos suelen agruparse en áreas o módulos específicos del software. Esto significa que al encontrar un defecto en una parte del sistema, es probable que existan otros problemas relacionados en la misma área. La identificación de patrones de defectos puede ayudar a optimizar el proceso de prueba y a enfocar los esfuerzos en áreas problemáticas. Para este caso recomiendo que tengas muy presente la práctica de la prueba de regresión ya que la misma puede ayudarte y mucho puesto que no debemos olvidarnos del concepto de trazabilidad.
Ejemplo 1: Durante las pruebas de un sistema de gestión de contenido, se detectan varios defectos relacionados con la generación de informes y la exportación de datos. Al analizar los informes de errores, se identifica que estos problemas están relacionados con una actualización reciente en el componente de generación de informes. Esto permite a los testers enfocar sus esfuerzos en esta área específica y descubrir y corregir más defectos relacionados.
Ejemplo 2: En un sistema de reserva de hoteles, se encuentra un defecto que impide la selección adecuada de habitaciones en ciertas fechas. Al investigar más a fondo, se descubre que el problema está relacionado con la interacción entre el módulo de reserva y el sistema de gestión de inventario. Esta agrupación de defectos ayuda al equipo de pruebas a concentrarse en el área problemática y a colaborar con los desarrolladores para solucionar los problemas subyacentes.
5. Cuidado con la paradoja del pesticida.
Explicación: La repetición constante de las mismas pruebas puede disminuir la efectividad de la detección de defectos. Al igual que los pesticidas, si se utilizan repetidamente, los defectos «resistentes» pueden pasar desapercibidos. Es necesario actualizar y diversificar las técnicas y los casos de prueba para detectar una variedad más amplia de defectos.
Ejemplo 1: En un sistema de gestión de inventario, los testers utilizan las mismas pruebas de regresión en cada versión del software. A pesar de ejecutar estas pruebas repetidamente, se descubre que algunos defectos relacionados con las actualizaciones más recientes pasaron desapercibidos. Para evitar la paradoja del pesticida, el equipo de pruebas revisa y actualiza las pruebas de regresión y agrega nuevos escenarios para cubrir las áreas modificadas.
Ejemplo 2: Durante las pruebas de rendimiento de una aplicación web, el equipo de pruebas utiliza una carga constante y repetitiva para evaluar el rendimiento. Sin embargo, se descubre que ciertos patrones de uso específicos y escenarios de carga no se habían considerado previamente, lo que resulta en un rendimiento deficiente en situaciones reales. Para superar la paradoja del pesticida, se diversifican los casos de prueba de rendimiento y se incorporan diferentes perfiles de carga que reflejen el comportamiento real de los usuarios.
6. La prueba depende del contexto.
Explicación: La estrategia y el enfoque de prueba deben adaptarse al contexto del proyecto, incluyendo los requisitos, la complejidad, el dominio del negocio y las restricciones. No existe una única solución o enfoque de prueba que se ajuste a todos los proyectos, y es importante comprender y adaptarse al contexto específico.
Ejemplo 1: Un equipo de pruebas trabaja en un proyecto de desarrollo ágil de una aplicación móvil de banca en línea. Dado el entorno de desarrollo rápido y los cambios frecuentes en los requisitos, se utiliza un enfoque de prueba continuo y se enfoca en la integración y las pruebas de aceptación automatizadas. Esto permite una rápida validación y retroalimentación continua en el contexto de un proyecto ágil.
Ejemplo 2: Un sistema de control de tráfico aéreo tiene requisitos de seguridad y confiabilidad muy estrictos. Debido a la criticidad y la complejidad del sistema, el enfoque de prueba se centra en pruebas de robustez, pruebas de carga y pruebas de estrés para garantizar que el sistema funcione correctamente en situaciones extremas y bajo una carga significativa.
7. La ausencia de errores es una falacia.
Explicación: La prueba exhaustiva no puede demostrar que un sistema esté libre de defectos, ya que siempre existe la posibilidad de que existan defectos no descubiertos. La ausencia de errores no puede ser garantizada y no debe asumirse como un indicador absoluto de calidad.
Ejemplo 1: Un equipo de pruebas lleva a cabo una serie de pruebas rigurosas en un sistema de gestión de recursos humanos y no encuentra ningún defecto. Sin embargo, después de la implementación en producción, se descubre un defecto crítico que afecta a la generación de nóminas. Esto destaca que incluso si no se encuentran errores durante las pruebas, no se puede asegurar la ausencia total de defectos.
Ejemplo 2: Durante las pruebas de una aplicación móvil de seguimiento de fitness, el equipo de pruebas no encuentra errores significativos y el sistema funciona correctamente en todas las pruebas realizadas. Sin embargo, después del lanzamiento, los usuarios informan problemas de sincronización con dispositivos wearables y errores ocasionales en la generación de informes. Esto demuestra que la ausencia de errores durante las pruebas no garantiza una calidad absoluta del software en todos los escenarios de uso.
Referencia
Programa de Estudios ISTQB CTFL v2018. 1.3. Siete Principios de la Prueba.
