Tester de software / ingeniero de QA

Pinchar por los mismos flujos en cada versión para confirmar que no se ha roto nada de lo que funcionaba.

Convertir requisitos en casos, y casos en guiones que corren en la canalización.

Probar lo que nadie especificó: la entrada rara, la condición de carrera, el usuario que hace el paso 3 antes que el 2.

Sopesar los fallos abiertos, el riesgo, el plazo y el negocio, y decir sí o no.

Evaluar software cuya salida no es determinista — construir conjuntos de evaluación, cazar regresiones de comportamiento, probar salidas dañinas.

Encuesta autodeclarada a 200 ingenieros sénior de grandes empresas de EE. UU., Reino Unido y la UE — y el informe lo publica Lightrun, que vende herramientas de depuración, así que el hallazgo y el producto apuntan en la misma dirección. Las caídas de Amazon que cita (2 y 5 de marzo de 2026, atribuidas a cambios asistidos por IA desplegados sin aprobación, seguidas de una revisión de seguridad del código de 90 días en 335 sistemas) son sucesos con información independiente; los porcentajes no lo son. Solo software de empresa.

Un fallo, una marcha atrás, una regulación o un coste están frenando la adopción. Puede bajar una evaluación o ensanchar su incertidumbre.

Una empresa, mejora de clases de pruebas unitarias ya existentes con filtros de compilación, aprobado y cobertura; el 75% de los casos generados compiló, el 57% pasó de forma fiable y el 25% añadió cobertura. Artículo escrito por la propia empresa; un contexto de maratón de pruebas acotada en el tiempo, no de uso rutinario en la canalización.

Ensayo a pequeña escala en un entorno real. Nos dice que se están probando las condiciones de despliegue, no que se cumplan, así que un piloto nunca basta por sí solo; dos independientes sí.

Entrar como tester manual es la entrada más débil de este sitio, porque esa es la tarea que se va más rápido. Entra mejor por la mentalidad adversaria y por la disciplina nueva: aprende a romper cosas que nadie especificó, y aprende a evaluar sistemas basados en modelos, donde casi no hay nadie con experiencia y los equipos están contratando. Saber programar es ya un mínimo del puesto y no una especialidad dentro de él.

Si tu semana es sobre todo regresión y mantenimiento de guiones, el puesto se está consolidando por debajo de ti y deberías moverte antes de que te muevan. Tu verdadero activo es el modelo que tienes en la cabeza de cómo se rompe este producto; conviértelo en pruebas exploratorias, decisión de publicación y evaluación de las funciones basadas en modelos que tu equipo casi seguro está añadiendo. Son posiciones sénior, y las ocupa quien las reclama primero.

Rehacer el puesto

De ejecutar pruebas a ser dueño de la calidad

Alguien tiene que decidir qué significa «suficientemente probado», sostener la decisión de publicar y ser dueño del trabajo exploratorio. Ese papel sobrevive; el de ejecutar, no.

Rehacer el puesto

Especializarte en evaluar sistemas basados en modelos

Es nuevo, escaso y está directamente al lado de lo que ya hacen los testers. Los equipos que sacan funciones con modelo necesitan a alguien que dé por supuesto que están rotas.

Movimiento lateral

Desarrollador en pruebas o ingeniería de plataforma

Construir las canalizaciones, los entornos y las herramientas que permiten probar a todo el equipo es trabajo de ingeniería con demanda constante, y usa el conocimiento del tester sobre qué sale mal.

La ejecución manual de pruebas sí, y rápido. La calidad como disciplina no: alguien sigue teniendo que imaginar cómo falla el sistema, decidir si está listo y — cada vez más — evaluar software cuyo comportamiento no es determinista, cosa que casi nadie sabe hacer todavía. El puesto se mueve de ejecutar pruebas a ser dueño del riesgo, y de afirmar salidas fijas a evaluar comportamiento. Quien hace ese movimiento vale más de lo que valían los testers; quien no lo hace se encontrará el puesto consolidado a su alrededor.

La señal es quién escribe la batería de regresión de tu equipo este trimestre. Cuando la batería se genere y se repare sola tras un cambio de interfaz, el bloque de horas que financiaba la mayoría de los puestos de QA habrá desaparecido — esa es la capacidad concreta que se movió, y la verás en tu propio repositorio antes que en ningún informe.

La regresión manual y escribir casos de prueba — las dos marcadas como en automatización, y la regresión manual por sí sola es el mayor bloque de horas de la mayoría de los puestos de QA. Las pruebas exploratorias y la decisión de publicar no lo están, pero ninguna es lo bastante grande como para absorber a la gente cuya semana llenaba la regresión.

Es una disciplina real y en crecimiento — conjuntos de evaluación, regresión de comportamiento, instrucciones adversarias — y la mentalidad de QA se transfiere directamente. La salvedad honesta es que es tan joven que nadie sabe qué tamaño acabará teniendo, y puede terminar cubierta dentro de los equipos de modelo en vez de en QA.