Ingeniero QA

Automatizo todo lo que es repetitivo, estable y de alto valor comprobar en cada build: los flujos de usuario principales como el inicio de sesión, el pago o la entrada de datos principal. Esos van a mi suite de Selenium o Playwright y se ejecutan en cada pull request. Mantengo las pruebas manuales para todo lo nuevo, muy visual, o susceptible de cambiar en el próximo sprint, porque automatizar una funcionalidad que todavía está en iteración es un esfuerzo desperdiciado. También reservo las pruebas manuales para sesiones exploratorias, donde intento deliberadamente romper el producto de formas que una prueba con script nunca contemplaría. Una regla simple que uso: si espero ejecutar la misma comprobación más de cinco veces durante la vida de una funcionalidad, merece la pena automatizarla. Reviso la suite automatizada cada trimestre para retirar pruebas de funcionalidades eliminadas o cambiadas lo suficiente como para que la prueba ya no refleje el comportamiento real del usuario.

Empiezo leyendo los requisitos y señalando cualquier ambigüedad antes de escribir un solo caso de prueba, porque requisitos poco claros producen pruebas poco claras. Primero trazo el camino principal de la funcionalidad, luego listo los casos límite: estados vacíos, longitudes máximas de entrada, usuarios concurrentes y límites de permisos. Agrupo los casos de prueba por nivel de riesgo, priorizando todo lo que toca pagos, autenticación o pérdida de datos. Incluyo casos positivos y negativos, y anoto cuáles son candidatos a automatización frente a comprobaciones manuales puntuales. Antes de la ejecución comparto el plan con el desarrollador que construyó la funcionalidad, porque suele conocer algún caso límite que yo no había considerado. También incorporo una pasada de regresión que cubre funcionalidades adyacentes que comparten código con la nueva. Una vez que empiezan las pruebas, registro los resultados en Jira para que la cobertura sea visible para todo el equipo.

Un buen informe de bug responde a tres preguntas antes de que el desarrollador las haga: qué hiciste, qué esperabas y qué ocurrió realmente. Incluyo pasos de reproducción exactos y numerados, el entorno (navegador, sistema operativo, número de build), y una captura de pantalla o una breve grabación de vídeo siempre que el bug sea visual. Adjunto los logs o errores de consola relevantes en lugar de describirlos de memoria. Siempre indico la severidad desde la perspectiva del usuario, no solo la severidad técnica: un botón roto en una página de administración poco usada no tiene la misma prioridad que un botón de pago roto. Evito frases vagas como "a veces falla" y en su lugar anoto la tasa de reproducción, por ejemplo "8 de cada 10 intentos". Si no consigo reproducirlo de forma consistente, lo digo explícitamente en lugar de dejar que el desarrollador asuma que es cien por cien reproducible. Un informe claro le ahorra veinte minutos de idas y vueltas al desarrollador.

Mantengo una suite de regresión principal que cubre los flujos de usuario críticos y la ejecuto en cada candidato de lanzamiento, automatizada en la medida de lo posible para no ralentizar al equipo. Para las áreas que cambian con frecuencia, mantengo un mapa de riesgo que señala qué funcionalidades comparten componentes o modelos de datos con el área que se está modificando, para saber qué más revisar aunque no se haya tocado directamente. Me apoyo en la suite automatizada para la amplitud de cobertura y reservo el tiempo de regresión manual para las áreas que las notas de la versión indican explícitamente como modificadas. Cuando una versión es grande, priorizo la regresión en torno a todo lo relacionado con ingresos o acceso a la cuenta primero, porque son las áreas donde un fallo no detectado tiene el coste más alto. También mantengo la propia suite de regresión bajo revisión, retirando pruebas de funcionalidades obsoletas para que se mantenga rápida y relevante en lugar de crecer indefinidamente.

Estábamos a punto de lanzar un flujo de mejora de suscripción, y todo el equipo había probado el camino estándar: de gratis a de pago, usando una cuenta de prueba nueva. Durante una sesión de pruebas exploratorias, probé mejorar una cuenta que ya tenía una suscripción cancelada pero todavía dentro de su periodo de gracia. La mejora parecía funcionar en la interfaz, pero el backend creaba un registro de suscripción duplicado en lugar de reactivar el existente, lo que habría cobrado dos veces al cliente en la renovación. Lo encontré porque probé deliberadamente un estado de cuenta que nadie había configurado antes, en lugar de solo el escenario de cuenta limpia previsto en el plan de pruebas. Lo reporté como bloqueante con el estado de cuenta exacto necesario para reproducirlo, y el equipo retrasó el lanzamiento un día para corregir la lógica de facturación. Esto me confirmó que los planes de prueba construidos solo alrededor del camino principal se pierden los estados de cuenta que los usuarios reales tienen después de meses de uso.

