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.
Comentarios
Publicar un comentario