Calidad en cada pull request: Una guía para testers

La mayoría de los bugs que llegan a producción no son bugs de lógica compleja. Son cambios que alguien hizo en una rama, mergeó a main sin que nadie los mirara en serio, y que rompieron algo que funcionaba desde hace meses como unos campeones.

El pull request es el momento de intervención más barato que existe. Cuesta infinitamente menos encontrar un bug ahí que en producción, que en QA de regresión, o incluso que en un ciclo de testing de staging. Y sin embargo, la mayoría de los equipos lo usan como un trámite de aprobación de código, no como una oportunidad de calidad real. Siempre me pone de muy muy malhumor cuando es un "¿me das un tick así corre el pipeline?"

Esta guía es para que eso cambie.

Por qué el PR es territorio de QA

Hay una idea instalada en muchos equipos de que el testing empieza después de que el código existe. Primero desarrollan, después testean. Primero mergean, después verifican.

Eso es al revés.

Cuando un desarrollador abre un PR, hay un contrato implícito: "esto es lo que cambié, esto es lo que debería hacer". Tu trabajo como tester es leer ese contrato, entenderlo, y pensar en todo lo que puede salir mal antes de que el código toque ningún ambiente compartido.

No es que el tester tenga que revisar el código línea por línea como si fuera un code reviewer. Hay dimensiones distintas que podés aportar:

• Cobertura de escenarios: ¿los tests que acompañan el PR cubren los casos felices y los casos borde?

• Impacto lateral: ¿este cambio toca algo que no está en la descripción del PR?

• Criterios de aceptación: ¿lo que se implementó es lo que se pidió?

• Riesgos no documentados: ¿hay algo obvio que el autor no vio porque estaba con la cabeza adentro del código?

Eso es valor de tester. No hace falta entender cada línea de TypeScript para aportarlo.

Qué hacer cuando llega un PR

1. Leer la descripción antes que el código

Parece obvio, pero mucha gente va directo al diff. La descripción del PR (si existe y es buena) te dice el por qué del cambio. El diff te dice el qué.

Empezá por el por qué. Preguntate: ¿tiene sentido este cambio en el contexto del sistema? ¿Hay algo en esta descripción que ya me genera duda?

Si la descripción dice "fix menor en la pantalla de login" y el diff toca el servicio de autenticación, ese gap ya es una señal.

¿Que no pusieron ninguna descripción dijiste? Bueno...ahí toca apurar al developer y pedir que por favor ponga una descripción. Si me pedís revisar algo mínimo poné eso papu.

2. Leer los tests antes que el código de producción

Antes de meterte en el código de la feature, mirá los tests que lo acompañan. Los tests te dicen qué escenarios el autor consideró.

Hacete estas preguntas:

• ¿Hay tests? (No es broma. Hay PRs sin ninguno.)

• ¿Los tests cubren el camino feliz y al menos un par de escenarios de error?

• ¿Los casos de prueba tienen nombres descriptivos o son test_1, test_2?

• ¿Hay algo que claramente debería testearse y no está?

Si el PR agrega validación de un formulario y los tests sólo cubren el caso donde todo está bien pero no cubren campos vacíos, caracteres especiales o longitudes extremas... eso es un gap de cobertura y lo podés señalar antes de que mergeen.

3. Buscar el impacto lateral

Este es el punto donde más valor aportás y donde más gente falla.

El autor del PR estaba pensando en resolver un problema puntual. Vos tenés que pensar en todo lo que ese cambio puede afectar sin que el autor lo haya considerado.

Ejemplo: un PR cambia cómo se formatean los montos en la pantalla de checkout. Parece cosmético. Pero ese mismo componente de formateo lo usan los emails de confirmación, los PDFs de factura, y el módulo de reportes del admin. Si el cambio rompe alguno de esos contextos, nadie lo va a ver hasta que ya esté en producción.

Para encontrar impacto lateral, podés:

• Buscar en el código quién más usa los módulos que se modificaron

• Checar el historial de bugs relacionados a ese área

• Pensar en integraciones externas que dependen de ese comportamiento

4. Revisar los criterios de aceptación

Tomá el ticket de origen (historia de usuario, issue, lo que sea) y comparalo con lo que se implementó.

Esto suena básico pero salva vidas. Es frecuente que:

• El criterio dice "el usuario puede cancelar el pedido antes del envío" y la implementación lo permite en cualquier estado

• El criterio dice "máximo 3 intentos de login" y la implementación no tiene contador

• El criterio dice "notificación por email" y la implementación no la incluye porque "eso lo hace otra tarea"

Si hay gaps entre lo pedido y lo implementado, ese PR no debería mergearse. No es un bug todavía, pero va a serlo.

5. Hacer preguntas en el PR, no en privado

Si algo no queda claro, la pregunta va en el comentario del PR, no en un mensaje privado al desarrollador.

¿Por qué? Porque el contexto queda documentado. En seis meses, cuando alguien mire el historial del PR para entender por qué se tomó cierta decisión, va a encontrar la pregunta, la respuesta, y el razonamiento.

Los PRs son documentación técnica del proceso de decisión. Tratalos así.

Qué no es revisar un PR

• No es hacer testing exploratorio completo. Eso viene después, en el ambiente de QA o staging. En el PR estás en el nivel del código y el diseño, no corriendo el sistema.

• No es aprobar o rechazar basándote en preferencias de estilo. Si el código funciona y cumple los criterios, el hecho de que vos lo habrías escrito diferente no es feedback de QA. Obvio que si hay patrones que mejorar o notas antipatrones que van a traer dolores de cabeza, un comentario bien puesto te puede salvar a vos y a tu equipo horas de trabajo después.

• No es bloquear por bloquear. Si tenés una duda, marcala como pregunta, no como bloqueante. Si encontrás un bug real o un gap de cobertura importante, ahí sí levantás la mano.

Un flujo concreto para revisar PRs

Cuando te llega un PR para revisar, podés seguir este orden:

1. Leer título y descripción → ¿entiendo qué cambia y por qué?

2. Leer los tests → ¿qué escenarios cubre? ¿qué falta?

3. Leer el diff de código → ¿hay impacto lateral evidente?

4. Comparar con el ticket → ¿se implementó lo que se pidió?

5. Dejar comentarios específicos → preguntas, observaciones, gaps identificados

No tiene que ser un proceso de una hora. En muchos casos podés hacer este recorrido en diez o quince minutos. Lo que importa es que sea sistemático, no reactivo.

El tester como primera línea de defensa

Hay una frase que escucho mucho: "QA es el colchón que atrapa los bugs antes de producción".

Prefiero pensar distinto. El QA no es el colchón. El colchón es costoso, tardío, y te da una falsa sensación de seguridad. El QA debería ser la red que está presente en cada etapa del proceso, desde que se escribe un criterio de aceptación hasta que el código se mergea.

La revisión de PRs es una de las herramientas más potentes para estar en esa red. No requiere acceso especial, no requiere configurar ambientes, no requiere esperar que el build pase. Requiere atención, criterio, y la disposición a hacer preguntas incómodas antes de que sea tarde.

Eso es QA moderno.

Para profundizar

• Google Engineering Practices: How to do a code review — escrito para devs, pero aplica directamente a revisiones de QA

• Atlassian: Pull request best practices

• Martin Fowler: Continuous Integration — el contexto mayor donde vive la revisión de PRs

Para reflexionar

¿En tu equipo actual los testers participan de la revisión de PRs, o el QA empieza recién cuando el código está en un ambiente de testing?

¿Qué tipo de bugs encontraste en producción que podrían haberse detectado si alguien hubiera revisado el PR con criterio antes de mergear?