Talently
Talently
QA Manual

QA Manual

Protege la experiencia del usuario ejecutando pruebas con criterio humano que la automatización no puede reemplazar.

Un QA Manual es responsable de verificar que el software funciona correctamente desde la perspectiva del usuario final, usando su criterio, experiencia y conocimiento del producto para detectar defectos que los tests automatizados no anticipan. Su trabajo abarca desde la revisión de requerimientos y la definición de casos de prueba hasta la ejecución de pruebas funcionales, exploratorias y de regresión. Trabaja en estrecha colaboración con desarrolladores, QA Automation Engineers y product managers para garantizar que cada release cumple con los criterios de calidad acordados antes de llegar a los usuarios.

Testing funcionalTesting exploratorioJIRACasos de pruebaRegresiónPostman

Recluta al mejor QA Manual aquí

Empieza ahora

Responsabilidades Principales

  • •Revisar requerimientos y criterios de aceptación antes del desarrollo para identificar ambigüedades y casos no contemplados.
  • •Diseñar y documentar casos de prueba que cubran los flujos principales, alternativos y de error de cada funcionalidad.
  • •Ejecutar pruebas funcionales, de regresión y exploratorias en cada ciclo de desarrollo, documentando los resultados con evidencia.
  • •Reportar defectos con información completa y reproducible, haciendo seguimiento hasta su resolución y verificación.
  • •Colaborar con el equipo de QA Automation para identificar los casos de mayor valor para automatización.
  • •Participar en las ceremonias del equipo ágil aportando la perspectiva de calidad en refinamientos, planificación y retrospectivas.

Habilidades Clave

Technical Skills

  • Diseño de casos de prueba con técnicas de partición de equivalencias, valores límite y tablas de decisión
  • Ejecución de pruebas funcionales, de regresión, de humo y exploratorias con criterio documentado
  • Reporte y seguimiento de defectos en herramientas de gestión como JIRA, Azure DevOps o equivalentes
  • Pruebas básicas de API con Postman para verificar respuestas de backend independientemente de la UI
  • Pruebas en múltiples dispositivos, navegadores y sistemas operativos para verificar compatibilidad
  • Lectura e interpretación de logs de aplicación y mensajes de error para enriquecer el reporte de defectos

Soft Skills

  • Pensamiento adversarial para anticipar cómo un usuario puede usar el sistema de formas no previstas por el desarrollo
  • Atención al detalle para detectar defectos sutiles en comportamiento, mensajes de error y estados de la UI
  • Comunicación clara y empática al reportar defectos sin generar fricción innecesaria con el equipo de desarrollo
  • Curiosidad para explorar más allá de los casos documentados y descubrir problemas no anticipados
  • Criterio para priorizar qué testear cuando el tiempo es limitado y el riesgo es alto
  • Capacidad de comunicar el estado de calidad del producto con claridad a stakeholders no técnicos

Casos de uso reales

Contexto

El defecto más barato es el que se detecta antes de escribir una línea de código. La revisión temprana de requerimientos por parte de QA reduce significativamente los defectos en fases posteriores.

Ejemplos reales

  • Revisión de historias de usuario identificando criterios de aceptación incompletos o contradictorios
  • Identificación de casos edge no contemplados en la especificación antes del desarrollo
  • Sesiones de tres amigos para alinear producto, desarrollo y QA en el entendimiento de la funcionalidad
  • Definición de criterios de aceptación testables y verificables antes de que comience el sprint

Contexto

Cada cambio en el código puede introducir defectos en funcionalidades previamente probadas. Los ciclos de regresión verifican que el sistema sigue funcionando correctamente en su conjunto.

Ejemplos reales

  • Ejecución de la suite de regresión completa antes de cada release a producción
  • Pruebas de humo para verificar que las funcionalidades críticas operan tras un deploy
  • Regresión focalizada en las áreas del código modificadas y sus dependencias conocidas
  • Documentación de los resultados de regresión con evidencia para el registro histórico de calidad

Contexto

Las features nuevas o rediseñadas tienen mayor densidad de defectos. El testing exploratorio con charters definidos descubre problemas que los casos de prueba formales no anticipan.

Ejemplos reales

  • Sesiones de testing exploratorio con charters focalizados en áreas de mayor riesgo
  • Exploración de flujos de error y recuperación ante comportamientos inesperados del usuario
  • Testing de usabilidad informal identificando fricciones en la experiencia del usuario
  • Pruebas de combinaciones de datos y configuraciones no cubiertas en los casos formales

Contexto

Los usuarios acceden a las aplicaciones desde distintos dispositivos, navegadores y sistemas operativos. La compatibilidad debe verificarse de forma sistemática en los entornos más frecuentes.

