Actualizado el 18/10/2020

icon Facebook icon Twiiter icon RSS icon EMAIL
  1. Portada
  2. >
  3. Opiniones
  4. >
  5. Tester Mindset

Tester Mindset

Escrito por Ariel Cymberknoh el 17/09/2020 a las 12:12:06
1316

(Gerente de Validación y Testeo de Firmware, Intel de Israel)

Autor: Ariel Cymberknoh

Gerente de Validación y Testeo de Firmware, Intel de Israel

 

“Tester Mindset” se suele traducir al castellano como “Mentalidad del Testeador”, una frase que clara y potentemente refleja la postura y actitud del Tester o Ingeniero en QA en  Inglés, pero que pierde parte de su potencial al ser traducida.

 

 

Hoy quisiera referirme a este Tester Mindset y su importancia cuando se refiere a la profesionalidad y calidad del trabajo proveniente de los grupos de Testeo y QA.

 

Como miembro del Comité Técnico de la conferencia anual QATEST, y luego de haber asistido durante años a la conferencia, he tenido la posibilidad de aprender y discutir acerca de esta temática con colegas de diferentes nacionalidades, sectores industriales y empresas

 

 

La vieja realidad a la que estábamos acostumbrados en las décadas de los ’90 y principios de los años 2000, donde veíamos definidas a las organizaciones de Software claramente separadas en sus funciones de Desarrollo y Testeo, se fue transformando: Con la incorporación de técnicas Agile, hemos visto como esta separación se tornó mucho más borrosa y poco clara. Al contrario de lo que los conceptos de Agile/Scrum indican (un equipo donde “todos hacen de todo”), en realidad continuamos viendo equipos Scrum donde parte de sus miembros participan casi con exclusividad en las tareas de desarrollo y la otra parte del equipo en las tareas de testeo.

 

Incluso, dejando de lado la adopción o no de técnicas de Agile, continuamos viendo equipos de desarrollo de Software que contienen en sí algunos miembros dedicados a las tareas de testeo. En algunos casos, disfrazados de ayuda para crear ULTs (Unit Level Testing), en otros casos no y simplemente cumplen funciones de QA y testeo dentro de los equipos de desarrollo.

 

Hace medio año, asumí el cargo de Gerente de Validación y testeo de Software Embebido. El grupo, distribuido en 4 sitios geográficos diferentes, hacía poco que se había independizado como equipo separado del equipo de desarrollo. Si bien me encontraba frente a un grupo de profesionales de diferente antigüedad y experiencia, con alta motivación y determinación de comenzar un nuevo camino de excelencia, en realidad se trataba de un grupo (o mejor dicho, un conjunto de personas individuales) sin estrategia, sin guía, sin identidad.

 

Durante años, nadie pudo (¿Quiso? ¿Supo?) invertir en aumentar el profesionalismo de este importante conjunto de gente que cumplían un rol fundamental dentro de la organización. Un grupo que sabía recibir un documento con Requerimientos y Especificaciones y escribir un plan de testeo (¡incluso automatizado!), pero que no sabía conceptos básicos como pruebas negativas, testeos de nstress y estabilidad, tests de performance, etc. Mas aún. Muchos de ellos nunca habían conocido conceptos como “Exploratory Testing”, “Pair Testing” u otras técnicas comúnmente utilizadas en la industria.

 

Pero lo mas sorprendente fue la total falta de “Tester Mindset”: ¿Tener que pedir permiso al developer para poder abrir un incidente (bug) en el sistema? ¿Poder reclamar la corrección de los documentos de especificaciones porque no describen correctamente los requerimientos del producto? ¿Es correcto detectar un cambio en el código del producto solo porque la última corrida del ciclo de regresión falló (o sería mejor exigir una mejor comunicación por parte de los developers hacia el grupo de testeo)? ¿Es correcto distribuir la última versión del código, aún sin haber sido testeada?

 

Como estas, innumerables otras preguntas existían.

 

Afortunadamente, y como resultado de un arduo trabajo, todas estas actitudes fueron cambiando. Tenemos un largo camino por delante. Pero los primeros resultados ya están a la vista.

 

Para mí, este fue nada más que otro ejemplo que demuestra que, a mi entender, no existe reemplazo a tener equipos de testeo y QA independientes donde sus integrantes (desde los gerentes más experimentados hasta los ingenieros más novatos) respiren este aire único llamado Testing. Es la única forma de asegurarse el máximo profesionalismo y el mejor rendimiento del equipo de testeo.