Reporté un bug donde los resultados de búsqueda aparecían en el orden incorrecto con ciertas combinaciones de filtros. El desarrollador cerró el ticket como "funciona según lo previsto", argumentando que la lógica de ordenación era técnicamente correcta. Volví al documento de requisitos y encontré que el texto original indicaba explícitamente que los resultados debían ordenarse primero por relevancia y luego por fecha, algo que el código no hacía. En lugar de discutir por Slack, grabé una breve captura de pantalla mostrando la discrepancia junto al texto de la especificación, y reabrí el ticket con ambas cosas adjuntas. Tuvimos una llamada de cinco minutos en la que reconoció que la intención se había malinterpretado durante la implementación. Intento mantener estas conversaciones centradas en el requisito documentado en lugar de en mi opinión personal, porque eso hace que el desacuerdo sea factual y rápido de resolver. La corrección salió en el siguiente parche, y añadimos una prueba de regresión específica para esa combinación de filtros.

Un correo de confirmación de pago salió con el símbolo de moneda incorrecto para un pequeño número de clientes internacionales. Pasó las pruebas porque nuestras cuentas de prueba estaban configuradas con una única región por defecto, así que el bug de formato de moneda nunca se activó en QA. El equipo de soporte lo detectó en pocas horas, y corregimos la lógica de formato y enviamos correos corregidos a los usuarios afectados ese mismo día. En el post-mortem, me di cuenta de que nuestros datos de prueba no reflejaban la distribución real de nuestra base de usuarios, que para entonces incluía varias regiones lanzadas más recientemente. Creé un conjunto de cuentas de prueba que cubren nuestros cinco mercados principales y añadí el formato de moneda a la suite de regresión principal para que se ejecute en cada versión que toque facturación o correo. Cambió mi forma de pensar sobre los datos de prueba en general: la diversidad realista de cuentas importa tanto como la cobertura de casos de prueba.

Para automatización de interfaz he usado Selenium y más recientemente Playwright, y prefiero Playwright para proyectos nuevos por su comportamiento de espera integrado, que reduce las pruebas inestables que afectaban a buena parte de nuestra antigua suite de Selenium. Para pruebas de API uso Postman para trabajo exploratorio y comprobaciones rápidas, y escribo pruebas de API automatizadas con un framework como REST Assured o la API de peticiones de Playwright cuando necesitan ejecutarse en integración continua. Para el seguimiento de bugs y casos de prueba he trabajado sobre todo con Jira, con los casos de prueba en Xray o en una hoja de cálculo sencilla según la madurez del equipo. Elijo las herramientas según la experiencia que ya tiene el equipo, salvo que haya una razón técnica clara para cambiar, porque cambiar de herramienta tiene un coste real en tiempo de adaptación. Cuando propongo una herramienta nueva, hago primero un piloto pequeño en un área de funcionalidad en lugar de migrar toda la suite de golpe.

Parto de la especificación o el contrato de la API, ya sea un documento OpenAPI o un acuerdo compartido con el desarrollador backend, y escribo los casos de prueba directamente contra ese contrato. Con Postman o un framework automatizado, pruebo primero el camino principal: entradas válidas que devuelven el código de estado y la forma de respuesta esperados. Después pruebo los casos límite: campos obligatorios ausentes, tipos de datos inválidos, valores límite y solicitudes no autorizadas o no autenticadas. Compruebo que las respuestas de error devuelven mensajes útiles y códigos de estado correctos, no solo un 500 genérico. También pruebo la idempotencia cuando es relevante, por ejemplo confirmando que llamar dos veces a un endpoint de pago con el mismo identificador de solicitud no genera un cobro duplicado. Una vez que la suite de pruebas es sólida contra el contrato, la mantengo en el pipeline de integración continua para que cualquier cambio en el backend que rompa el contrato se detecte de inmediato, mucho antes de que el equipo de front end lo toque.

Divido la suite en niveles según la velocidad y el nivel de confianza. Las pruebas unitarias y las pruebas de API rápidas se ejecutan en cada commit y deben pasar antes de permitir una fusión. Una suite de smoke tests que cubre los flujos críticos se ejecuta en cada pull request contra un entorno de staging, normalmente en menos de diez minutos. La suite de regresión completa, más lenta y con cobertura de interfaz más amplia, se ejecuta cada noche o antes de crear un candidato de lanzamiento, no en cada commit, porque ralentizaría demasiado al equipo. Configuro el pipeline para que falle el build ante cualquier fallo de smoke test, pero solo marco los fallos de regresión para revisión sin bloquear automáticamente, ya que una prueba inestable en una suite grande no debería bloquear un lanzamiento por sí sola. También hago seguimiento de las pruebas inestables por separado y las pongo en cuarentena hasta que se corrigen, para que el equipo no pierda confianza en la suite al ver el mismo fallo falso repetirse.