Ejemplos reales

  • Pruebas en los navegadores con mayor cuota de uso según los datos de analytics del producto
  • Verificación en distintos tamaños de pantalla y orientaciones para aplicaciones responsive
  • Testing en versiones de sistema operativo distintas para aplicaciones móviles nativas
  • Validación de que el comportamiento es consistente en los entornos de staging y producción

Contexto

El QA Manual tiene el conocimiento más profundo de qué casos son más relevantes y cuáles tienen mayor valor para automatizarse. Su input es esencial para priorizar la inversión en automatización.

Ejemplos reales

  • Identificación de los casos de regresión más frecuentes y costosos en tiempo para automatización prioritaria
  • Documentación detallada de los casos de prueba que servirán de base para la implementación automatizada
  • Validación de que los tests automatizados cubren los mismos escenarios que los manuales equivalentes
  • Detección de casos que no deben automatizarse por su naturaleza exploratoria o su alta frecuencia de cambio

Preguntas básicas

Priorizar según riesgo e impacto: primero los flujos críticos de negocio que si fallan bloquean a los usuarios (login, checkout, funcionalidades core). Segundo, las áreas modificadas en este release y sus dependencias directas. Tercero, los flujos que históricamente tienen mayor densidad de defectos. Documentar qué se dejó sin testear y comunicarlo al equipo para que la decisión de release sea informada. El objetivo es maximizar la cobertura de riesgo con el tiempo disponible, no alcanzar un porcentaje de casos ejecutados.
Bloqueante cuando: afecta un flujo crítico del negocio sin workaround, expone datos de usuarios, causa pérdida de datos, o produce comportamiento completamente incorrecto en el flujo principal. Puede entrar como deuda cuando: afecta funcionalidades secundarias, tiene un workaround documentado, el impacto es visual sin consecuencias funcionales, o el número de usuarios afectados es muy bajo. La decisión final la toman producto y negocio con la información de impacto que QA provee, no QA unilateralmente.
Título descriptivo del comportamiento incorrecto, pasos numerados y exactos para reproducirlo, resultado esperado versus resultado actual, evidencia visual (screenshot o video del momento del fallo), entorno donde se detectó (navegador, OS, versión de la app, usuario de prueba usado), y severidad estimada. Un buen reporte elimina el ciclo de preguntas entre QA y desarrollo. Si el defecto es intermitente, documentar la frecuencia de reproducción y las variaciones que lo provocan.
Antes de testear, solicitar la aclaración de los criterios de aceptación con el product manager y el desarrollador. Si el tiempo no lo permite, documentar los supuestos que se están testeando y compartirlos con el equipo antes de ejecutar. Usar el comportamiento del sistema en producción como referencia para el comportamiento esperado, y si es una funcionalidad nueva, buscar referencias en el diseño o en productos similares del mercado. Reportar los hallazgos como preguntas además de como defectos cuando el comportamiento esperado es ambiguo.
El testing exploratorio es simultáneamente diseño y ejecución de pruebas: el tester aprende sobre el sistema mientras lo prueba, adaptando su enfoque según lo que descubre. Se guía por charters que definen el área de exploración y el objetivo, pero sin pasos predefinidos. Complementa los casos formales cubriendo escenarios no anticipados, especialmente en features nuevas o complejas. Los casos formales garantizan cobertura sistemática de los requerimientos conocidos; el exploratorio descubre lo desconocido.
Reproducir el defecto original siguiendo exactamente los pasos del reporte para confirmar que ya no se manifiesta. Verificar el comportamiento con variaciones del escenario original (distintos datos, distintos entornos) para confirmar que la corrección es completa. Ejecutar las pruebas de regresión del flujo afectado para verificar que la corrección no introdujo nuevos defectos. Documentar el resultado de la verificación en el ticket con evidencia antes de cerrarlo.
Organizar por módulo o feature del producto, con etiquetas de prioridad (crítica, alta, media, baja) y tipo de prueba (humo, regresión, funcional, edge case). Mantener un subconjunto marcado como 'regresión crítica' que se ejecuta en cada release y otro como 'regresión completa' para releases mayores. Revisar y depurar periódicamente los casos: eliminar los obsoletos, actualizar los que cambiaron y añadir nuevos por features. Una suite sin mantenimiento acumula casos desactualizados que consumen tiempo sin aportar valor.
En desktop, usar las herramientas de throttling de red del DevTools del navegador para simular conexiones 3G, 4G o de alta latencia. En móvil, usar las opciones de simulación de red del emulador o las condiciones reales de red móvil. Verificar: que la aplicación muestra indicadores de carga apropiados, que no pierde datos del usuario ante interrupciones, que los mensajes de error son claros y accionables, y que la aplicación se recupera correctamente cuando la conexión se restaura. Estos escenarios son frecuentes en usuarios reales y raramente se testean.

Preguntas técnicas

