Enseñar QA en Universidades: Conectando Teoría y Práctica

La mayoría de los graduados en ingeniería de software entran al mundo laboral habiendo escrito miles de líneas de código pero menos de una docena de casos de prueba. Pueden construir una API REST desde cero pero no pueden articular una estrategia de testing para ella. Esto no es su culpa, es un problema curricular. Y después de enseñar aseguramiento de calidad en UPC en Lima durante varios años, mientras simultáneamente lideraba equipos de QA en ambientes de producción, he desarrollado opiniones firmes sobre cómo cerrar esta brecha.

Este artículo comparte lo que he aprendido sobre hacer que la educación en QA sea genuinamente útil, no solo académicamente correcta, sino profesionalmente relevante desde el primer día que un graduado se une a un equipo.

La Brecha entre el QA Académico y la Realidad de la Industria

Los currículos tradicionales de ciencias de la computación tratan el testing como algo secundario. Un curso típico de ingeniería de software puede dedicar dos clases a "verificación y validación", cubrir el modelo V, mencionar técnicas de caja negra vs. caja blanca, y seguir adelante. Los estudiantes se gradúan conociendo el vocabulario del testing sin entender su práctica.

Mientras tanto, la industria necesita ingenieros que puedan diseñar una pirámide de pruebas para una arquitectura de microservicios, escribir tests E2E confiables en Playwright, configurar un pipeline CI/CD con quality gates, y tomar decisiones basadas en riesgo sobre qué automatizar y qué probar manualmente. La desconexión es enorme.the current state of test automation, and make risk-based decisions about what to automate and what to test manually. Understanding the journey from manual to AI-assisted QA is critical context for educators. The disconnect is enormous.

La causa raíz: la mayoría de los currículos de QA son diseñados por académicos que no han trabajado en equipos de entrega de software. Enseñan bien la teoría del testing pero pierden la realidad operativa: los tests inestables, las pesadillas de configuración de ambientes, la dinámica política de convencer a un product owner de que la infraestructura de pruebas merece inversión.

Diseño Curricular: Lo que los Estudiantes Realmente Necesitan

Cuando rediseñé el módulo de QA en UPC, comencé con una pregunta que le hago a cada profesional de la industria con el que trabajo: "Qué desearías que tus ingenieros QA junior ya supieran desde el primer día?" Las respuestas fueron notablemente consistentes:

• Pensamiento de estrategia de pruebas: la capacidad de mirar una funcionalidad y decidir qué pruebas escribir, en qué nivel y por qué.
• Fundamentos de automatización: no solo la sintaxis de una herramienta, sino comprender el patrón Page Object, la gestión de datos de prueba y qué hace que un test sea confiable vs. inestable.
• Testing de API: la mayoría de las aplicaciones modernas son API-first, sin embargo los graduados rara vez saben usar Postman, y mucho menos escribir contract tests.
• Conocimiento de CI/CD: comprender cómo las pruebas encajan en un pipeline de entrega, qué es un quality gate y por qué importa el tiempo de ejecución de las pruebas.
• Comunicación: escribir un reporte de bugs claro, defender una decisión de calidad ante stakeholders, explicar riesgo técnico en términos de negocio.

Noten lo que está ausente de esta lista: nadie pidió estudiantes que memorizaran terminología ISTQB. Quieren ingenieros que puedan pensar sobre calidad, no solo definirla.

Práctica Desde el Primer Día

Mis cursos comienzan con herramientas, no con teoría. En la primera sesión, los estudiantes instalan Playwright, escriben un test que navega a un sitio web real y verifica algo visible, y lo ejecutan. Al final de la primera semana, han visto un test verde pasar y un test rojo fallar. Han experimentado el ciclo de retroalimentación.

La teoría sigue a la práctica, no al revés. Después de que los estudiantes han escrito tests que fallan por problemas de sincronización, introduzco el concepto de estrategias de sincronización. Después de que han luchado con código de configuración duplicado, introduzco fixtures y el Page Object Model. La teoría aterriza porque ya han sentido el dolor que aborda.

Este enfoque refleja cómo los profesionales realmente aprenden. Nadie lee el syllabus de ISTQB Foundation Level de principio a fin antes de escribir su primer test. Aprenden haciendo, y buscan teoría cuando se topan con una pared. Mi aula replica ese ciclo intencionalmente.

Enseñar Estrategia, No Solo Herramientas

Las herramientas cambian. Selenium dominó por una década; ahora Playwright y Cypress son el estándar. Enseñar la API de una herramienta específica tiene una vida media de quizá tres años. Enseñar estrategia de pruebas dura toda una carrera.

