Tres jóvenes se suben al escenario del auditorio durante el coffee break de un evento que reúne participantes de todo el mundo en Montevideo. Las letras gigantes y en tres dimensiones #testinguy dominan el espacio. Los chicos intentan una selfie, pero parece que no están conformes. Luego se sacan fotos unos a otros delante y detrás de las grandes letras.
Janet Gregory los mira y no puede evitar su pensamiento: ¿alguno se recostará sobre las letras?, ¿caerá alguna de ellas con tanta actividad alrededor? Reconoce que pensar así, evaluar el riesgo, eventuales errores y tratar de predecirlos, refleja su profesión. Es tester.
Cuando se crea un software, este tiene que pasar por etapas de pruebas para ver si surgen problemas, si hay huecos o fallas a resolver antes de dar por finalizada la tarea. Así surgió el testing. Según el ingeniero estadounidense Cem Kaner —fundador de la Asociación para el Testing de Software— el testing es como una investigación técnica de un producto bajo prueba con el fin de brindar información relativa a la calidad del software destinada a los involucrados en el proyecto.
Janet Gegory es coach en testing, consultora y docente. Se especializa en Agile Testing, una práctica de pruebas de software, y es referente en el tema. Viajó a Uruguay para participar en el evento Testing Uy, organizado por la comunidad del testing con el objetivo de fomentar el tema en Uruguay y la región. Para Gregory, el desarrollo de software está en medio de una transición impulsada por los consumidores que quieren más y más. Las actualizaciones de los sistemas son una necesidad, y el lograr hacerlos sin molestar al usuario, hacer los cambios sin que se noten, es el futuro.
A continuación un resumen de la entrevista durante su visita a Uruguay.
—Quienes trabajan en testing buscan detectar problemas, errores, baches en el software en desarrollo para mejorarlo. ¿Siente que tienen un espíritu de investigación?
—Sí, nunca lo había pensado así. De alguna manera lo es. Cuestionas, miras las cosas desde otra perspectiva. Es un poco como investigar, a veces haces algo de experimentación para ver qué ocurre y observar los resultados.
—¿Cuándo comenzó a interesarse por el testing?
—Al salir de la universidad empecé a trabajar como programadora. Mi supervisor llegaba todas las mañanas y me decía: “Janet, ¿cómo vas a testear esto?” y al final del día volvía y me decía: “bueno Janet, ¿cómo testeaste tu código?”. En mi siguiente trabajo un día vino mi jefe y me dijo “Janet, necesitamos un equipo de testing y eres la única persona que se queja de la falta de testing y la falta de procesos. ¿Serías nuestra gerente de calidad?”. Lo pensé y dije que sí, sabía que no quería ser programadora por siempre. Aprendí todo lo que estuvo a mi alcance sobre testing.
Era 1996 y en ese momento era testing con un enfoque en pruebas en cascada, el testing tradicional.
—¿En qué se diferencia la forma en que se ponía a prueba el software en la década de 1990, el testing tradicional, y la de ahora?
—En cascada quiere decir que tienes todos los requerimientos, diseñas el sistema y se lo das a los programadores para que programen y por último los testers hagan las pruebas. Yo era de las últimas en la cadena.
El testing antes era de pensamiento tardío. Encontrar todos los errores ya hechos y arreglarlos. El testing en equipos Agile es diferente. Sos parte del equipo: ayudamos a prevenir los defectos, hablamos del tema de los riesgos y también de cómo ponerlo a prueba antes de empezar a escribir el código. En los últimos 19 años he trabajado con estos equipos, ayudando a intentar difundir el mensaje porque soy una apasionada del tema. Es una manera diferente de trabajar para mucha gente.
—¿Qué es Agile y cómo ayudó a cambiar la forma en que se pone a prueba el software?
—Es una manera de abordar el desarrollo del software, tiene un manifiesto y algunos principios. No te dice cómo hacerlo, aunque hay metodologías para eso (como Extreme Programming y Scrum). Agile dice: colaboremos, veamos cómo construir este software asegurándonos de que tomamos en cuenta al cliente y al equipo responsable de hacer el producto.
—¿Cuándo se expandió y qué tan difundido está hoy?
—En cada organización del mundo hay nichos de Agile. Tiene presencia en la mayoría de las empresas del mundo. En 2003 y 2004 se expandió por los impulsores de los negocios, por las empresas. Sus estrategias están cambiando rápido porque los clientes ya no pueden esperar más dos años para obtener sus productos. Agile es una manera de hacerlo más rápido.
—Porque en vez de detectar los errores cuando el software está hecho se trata de prevenir los problemas o atacarlos antes…
—Entonces, colaboramos más. En estos tiempos de delivery continuo, hagámoslo disponible para el cliente. Cuando piensas en Google, está siempre haciendo actualizaciones. Tú no lo sabes. Eso es el futuro. Es lo que pasará con casi todo el software. Pero hay muchas compañías que están demasiado lejos de eso todavía. Los sistemas Legacy (en computación se refiere a sistemas viejos que aún viven dentro de las organizaciones) tienen sistemas tan grandes que para que ellos aprendan a hacerlo de esta manera les llevaría mucho tiempo. Tienen que cambiar su arquitectura. Siempre habrá algunos más lentos al final de la curva.
—Entonces el futuro son sistemas que están continuamente actualizándose.
—Sí, yo creo que sí.
—¿No es complicado para el usuario?
—El ideal es que no haya impacto real para el usuario. Cuando Google actualiza lo que sea que hace, tú no sabes y no hay impacto. Cambios podrían hacerse en tu computadora o celular y no lo sabrás hasta que de pronto lo activen y “ah mira, tengo un look completamente nuevo”. Si las empresas pueden proveer esta información sin hacer un impacto en el cliente, entonces podrán hacer cambios todo el tiempo.
—Sin tener que descargar nuevas versiones.
—Android está mejorando mucho en lograr menos impacto.
—¿Técnicamente cuál es el desafío para lograrlo?
—Depende de dónde partas. Hay compañías con grandes sistemas Legacy, gigantescos. Las nuevas empresas fueron capaces de adaptarse rápido. La tienen más fácil. Mucho es por la mentalidad de las organizaciones. La cultura organizacional tiene que cambiar para permitir que cambien también.
—¿A qué se debe la necesidad de que los sistemas se estén actualizando continuamente?
—Está siendo impulsada por los consumidores que quieren más y mejor, más nuevo. Las compañías le responden las demandas a los consumidores con gratificación inmediata. Esa es la sociedad en la que vivimos. Los negocios están empezando a responder a esto. Algunos son más lentos y los que respondan más rápido son los que van a sobrevivir.
—En una escala del 1 al 10, ¿qué papel juega la creatividad en el testing?
—Nueve, porque tienes que estar pensando “¿qué pasa si…?”. Esos chicos que estaban ahí sacándose una foto en el cartel de Testing Uy. Sentada mirándolos pensaba: “¿a ver quién se va a recostar sobre una de las letras y se va a caer?” (sonríe). Esa es la mentalidad del testing. Estamos constantemente testando el mundo alrededor y nos enfocamos en el producto.
—¿Qué cambios traerá aparejados la inteligencia artificial al testing?
—Actualmente no mucho, porque la inteligencia artificial es tan buena como la información que le proporcionas. Muchas compañías se están acercando, pero otras luchan con temas como dónde conseguir las bases de datos para poder entrenar la inteligencia artificial. En el futuro testearemos la inteligencia artificial en vez. Si la inteligencia artificial puede testear todos los productos, entonces nosotros terminaremos testeándola a ella. Alguien tiene que asegurarse de que eso funciona, que la información que le proporcionas es correcta y también los resultados. Hay tantas compañías que están lejos de usar esta tecnología que no creo que los testers estén en peligro aún. No puedo decir por cuántos años.
—¿Cómo ve el testing en Uruguay?
—La comunidad es increíble. Se está haciendo un muy buen esfuerzo. Las preguntas que se están haciendo son similares a las que se hacen en otras partes del mundo. Están a nivel del mundo.