Hola, me llamo Mauri y yo también he ignorado las revisiones de código con la excusa de que son «terreno de los desarrolladores».
¡Pero ya no! Desde que trabajo en Atlassian que me he dado cuenta que, para que la calidad escale con el desarrollo, hay que invertir esfuerzos en la prevención por delante del control o la mitigación, y un buen lugar para prevenir son las revisiones de código, que acostumbran a ocurrir antes de cualquier testing hands-on.
Y no quiero oir a nadie diciendo cosas del estilo «pero yo no soy desarrollador» o «es que no sé leer código», porque no hace falta ser un developercon213añosdeexperiencia para mirarse una revisión de código. Además, leer código es más fácil de lo que aparenta, y las revisiones de código son un buen lugar por donde empezar, ya que los cambios estan asociados a una funcionalidad o bugfix, de tal manera que el código se puede vincular fácilmente a su objetivo.
Listado de 5 cosas al azar que te interesan, como tester, de las revisión de código:
- Mayor conocimiento de los sistemas y aplicaciones: como tester más funcional, seguro que ya te conoces todos los recovecos de la interfaz de usuario, ¿por qué no ampliar ese conocimiento con nociones del funcionamiento de la cara interna de las aplicaciones?
- Inspiración para futuras fases de pruebas: dependencias inesperadas, secciones complejas, condicionales gigantes, dudas sin resolver expresadas en los comentarios… Este tipo de cosas son pistas invaluables para exprimir las aplicaciones durante la fase de pruebas. Este conocimiento, bien usado y con práctica, hace que el testing sea como jugar al Trivial Pursuit consultando la Wikipedia.
- Mejores tests automáticos: el input de un tester en las pruebas automatizadas que vengan con el código (tests unitários, de integración o de lo que sea) puede ser muy útil para que las nuevas funcionalidades nazcan con una cobertura exhaustiva e útil, más allá de los happy paths.
- Se cazan bugs también! Que sí, que sí, que se puede! Y no solo bugs, también comentarios confusos, errores de formato, secciones poco claras, tests unitarios que no testean nada… Las revisiones de código son el momento idóneo para corregir este tipo de problemas.
- Respeto: también puedes ganarte (más) el respeto de los desarrolladores con tu participación e interés en las revisiones de código, gracias a tus consejos y aportaciones en las mismas. Sabrás que estás por el buen camino cuando tu input sea solicitado en ellas o (todavía mejor) cuando algún desarrollador te pida consejo sobre qué casos de prueba automatizar ¡en la fase de codificación!
Estas son las mías, pero hay muchas más razones por las que, como tester, puede ser interesante participar en las revisiones de código. ¿Cuáles son las tuyas? ¡Cuéntamelo en los comentarios!
Testing funcional 
donde estoy ahora mismo hay una cultura muy fuerte de las revisiones de codigo (un poco extrema) pero la verdad es que se usan para todo incluido cambios de infraestuctura o configuracion y son la mejor manera (y puede que de las pocas) de conocer lo que esta pasando en otras zonas. Eso si, como todo no se puede hacer CodeReview a lo loco, se require bastante tiempo y contexto.
Pero creo que es una buena manera de transmitir la problematica y complejidad con la que se esta tratando. Ya solo para conocer el codigo y unficar otros productos creo que son validas.
Coincido, mi sensación es que los Code Reviews se entienden como un pairing asíncrono. Me gusta tu referencia a las revisiones como una buena manera de conocer lo que está pasando en otras áreas, definitivamente es una fase ideal para enterarse de lo que se cuece en un sistema concreto 🙂
En nuestro caso hacemos revisiones de código tanto de desarrollo como de los tests automáticos. Nos acostumbramos hace tiempo a que como mínimo toda pieza de código ha de ser revisada antes de hacer un merge con un tester y un developer como mínimo, y aplicando siempre los mismos criterios aunque el código revisado sea de QA o de sistemas.
La verdad que es una practica que aunque al principio parece tediosa, es muy útil, y proporciona muchisima información sobre el sistema y sobre como se han realizado las cosas y te ayuda a integrarte mucho mejor con el equipo de desarrollo.
Como improvement hemos empezado a realizar también pair programming entre desarrollo y QA de piezas sencillitas para intentar mejorar en la medida de lo posible los conocimientos tanto de programación como de la plataforma en si… y la verdad es un buen subidón saber que el software tiene una parte (aunque sea pequeña) de ti 😉
Gracias por tu aportación Toni, muy interesante lo que sugieres, supongo que el approach mencionado debe facilitar el acercamiento entre Desarrollo y Calidad, cosa que me parece muy positiva, aunque discrepo amigablemente sobre la necesidad de revisar o programar para que el software tenga parte de uno, ya que eso dejaría fuera a diseñadores, project managers, leads, QAs, soporte, sistemas… Sin los que el desarrollo de software a gran escala no sería posible 😉