QA

Empieza por entender el cambio, los criterios de aceptación y qué fallas perjudicarían más a las personas usuarias o al negocio. Aclara alcance, dependencias, datos, entornos, responsables y evidencia esperada. Prioriza los caminos críticos y riesgos altos; elige pruebas rápidas que den retroalimentación antes y reserva tiempo para explorar áreas inciertas. Haz explícito qué no alcanzará a probarse y qué riesgo queda, para que la decisión de salida sea informada.

El testing puede revelar defectos y aportar evidencia de cómo se comporta el producto bajo condiciones probadas; no puede demostrar que no existan defectos ni cubrir todas las entradas y contextos posibles. QA es más amplio que ejecutar pruebas: incluye mejorar requisitos, diseño, procesos y colaboración para prevenir problemas y sostener la calidad. Por eso, comunica hallazgos, cobertura y riesgo residual, en vez de prometer que un producto está libre de errores.

Los niveles describen el alcance: componente o unidad, integración entre componentes, sistema completo, integración entre sistemas y aceptación. Los tipos describen la propiedad evaluada: funcionalidad, rendimiento, seguridad, usabilidad, entre otras, y pueden aplicarse en varios niveles. Por ejemplo, una prueba de rendimiento puede evaluar un componente o el sistema completo. Separar estos conceptos ayuda a elegir evidencia complementaria sin duplicar pruebas innecesariamente.

Las pruebas estáticas examinan requisitos, código, diseños u otros artefactos sin ejecutar el software, mediante revisiones o análisis estático; pueden detectar ambigüedades y defectos temprano. Las dinámicas ejecutan el producto y analizan sus resultados para encontrar fallas. La verificación pregunta si el artefacto cumple sus especificaciones; la validación pregunta si resuelve la necesidad real de sus usuarios. Se complementan: una revisión puede encontrar requisitos contradictorios que una prueba de ejecución no revela.

Usa particiones de equivalencia para agrupar valores que deberían comportarse de forma similar y análisis de valores límite para probar alrededor de los extremos. Aplica tablas de decisión cuando varias condiciones cambian el resultado, y pruebas de transición de estado cuando importa el orden de acciones. Por ejemplo, para un campo de 1 a 100, prueba valores representativos dentro y fuera del rango y los límites 0, 1, 100 y 101. Combina técnicas según la lógica y el riesgo, no como una lista mecánica.

Parte de una condición verificable de un requisito, historia o riesgo y especifica precondiciones, datos, pasos y resultado esperado. Ese resultado esperado debe tener un oráculo confiable, como una regla de negocio, contrato de API o criterio de aceptación. Mantén un vínculo entre requisito, riesgo, prueba y resultado para identificar áreas sin cobertura y evaluar el impacto de cambios. Evita pasos ambiguos como “comprobar que funciona”; indica qué comportamiento observable confirma el éxito.

Identifica qué puede fallar y estima probabilidad e impacto para usuarios, operaciones, seguridad o cumplimiento. Prioriza escenarios de alto riesgo, por ejemplo, pagos, permisos o pérdida de datos; define más cobertura o pruebas independientes donde el daño potencial sea mayor. Reevalúa al cambiar código, dependencias o uso, y cuando llegan datos de incidentes. La puntuación ayuda a ordenar el esfuerzo, pero no sustituye el criterio del equipo ni una conversación sobre riesgos aceptados.

Automatiza comprobaciones repetibles, deterministas y valiosas por su frecuencia o por el costo de ejecutarlas manualmente. Suele convenir tener muchas pruebas de componente, una cantidad intermedia de integración o API y menos recorridos completos de interfaz, que tienden a ser más lentos y sensibles al entorno. No es una proporción obligatoria: el riesgo y el costo de mantenimiento mandan. Mantén juicio humano para exploración, evaluación de usabilidad y escenarios nuevos; mide si la automatización aporta retroalimentación confiable.

Comprueba que cada operación respete el contrato acordado: método, ruta, parámetros, encabezados, códigos de estado, estructura y tipos de los datos, y reglas de negocio. Incluye respuestas de éxito y error, campos requeridos u opcionales y compatibilidad ante cambios de versión. Si existe una especificación, valida que consumidor y proveedor coincidan con ella. No basta con recibir HTTP 200: la respuesta debe ser correcta y útil para quien consume la API.