Partición de equivalencias: agrupar los valores de cada campo en clases válidas e inválidas y crear un caso por clase. Análisis de valores límite: para campos con restricciones de longitud o rango, testear los valores en el límite exacto, justo por debajo y justo por encima. Tabla de decisión para las combinaciones de condiciones que activan distintas validaciones. Pairwise testing si el número de combinaciones es muy alto para reducir los casos sin perder cobertura de pares. El conjunto resultante debe cubrir los happy paths, cada validación de error individualmente y las combinaciones de mayor riesgo.
Usar Postman o herramientas equivalentes para enviar requests directamente al endpoint. Verificar: el status code correcto para cada escenario (200 para éxito, 400 para input inválido, 401 para no autenticado, 404 para recurso no existente), la estructura del response body según la especificación, los headers de respuesta relevantes, y el comportamiento con datos en los límites (campos vacíos, valores máximos, caracteres especiales). Crear una colección de Postman organizada por endpoint y escenario que sirva como documentación ejecutable de los tests de API.
Usar el entorno sandbox del proveedor de pagos para los tests, nunca el entorno de producción. Verificar el happy path con los números de tarjeta de prueba del proveedor. Testear los escenarios de error que el proveedor documenta: tarjeta rechazada, fondos insuficientes, tarjeta expirada, timeout de la pasarela. Verificar que la aplicación maneja cada error de forma adecuada: mensajes claros, sin pérdida del carrito, sin cobros duplicados. Verificar los webhooks de confirmación si el flujo es asíncrono. Documentar qué escenarios solo son testeables en producción y cómo se validarán.
Definir el charter antes de la sesión: misión (explorar el comportamiento de búsqueda con combinaciones de filtros), área (módulo de búsqueda), duración (90 minutos), y riesgos que se busca cubrir. Durante la sesión: documentar cada acción relevante, hallazgo y pregunta en notas de la sesión. Explorar: combinaciones de filtros que podrían interferirse, búsquedas con caracteres especiales, comportamiento con cero resultados, rendimiento con términos de búsqueda muy amplios, y consistencia de los resultados paginados. Al finalizar, clasificar los hallazgos en defectos, preguntas e ideas para casos de prueba adicionales.
Mapear las dependencias entre módulos para entender qué cambios en un módulo pueden afectar a los otros. Priorizar el testing en el orden de las dependencias: testear primero los módulos que otros dependen. Definir los casos de integración que verifican el flujo completo a través de los tres módulos. Ejecutar la regresión de los flujos que cruzan los módulos afectados, no solo los de cada módulo individualmente. Documentar el scope de la regresión explicitando qué se testea y qué queda fuera para que el equipo tenga visibilidad completa del riesgo aceptado.
Navegación por teclado: verificar que todos los elementos interactivos son alcanzables con Tab, que el orden de foco es lógico, y que hay indicador visual de foco activo. Contraste de colores: verificar que el texto cumple el ratio mínimo de 4.5:1 con herramientas como el Color Contrast Checker. Textos alternativos: verificar que las imágenes informativas tienen alt text descriptivo. Mensajes de error: verificar que son identificables por herramientas de asistencia. Herramientas automáticas como axe DevTools detectan aproximadamente el 30% de los problemas; el resto requiere verificación manual con estos pasos.
Priorizar la regresión basándose en el riesgo: ejecutar primero los casos críticos de negocio, luego los del área modificada y finalmente la regresión general en orden de criticidad. Distribuir los módulos entre los miembros del equipo evitando duplicación. Si hay automatización disponible, ejecutarla en paralelo para los casos cubiertos y dedicar el esfuerzo manual a los flujos críticos no automatizados. Comunicar al equipo qué áreas quedan sin testear para que la decisión de release sea con información completa. Un ciclo de regresión con cobertura de riesgo documentada es más valioso que uno con cobertura uniforme.
Verificar que los cambios en el perfil se persisten correctamente en la base de datos (consultando directamente si hay acceso, o a través de la API). Verificar que la sincronización con el sistema externo ocurre en el tiempo esperado y con los datos correctos. Testear el comportamiento cuando la sincronización falla: ¿el usuario recibe feedback? ¿los datos quedan en un estado inconsistente? Verificar que los campos sensibles no se exponen en logs ni en responses de API innecesariamente. Testear con datos que incluyan caracteres especiales, nombres muy largos y campos opcionales en blanco.

Preguntas avanzadas

