Blog

En los últimos años, la conversación sobre la Inteligencia Artificial en el mundo de la calidad de software ha oscilado entre dos extremos: el marketing corporativo que promete automatización autónoma sin esfuerzo (“el área debe vender” y después nosotros -el área técnica- debemos implementar la solución, ja), y el escepticismo de quienes han intentado usar herramientas genéricas encontrando solo «alucinaciones» o respuestas fuera de contexto (probablemente por no usar las técnicas apropiadas de prompt engineering y a partir de este año, loop engineering).

Para los que lideramos estrategias de calidad, el verdadero desafío no es encontrar la herramienta más vistosa, sino transitar del «pensamiento mágico» (que no existe) a la «ingeniería de contexto estructurada» (que sí existe).

Este artículo mi intención es establecer un puente metodológico entre el glosario de capacidades tecnológicas de Claude (Anthropic) y las prácticas formales de la Gestión de Pruebas (Test Management). Analizo bajo un enfoque práctico y realista cómo estas capacidades cognitivas impactan en el día a día de todo tester, equipo de testers y test lead / test manager, compartiéndoles un marco de acción para mejorar sus procesos actuales o reestructurar sus flujos de trabajo de QA asistidos por IA.

1. Conceptos fundamentales de IA: La infraestructura cognitiva del QA

Para que un Test Lead pueda diseñar una estrategia robusta, primero debe entender los límites físicos y lógicos del «motor» con el que trabaja.

1.1. Token: La unidad de medida del esfuerzo cognitivo

• Concepto: Un token es la unidad básica de procesamiento de un LLM (aproximadamente 4 caracteres en español). Es el «combustible» que consume la máquina tanto para leer tus instrucciones como para escribir la respuesta.
• Finalidad en QA: Actúa como el costo operativo de la infraestructura de IA. Permite calcular el volumen de información técnica que podemos procesar y estimar presupuestos si nos integramos vía API.
• Justificación y filtro de realidad: Un Test Lead debe gestionar el presupuesto de tokens como un activo financiero de la QMO (Quality Management Office). Si alimentas al modelo con una especificación de requisitos de 300 páginas para que derive casos de prueba de manera directa, el costo en tokens (y el riesgo de dispersión de atención) será altísimo.
• Punto de mejora: No hagas «dumping» de archivos gigantes. Aprende a aplicar técnicas de hojeado y escaneo (skimming & scanning) o usa filtros previos para procesar únicamente el módulo bajo análisis, ahorrando hasta un 60% en consumo de tokens sin perder precisión.

1.2. Ventana de contexto: La memoria de trabajo del tester

• Concepto: Es la cantidad total de tokens que el modelo puede «mantener en memoria» durante una sola conversación (en Claude, típicamente 200,000 tokens).
• Finalidad en QA: Permite inyectar documentación masiva (manuales de usuario, bases de código, especificaciones de APIs, logs de producción) para que la IA actúe con un contexto de negocio real.
• Justificación y filtro de realidad: Aunque Claude cuenta con una ventana masiva de 200K, existe el fenómeno de «pérdida en el medio» (el modelo atiende mejor al inicio y al final del prompt, pero puede ignorar detalles críticos en el centro).
• Punto de mejora: Si vas a subir un PRD (Product Requirement Document) extenso, utiliza delimitadores XML (ej. <requisitos_negocio> … </requisitos_negocio>) para guiar el mecanismo de atención del transformador. Esto evita que la IA ignore las reglas complejas situadas a mitad del documento.

1.3. No-determinismo: El desafío de la repetibilidad

