Los Bugs del Testing en México: Madurez en tiempos de pruebas

En números anteriores de SG, Sandra Berenice Ruiz compartió un interesante artículo sobre las retrospectivas y tendencias sobre testing y nos hacía la invitación de dar pasos firmes hacia los nuevos retos que ya se están presentando en la industria. Sin embargo, nuestro día a día nos hace formularnos la pregunta: ¿realmente estamos impulsando un testing de calidad?

No se trata solamente de hacer presencia, certificar gente o abrirnos camino. Se trata, incluso, de ser ejemplo a otras áreas en la empresa de que nuestro trabajo es de calidad, y que genera un verdadero valor.

México ha hecho un muy buen esfuerzo al ser el 2º país en Latinoamérica con mayor número de certificados por el ISTQB en el nivel de fundamentos, lo que nos deja ver el crecimiento y especialización de nuestra área. En este crecimiento se vuelve fundamental que los que estamos involucrados seamos evangelistas y no solo creyentes. El reto ya no es poder aterrizar al testing, es ser autocríticos y perfeccionar lo que ahora realizamos para lograr mejores resultados. Sobre todo, sabiendo que nuestro país ha dado pasos importantes en materia de competitividad TI en el mundo.

Es con este afán que expongo a continuación cuatro rasgos negativos que en general he detectado en organizaciones de software en nuestro país y que considero que debemos corregir para poder mejorar el nivel e impacto del testing.

No se reconoce la especialización del perfil de tester

Desafortunadamente, en México todavía predomina la percepción de que para dedicarse al testing no se requieren conocimientos y aptitudes específicas y por lo tanto cualquiera puede dedicarse al testing. Muestra de ello es que se siguen solicitando testers sin conocimientos en estándares, mejores prácticas, aptitudes específicas, e incluso sin tener una formación en TI. Esto es señal de una baja madurez de esta práctica en nuestra región.

Formación empírica

Al trabajar con distintos equipos de testing a través de los años, con frecuencia me he encontrado con que los profesionistas con mayor experiencia siguen procesos y técnicas rudimentarias que están poco dispuestos a dejar, mientras que los integrantes jóvenes tienen una formación poco robusta (consecuencia de lo que comento en el punto anterior). Básicamente, el grueso de nuestros testers aprendió a trabajar en base a sentido común y sus necesidades específicas, es decir que solamente cuentan con una formación empírica. Entre otras cosas, esto provoca discrepancia en la forma de trabajar entre distintos testers. Un ejemplo de ello es la gran diferencia que suele existir al diseñar casos de prueba, lo que provoca problemas de entendimiento; genera retrabajo, falsas estimaciones, y retrasos en la ejecución.

Matando a la hormiga, no al hormiguero

Los perfiles formados en testing “a prueba y error”, la realización de tareas rutinarias y una cultura de corregir en lugar de prevenir repercuten en nuestros procesos actuales de calidad. Seguimos con la idea de que el testing consiste principalmente en detectar defectos de software, creando así una mentalidad de que la detección de defectos es el fin, cuando en realidad solo es el medio para llegar a la prevención de defectos.

Organizaciones y procesos no diseñados para testing

En organizaciones poco maduras, los procesos y estructura no tienen considerados a los equipos y actividades de testing, por lo que se terminan incorporando “con calzador” y con resultados de poco impacto. Toda organización debe preguntarse qué es lo que se pretende al incorporar a un ingeniero de pruebas o a todo un equipo, y cómo van a soportar los esfuerzos de dicho equipo.

Algunas de las preguntas que pueden surgir como resultado de este ejercicio son:

• ¿Mi proceso de desarrollo tiene la flexibilidad para integrar un equipo de pruebas?

• ¿Cuánto presupuesto vamos a disponer para herramientas de testing?

• ¿Qué actividades harán los testers? ¿Aporta calidad que los testers también modifiquen código, realicen análisis, definan requerimientos, etc.?

• ¿Qué aspectos probaremos y qué prioridad daremos a cada uno? ¿funcionalidad?, ¿desempeño?, ¿seguridad?