Las armas más poderosas del tester

El trabajo de pruebas es de los más sujetos a las circunstancias de otros, dentro del desarrollo de software. Tenemos que lidiar habitualmente con:

• Requisitos completos o incompletos
• Documentación existente (completa o no) e inexistente
• Todos los retrasos acumulados en fases previas
• Entregas parciales o totales
• Entregas de software a mitad de pruebas
• Entornos configurados o no
• Datos cargados o no, o parcialmente
• Presión del tipo prueba esto ahora; prueba otra vez, prueba de nuevo; prueba que ahora sí...

Y a todo esto, hay que añadir que los planes de prueba son cosas que nadie lee, por lo que se pretende que "todo" esté probado en una fecha inamovible independientemente los retrasos en fases anteriores.

Ante esta situación complicada, el tester tiene 2 armas definitivas en su mano:

• El registro
• El informe de resultado de las pruebas

El registro, el correo electrónico o cualquier otra forma de comunicación escrita es absolutamente esencial. Registrar. Esa es la palabra clave.

     - Oye Juan, que he modificado este código. Lo subo a pre, ¿vale?

     - Sí, mándame un mail con la versión del código y las incidencias que corrige y yo hago la petición.

     - Pedro, ahora que te veo tomando un café, que al final este requisito no era exactamente así, sino que es asá. Pruébalo.

     - Sin problema, pero mira, lo más probable es que no me acuerde cuando vuelva a mi sitio. Por favor, mándame el cambio por mail.

     - Hola Andrés, ¿que tal? Anda, deja de probar eso y ponte con esto otro que es más importante.

     - Claro. Anda, mándame un mail para dejarlo registrado.

Dejarlo registrado. Así podríamos poner todos montones ejemplos en los cuales se intenta ningunear el trabajo de pruebas. Dejarlo registrado es fundamental, porque al final hay una tendencia muy grande a buscar culpables, especialmente cuando las cosas no salen bien, cuando hay retrasos y cuando hay defectos con un software teóricamente probado.

Registrar; registrar y registrar.

He puesto algún ejemplo de comunicación entre equipos. Puedo poner ejemplos clásicos de registro. A este registro algunos lo llaman bitácora, otros log de actividad, otros registro histórico, etc. Tenga el nombre que tenga, es fundamental que se registren situaciones como:

     - Las pruebas comenzaron 3 días tarde por retraso en la entrega [código de entrega]

     - Hoy día [día] hubo un defecto bloqueante que impidió el trabajo de pruebas durante 8 horas

     - Hoy día [día] el jefe de proyecto solicitó reducción de alcance en las pruebas. Adjunto correo.

     - Hoy día [día] se entregó una nueva versión de código con el ciclo de pruebas a medias. Comenzamos un nuevo ciclo.

     - Hoy he detectado un cambio de versión de tal código que no ha sido ni formalmente solicitado ni formalmente desplegado. Esto me obliga a repetir tal grupo de pruebas. Adjunto evidencia.

Registrar da gran información sobre el proceso de pruebas. Registrar es un escudo de defensa contra la búsqueda de cabezas de turco que, lamentablemente, siguen siendo habituales. Registrar permite compartir el conocimiento. Registrar permite encontrar soluciones a problemas recurrentes.

El informe de resultado de las pruebas es la otra herramienta poderosa que tiene el tester. El informe de resultado de pruebas es algo más que los KO y OK resultantes de ejecutar los casos de prueba. El informe de resultados es el semáforo que da luz verde al despliegue en producción, o que lo impide.

Los testers o más bien sus responsables, muchas veces no asumen la responsabilidad de decir "Software no certificado". Es como decir "Agua no potable. No apta para su consumo". Para mi este hecho es fundamental. Puedes poner el software en producción porque te garantizo que en este contexto no va a haber problemas; o bien te recomiendo que no lo pongas en producción porque te confirmo que tiene este, este, y este otro problema que hace que tales procesos o casos de uso no puedan ser ejecutados.

Mayor es la responsabilidad de decir "Certificado", que la de decir "No certificado", porque certificar un software compromete al equipo que lo ha probado. Esa garantía de calidad es responsabilidad del equipo de pruebas. El informe de resultado de las pruebas debe recoger este hecho, y debe usarse con coherencia y con el conocimiento de lo que implica.

Cuando certificar o rechazar un software se usa con responsabilidad dentro de una organización, las áreas de negocio y los jefes de proyecto acaban buscando esa única línea en el informe de resultados de las pruebas; y eso da mucho poder al equipo de pruebas.

Registra y sé asertivo. Ha pasado esto y esto, y el software vale o no vale. Esas son tus mejores armas.