WinstonCastillo.com

Uno de los errores más dañinos en la automatización es normalizar los flaky tests:
casos de prueba que fallan o pasan bajo las mismas condiciones, sin que el código haya cambiado.

Y aquí está el verdadero problema 👇
Automatizar requiere mucho esfuerzo: tiempo, diseño, mantenimiento, análisis.
Cuando esos tests no son confiables, todo ese esfuerzo pierde sentido.

El impacto no es solo técnico:
• El equipo deja de confiar en los resultados
• Los fallos se ignoran (“seguro es el test”)
• La automatización deja de ser una señal de calidad

En ese punto, la suite ya no protege al producto.
Se vuelve ruido.

Y cuando no hay confianza, ocurre lo inevitable:
👉 la automatización no se usa como debería,
👉 se saca del pipeline,
👉 o se ejecuta solo “para cumplir”.

Un test automatizado debería dar feedback claro y consistente.
Si no puedes confiar en él, no te está ayudando a tomar mejores decisiones.

La automatización no está para fallar “a veces”.
Está para reducir riesgo, no para introducir dudas.

Quería compartir un poco de humor…

Pero ahora en serio:

Trabajar en remoto me enseñó algo muy claro: las videollamadas son oro, pero no siempre son posibles.
No todos los equipos las disfrutan, no todos pueden, y a veces… simplemente no coinciden los husos horarios.

En un proyecto de automatización que recuerdo con cariño, mi compañera estaba en Australia.
Mientras yo empezaba el día, ella ya lo estaba cerrando.
Hacer videollamadas era casi imposible, así que tuvimos que adaptarnos o fallar.

Lo que hicimos fue simple, pero poderoso:
📄 documentos compartidos
💬 chats asíncronos
🧠 mucha claridad al escribir

Y funcionó.

De esa experiencia me quedaron cinco aprendizajes que sigo usando hoy:

1️⃣ Escribe como si no fueras a estar disponible
Deja contexto, ejemplos y decisiones claras.

2️⃣ Documentar no es burocracia, es empatía
Un buen doc ahorra reuniones y malentendidos.

3️⃣ Haz preguntas completas, no mensajes sueltos
Facilita respuestas claras, incluso horas después.

4️⃣ Acepta que no todo es inmediato
El trabajo asíncrono también avanza, solo que de otra forma.

5️⃣ Confía más en el proceso que en la presencia
No verse no significa no estar alineados.

El trabajo remoto no se trata solo de herramientas, sino de intención, claridad y respeto.
Y sí, a veces sin cámara… también se puede construir algo increíble.

Estos devs no aguantan nada 🤭… nah mentira, estoy jugando.

Al final, esta relación QA vs Dev es puro teamwork (aunque a veces venga con un poquito de sarcasmo incluido 😅).

Etiqueta a tu desarrollador más cool… ese que aunque le reportes 10 bugs, igual te responde bien (o al menos lo intenta).