Portafolio del tester: cómo crecer de pruebas manuales a arquitecto de soluciones
Cuando te unes a una startup, todo es simple. Muestras un par de proyectos en GitHub, cuentas cómo encontraste errores y te contratan. En una corporación, la historia es diferente con el portafolio. Allí no solo observan tus habilidades técnicas, sino también tu capacidad para trabajar con sistemas grandes y complejos, tu comprensión de la lógica de negocio y el ciclo de vida del producto. Una lista común de proyectos no te ayudará aquí.
Analicemos cómo armar un dossier que te muestre no solo como un tester, sino como un miembro valioso de un gran equipo, y cómo trazar el camino desde tester manual hasta arquitecto de soluciones de pruebas.
Por qué "solo pruebas" no es suficiente
Imagina una construcción donde trabajan mil personas. Tu tarea es verificar si una pared del nuevo edificio se ha agrietado. Si le dices al capataz: «Revisé 25 paredes, todo está bien», eso no dice nada. Debes mostrar: «Revisé los muros de carga en el segundo piso de la sección norte y detecté que en dos de ellos el esquema de armado está alterado, lo que podría causar grietas bajo carga».
Al reclutador corporativo no le interesa cuántas listas de verificación completaste. Le importa entender:
• Cómo piensas.
• Cómo priorizas cuando hay cientos de errores.
• Cómo te comunicarás con los desarrolladores cuando necesites incluir una corrección en el lanzamiento de mañana.
En lugar de: «Probé una aplicación web para un banco». Escribe: «Realicé pruebas de integración del módulo de pagos. Identifiqué un error crítico en el procesamiento de transacciones superiores a 500 000 rublos, que amenazaba con bloquear las cuentas de los clientes. Desarrollé un escenario para reproducirlo y logré la corrección antes del lanzamiento».
Qué debe estar en el centro
Eres responsable de un producto que usan millones de personas al día. No se trata solo de "encontrar un error", es la responsabilidad de que alguien no pierda dinero, no se cancele un vuelo o no se rompa el sistema de entrega de comida.
Tu portafolio debe mostrar: «Entiendo esta responsabilidad. Veo el sistema como un todo, no solo el área de mis listas de verificación».
De pruebas manuales a automatización: un paso clave
Si quieres crecer, las pruebas manuales te frenarán. En una empresa con cientos de lanzamientos al año, físicamente no te alcanzarán las manos para repetir las mismas verificaciones. Te convertirás en un cuello de botella.
Aquí se necesita automatización. Pero en una corporación, no es solo "escribir una prueba en Selenium". Es:
• Integración con el pipeline de CI/CD para que las pruebas se ejecuten en cada commit.
• Escribir pruebas estables que no fallen cada vez debido a resultados aleatorios.
• Saber trabajar con entornos distribuidos y contenedores.
💡 Consejo: No empieces con marcos gigantescos. Toma un proyecto con el que trabajes y automatiza la lista de verificación más aburrida y repetitiva. Mide cuánto tiempo ahorraste en la primera ejecución. Muestra esa cifra en tu portafolio.
Qué agregar al dossier
Tu historia debe ser un sistema, no una lista de tecnologías. Muestra no que sabes Python, sino cómo resolviste un problema:
- Problema: Cada lanzamiento (y había 4 al día) requería pruebas de regresión manuales del módulo de pagos. Tomaba 2 horas.
- Solución: Escribí pruebas automatizadas en Python + Pytest, que se ejecutan en Jenkins después de cada compilación.
- Resultado: Reduje el tiempo de regresión a 10 minutos. Los errores comenzaron a detectarse entre 15 y 30 minutos después del commit, no al día siguiente.
Esto no trata de herramientas. Se trata de valor empresarial.
Comunicación en un equipo grande: no es una habilidad técnica, es un superpoder
La infraestructura más compleja en una corporación son las personas. Cuando en un lanzamiento participan 50 desarrolladores, 5 testers, 3 analistas y un product manager, los errores a menudo no surgen en el código, sino en los puntos de conexión entre sistemas y en la falta de comprensión de los requisitos.
Como tester, eres el puente entre el negocio y la tecnología. Tu tarea no es solo decir "no funciona", sino decir:
- «Tenemos un error porque en el lado de la API no consideraron el cambio en el mapeo de campos, y el frontend aún espera el formato anterior. Necesitamos sincronizar a los equipos.»
Qué escribir en la carta de presentación
No enumeres las tecnologías que conoces. Cuenta una historia sobre una crisis específica que preveniste.
"En mi trabajo anterior, noté que en la especificación del nuevo módulo de facturación no se consideraba la lógica para la devolución de pagos parciales. Lo detecté en la etapa de análisis de requisitos, antes de que comenzara el desarrollo. Registré el error en Jira, lo discutí con el analista y corregimos las especificaciones. Si lo hubiéramos pasado por alto, en la etapa de aceptación habría tenido que reescribirse la mitad del código".
Esto habla de: pensamiento anticipado, proactividad, comprensión de la lógica de negocio, no solo competencia técnica.
Cómo no quemarse en el entorno empresarial
Una gran empresa con cientos de miles de líneas de código heredado, plazos ajustados y juegos políticos puede desgastar a cualquiera. Tu tarea no es solo sobrevivir, sino crecer.
Aquí están las principales trampas y cómo evitarlas:
• Miedo al código heredado. No es un pantano, sino un mapa del tesoro. Cuanto más antiguo es el código, más "demonios" ocultos tiene. Si lo entiendes y automatizas las pruebas, te volverás indispensable.
• Problema de "nadie valora". Muestra números. Recopila estadísticas: «En el trimestre, mis pruebas evitaron 5 incidentes que podrían haber costado a la empresa N horas de trabajo de soporte». Lo que se valora no son las charlas, sino el beneficio medible.
• Agotamiento profesional. A menudo llega cuando haces lo mismo durante meses. Dedica tiempo a aprender nuevas herramientas (incluso 2 horas a la semana). Cuando ves progreso y crecimiento en tus habilidades, el agotamiento retrocede.
💡 Consejo: Crea en tu portafolio una sección separada "Arquitectura y estrategia". Donde muestres cómo probarías un producto ficticio pero complejo, por ejemplo, un sistema de gestión para una aerolínea. Esto mostrará tu visión sistémica.
De tester a arquitecto: mapa del camino
En una corporación tienes tres niveles de crecimiento:
- Especialista. Haces tu trabajo con calidad. Automatizas, escribes casos de prueba, cierras tareas.
- Experto. Vienen a ti por consejo. Realizas revisiones de código de pruebas automatizadas de colegas. Empiezas a pensar en cómo mejorar el propio proceso de pruebas en el proyecto.
- Arquitecto. No escribes pruebas. Diseñas cómo estarán estructuradas en la empresa: qué marcos usar, cómo configurar la infraestructura, cómo probar microservicios distribuidos.
Tu portafolio debe mostrar el avance por este camino. Si aún estás en la primera etapa, enfócate en herramientas. Si estás en la segunda, en soluciones a problemas del equipo. Si estás en la tercera, en conceptos y estrategias.
Qué poner en tu portafolio ahora mismo
Toma un archivo de texto común o una página de Notion. Empieza a llenarlo con esta plantilla:
-
Título: Puesto y especialización (QA Automation Engineer | Enfocado en crecer a QA Lead)
-
Competencia clave: Una frase que refleje tu valor (por ejemplo: «Construyo procesos de pruebas en condiciones de lanzamientos rápidos»)
-
Caso destacado: Una historia (siguiendo el esquema «Problema → Solución → Resultado») que responda mejor a la vacante a la que apuntas.
-
Base: Lista breve de tecnologías, donde muestres no «sé», sino «uso en contexto» (Java + Selenide + Jenkins, Docker, Rest Assured, Allure)
-
Vector de crecimiento: «Actualmente estudio Kubernetes, ya que planeo automatizar las pruebas de despliegue de microservicios».
No necesitas 50 páginas de texto. Dale al reclutador exactamente lo que necesita para verte como un experto. Una hoja que hable más fuerte que una lista de verificación de 1000 puntos.
