Vuelve el Tester Funcional ¿o es que nunca se ha marchado?


Vuelve el tester funcional.

Efectivamente, has leído bien. En la época de la automatización, de los RPA, del DevOps, lo digo y lo reafirmo: el testing funcional ha vuelto con fuerza.

Puedo deciros, sin miedo a equivocarme, que jamás se fue. Éramos pocos los que seguíamos haciendo ese tipo de trabajo, pero ahora, es mas necesario que nunca.

Llevo meses viéndolo una y otras veces, empresas con unos procesos automáticos brutales, elaborados minuciosamente y con unas baterías dignas de los grandes, pero...con agujeros en producción. Errores graves y críticos que se cuelan y hacen que todo el esfuerzo invertido se quede en nada, además de que el cliente tenga una percepción negativa.

Os cuento lo que sucede.

Ahora todo es automatizar, hacer TDD, testing integrado en DevOps, incluso procesos completos con RPAs que se olvidan de las personas y manejan complejos proyectos de una manera ágil y especialmente rápida.

Viendo lo que se ha avanzado y lo que tienen algunas empresas montado, es digno de estudio y de, en algunos casos, hacerlos estándares y exportables de una empresa a otra.

Ahora bien, ¿que está sucediendo si estos procesos automáticos dejan estos agujeros en los productos que se elevan hasta el entorno de producción?

Pues, es tan sencillo como que la capa experta funcional se ha olvidado y no se cubren todos los caminos y se escapan. Mi experiencia, durante todo este tiempo, es que antes de hacer estos proyectos automáticos es que hay que hacer un análisis o un diagnóstico inicial, unido a un proyecto que realice una primera capa funcional en la que basarse todo.

Con este primer análisis, se realiza una batería completa, una documentación funcional y se crea la base total de lo que se tiene que automatizar con total garantía.

Además, aunque queramos realizar automatización de primeras en un proyecto, siempre, en la primera etapa, hay que apoyarse en, al menos, unas sesiones de pruebas exploratorias manuales que permitan cubrir, bajo el punto de vista de una persona, que todo está funcionando como debe de funcionar.

La realidad está ahí presente y no es la primera ni la segunda vez que encontramos esta situación y nos piden ayuda para averiguar que sucede con sus productos.

Volviendo a los orígenes.

La época de la automatización está presente y os digo que una persona dedicada a la calidad debe de saberla, casi por encima de cualquier otra cosa, pero también debe de aplicarse en formación procedimental, funcional y metodológica, ya que, si no, toda la fuerza que podamos aportar, acaba diluyéndose con estas situaciones inoportunas y engorrosas.

Ahora bien, nuestra intención no es decir que se tienen que hacer proyectos manuales, que la automatización es el demonio, ni nada por el estilo, si no que, es tan sencillo como que no se debe de olvidar el origen del testing y el conocimiento funcional o documental que hay que realizar, antes de nada.

El tester, debe de ser una persona metódica y concienzuda y muy enfocada a documentar todo, sobre todo, los casos de prueba (ya sea a nivel de código o en un documento). Estos casos de prueba deben de ser estudiados y extraídos de un documento funcional o requisitos que han sido entregados previamente.

Aquí, es donde se suele cojear, ya que en muchas ocasiones ni siquiera las personas que hacen esta batería de pruebas son tester, si no que son desarrolladores preocupados de la calidad o involucrados en equipos multidisciplinares.

Estos equipos, funcionan realmente bien en muchas ocasiones, pero como siempre se dice, no todo el mundo puede saber de todo y ser experto de ello, por lo tanto, una persona dedicada a una sola pata del amplio abanico del mundo tecnológico o informático, siempre aportará mucho más valor que una persona enfocada en varias cosas, que no puede llegar a ser experto de todo.

Desde aquí, hacemos un llamamiento a no olvidar ese conocimiento y labor funcional que puede salvarnos de más de un disgusto en nuestros proyectos.
Siguiente Publicación

Comentarios