• Concepto: A diferencia del software tradicional (donde una misma entrada siempre produce la misma salida), los LLM operan con probabilidades. Una misma instrucción puede generar respuestas redactadas de manera diferente en cada ejecución.
• Finalidad en QA: Entender esta propiedad permite diseñar prompts que limiten los «grados de libertad» del modelo según la rigidez requerida para el entregable.
• Justificación y filtro de realidad: Los testers estamos acostumbrados a la predictibilidad. Si un prompt genera una matriz de prueba impecable hoy, pero mañana genera una lista incompleta, el proceso no es escalable.
• Punto de mejora: Para tareas lógicas (como derivar clases de equivalencia o valores límite mediante BVA), exige un formato de salida rígido usando estructuras Markdown o JSON y configura la temperatura del modelo en un rango bajo (). Para lluvias de ideas de escenarios exploratorios o pruebas no funcionales, eleva la temperatura () para fomentar la «creatividad libre» y descubrir casos de borde (edge cases) que un humano podría omitir.

2. Funciones principales: Configurando el «cerebro» de pruebas

Aquí es donde configuramos el comportamiento dinámico de la IA para que actúe bajo los estándares rigurosos de nuestra disciplina.

Capacidades de Claude	Aplicación práctica en Testing	Framework recomendado
System Prompt	Definición de rol y límites del QA escéptico	RTF / RTCROS
Pensamiento extendido	Desglose lógico de cobertura antes del diseño	Chain of Thought (CoT)
Uso de herramientas	Integración con APIs de ejecución e Jira	Tool Use / Function Calling

2.1. System Prompt (Instrucciones del Sistema)

• Concepto: Es la directiva de nivel superior que define la identidad, reglas de comportamiento, tono y restricciones que la IA debe adoptar de forma persistente.
• Finalidad en QA: Moldear el comportamiento de Claude para que actúe, por ejemplo, como un «QA Lead escéptico experto en análisis de riesgos» en lugar de un redactor genérico que acepta cualquier historia de usuario como válida.
• Justificación y filtro de realidad: Sin un System Prompt configurado profesionalmente mediante el patrón de rol (ej. RTCROS: Role, Task, Context, Reasoning, Output Format, Stop Conditions), la IA pecará de condescendiente. Te dirá que tus requisitos son perfectos cuando en realidad están plagados de ambigüedades.
• Punto de mejora: Configura un System Prompt corporativo que incluya un protocolo de retroalimentación. Obliga al modelo a cuestionar las especificaciones incompletas antes de proponer casos de prueba.

2.2. Pensamiento extendido (Extended Thinking / CoT)

• Concepto: Es la capacidad de la IA para generar una secuencia de pasos de razonamiento interno visibles antes de entregar la respuesta final.
• Finalidad en QA: Forzar a la IA a desglosar matemáticamente y metodológicamente la cobertura antes de escribir los casos de prueba finales.
• Justificación y filtro de realidad: Si le pides directamente a un LLM: «Genera los casos de prueba para este campo que acepta de 1 a 10», es muy probable que te devuelva ejemplos redundantes o que omita valores críticos. Al aplicar Chain of Thought (CoT), el modelo calcula primero los límites lógicos () y justifica sus decisiones paso a paso, aumentando la fidelidad técnica del artefacto final.
• Punto de mejora: Utiliza frameworks de prompting de producto como R.I.S.E. (Request, Input, Scenario, Expectation) o C.L.I.M.B. (Context, Limitations, Inputs, Method, Benchmark). En el prompt, escribe explícitamente: «Razona paso a paso la cobertura aplicando Partición de Equivalencias antes de estructurar la tabla de casos».

2.3. Uso de herramientas (Tool use / Function calling)

• Concepto: Capacidad del modelo de decidir cuándo y cómo llamar a una función de software externa (una API, una base de datos) para complementar su razonamiento con datos precisos del mundo real.
• Finalidad en QA: Automatizar la transición entre el análisis analítico y la acción operativa en el ciclo de vida del testing.
• Justificación y filtro de realidad: La IA por sí sola no puede «ver» el estado actual de tu suite en Jira o el resultado de un pipeline en Jenkins. Al habilitar el uso de herramientas, Claude puede leer un reporte de logs de error, decidir consultar el estado del ticket relacionado, y actualizar el informe de defectos de forma automatizada.
• Punto de mejora: Diseña un flujo donde la IA analice la respuesta en JSON de un endpoint fallido mediante Postman, use una herramienta para comprobar si el bug ya fue reportado en Jira y, si no, estructure y envíe un nuevo reporte formateado bajo las mejores prácticas de Bug Advocacy.