Prueba cada operación con usuarios autenticados con roles distintos, sin autenticación y con acceso a recursos propios y ajenos. Verifica que el servidor rechace acceso no autorizado y no filtre propiedades sensibles, incluso si se manipulan identificadores o campos del cuerpo. Comprueba datos inválidos, límites, paginación, idempotencia si aplica, rate limiting y fallas de dependencias. Una respuesta de error debe ser segura y consistente, sin exponer secretos, trazas internas ni datos de otros usuarios.

Cubre con interfaz los recorridos críticos que dependen de la interacción real, como iniciar sesión o completar una compra. Localiza controles por rol, nombre accesible o texto visible, en vez de acoplarte a clases CSS o a la estructura interna del DOM. Cada prueba debe poder ejecutarse sola con estado y datos controlados, y comprobar un resultado observable. Usa esperas basadas en condiciones, no pausas fijas; reserva UI para flujos clave y prueba reglas de negocio con capas más rápidas.

Úsalo cuando los requisitos son incompletos, el cambio es nuevo, aparecen patrones de fallas o quieres descubrir problemas que los casos existentes no anticipan. Define una misión y un tiempo acotado, explora con libertad y registra rutas, datos, hallazgos y preguntas. Si encuentras un defecto, busca una reproducción mínima y crea una prueba automatizada cuando sea estable y valiosa. Exploratorio no significa improvisado ni reemplaza la regresión sistemática: complementa la cobertura conocida con aprendizaje.

Cubre datos válidos, inválidos, límites, combinaciones y estados necesarios para cada escenario. Usa datos sintéticos o anonimizados, evita copiar información personal de producción y controla quién puede acceder a ellos. Prepara valores deterministas y únicos para que las pruebas puedan repetirse sin colisiones; elimina o restablece los datos al terminar. Documenta supuestos como zona horaria, moneda y localización, porque pueden cambiar resultados aunque el código sea el mismo.

Mantén versiones de aplicación, configuración y dependencias controladas y visibles. El entorno debe ser lo bastante parecido a producción para revelar diferencias relevantes, pero aislado de usuarios y datos reales. Usa servicios simulados cuando se necesite controlar fallas o respuestas externas; usa integración real cuando la compatibilidad con ese servicio sea parte del riesgo. Registra diferencias conocidas, restablece el estado entre ejecuciones y evita que cambios no coordinados vuelvan irreproducible un resultado.

En cada cambio, ejecuta primero verificaciones rápidas como formato, análisis estático, compilación y pruebas de componente; luego agrega integración y API, y un conjunto pequeño de recorridos críticos de interfaz. Ejecuta matrices amplias o pruebas costosas de forma programada cuando corresponda. Fija versiones y datos, establece límites de tiempo y publica resultados, registros o trazas útiles. Una falla debe señalar qué comprobación falló y bloquear la integración según criterios acordados, con una ruta clara para investigar o corregirla.

Confirma que el fallo ocurre de forma variable con el mismo cambio y guarda la evidencia de una ejecución fallida. Busca condiciones de carrera, estado compartido, datos no aislados, esperas arbitrarias, límites de recursos o dependencias externas. Haz la prueba independiente y determinista; reemplaza pausas fijas por esperas de estado cuando sea apropiado. No ocultes la falla con reintentos ilimitados ni excluyas la prueba indefinidamente: registra responsable y plazo de reparación, y distingue un fallo del producto de inestabilidad del entorno.

Define el objetivo antes de generar carga: volumen esperado, concurrencia, latencia objetivo, tasa de errores y duración. Elige un perfil que represente el uso previsto, como carga constante, incremento gradual o pico; prepara datos y dependencias realistas, y evita que la máquina generadora sea el cuello de botella. Observa percentiles de latencia, throughput, errores y recursos del sistema. Prueba por separado carga normal, picos y duración sostenida; compara resultados bajo condiciones consistentes y no extrapoles de una prueba pequeña sin justificarlo.