Dedico tiempo significativo a ejercicios donde los estudiantes reciben una especificación de producto y deben producir un documento de estrategia de pruebas, no código, solo decisiones. Qué niveles de testing? Cuál es la división entre automatización y manual? Dónde están las áreas de mayor riesgo? Qué ambientes se necesitan? Cuáles son los criterios de salida?

Estos ejercicios obligan a los estudiantes a pensar como líderes de QA, no solo como escritores de tests. Rápidamente descubren que la parte más difícil del QA no es escribir el test, sino decidir cual test escribir y cuándo es suficiente para dejar de probar.

ISTQB como Base, No como Techo

La certificación ISTQB Foundation Level provee un excelente vocabulario y un modelo mental compartido para conceptos de testing. Uso su estructura como la columna vertebral de mi currículo. Partición de equivalencia, análisis de valores límite, tablas de decisión, pruebas de transición de estados: estas técnicas son atemporales y universalmente aplicables.

Pero soy explícito con los estudiantes: la certificación ISTQB por si sola no te convierte en ingeniero QA. Te convierte en alguien que entiende la terminología de QA. La certificación no te enseña cómo depurar un test de Playwright inestable, cómo diseñar datos de prueba para un sistema multi-tenant, o cómo negociar el alcance de las pruebas con un product manager bajo presión de entrega.

Animo a los estudiantes a obtener la certificación como un camino de aprendizaje estructurado, pero combino cada concepto teórico con un ejercicio práctico que lo fundamenta en herramientas y escenarios reales.

Proyectos Estudiantiles: Probando Software Real

La parte más impactante del curso es el proyecto final. Los estudiantes no prueban aplicaciones de juguete, prueban proyectos open-source reales. Cohortes anteriores han escrito suites de pruebas para proyectos como TodoMVC, contribuido reportes de bugs a issue trackers de código abierto, e incluso enviado pull requests con mejoras de tests.

Esto logra varias cosas simultáneamente. Los estudiantes interactuan con bases de código que no escribieron, lo cual refleja la realidad de la industria. Practican la lectura de documentación y la toma de decisiones de testing con información incompleta. Experimentan la satisfacción de contribuir a un proyecto real, lo cual construye confianza profesional. Y construyen un artefacto de portafolio que pueden mostrar en entrevistas de trabajo.

Una exalumna consiguió su primer rol en QA en parte porque pudo mostrar a un entrevistador una suite de pruebas de Playwright que había escrito para un proyecto open-source, completa con integración CI via GitHub Actions. Ese es el tipo de resultado que válida el enfoque.

Mentoreando a la Próxima Generación

Enseñar es mentorear a escala. Cada semestre, veo estudiantes que llegan convencidos de que QA es "menos técnico" que desarrollo. Al final del curso, muchos de ellos reconocen que la ingeniería de calidad requiere habilidad técnica profunda, pensamiento estratégico y capacidad de comunicación en igual medida.

Los estudiantes que prosperan no son necesariamente los programadores más fuertes. Son quienes desarrollan una mentalidad de calidad: el hábito de preguntar "qué podría salir mal?" antes de preguntar "cómo construyo esto?". Esa mentalidad se puede enseñar, pero requiere práctica deliberada, no solo conferencias.

También conecto a los mejores estudiantes con profesionales en mi red para pasantias y primeros roles. La comunidad de QA en América Latina está creciendo rápido, y la demanda de ingenieros junior bien preparados supera con creces la oferta. Las universidades que inviertan en educación práctica de QA producirán graduados inmediatamente valiosos para la industria.

Lo que la Industria Puede Aprender de la Academia

La transferencia de conocimiento no es unidireccional. Trabajar en la academia ha afinado mi práctica en la industria de maneras inesperadas. Enseñar te obliga a articular conocimiento tácito: las intuiciones y heurísticas que los líderes de QA experimentados aplican inconscientemente. Cuándo un estudiante pregunta "por qué empiezas a probar ahi?", necesitas una respuesta más rigurosa que "porque se siente riesgoso".

El rigor académico también proporciona marcos para evaluar enfoques de testing sistemáticamente. La industria a menudo adopta herramientas y prácticas basándose en charlas de conferencias y posts de blogs. La academia exige evidencia. Combinar ambas perspectivas, experiencia práctica con rigor analítico, produce mejores líderes de QA.

La mejor educación en QA no elige entre teoría y práctica. Enseña teoría a traves de la práctica, y usa la práctica para desafiar la teoría.

Si eres un educador diseñando un currículo de QA, empieza con las necesidades de la industria y trabaja hacia atras. Si eres un líder de QA, considera dar una clase invitada en una universidad local: los estudiantes necesitan tu perspectiva, y afilarás tu propio pensamiento en el proceso. La calidad futura de nuestro software depende de qué tan bien preparemos a la próxima generación para pensar criticamente sobre el.