3. Productos del ecosistema: Espacios de trabajo colaborativos para QA

¿Cómo llevamos estos conceptos a la práctica diaria de un equipo ágil? Anthropic organiza estas capacidades en herramientas listas para usar.

3.1. Projects (Proyectos)

• Concepto: Espacios dentro de Claude que permiten agrupar chats, documentos de conocimiento compartidos (playbooks, guías de estilo, historias de usuario) e instrucciones personalizadas bajo un único entorno temático.
• Finalidad en QA: Crear un «asistente experto» exclusivo para un proyecto o sprint específico, garantizando que todas las interacciones mantengan la alineación contextual adecuada.
• Justificación y filtro de realidad: El principal dolor de cabeza de los testers que usan chats tradicionales es tener que reintroducir el contexto en cada nueva conversación. Al estructurar un «Proyecto de QA», los artefactos del proyecto quedan cargados persistentemente.
• Punto de mejora: Sube las especificaciones técnicas de tus APIs (Swagger/OpenAPI), la guía de estándares de automatización de tu empresa (ej. con Playwright o Cypress), y el manual de negocio al proyecto. A partir de allí, cualquier miembro del equipo puede pedirle al asistente que redacte un script de prueba que se ajuste perfectamente a la arquitectura de la organización sin tener que explicar las reglas desde cero.

3.2. Artifacts (Artefactos)

• Concepto: Interfaz visual separada del hilo de chat donde Claude muestra, edita y organiza bloques de contenido extensos y estructurados (como código, documentos markdown o diagramas SVG).
• Finalidad en QA: Separar la conversación de análisis (el porqué se hace la prueba) de la entrega de los entregables de calidad (el plan de pruebas, los scripts o las plantillas Gherkin).
• Justificación y filtro de realidad: Copiar código de automatización o tablas masivas de un chat conversacional es incómodo y propenso a errores de formato. Los Artifacts permiten un control de versiones de los entregables propuestos por la IA directamente en pantalla.
• Punto de mejora: Cuando le pidas a Claude que diseñe los escenarios en Gherkin para una historia de usuario, indícale que cree un Artifact llamado escenarios_sprint_X.feature. Esto permite al Test Lead leer el análisis en el chat y, en paralelo, ver el archivo listo para descargar o copiar en su repositorio de código sin contaminación de texto.

3.3. Model Context Protocol (MCP)

• Concepto: Un estándar abierto propuesto por Anthropic para conectar modelos de IA de forma segura a fuentes de datos locales y herramientas (como bases de datos PostgreSQL, repositorios de GitHub o carpetas locales de tu equipo).
• Finalidad en QA: Eliminar el tedioso «copiar y pegar» integrando al asistente de IA de forma nativa con los repositorios de pruebas y las bases de datos de prueba del equipo.
• Justificación y filtro de realidad: Los entornos empresariales reales requieren seguridad y dinamismo. Con el protocolo MCP, Claude no necesita que le subas manualmente un archivo JSON de base de datos; puede consultar directamente el esquema de base de datos local en tu máquina o leer los últimos commits de tu rama de desarrollo para identificar qué archivos han cambiado y sugerir la cobertura de regresión adecuada.
• Punto de mejora: Configura un servidor MCP para conectar el IDE de tu equipo de automatización con Claude. El asistente podrá analizar el código de prueba local, identificar scripts «rotos» por cambios de UI, y proponer la autoreparación (auto-healing) directamente en tu entorno local.

4. Agentes y Automatización: El horizonte del testing autónomo

De los chats conversacionales a la automatización de procesos de extremo a extremo. Así se configuran los flujos de trabajo de nueva generación.

4.1. Workflows Agénticos: Orquestador y Distribuidor (Dispatch)

