Diseñar los tests

Las 4 vías para crear test cases

Generación con IA

Ve a Test Design → AI Generation. La IA genera test cases adaptados al dominio de tu agente de IA.

Parámetros de generación

• Industry: 15 dominios soportados (general, customer support, healthcare, finance, ecommerce, travel, telecom, education, legal, hr, saas, insurance, real estate, food, safety). Cada uno tiene un prompt específico afinado.
• Test Type: Simple Q&A (un par pregunta/respuesta) o Conversational (varios turnos).
• Quantity: cantidad de casos a generar.
• Language: Spanish o English.
• Context Sources: selecciona qué fuentes de contexto incluir (knowledge bases del proyecto) para que los casos sean específicos al dominio real del agente de IA.
• Additional Context: describe en lenguaje natural el contexto del agente de IA, qué tipos de pregunta quieres cubrir, ejemplos de tono, etc. Cuanto más contexto, más relevantes los casos.

Parámetros avanzados

Adicional a la configuración básica, puedes afinar la generación con:

• User Tone — el tono con que la IA simula al usuario en los casos generados. Chips disponibles: Formal, Informal, Angry, Confused, Brief, Detailed. Combinables — útil para validar cómo se comporta el agente de IA ante usuarios molestos, confusos, o que escriben muy corto.
• Risk Categories — focaliza la generación en vulnerabilidades específicas. Chips disponibles:
  • Bias — discriminación por género, raza, edad, religión.
  • Hallucinations — datos inventados o fuentes ficticias.
  • Prompt Injection — jailbreaks, override de rol, leak del system prompt.
  • Data Leakage — exposición de PII, extracción de datos sensibles.
  • Harmful Content — instrucciones peligrosas, guías ilegales.
  • Toxicity — insultos, lenguaje hostil, discurso de odio.
  • Inconsistency — respuestas contradictorias, drift de contexto.
  • Robustness — typos, ambigüedad, inputs malformados.
  • Knowledge Limits — info desactualizada, preguntas fuera de dominio.
  • Emotional Manipulation — guilt-tripping, coerción emocional, presión por urgencia.

Si no seleccionas ninguna Risk Category, la IA genera tests funcionales estándar. Seleccionar categorías es la forma de armar suites focalizadas en seguridad y robustez.

Vista de revisión

Los casos generados no entran directo a tu base de test cases. Quedan en una vista de revisión donde para cada caso puedes:

• Editarlo — ajustar input, respuesta esperada, asserts, tipo, etc.
• Enviarlo a tu catálogo de Test Cases — queda disponible para sumarlo después a las suites que quieras.
• Enviarlo directo a una Test Suite específica — útil si ya sabes a qué suite pertenece.
• Descartarlo — si no aporta o quedó mal generado.

Esto mantiene un humano en el loop, evita que entren casos irrelevantes y te da control total sobre qué se incorpora a tu testing.

Desde el catálogo público

ArtificialQA mantiene un catálogo público con más de 25.000 test cases curados por industria, listos para importar a tu proyecto. Es la forma más rápida de empezar con casos validados sin tener que generar ni escribir nada desde cero.

• Filtra por industria, tipo de caso (Simple / Conversational), riesgo, idioma o palabra clave.
• Previsualiza cada caso antes de importarlo.
• Selecciona los que te interesan e impórtalos a tu base de Test Cases — pasan por la vista de revisión, igual que los generados con IA, donde puedes editarlos o mandarlos a una Test Suite específica.

Útil para empezar un proyecto nuevo, complementar tus casos propios con baterías de seguridad/sesgo/hallucinations, o mantenerte al día con casos nuevos que sumemos al catálogo.

Importación y exportación Excel / JSON

Ve a Test Design → Import.

El sistema acepta Excel (.xlsx) o JSON con un esquema definido. Te ofrece descargar un template para que escribas los casos en el formato correcto.

Campos principales que se mapean:

• input — la pregunta del usuario.
• expected_response — la respuesta esperada (para evaluadores que la usan).
• tags — etiquetas opcionales para organizar.
• turns — para casos conversacionales, lista ordenada de mensajes user/assistant.

También podés exportar tus test cases existentes como JSON desde el listado de Test Cases (el archivo exportado usa el mismo esquema que el endpoint de import, así que podés exportar, editar externamente y reimportar). Útil para control de versiones, compartir baterías de casos entre proyectos o armar automatizaciones sobre la API.

Creación manual

Ve a Test Design → Test Cases → New Case.

• Elige el tipo (Simple o Conversational).
• Escribe el input y la respuesta esperada.
• Agrega asserts determinísticos si quieres.
• Guarda; el caso queda disponible para sumar a una Test Suite.

Editar test cases ya creados

Un test case se puede modificar después de creado — ajustas el input, la respuesta esperada, los asserts o cualquier otro campo, y guardas. La plataforma se asegura de que la edición no rompa la trazabilidad histórica:

• Se conserva la versión original del test case asociada a las corridas previas. Si un Run viejo usó la versión anterior del caso, ese Run sigue mostrando exactamente el caso que se ejecutó esa vez — sin importar cuántas veces edites el caso después.
• Al guardar el cambio, la plataforma te pide una nota explicando el motivo de la edición (por ejemplo: "ajusté la respuesta esperada después de un cambio en el flujo del bot"). Esta nota queda registrada en el historial del test case.

El resultado: las ediciones son seguras desde el punto de vista de auditoría. Tú puedes iterar libremente sobre tus casos sin miedo a perder evidencia de qué se ejecutó cuándo.

Casos conversacionales (multi-turno)

Cuando un test case es Conversational, defines una secuencia de turnos. Cada turno es un par (usuario dice X → se espera que el bot responda con Y o cumpla las características Z).

Es lo que hay que usar para validar flujos como: pedir una cotización, hacer una reserva, escalar a humano. Pruebas todo el diálogo, no solo la primera respuesta.

Asserts determinísticos

Verificaciones programáticas que no dependen de IA. Tipos disponibles:

• exact_match — la respuesta debe coincidir exactamente.
• regex — la respuesta matchea una expresión regular.
• contains / not_contains — la respuesta contiene (o no) una subcadena.
• json_schema — la respuesta valida contra un JSON Schema.
• numeric_range — un valor numérico extraído está dentro de un rango.
• response_time — el tiempo de respuesta es menor a un umbral.
• keyword_present — al menos una palabra clave aparece en la respuesta.
• classification — la respuesta encaja en una categoría predefinida.

Cada assert puede ser hard (si falla, el test case falla) o soft (queda como observación, no bloquea el resultado).

Test Suites: agrupar casos

Ve a Test Design → Test Suites → New Suite. Le pones un nombre y agregas los test cases que la componen. Un mismo caso puede vivir en varias suites.

Estrategias típicas de agrupación:

• Por flujo: "Onboarding", "Cotización", "Soporte post-venta".
• Por nivel de criticidad: "Críticos", "Regresión", "Smoke".
• Por release: "v1.4 — nuevas funcionalidades".
• Por dimensión: "Seguridad", "Datos sensibles", "Manejo de errores".

Próximo paso

Una vez que tienes tus suites armadas, lo siguiente es ejecutarlas.