Integra revisiones y análisis estático temprano, y prueba dinámicamente amenazas pertinentes al producto: autenticación, autorización, validación de entradas, manejo de sesiones, configuración y exposición de datos. Usa modelos de amenazas para identificar activos, límites de confianza y abuso posible; prioriza con riesgo, no solo con una lista genérica. Emplea guías como OWASP para orientar cobertura, pero adapta pruebas a la arquitectura y complementa automatización con revisión experta cuando el impacto lo justifique. Las pruebas de QA no sustituyen una evaluación de seguridad especializada para sistemas de alto riesgo.

Usa WCAG como referencia y combina herramientas automáticas con revisión manual: ningún escáner encuentra todos los problemas. Recorre flujos clave solo con teclado, inspecciona foco y orden de navegación, comprueba nombres y roles accesibles, contraste, textos alternativos y mensajes de error, y prueba con tecnologías de asistencia cuando sea posible. Verifica en páginas y estados reales, no solo en componentes aislados. Registra alcance, criterio evaluado, evidencia y barreras; no afirmes conformidad total a partir de un porcentaje automático.

La prueba de confirmación repite el escenario que reveló el defecto y comprueba que la corrección lo resuelve. La prueba de regresión busca efectos no deseados del cambio en otras funciones, datos o integraciones. El alcance depende del impacto y de las dependencias: puede incluir componente, API, flujo de interfaz u otros sistemas. Si el defecto puede reaparecer, conserva una prueba estable en la suite adecuada y ejecuta suficiente regresión según el riesgo del cambio.

Registra título claro, versión y entorno, precondiciones, pasos mínimos, resultado esperado y real, frecuencia, impacto y evidencia como capturas, registros o traza. En triage, confirma la reproducción, descarta duplicados y decide severidad por el impacto y prioridad por la urgencia de resolverlo; son dimensiones relacionadas, pero distintas. Clasifica estado y responsable y comunica lo que falta para decidir. Un reporte debe ayudar a reproducir y resolver el problema, no limitarse a etiquetarlo como “crítico”.

Combina señales vinculadas a objetivos: cobertura de requisitos o riesgos, defectos encontrados antes y después de liberar, frecuencia de fallas, tasa de pruebas intermitentes, tiempo de retroalimentación y costo de corregir. La cobertura de código mide qué código ejecutan las pruebas, no si comprueban el comportamiento correcto. Evita metas aisladas como “cero defectos” o aumentar el número de casos, que pueden ocultar riesgos o promover volumen sin valor. Revisa tendencias y contexto junto con evidencia cualitativa.

Define necesidades como objetivos observables y medibles: por ejemplo, una acción debe completarse en un percentil de latencia bajo una carga concreta, o un flujo debe poder realizarse con teclado. Especifica alcance, contexto, umbral y método de medición antes de probar. Considera características como rendimiento, fiabilidad, seguridad, compatibilidad, accesibilidad y mantenibilidad, según el producto. Si un requisito usa términos vagos como “rápido” o “fácil”, acuerda qué evidencia y umbral permitirán evaluarlo.

Compara resultados con criterios de salida acordados: requisitos críticos cubiertos, pruebas obligatorias aprobadas, defectos bloqueantes resueltos y riesgos residuales entendidos por las personas responsables. Considera también cambios no probados, límites del entorno y señales de producción disponibles. Una suite verde no garantiza ausencia de defectos; una suite roja tampoco siempre indica un defecto del producto. Documenta la decisión, excepciones y mitigaciones, como despliegue gradual, monitoreo o reversión.

Involucra a QA, desarrollo y producto al refinar requisitos; revisa historias y criterios de aceptación antes de codificar para encontrar ambigüedades. Integra pruebas, análisis estático y retroalimentación temprana en el flujo de trabajo, y conserva pruebas de regresión de fallas importantes. En retrospectivas, identifica causas sistémicas —requisitos, diseño, datos, herramientas o coordinación— y asigna acciones concretas con seguimiento. Shift-left significa probar antes además de seguir probando en etapas posteriores, no trasladar toda la responsabilidad a una sola persona.

Para profundizar: temario oficial ISTQB CTFL v4.0.1, modelo de calidad ISO/IEC 25010:2023, buenas prácticas de Playwright y Playwright en CI, pruebas de respuesta de API en Postman y pruebas de rendimiento en Postman, OWASP Web Security Testing Guide y OWASP API Security Top 10, WCAG 2.2 del W3C.