• Concepto: Arquitectura de software donde un «Agente Orquestador» central analiza la tarea compleja de testing, la divide en subtareas lógicas, y las deriva a «Agentes Distribuidores» especialistas en dominios específicos de calidad.
• Finalidad en QA: Ejecutar flujos de pruebas híbridas de alta complejidad (rendimiento, seguridad, usabilidad) de forma coordinada y autónoma.
• Justificación y filtro de realidad: Un único agente de IA que intente validar la interfaz, revisar la seguridad de las peticiones HTTP y medir el tiempo de respuesta del servidor colapsará bajo el peso de su propia complejidad. La arquitectura orquestador-distribuidor imita la estructura de un equipo de QA real.
• Punto de mejora: Implementa un agente central que reciba el reporte diario de construcción (build) de tu software. Este agente «distribuye» las tareas: envía las nuevas APIs al agente especialista en pruebas unitarias e integración, los cambios visuales al agente especialista en UI, y consolida las alertas generadas por ambos en un único informe ejecutivo para el Test Lead.

4.2. Uso de computadora (Computer use)

• Concepto: Capacidad avanzada que permite a Claude interactuar físicamente con un sistema operativo a nivel de interfaz de usuario (moviendo el cursor del mouse, haciendo clic en botones, escribiendo texto y capturando pantallas) tal como lo haría un usuario humano.
• Finalidad en QA: Habilitar la automatización de pruebas exploratorias dinámicas y pruebas de extremo a extremo (E2E) en aplicaciones complejas sin necesidad de código rígido de automatización.
• Justificación y filtro de realidad: La automatización tradicional basada en localizadores (XPath, selectores CSS) es propensa a romperse ante mínimos cambios estéticos (un cambio de texto de «Login» a «Sign In» rompe el test). La IA con capacidad de «Computer Use» no lee el código HTML de fondo; mira la pantalla de manera cognitiva. Si el botón cambia de color o de texto, lo sigue identificando como el objetivo de inicio de sesión debido a su comprensión visual.
• Punto de mejora: Diseña un flujo de pruebas exploratorias periódicas donde indiques a Claude: «Accede al portal web, simula la compra del producto X usando un cupón vencido y reporta los comportamientos anómalos o de bloqueo de la UI». Esto te permite descubrir fallos de accesibilidad, problemas visuales de superposición y errores de flujo lógico de negocio que escapan a los scripts estructurados de Selenium o Cypress.

5. El «filtro de realidad»: La fusión del tester y la IA (El enfoque centauro)

La adopción de la IA generativa aplicada al Test Management no busca reemplazar al equipo de control de calidad. Su verdadero objetivo es optimizar el tiempo operativo para que la capacidad analítica humana se enfoque en donde realmente genera valor: la evaluación de riesgos de negocio complejos, la empatía con el usuario final y la toma de decisiones éticas y de cumplimiento.

La adopción óptima ocurre bajo el enfoque del «Tester Centauro» (co-creación Humano-IA):

1. La IA propone, el Humano valida: Nunca utilices las salidas de un modelo de lenguaje de forma directa en producción o planes de prueba sin una revisión minuciosa. El tester actúa como el conductor crítico del modelo.
2. Pasa de «Prompts Mágicos» a plantillas: En lugar de buscar la instrucción perfecta en foros, crea tus propios playbooks documentados e incorpóralos en proyectos de Claude.
3. Mide la madurez de tu equipo: La incorporación de IA debe ser un proceso gradual. Evalúa la capacidad técnica del equipo, establece métricas claras de adopción (ej. reducción del tiempo de documentación, ampliación de escenarios críticos de riesgo) y calibra la suite de herramientas según las políticas de privacidad de datos de tu organización.

El futuro de la calidad no pertenece a las máquinas que prueban solas, sino a los equipos de QA que dominan la ingeniería de contexto para guiar a las máquinas a probar mejor. ¿Entonces? ¿En qué tramo de tus procesos de testing vas a comenzar a aplicar este mapeo estratégico hoy? ¿Necesitas ayuda? 

Puedes contactarme por DM desde LinkedIn y seguir mis publicaciones también.-

Muchas gracias por seguirme