Hace unas semanas hubo un poco de movimiento en twitter por un tweet que, básicamente, decía
Quiero trabajar en un proyecto con testing
La verdad es que, algunas cosas me sorprendieron porque, prácticamente en todas las empresas en las que he trabajado y mi entorno cercano entendemos el valor que aportan los tests y es algo que hacemos e intentamos mejorar en nuestro día a día.
⚠️ Esto que escribo esta basado 100% en mi experiencia y opinión como backend developer, lo digo antes de que alguien se enfade de más porque mi opinión es distinta de la suya
Cuando desarrollamos cualquier funcionalidad o arreglamos algun bug tenemos que asegurarnos de que nuestra implementación se comporta acorde a los requisitos que tenemos. Esta comprobación la podemos hacer manual o automaticamente. Aunque de primeras puede parecer que es más rápido si lo probamos a mano, la experiencia me ha demostrado lo contrario. Si lo hacemos manualmente, cada vez que vayamos a subir a producción tendríamos la responsabilidad de asegurar que absolutamente todo lo que hay implementado esta funcionando correctamente, esto no es solo tiempo invertido, también es carga mental que nos afecta en el trabajo diario.
Cuando yo hablo de testing, en el contexto de programación, me refiero a lo que nosotras, como desarrolladoras, podemos hacer en nuestro día a día para asegurar que nuestro código funciona sin probarlo manualmente, en este grupo entrarían los tests unitarios y los de integración(sé que hay sitios donde reciben otro nombre pero es el que yo más utilizo), el objetivo de estos test es asegurarnos de que nuestro sistema funciona correctamente pero sin llamar a servicios externos (tengo pensado hablar sobre esto en más profundidad en otro post pero no es el objetivo de este)
fuente: https://www.ministryoftesting.com/dojo/lessons/the-mobile-test-pyramid
<aside> 💡 Los tests unitarios y de integración forman parte del proceso de desarrollo de una tarea, por lo que es la persona que la desarrolla quién tiene que hacerlos
</aside>
Hacer estos tests nos aporta muchísimo valor, primero el evidente, que es asegurar que nuestro código funciona como debería y ayudarnos a saber que no hemos roto ninguna funcionalidad que ya estuviera implementada. Pero, además de eso, es documentación viva, podemos recurrir a los tests de un proyecto cuando acabamos de entrar para entender los flujos y la lógica que ya está funcionando. También podemos usarlos para reproducir bugs y asegurarnos de que los hemos arreglado y que no se vuelven a producir. Tiene otros beneficios no tan directos pero si muy importantes, nos van a abrir la puerta a otras prácticas como continuous integration y continuous delivery y nos va a permitir acceder a más empresas, he revisado bastantes pruebas técnicas durante los últimos años y, sin algún test, no pasan a la siguiente fase.
Es un perfil que existe en algunos equipos, es la persona responsable de la calidad, pero no del código si no de TODO el sistema el conjunto, esto puede implicar varios proyectos conectados entre si. Como digo, es un perfil y un mundo entero aparte, tienes QA Automation, QA Manual y Tester cada uno con objetivos distintos. QA Automation y QA manual estarían involucrados desde que se empieza a hablar de una feature para poder identificar puntos criticos, podrían implementar algunos end-to-end (Automation) o definir tests cases (Manual), sin embargo, el tester solo estaría involucrado una vez que la funcionalidad se considera implementada para comprobar que los tests cases definidos antes funcionan correctamente. Además de todo esto las personas que trabajan como QA manual suelen hacer exploratory testing que consiste en probar la web o aplicación como lo haría una usuaria, enfocandose en encontrar errores o funcionamientos diferentes a los definidos.
Vamos a poner un ejemplo, alguien que sea QA Automation desarrollará tests end-to-end automáticos que podrían cubrir el proceso de alta de una usuaria en una plataforma, asegurarse de que se le envía un email de verificación y que, si pincha en ese link, su cuenta queda verificada en la plataforma. Si lo pensamos...aquí puede intervenir 1 servicio o 20, dependiendo de la arquitectura del proyecto. Por lo tanto, este tipo de tests no es algo que llevemos a cabo las personas de desarrollo porque son muy lentos y pueden llegar a tener muchas dependencias entre distintos equipos.
fuente: https://www.ministryoftesting.com/dojo/lessons/the-mobile-test-pyramid
Aunque yo creo que es un perfil que aporta mucho valor en los equipos siempre que todas las personas del equipo asuman que la gente de QA no esta ahí para probar su código, si no que el código es responsabilidad de quienes que lo desarrollamos. Hace algun tiempo se empezó a comentar que es un perfil prescindible, ya que se espera de nosotras, como desarrolladoras, que nos hagamos responsables de que todo lo que se sube a producción tiene la suficiente calidad.
Existe también otro perfil relacionado, pero no está muy extendido en España, Quality Assistant cuyo objetivo es ayudar a los equipos, tanto desarrollo como QA, a implementar buenas prácticas y mejoras que impulsen la calidad del proyecto.
Son las siglas de Test-Driven Development y es un concepto que “redescubrió” uno de mis héroes Kent Beck, si quereís saber por qué lo es os dejo esta charla.
He pasado bastante tiempo intentando encontrar las palabras adecuadas para explicar qué es TDD, porque TDD no es una forma de hacer tests. TDD es una forma de desarrollar haciendo que nuestra implementación se guíe por los tests.
fuente: https://www.ministryoftesting.com/dojo/lessons/the-mobile-test-pyramid