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 chatbot.

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 chatbot.
• Additional Context: describe en lenguaje natural el contexto del chatbot, 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 chatbot 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 desde 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.

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.