El otro día estaba chequeando mi LinkedIn y me encuentro con este posteo… una especie de chiste de alguien que buscaba personas que hagan QA para una empresa, era una placa que decía I make developers cry.

Al comienzo me enojé porque creo que el mensaje es nocivo, no aporta en absoluto.

Varias personas le dijeron a quien lo publicó que no era gracioso y ésta se negó a escuchar y a entender sus motivos, sumado a que esta persona no trabaja como dev o QA. Es decir, cualquiera puede opinar de cualquier cosa y hacer chistes, pero si usás como base para tu chiste un estereotipo sobre una realidad que conocés superficialmente, quizás corras el riesgo de pifiarle. Un chiste solamente es gracioso si alguien se ríe.

Además creo que hay cosas de las que nos podemos burlar solo entre nosotros y nosotras porque entendemos las sutilezas. Por ejemplo: digamos que nosotres los ñoños y ñoñas podemos usar la palabra con ñ, el resto no.

Del enojo pasé a reflexionar y comprender. Entendí por qué esta persona piensa esto y es que hay algo de cierto.

El QA como disciplina que se ve hoy en muchísimas empresas que se dedican al software no es QA. Es revisar cosas.

La cultura en muchos lugares con respecto a este rol es nefasta o inexistente e incita a que devs y QAs se establezcan como dos tipos de personas donde una parece que hace el menor esfuerzo para cumplir, llegar a la fecha o mostrar que avanza y la otra parte revisa y señala los errores cometidos, dejando a estos dos roles enfrentados.

Entonces las personas que se dedican al QA como muestra este chiste, hacen llorar a las y los devs.

Esa es la mecánica que existe en muchos lugares y no es nada divertido, además de que genera un mensaje equivocado sobre este rol que lejos está de tener a los devs como enemigos.

Imaginen una empresa donde se diseñan y construyen autos. Allí hay personas que se dedican a que la calidad de esos autos sea la mejor. Creen que van a decir “vos Armalo como quieras y yo vengo al final y te lo pruebo”? No! Están ahí estableciendo procesos, prácticas, para que el proceso de diseño y armado fluya y se logre cumplir con el objetivo de calidad. Obviamente al final van a probar que el auto no explote pero esa es la prueba final.

QA o Quality Assurance es la disciplina que se encarga, como su nombre lo indica, de asegurar la calidad de los productos, en nuestro caso: software.

Como el concepto de calidad es bastante complejo de definir. Podemos reducirlo a que “el software cumpla con lo que es esperado” y esto tan sencillo como parece es bastante difícil de gestionar. Hay que entender bien qué es lo esperado. Esto implica hablar con la gente que decide qué es eso que se espera para tener esa visión.

Una persona que se dedica al QA no decide arbitrariamente qué es lo esperado. Hay muchas preguntas que nos tenemos que hacer de forma conjunta. ¿Qué es lo esperado? ¿Que que funcione bien? (¿y qué sería que funcione bien para la persona que nos contrata?) ¿Que sea lindo? ¿Que funcione rápido? ¿Que funcione a veces? ¿Que funcione siempre? Y además: ¿podemos lograr esa calidad que esperamos con los recursos que tenemos? Personas, tiempos, servidores.

El software de hoy en día es relativamente complejo, implica interfaces con mucha información. Equipos grandes trabajando sobre una misma base de código, distintas fuentes de información para un mismo propósito, bases de datos, cachés, réplicas. También hay diferentes usuarios, roles, permisos.

Un pequeño universo de datos y lógica que se combinan para lograr un producto, y en ese pequeño universo cambiante de datos en movimiento, las cosas pueden mutar de formas inesperadas.

Por ejemplo: cambios en el código de la pantalla de login que generan un error en la pantalla de recupero de contraseña. Un dato nuevo en la base que afecta a una versión vieja de nuestra UI, y muchos escenarios que contemplar donde nuestro software debe cumplir con la calidad mínima esperada.

Entonces ¿qué hace alguien que se dedica al QA?

Es parte del equipo junto con desarrollo. Muchas veces QA es un equipo separado o los equipos de desarrollo están distribuidos y así también el de QA. Pero definitivamente trabaja codo a codo y desde el principio con quienes implementan.

Esto quiere decir que si bien no se ocupa de implementar la lógica de negocio, o sea de codear la app o las apps. definitivamente entiende la arquitectura de todo. Define estrategias y buenas prácticas para disminuir el riesgo a la hora de hacer cambios y de crecer. Puede medir ese riesgo.

Define procesos, metodologías, enfoques y técnicas para asegurar la calidad. Que pueden ir desde formas de trabajar el código hasta procesos automáticos y manuales de testeo. O sea que, revisar manualmente lo que hacen las personas que implementan es solo una parte de su trabajo.

Y, ¿esto es así en la vida real?

En las empresas serias sí, pero en las empresas donde todavía están reinventándose la rueda o codeando artesanalmente, o en esos lugares oscuros del reino donde la metodología es un mito: todavía hay prácticas nefastas para la industria.

Obviamente la culpa no es de quien recién comienza. Porque vos caés en un mundo donde en los libros leés las maravillas de cómo se podría trabajar y en la realidad te encontrás el famoso “atado con alambre” o “Esto aquí nunca va funcionar”. ¿Y qué vas a hacer?

Pero lo importante es que sepan que estas formas de trabajar “ideales” o “utópicas” son más comunes de lo que piensan. Que las personas con experiencia sabemos que trabajar metodológicamente no es más caro ni lleva más esfuerzo y de hecho te da muchísimos y mejores beneficios.

Así que cuando te digan que las cosas las hacen a medio pelo porque no se puede de otra forma porque es muy costoso o difícil, es mentira. Trabajé en muchos proyectos muy mal gestionados y en muchos muy bien organizados, con gente responsable y dedicada que se tomaba lo suyo muy en serio y realmente es un placer. La complejidad deja de pasar por arreglar bugs, o porque el día del deploy algo malo va a pasar. La complejidad va por otro lado.

¿Sabían ustedes que era QA? ¿Sabían qué hace una persona que se dedica al QA? ¿Han trabajado con personas que se desempeñen en este rol? ¿Qué piensan de todo esto? Les leemos.