Estoy peleado con la visión simplista que cualquiera puede probar una aplicación, pues no le hace justicia a nuestra profesión tan llena de retos. Tampoco estoy de acuerdo con aquellos testers que se suben a un pedestal ( o se montan en su macho) y se creen dueños de la calidad de un producto, con super poderes para bloquear la salida a producción de un software que tiene baja calidad. Y mucho menos comulgo con aquellos que dicen requerir especificaciones/requerimientos exhaustivos para probar un software, so pena de negarse a empezar su trabajo.
A lo largo de mi carrera he oído con cierta frecuencia que "Cualquiera puede hacer testing (manual), al cabo es bien fácil, nomás sigues el caso de prueba", o "No es necesario probar la aplicación". Y aún, recientemente, se requirió la colaboración de 5 programadores para un proyecto de testing que ya iba atrasado: La cara que pusieron lo dijo todo, pero aún así, no se hicieron esperar sus peroratas de "que flojera, todavía fuera automatizado" y cosas por el estilo.
Lamento decirles, señores, pero ese es un sólo una técnica de testing manual: el basado en Casos de Prueba o scripts. Es muy 'cuadrado': requiere de mucho esfuerzo pero poca o nula creatividad. El tester rara vez necesita salirse del guión (aunque éste mismo lo haya escrito), y tiende a no percibir otras fallas obvias, ya que está enfocado a un resultado esperado a la vez. Es bastante miope.
Entre otras bellezas, (los testers) nos encargamos de maximizar el conteo de defectos, ayudamos a los Managers a tomar decisiones de cuando liberar o no un software a producción, a minimizar los costos de soporte técnico, evaluar si el producto está conforme a especificaciones y leyes regulatorias, a encontrar flujos de la aplicación libres de errores, evaluar la calidad y verificar si el producto está implementado correctamente. Para ello nos valemos de todo un catálogo de herramientas disponibles o desarrollamos las propias a la medida de las necesidades del Cliente. Si, leyó usted bien. Desarrollamos. No todos, mas al parecer la tendencia es que los testers programemos.
Hay por otro lado, los testers que se creen la última línea de defensa. Son lo que Lis Hendrickson llamó "guardianes" de la calidad, quienes alegan ser a los únicos que les importa. Esa actitud resulta en dos efectos negativos, a saber: logra excluir los esfuerzos del resto del equipo, frustrando a todos aquellos que se esfuerzan por lograr un producto de mayor calidad; es también una lamentable excusa para aquellos miembros del equipo que se creen muy ocupados para pensar en la calidad, al fin los testers ya tomaron la estafeta, enemistándose con medio mundo en el proceso. Aún más, al asumir el poder de veto sobre un producto, terminan tomándose atribuciones que no le van, porque debería ser el project manager quien sopesa riesgos y conflictos. Nadie más.
En ausencia de una especificación clara, o dada con antelación, es que utilizamos nuestras habilidades investigativas, en combinación de técnicas como pruebas exploratorias. Sobre todo en contextos de desarrollo ágil, donde el grupo de desarrollo prefiere no tener una especificación detallada, ni siquiera documentar de manera excesiva potenciales cambios. Esto implica el reto de crear pruebas basadas en cualquier información que llegue a nuestras manos, empapándonos del dominio de la aplicación. Como proveedores de un proyecto, no podemos rehusarnos a trabajar. Si acaso a pedir más aclaraciones; a utilizar técnicas de prueba en ambientes dinámicos; a estar en más comunicación con el cliente y con desarrollo, dándoles retroalimentación sobre el software en desarrollo.
Estas tres o cuatro mentiras sobre el rol del tester son las más frecuentes en mi práctica profesional, y las que más me causan comezón cada vez que las escucho. Estamos tan acostumbrados a proyectos con CMMi y sus mejores prácticas que cuando nos cae un proyecto poco documentado a la bandeja, tendemos a sentirnos desamparados. Es mi sincera opinión que debemos empezar a basar nuestras pruebas en cualquier dato podamos obtener.
