Ponente: Abel Meriño. Testing en Chile 2025 – 9na edición

Entrando en tema

Esta charla se centra en la función de QA (Quality Assurance) como una estrategia integral para asegurar la calidad en el desarrollo de software. El presentador, Abel Meriño, comparte su experiencia y evolución profesional de profesor de matemáticas a desarrollador y, finalmente, a líder de QA, enfatizando que su objetivo no es solo probar el software, sino supervisar todo el proceso de calidad desde la concepción inicial del proyecto. Meriño presenta un flujo de trabajo que integra a todo el equipo en las acciones de aseguramiento de la calidad, buscando que cada «commit» o «pull request» sea potencialmente desplegable en producción. Destaca la importancia de una arquitectura de pruebas robusta y la elección de herramientas compatibles con el lenguaje del proyecto, sin olvidar la relevancia de los valores compartidos del equipo, como la confianza, el compromiso con la calidad y la honestidad, para fomentar un entorno de trabajo colaborativo y eficaz.

Introducción y trayectoria del Ponente

Abel Meriño, un ex profesor de matemáticas en La Habana, emigró a España en 2008. Su carrera profesional evolucionó de desarrollador .NET (especializado en software ERP y cálculo de nóminas) a experto en aseguramiento de la calidad. Durante más de 10 años como desarrollador, comenzó a interesarse por cómo asegurar y testear lo que se hacía, independientemente de la tecnología. Actualmente, se desempeña como QA Manager o Arquitecto de Testing, dedicándose a implementar procesos de aseguramiento de la calidad dentro del desarrollo de software.

Enfoques y estrategias del QA

Meriño presenta dos escenarios principales para la organización del QA

• Oficina de QA: Que brinda servicio a múltiples equipos.
• QA Integrado: Un QA que forma parte integral del equipo de desarrollo. Este último es el que Meriño prefiere y busca implementar.

La estrategia de calidad, según una definición de 2008, implica «hacer coincidir las prácticas de desarrollo con los objetivos del negocio y las prácticas de pruebas», enfatizando la retroalimentación continua y la evaluación constante, conceptos relevantes aún hoy con procesos CI/CD.

Metas fundamentales de la estrategia

• Consolidar el rol del asegurador de la calidad: Su objetivo no es solo testear, sino «velar por el proceso de calidad desde el principio», desde la toma de requerimientos y el aseguramiento de estos.
• Involucrar a todo el equipo en acciones de aseguramiento de la calidad.
• Garantizar que el commit o pull request sea potencialmente desplegable en producción.

Cuatro pilares de la estrategia de QA

• Consolidar el rol del asegurador de la calidad.
• Consolidar tareas de aseguramiento de la calidad dentro del equipo.
• Consolidar procesos de testing automatizado (el test en sí mismo y su documentación).
• Consolidar sesiones de testing exploratorio de forma sistemática.

El rol del QA actual

La tendencia actual del QA es hacia un perfil híbrido. Meriño cita una definición: «personas que puedan moverse entre la visión del usuario, el conocimiento técnico, la entrega de valor continuo, lo cual no significa saber de todo sino conectar diferentes mundos y aportar desde varias perspectivas».

Funciones clave de un QA hoy:

• Contribuir a la definición de historias de usuario.
• Crear casos de prueba.
• Apoyar en la revisión de código.
• Ejecutar casos de prueba manuales.
• Crear arquitectura para favorecer el desarrollo de pruebas automatizadas.
• Automatizar casos de prueba.
• Realizar testing exploratorio.
• Hacer seguimiento de la gestión de ramas.
• Aportar en los procesos de CI/CD, definiendo qué tipos de pruebas se ejecutan en cada etapa.
• Medir indicadores, publicar métricas y monitorizar, buscando que la publicación de métricas sea automatizada y los casos de prueba queden en código.

Meriño subraya la importancia de que el QA no se conforme con que algo «funcione», sino que indague en el código para asegurar la solución más correcta, citando un ejemplo de un bug y una solución superficial frente a una revisión de código.

Flujo de trabajo del aseguramiento de calidad

El flujo propuesto por Meriño es el siguiente:

• Definición previa: Antes de que la historia de usuario entre en desarrollo, se definen la historia de usuario, los criterios de aceptación y los casos de prueba. Meriño prefiere que el desarrollador «conozca ya de antemano cómo se le va a probar la aplicación».
• Desarrollo: El desarrollador realiza su trabajo, despliega su rama y ejecuta sus test unitarios y casos de prueba de aceptación.
• Validación: Una vez que el SonarCloud da el okay y el equipo aprueba la pull request, se ejecutan automáticamente los casos de prueba automatizados y manualmente los restantes.
• Testing Exploratorio: La historia de usuario (o varias) pasa a una etapa de testing exploratorio. La meta es que este no detecte nada que impida el despliegue a producción, ya que la historia debería ser «potencialmente desplegable». Sin embargo, se reconoce un margen de error.
• Hallazgos: Se registran los hallazgos del testing exploratorio, que pueden ser asumidos, resueltos (implicando resolución antes de producción) o gestionados más adelante.

Automatización y ejemplos

Meriño discute la pirámide de testing clásica versus un enfoque de reloj de arena para la automatización, donde hay muchos tests unitarios, muchas pruebas de aceptación y algunas pruebas de servicio. Cada historia de usuario debería tener su prueba de aceptación asociada.

Elementos clave en la estrategia de automatización:

