Cuando un equipo dice que “la build se fue a un entorno”, significa que la build de release se desplegó en un entorno separado con su propia dirección, configuración y datos.
La misma build puede comportarse de forma completamente distinta en DEV, IFT y PROD.
Veremos:
DEV se usa para experimentos rápidos y comprobaciones iniciales de cambios recientes, mientras que QA se usa para comprobar con calma una build acordada.
PROD es el entorno de usuarios y datos reales, así que solo llega allí una versión verificada.
Ejemplos de problemas al trabajar en un solo entorno
Si todo está en un solo entorno
Un desarrollador redeploya una build al entorno compartido y quien prueba no entiende por qué se rompió todo: por la comprobación, por la nueva versión o por un entorno inestable.
Cuando los entornos están separados
En DEV se puede revisar rápido una build nueva, y en QA se trabaja con una versión acordada para ver después de qué despliegue apareció el problema.
Ejemplos de problemas al trabajar en un solo entorno
Si todo está en un solo entorno
Cuentas, solicitudes, pedidos y estados de prueba terminan en una base compartida. Después no queda claro qué registros se pueden cambiar y cuáles se necesitan para aceptación o procesos reales.
Cuando los entornos están separados
En QA se pueden preparar y limpiar datos de prueba libremente, mientras aceptación usa un conjunto estable separado que no se rompe por experimentos.
Ejemplos de problemas al trabajar en un solo entorno
Si todo está en un solo entorno
El equipo espera a que un servicio externo o un componente vecino esté listo, así que la comprobación del escenario se queda parada.
Cuando los entornos están separados
En QA se pueden comprobar escenarios con stubs: simulan respuestas de servicios externos y evitan esperar a que todas las dependencias estén terminadas.
Los nombres pueden variar: algunos equipos dicen TEST, otros QA; IFT puede llamarse SIT; PREPROD puede llamarse STAGE. La abreviatura importa menos que el acuerdo del equipo: quién despliega, quién prueba, qué datos se pueden cambiar y qué significa estar listo para el siguiente paso.
Los desarrolladores comprueban rápidamente cambios recientes justo después de una build: la aplicación arranca, el cambio está disponible y el happy path evidente no falla. La estabilidad no está garantizada y los datos de prueba pueden recrearse.
Este entorno ayuda a detectar problemas evidentes rápidamente, pero no sustituye una comprobación completa de calidad.
Un entorno controlado donde se hace la comprobación principal de la tarea: smoke testing, escenarios funcionales y comprobaciones de regresión.
Aquí importan los requisitos, datos de prueba, checklists e informes de bugs claros.
IFT significa Integration Functional Testing y SIT significa System Integration Testing. Los servicios se conectan entre sí y a versiones de prueba de sistemas externos.
En esta etapa se comprueba el intercambio de datos entre componentes: contratos API, colas, pagos, autorización y callbacks.
UAT significa User Acceptance Testing. Negocio, product owner o cliente revisa escenarios desde la perspectiva del valor real.
El objetivo es confirmar que el escenario resuelve el problema del usuario y separar bugs de cambios de requisitos.
Preprod o stage se parece al máximo a production en configuración, proceso de despliegue y conexiones. Los datos suelen estar anonimizados o preparados.
El equipo ensaya el despliegue de production y comprueba migraciones, configuración, feature flags, smoke final y readiness de release.
Production es donde viven usuarios reales, dinero, pedidos y reputación. No es el lugar para pruebas que podían hacerse antes.
Después del despliegue, el equipo ejecuta post-release smoke y revisa logs, métricas y trazabilidad para decidir rápido si hace falta un hotfix.
“No se reproduce” a menudo no significa “no hay bug”, sino “estamos mirando entornos distintos”. Antes de probar, registra el contexto.
Si un bug depende del entorno, incluye entorno, versión, datos e integración en el informe de bug . Ahorra horas de ida y vuelta y ayuda a entender dónde buscar.
Un release candidate es una build que el equipo considera suficientemente madura para las comprobaciones finales. Normalmente no salta de dev a prod; avanza por una cadena:
Un proyecto pequeño puede vivir con dev, test y prod. Un producto fintech grande casi siempre separa integraciones, aceptación y preprod.
¡Subiste de nivel!
