Retomemos los 7 principios del Testing

Sofka Blog
Por Martha Rodas
Comparte

Los que estamos día a día en el aseguramiento de la calidad (QA) de software alguna vez nos hemos preguntado ¿qué lineamientos o reglas nos permitirían ser más asertivos en nuestra profesión?

Y también sobre cada uno de los métodos específicos que sin duda enriquecen ampliamente nuestras aptitudes y rendimiento y que nos permiten diseñar y ejecutar pruebas de una forma más óptima, realizar pruebas automatizadas y muchas cosas más.

En ese sentido, resulta indispensable contar con una colección de principios esenciales que nos sirven de guía y son de gran utilidad en nuestro afán por realizar nuestro trabajo con seriedad y dedicación.

Ejecución de pruebas demuestra la presencia de defectos

El testing exhaustivo no es posible

Pruebas tempranas

Agrupación de defectos

Paradoja de pesticida

El testing depende del contexto

Falacia de ausencia de incidentes

Es importante resaltar que los principios que ya todos conocemos se generaron puntualmente del resultado de una exhaustiva investigación y no existen porque sí.

  1. Las pruebas muestran la presencia de defectos, no su ausencia… ¿Es posible demostrar, con total certeza, que NO hay defectos en un software? La respuesta es un NO rotundo en mayúsculas.¿Cuántas veces te han reportado bugs extraños encontrados por los usuarios finales del software que ya habías probado? El testing nos permite demostrar la existencia de incidentes en un producto, ten presente de que no se trata de hablar de su ausencia.
  2. Las pruebas exhaustivas no son posibles Probar todas las combinaciones posibles de un sistema NO es factible, excepto para casos muy puntuales o excepcionales. De aquí nace un gran reto en nuestra profesión: al no poder asumir la verificación de todas las combinaciones a probar, asumimos un cierto porcentaje de riesgo, el cual tenemos que garantizar que pueda ser cubierto o mitigado en gran medida desde una muy completa definición de la estrategia de pruebas.
  3. Las pruebas tempranas ahorran tiempo y dinero. … El trabajo de QA debe empezar de manera paralela al inicio del ciclo de vida del desarrollo del software, esto para detectar los defectos en fases tempranas de la construcción del producto ¡Entre más tarde encuentres un defecto más costoso será su arreglo!
  4. Agrupación 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 los errores en los módulos de software restantes. 
  5. La paradoja del pesticida Al igual que el sobre uso de un pesticida, esto sería un conjunto de pruebas que se utilizan repetidamente en el disminuirá en su eficacia. La invitación es a utilizar una variedad de pruebas y técnicas ya que esto expondrá una serie de defectos a través de las diferentes áreas del producto. Antes de cada re-test se debe cambiar el juego de datos de prueba, para tener un mayor abanico de probabilidades de encontrar nuevos o reapertura de defectos.
  6. El testing es totalmente dependiente del contexto Los servicios de testing se adaptan completamente al sistema y entornos que vamos a verificar. 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 validar formas de pago de un crédito puede ser necesariamente más rigurosa que para la realizada en un foro de discusión por ejemplo. 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 la 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 de las pruebas al software fueron los adecuados, se llevan a cabo varias situaciones y los tester deben asumir que el software a la final puede llegar a tener algún (aunque disimulado) error.

Conozcámolos, apliquémoslos, ellos nos van a permitirán ser eficaces en nuestras estrategias de pruebas y veremos la recompensa en la entrega de un producto de la mejor  calidad posible.

Últimos artículos