• Sistema de diseño: Estandariza la interfaz de la aplicación.
• Patrones/plantillas: Para diferentes interfaces.
• Validación de servicios: Mediante tests de integración.
• Pruebas End-to-End (E2E): Validan el sistema completo.
• Documentación de pruebas: Se prefiere una buena documentación de los tests de aceptación en sistemas como Azure DevOps, utilizando etiquetas que dejan claro «qué hace cada test y cuáles son sus pasos y cuáles son sus elementos», en lugar de Gherkin, si no hay otros stakeholders de negocio involucrados.
• Compatibilidad con el lenguaje de desarrollo: El proyecto de testing debe estar dentro del proyecto de desarrollo, en el mismo lenguaje, para que el desarrollador se sienta cómodo y la curva de aprendizaje sea más simple.

Tecnologías utilizadas (en el contexto .NET):

• XUnit: Para pruebas unitarias.
• B Unit: Para pruebas de componentes (en caso de Blazor).
• .NET: Para pruebas de integración y API.
• Test Container: Para la creación de contenedores Docker que simulen la infraestructura necesaria para probar servicios.
• Selenium / Playwright: Para pruebas E2E, con una capa de abstracción (p. ej., PlayBrowserDriver o SeleniumBrowserDriver) para encapsular las funcionalidades del browser driver y facilitar el mantenimiento y la reutilización.
• Basemark.NET y NBomber: Para pruebas de carga.
• Grafana: Para monitorizar el comportamiento de las pruebas de carga.

Ejemplos prácticos mostrados:

• Pruebas E2E (Login): Demostración de un login, estructurado por pasos y con inyección de dependencias para los drivers y páginas, permitiendo cambiar fácilmente entre Playwright y Selenium.
• Pruebas de carga (Smoke Test de Login): Utilizando NBomber con 5 usuarios concurrentes durante un minuto, monitorizado con Grafana. Se mostró cómo un cambio en el rendimiento es una señal para el desarrollador de revisar su código.
• Pruebas de integración (GET de Productos): Utilizando WebApplicationFactory y Test Container para levantar una API y una base de datos específica para la prueba, y ejecutando una prueba de carga con NBomber para un GET de productos.

Valores compartidos en el equipo

Meriño enfatiza que, a pesar de haberlos «despreciado» en su juventud, los valores compartidos son cruciales para que el equipo trabaje en conjunto por la calidad.

• Confianza y respeto, pensar en positivo: El QA no es un «policía», sino un «espejo para que el equipo se refleje y tome sus decisiones». Es importante que el QA pueda opinar y revisar el código, fomentando la apertura y la comunicación.
  • Compromiso con la calidad: Lo que se describe en la historia de usuario.
  • Calidad realizada: Lo que se consigue; idealmente, que sea igual a la solicitada.
  • Calidad esperada: Aspectos que no siempre están escritos en la historia de usuario, pero que el QA (como usuario final) o el equipo esperan. Si el testing exploratorio revela algo que afecta la «calidad esperada», el equipo debe decidir si resolverlo, asumirlo o posponerlo, incluso si los criterios de aceptación ya se cumplieron.
• Honestidad y transparencia: Evitar «desarrolladores de habitación oscura». Fomentar que el código sea visible y compartido regularmente («el push tiene que ser más que diario»). La transparencia permite al QA empezar a montar casos de prueba y al equipo colaborar de forma efectiva.

Preguntas y respuestas

• Documentación como herramienta para el aprendizaje continuo
  • Testing exploratorio: Se documenta en una Wiki. Antes de la sesión, se define el objetivo, el área a explorar y un guión, compartiéndolo con el equipo. Después, se registran los resultados, inconvenientes y una lista de hallazgos (Work Items en Azure DevOps) para que el equipo decida su gestión.
  • Casos de prueba: Se escriben previamente en Azure DevOps (Test Plan) y se marcan los más importantes para automatizar (casos de prueba de aceptación).
  • Tests unitarios: El QA también aporta, dejando a veces tests en «fallido» para que el desarrollador los pase al completar su código.
  • Casos de prueba automatizados: Se publican en un repositorio de Azure DevOps (como parte del proceso CI/CD), ofreciendo «documentación paso a paso de cada caso de prueba que se ha ejecutado», una «documentación viva».
• Diferencia de lenguaje en playwright (ej. Python vs. .NET):
  • No debería haber una diferencia fundamental en la estrategia. Se puede implementar la misma arquitectura de pruebas E2E en Python con Playwright.
  • La principal diferencia sería el lenguaje de escritura. Meriño menciona que en su contexto .NET, tiene la ventaja de tener todo el stack (unitarias, componentes, integración, E2E, API) en el mismo lenguaje, facilitando la colaboración con el desarrollador. La única limitación podría ser la disponibilidad de herramientas específicas como NBomber para Python.
• Mayores oportunidades de mejora/debilidades de los ingenieros QA:
  • Inteligencia Artificial (IA): Gran oportunidad de mejora y optimización. La IA puede ayudar a escribir casos de prueba, detectar ambigüedades en historias de usuario, y acelerar el proceso. Sin embargo, es crucial usarla «con criterio», ya que a veces puede sugerir cambios excesivos o incorrectos.

Conclusión General

La charla de Abel Meriño ofrece una visión integral y pragmática de la estrategia de QA, trascendiendo el mero «testing» para enfocarse en un rol proactivo y transversal en el aseguramiento de la calidad. Destaca la importancia de la integración del QA en el equipo de desarrollo, la automatización inteligente y la construcción de una cultura de calidad basada en la confianza y el compromiso de todo el equipo. Su enfoque en la «calidad esperada» y la revisión de código por parte del QA subraya la profundidad y el valor que este rol aporta al ciclo de vida del software.