The Dark Knights of Testing

La mayoría de los desarrolladores ven al departamento de QA como un mal necesario con el que tienen que (con)vivir; nada raro pues después de todo, a nadie le gusta que le digan que aquella aplicación a la que le dedicó horas, puede no ser más que un módulo poco funcional, que además de no funcionar correctamente, afecta a otros módulos previamente estables.

Cuando las compañías de IT promocionan sus vacantes en las ferias de empleo, la mayoría de los egresados o futuros egresados ve con ojos deslumbrados los flamantes puestos de desarrollador en una u otra tecnología. Siendo sinceros no es de extrañarnos esto, un desarrollador es lo más cercano a un mago que usa conocimientos arcanos inaccesibles para el humano promedio (sin conocimiento de lógica matemática) para resolver problemas y/o crear soluciones a alguna problemática que aqueje a la empresa.

Son los Rockstars, son los “cool” , “los que saben”, los magos.

-Pero ¿Y qué diablos es un QA? — Fue lo primero que pensé cuando vi el anuncio de una vacante en una empresa de mi ciudad. Una rápida leída a Wikipedia despejó la duda y creó otras dudas más: ¿Porqué es necesario que prueben el software? ¿Los todopoderosos desarrolladores no se aseguran de que lo que hacen esté bien hecho? ¿Qué es caja blanca? ¿Qué es caja negra? ¿Por qué tanta fijación en las cajas? ¿Qué son límites? ¿Para qué uso las particiones equivalentes?

Esas preguntas tienen fácil respuesta apenas usando unos minutos a don Google, pero otras que surgen al iniciar una carrera como QA no tienen una solución exacta o respuesta verdadera, un claro ejemplo la clásica “¿Cuando dejar de probar?”, que es la pregunta primigenia que todo QA novato se hace alguna vez. Ante esto se pueden tener varias posibles respuestas, la socialmente aceptada (e ISTQB-able): “terminas de probar cuando hayas completado todas las pruebas programadas”, la más realista: “cuando hayas probado todos los requerimientos” y finalmente la idealista: “no has terminado aún”.

Es ahí precisamente donde existe una división entre un QA “a secas” y un QA con grado “Seniority”, parafraseando al grandioso James Bach — “El testing es un proceso infinito de comparar lo invisible con lo ambiguo, para así prevenir que lo impensable le pase a lo anónimo”.

Sin duda todo buen tester debe saber hasta qué punto confiar o desconfiar de su equipo de desarrollo y sin duda, un buen tester debe pensar “out of the box” para poder plantearse el cómo preparar el set de pruebas con el que atacará a la creación del desarrollador, con pruebas puntuales que garanticen que el producto se entregará exento de fallos y el máximo de satisfacción del cliente

Como testers tenemos en nuestra curiosidad innata humana, nuestra mejor arma. Hay que dudar siempre de lo que te digan, aún y cuando todo parezca tener sentido y estar bien, la Ley de Murphy nos recuerda siempre que si algo puede salir mal, generalmente saldrá mal.

La improvisación guiada por la intuición y la experiencia también generan grandes dividendos, cuando de encontrar anomalías en las aplicaciones se trata. Muchas veces al estar simplemente explorando la aplicación puedes encontrarte con errores de código que de otra manera jamas pudieras haberte topado.

Los QA estamos ahí para ayudar a evitar que filtraciones y vulnerabilidades de la aplicación estropeen la reputación de la compañía. Es nuestra responsabilidad evitar que errores de programación ocasionen fallas que impacten al usuario en cualquier interacción que pudiera tener con el software.

Somos los que apagan la fiesta, los que le quitan la magia a los desarrolladores levantándoles “bugs” a las 6 p.m. un viernes, los malos de la película, pero finalmente lo único que queremos y deseamos es que todo salga bien.

Somos guardianes silenciosos, observadores, y protectores, somos los Caballeros de la Noche.