Testing Exploratorio – Cuando faltan elementos en las evidencias de resolución

Las verificaciones funcionales tuvieron una tónica un poco desagradable el día de hoy, ya que para la ejecución de las pruebas de sistemas requirieron mucho esfuerzo en el levantamiento de elementos que me permitan formar un concepto de cómo realizar el Testing y que resultados esperar.

La mayoría de las verificaciones no pudieron ser ejecutados por aspectos relacionados a elementos faltantes del despliegue, los cuales no son mencionados en ninguna de las evidencias de resolución. Sin embargo, al revisar la evidencia de cada una de las resoluciones encuentro que tales evidencias no tienen elementos que permitan formar con cierta normalidad los conceptos de Testing Funcional.

De esta manera solo se consigue dilatar los tiempos de Testing, se tienen más rechazos de soluciones (inclusive por desentendimiento), no cumplir con la entrega planificada y el re trabajo que implica en todas las áreas involucradas. Ni hablar si se aprueba un resolución y luego la rechazan en Despliegue al detectarla como fallida.

Creo que las evidencias tienen que tener el foco funcional que hace falta, principalmente por que en situaciones como la de hoy, se hace “testing forzado”, sin planificación, sin anticipación.
Las evidencias no deberían simplemente tener las sentencias SQL que se usan o los valores booleanos que adoptan las variables o los nombres de formularios ocultos, entre otros elementos de bajo nivel, que muchas veces es interpretable y sirve solo en el contexto adecuado, pero fuera de el no es de utilidad.

Tal como mencioné varias veces, estoy convencido que para ciertos artefactos, no es necesario intentar recurrir a prácticas de Pruebas Unitarias sin el framework adecuado, pero se pueden plantear juegos de pruebas de caja negra, en la cual es posible definir aspectos relacionado a las interfaces, totalizadores, los comandos de acción, etc.

Dicho de otra manera, las pruebas del desarrollador tal vez deberían declarar el juego mínimo de pruebas de funcionales (caja negra) que indiquen un estado previo, el proceso ejecutado y el estado posterior del juego de datos.

O en su defecto hay que darnos el tiempo para que luego de notificada la resolución, se asuma “un tiempo de estudio” para generar los conceptos de pruebas funcionales, pero así no se garantiza nada.

Por otro lado, el día de hoy se vio una debilidad en el traspaso al darnos cuenta que falta la especificación de la corrida de agentes y también el momento de la corrida, lo cual parece ser estratégico para que no se presenten los fallos que se presentaron en Testing.

En definitiva me doy cuenta de la debilidad que hay en los traspasos y posiblemente tenga que ver con la estrategia que se deba plantear antes de iniciar las resoluciones.

A mi me sigue costando enterarme con anticipación de que bloques serán entregados y según la experiencia que tengo en nuestra interacción cotidiana (Desarrollo – Testing / Testing – Desarrollo), aún las correcciones más sencillas nos cuesta un esfuerzo muy importante tanto a Desarrollo como a Testing y las verificaciones se demoran de manera no convenientemente, como es lógico.

Si estos elementos se siguen presentando con tanta dificultad, las estimaciones del esfuerzo de Testing van a quedar subestimadas por la necesidad de estudio de los Testers para cada uno de los artefactos de software, siempre que se efectúen pruebas exploratorias.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s