Comenzar con un análisis de riesgo del producto: qué funcionalidades tienen mayor impacto en el usuario si fallan. Definir la estrategia en función de los recursos: qué se testea manualmente, qué se automatiza y qué se deja fuera del scope. Diseñar los casos de prueba para los flujos críticos en las primeras dos semanas, mientras se realiza testing exploratorio de los primeros entregables. Establecer criterios de entrada y salida para cada fase de testing. Coordinar con el equipo de automatización para que los casos de regresión prioritarios estén automatizados antes del primer release. La estrategia debe ser revisable: ajustar el scope según el ritmo real de entrega del equipo de desarrollo.
El testing manual tradicional no escala a continuous deployment. La base debe ser una suite de automatización sólida que ejecuta en cada deploy. El QA Manual se enfoca en: revisión de requerimientos antes del desarrollo, testing exploratorio de features nuevas antes de que lleguen al pipeline de CD, y monitoreo de producción post-deploy con criterios definidos de rollback. Los criterios de aceptación se convierten en tests automatizados como parte de la definición de done. El QA en CD es más un rol de arquitecto de calidad que de ejecutor de casos de prueba.
Defect escape rate: porcentaje de defectos encontrados en producción versus en QA. Una tasa alta indica que el proceso de testing no está cubriendo los riesgos correctos. Tiempo medio de detección: cuánto tarda en detectarse un defecto desde que se introduce. Distribución de defectos por módulo y por tipo para identificar áreas sistemáticamente problemáticas. Cobertura de testing respecto a los cambios del sprint. Estas métricas deben analizarse con tendencia temporal: un aumento en el escape rate es la señal más crítica de degradación del proceso.
No resistir la presión con argumentos de proceso: responder con datos de impacto. Mostrar el costo histórico de los defectos que llegaron a producción por testing reducido: tiempo de desarrollo para corregirlos, impacto en usuarios, tickets de soporte generados. Proponer una reducción del tiempo de testing con un scope de riesgo aceptado documentado y compartido con producto y negocio. La decisión de aceptar ese riesgo es del negocio, no de QA; QA provee la información para tomarla. Si se reduce el tiempo, aumentar la cobertura de automatización para mantener el nivel de confianza.
Diseñar un plan de validación de datos con queries que verifiquen: integridad referencial (no hay registros huérfanos), completitud (todos los registros migrados, ninguno perdido), corrección (los valores transformados son correctos en una muestra representativa de cada tipo). Ejecutar el plan completo en una copia de producción antes de la migración real. Definir los criterios de go/no-go de la migración con umbrales de error aceptables. Diseñar el proceso de rollback y verificar que funciona antes de la ventana de producción. Monitorear activamente las métricas de la aplicación durante las primeras horas post-migración para detectar comportamientos anómalos.
Testing de autenticación y autorización: verificar que los recursos protegidos no son accesibles sin autenticación, que un usuario no puede acceder a datos de otro usuario modificando IDs en la URL o en el payload, y que los roles tienen el acceso correcto según la especificación. Testing de validación de inputs: probar campos de texto con scripts básicos de XSS, SQL injection simple y caracteres especiales. Testing de información expuesta: verificar que los mensajes de error no exponen stack traces ni información interna del sistema. Estos tests básicos no reemplazan un pentest profesional, pero detectan las vulnerabilidades más frecuentes y evidentes antes del release.

Errores comunes en entrevistas

Un QA Manual moderno participa desde el refinement, contribuye a la definición de criterios de aceptación, hace testing exploratorio y colabora con el equipo de automatización. Presentarse solo como ejecutor de casos al final del proceso refleja una visión del rol que las empresas con prácticas ágiles maduras ya han superado.
La transparencia sobre el scope del testing es tan importante como la ejecución. Un QA que no puede explicar qué riesgos aceptó, qué dejó fuera y por qué genera desconfianza. Los entrevistadores de equipos maduros preguntan específicamente por las decisiones de scope en condiciones de tiempo limitado.
Un defecto reportado como 'el botón no funciona' sin pasos de reproducción, screenshot ni contexto del entorno obliga al desarrollador a invertir tiempo investigando antes de poder corregirlo. La calidad del reporte de defectos es una competencia central del rol que los entrevistadores evalúan directamente.
Los happy paths son la parte más fácil del testing. Los defectos más frecuentes en producción están en los flujos de error, los estados vacíos, los datos atípicos y las combinaciones no anticipadas. Un QA que solo testea el flujo exitoso cubre una fracción pequeña del riesgo real del producto.
Confundir severidad técnica con prioridad de negocio produce clasificaciones incorrectas que distorsionan el backlog de defectos. Un error tipográfico en la página de precios tiene baja severidad técnica pero puede tener alta prioridad de negocio. Esta distinción es básica para cualquier QA y su ausencia señala falta de experiencia en contextos de producto real.
La automatización no reemplaza el criterio humano del QA Manual; reemplaza la ejecución mecánica de casos repetitivos. Un QA Manual que ve la automatización como una amenaza a su rol demuestra falta de visión sobre cómo evoluciona la función de calidad. Los equipos maduros esperan que el QA Manual colabore activamente en la estrategia de automatización.