En una startup con 30 ingenieros, probablemente eres la única persona de QA probando todo desde la app móvil hasta el panel de admin, sin un plan de pruebas que te entreguen y con builds que van a producción la misma tarde. En una empresa grande, eres responsable de la suite de tests para un servicio dentro de un squad, con revisión de código, gates de CI y un ciclo de release de dos semanas. El trabajo diario es completamente diferente, y también lo son los modos de falla, las trayectorias de carrera y lo que realmente aprendes en cada uno.
Cómo se ve el trabajo día a día
En una startup (menos de 100 ingenieros)
Probablemente eres el único QA engineer, o uno de dos. Pruebas todo: nuevas funcionalidades, correcciones de bugs, integraciones de terceros, el panel de admin que nadie tocó en ocho meses. No hay un plan de pruebas que te entreguen. Lo escribes tú. No hay un entorno de staging separado. Pruebas en producción con feature flags, o en un deploy de branch que se destruye esta noche.
Los standups son de cinco minutos. Nadie espera la aprobación de tres revisores. Subes un build a las 2pm y está en producción a las 4pm. Los bugs se reportan en Slack. Jira existe pero los tickets de nadie están en orden.
En una empresa grande (1000+ ingenieros)
Eres un QA en un squad de cuatro a doce personas probando un servicio específico. Eres responsable de la suite de tests de ese servicio: quizás 500 tests de Playwright, algunos tests de contrato, tests de integración contra staging. Tu trabajo pasa por revisión de código. Tus ejecuciones de tests tienen gates de CI. El ciclo de despliegue es de dos semanas, o trimestral para algunas herramientas internas.
Hay un documento de estrategia de testing. Hay un QA lead. Hay requisitos de cumplimiento que significan que algunos tests existen únicamente para el rastro de auditoría. Asistes a la planificación del sprint, al grooming del backlog, a las retrospectivas. El triaje de defectos es un evento de calendario.
Velocidad vs. estabilidad
La diferencia más significativa es la tolerancia al riesgo.
Las startups están optimizando para la velocidad. Lanzar importa más que la cobertura. Un QA engineer de startup que bloquea un release durante 48 horas para terminar una suite de regresión puede estar haciendo más daño que bien, porque en ese tiempo tres competidores lanzaron y un cliente clave se fue. El cálculo es diferente. Sacar algo rápido, recopilar feedback y corregir rápido a menudo es mejor que estar seguro.
El QA empresarial está optimizando para la estabilidad y la previsibilidad. Una plataforma bancaria, un sistema de salud, un procesador de pagos: estos no pueden lanzar "muévete rápido y arréglalo mañana". Las regresiones cuestan dinero real, a veces sanciones regulatorias. El ritmo más lento no es burocracia por sí misma; es una decisión de gestión de riesgos.
Ninguno está equivocado. Ambos requieren recalibrar la definición de "suficientemente bueno".
Qué aprendes en cada entorno
Fortalezas de la startup
- Amplitud. Pruebas mobile, web, API y fallos de infraestructura en la misma semana.
- Propiedad. Tú decides qué importa probar. Nadie te lo dice.
- Contexto de negocio. Estás suficientemente cerca de los fundadores y del equipo de ventas como para entender por qué importan las cosas.
- Velocidad. Aprendes a triagiar rápido y a confiar en tu instinto.
Fortalezas de la empresa grande
- Profundidad. Profundizas mucho en un dominio: escalar tests, optimizar pipelines, construir frameworks de testing.
- Proceso. Aprendes a trabajar dentro de las ceremonias Agile, cómo escribir estrategias de testing, cómo comunicar el estado del QA a stakeholders que no son ingenieros.
- Arquitectura. Las bases de código grandes te enseñan sobre sistemas distribuidos, dependencias entre servicios y cómo probar cosas que son difíciles de aislar.
- Hábitos de documentación. Todo está documentado porque el equipo que lo construyó se fue hace dos años.
Qué puede salir mal en cada uno
Modo de falla en startup: acumulación de deuda técnica
Sin tiempo para la infraestructura de tests, las startups acumulan deuda de testing rápido. Terminas con 300 tests que todos hacen login por UI porque nadie configuró storageState. La mitad de la suite es flaky porque no hay datos de prueba aislados. Nadie refactoriza los tests porque siempre hay una funcionalidad pendiente.
El peligro: lanzas funcionalidades con confianza porque los tests están en verde, pero los tests no están cubriendo las cosas correctas. El número de cobertura parece bien; el producto tiene regresiones.
Modo de falla en empresa grande: proceso sobre sustancia
Las empresas grandes pueden construir tanto proceso alrededor del QA que el testing real pasa a segundo plano. Tienes planes de prueba, gates de revisión, checklists de aprobación, y tests que no se actualizaron desde 2022 porque la funcionalidad cambió pero el test todavía pasa en una versión antigua de la app.
El peligro: las métricas de cumplimiento se ven bien, pero los tests se alejaron de lo que el producto realmente hace. Estás probando un sistema que ya no existe.
Salario y trayectoria de carrera
Las startups generalmente pagan algo menos en salario base pero ofrecen equity. El equity importa mucho en el resultado: sin valor en la mayoría de las startups, transformador en el pequeño porcentaje que tiene exit.
Las empresas grandes pagan de forma más confiable, a menudo con bonus y pensión o matching de 401k sólido. El techo es más bajo pero el piso es más alto.
En cuanto a la trayectoria de carrera: en una startup puedes pasar de QA junior a QA lead en 18 meses si la empresa crece y tú te destacas (la inflación de títulos es real, pero también lo es la experiencia). En una empresa grande avanzas por bandas bien definidas (QA I → QA II → Senior → Lead), los ascensos tardan más, los criterios son más claros, y los roles de nivel Staff existen aquí (raramente en las startups).
Para un primer trabajo, las startups te enseñan a pensar; las empresas grandes te enseñan a escalar. Los ingenieros que se mueven entre ambos entornos (velocidad de startup combinada con rigor empresarial) son los más efectivos.
Cómo elegir
Elige una startup si
- Quieres aprender rápido y no te molesta la incertidumbre
- Estás bien con que te digan "pruébalo y mira si se rompe" sin más orientación
- Quieres eventualmente construir una función de QA desde cero en algún lugar
- El potencial upside del equity te importa
Elige una empresa grande si
- Quieres mentoría y onboarding estructurado
- Te interesa desarrollar experiencia en arquitectura de tests e ingeniería de frameworks
- La estabilidad y los beneficios importan más que la velocidad
- Quieres un camino de ascenso claro
