Olfato e intuición amplificada

Posted on 5 agosto 2008. Filed under: Calidad del Software, Procesos Ágile, Testing, Trabajo en Equipo | Etiquetas: , , , |

Fortalezas y debilidades de las Pruebas Exploratorias

Muchas veces se habla del Testing Exploratorio sin tener una verdadera conciencia de lo que se trata ni del modo en que se debe ejecutar. Los detractores de este tipo de verificaciones, opinan mostrando la práctica como informal, sin procedimiento y fuera de los cánones del Testing y por transferencia intentan establecer que no existe Calidad del Software.

Les doy la razón únicamente en que este tipo de pruebas del software no están en los cánones del Testing, puesto a que es una actividad extremadamente compleja de interpretar y realizar si no se tienen en cuenta los elementos de soporte que finalmente avalan la práctica.

Las pruebas exploratorias muestran sus resultados y garantías en base a los resultados y garantías de prácticas previas y del mismo modo, fallan sus resultados y garantías cuando prácticas que le anteceden son ejecutadas en forma endeble o imprecisa.

Para este tipo de verificaciones y validaciones son necesarios ciertos elementos del lado del QA y Testing:

  • Conciencia de que todo lo que se verifica está orientado a la detección de problemas que impidan satisfacer requisitos funcionales y no funcionales
  • Capacidad de análisis elevado para entendimiento cabal de requisitos en base a la observación y análisis de la evolución de los mismos
  • Abstracción para la elaboración de circuitos de pruebas de verificación y validación
  • Capacidad de ampliación de caminos de pruebas para mejora espontánea de la cobertura
  • Conocimiento y dominio del negocio al que pertenece el problema
  • Alta proactividad y gran capacidad comunicacional para generar ambiente colaborativo
  • Conocimiento cabal del proceso que rige para reconocer las fallas que se manifiestan en los resultados no deseados
  • Gran capacidad para definir y variar las estrategias, tácticas y técnicas de validación y verificación
  • Olfato e intuición amplificada

Este es un formato simple de ideación de prueba exploratoria y aquí les muestro un breve ejemplo:

“Se hizo el planteo de ir cambiando fechas del servidor para que las Presentaciones venzan con la regularidad que precisamos y los avisos visuales se evidencien en cada vencimiento, según la parametrización establecida para cada Etapa del Circuito de Aprobación. Con esto tendremos la cobertura necesaria para verificar las funcionalidades relacionadas con el establecimiento de fechas luego de haberse aceptado una Presentación para que ingrese al Circuito de Aprobaciones.
Será necesario realizar verificaciones también un paso adelante, es decir desde el Circuito de Aprobaciones, para lo cual preparamos el siguiente juego de datos sencillos:
Se prepararon a nivel de juego de datos para Testing, 16 presentaciones vencidas donde existe al menos una presentación vencida para cada Etapa.
Se definen seis (6) usuario donde cinco (5) tienen el rol de Aprobador de Circuito, más su rol principal y un (1) usuario tiene el rol de Administrador.
Se define una cuenta de Test para cada aprobador y se la configura con alias en ThunderBird.
Cada vez que se cierra una etapa se notifica vía mailing tanto al Administrador como al Aprobador de cada etapa del circuito.
Cuando una Presentación se encuentre vencida en la Etapa Actual, según los parámetros definidos para la etapa, se notificará vía mailing al Administrador y al Aprobador”

Hay que considerar que para el éxito de esta verificación se utilizarán las definiciones que se hacen a nivel de requerimiento (por eso es importante la completitud y correctitud del Req.) para verificar mediante pruebas exploratorias (sin script), que el sistema esté haciendo lo que se solicita y se ampliará el grafo de pruebas según criterio de SQA, para verificar que el sistema no haga lo que no debe hacer.
Es decir que básicamente los requerimientos definidos son los Scripts de ejecución y también evidencia de funcionalidad.

Según este tipo de proceso de verificación y validación, las evidencias de funcionamiento se deben dar en la fase de construcción e integración, más no pretender que las pruebas funcionales indiquen que el sistema funciona correctamente, sino entender que el concepto es la detección de fallos y errores.

Liked it here?
Why not try sites on the blogroll...

A %d blogueros les gusta esto: