Cómo probar flujos conversacionales de WebChat antes de publicar

Define el alcance: prueba flujos, no todo el lanzamiento

Un widget visible en una página no demuestra por sí solo que una conversación funcione de principio a fin. Esta guía se centra en probar flujos conversacionales de WebChat: los pasos que sigue una persona, las respuestas que recibe y el resultado previsto. No es una especificación completa de lanzamiento ni sustituye las verificaciones operativas que tu equipo necesite realizar.

Antes de empezar, separa las preguntas. ¿El recorrido conduce al resultado previsto? ¿Se completan las llamadas al backend que forman parte del flujo? ¿Se usa correctamente la información anterior de la conversación? Y, por otro lado, ¿se ha comprobado la instalación del widget, la recepción y asignación de conversaciones, y el cumplimiento de requisitos de privacidad, accesibilidad y seguridad? Mantener estas categorías separadas evita dar por validado el lanzamiento completo a partir de una sola prueba conversacional.

El alcance operativo depende de la configuración y las obligaciones de cada equipo. Por eso, define quién verifica cada aspecto y qué evidencia necesita antes de publicar. Las fuentes enlazadas al final respaldan recomendaciones generales de prueba conversacional; no establecen una lista oficial de aceptación específica de WebChat.

• Elige situaciones representativas de los recorridos que realmente planeas publicar.
• Anota qué queda fuera de la prueba conversacional, como los controles de instalación, operación, privacidad, accesibilidad y seguridad.
• No declares listo todo el lanzamiento basándote únicamente en que un flujo conversacional se haya completado.

Mapea situaciones y resultados esperados

Empieza con situaciones concretas, no con una lista abstracta de funciones. Por ejemplo, puedes describir una pregunta frecuente o una solicitud que deba pasar de un flujo automatizado a una persona. Elige las situaciones que correspondan al alcance real de tu publicación; no es necesario suponer que todos los equipos tienen los mismos recorridos.

Para cada situación, traza los pasos desde el primer mensaje hasta el resultado final. Incluye lo que la persona escribe o selecciona, la respuesta que se espera, las posibles bifurcaciones y cualquier transferencia configurada. Un resultado esperado debe ser lo bastante claro para comparar lo que ocurre durante la prueba, no solo una impresión general como «parece funcionar».

La recomendación de mapear cada situación antes de realizar pruebas manuales coincide con el material de Testim enlazado más abajo. Puedes comenzar con una ejecución manual. Si tu equipo elige automatizar pruebas o añadirlas a una canalización de integración continua, trátalo como una práctica que debe planificarse y mantenerse; no como una capacidad garantizada por WebChat.

• Anota el punto de inicio, cada paso del recorrido y el resultado previsto.
• Incluye las bifurcaciones y transferencias que pertenezcan a la situación elegida.
• Registra qué se probó, quién lo revisó y qué sigue pendiente, sin marcar pasos no ejecutados como verificados.

Ejecuta los recorridos completos y revisa las llamadas al backend

Ejecuta cada situación en el orden que definiste y compara el resultado observado con el esperado. Revisa la conversación entera, no solo el mensaje final: un paso intermedio puede cambiar la ruta, omitir una respuesta o impedir que el flujo llegue al destino previsto. Si detectas una diferencia, anótala junto con los pasos necesarios para reproducirla.

Cuando un recorrido incluya llamadas a la API del backend, comprueba por separado que cada llamada se complete. Que la persona vea una respuesta no confirma por sí solo que todas las llamadas necesarias hayan terminado. La recomendación de probar recorridos completos y verificar sus llamadas al backend está respaldada por el artículo de Cekura enlazado en la sección de fuentes.

La forma de observar y confirmar esas llamadas dependerá de las herramientas y la configuración de tu equipo. No compartas credenciales, datos personales ni información sensible en capturas o registros de prueba. Si una llamada falla, conserva una descripción segura del escenario y los pasos para repetirlo, y deriva el problema al responsable correspondiente.

• Sigue todos los pasos del escenario y compara cada resultado con lo que se había definido.
• Confirma por separado la finalización de cada llamada al backend que forme parte del flujo.
• Registra los fallos de forma que puedan reproducirse sin incluir secretos ni datos reales innecesarios.

Comprueba el uso del contexto y los pasos automatizados

Si una respuesta depende de información compartida anteriormente, comprueba si el flujo utiliza esa información después de que hayan intervenido otros turnos. Una prueba sencilla puede incluir un dato ficticio en un turno, dos preguntas no relacionadas y una referencia posterior al dato. Compara la respuesta con el comportamiento previsto para ese escenario.

Esta comprobación sigue el ejemplo descrito por Autonoma: evaluar si el chatbot usa correctamente un dato anterior después de turnos no relacionados. Es una prueba de un caso concreto, no una demostración de que el contexto se conservará correctamente en todas las conversaciones posibles.

Si el recorrido usa funciones de automatización de webchat.vip, prueba los pasos que efectivamente hayas configurado. La plataforma permite crear flujos que envían mensajes y archivos, recopilan respuestas validadas, crean bifurcaciones y transfieren conversaciones a personas. La existencia de estas opciones no significa que cada flujo esté configurado correctamente: verifica el comportamiento de tu escenario y cualquier salida hacia una persona como parte del recorrido completo.

• Usa información inventada para probar el contexto y no incluyas datos personales reales.
• Incluye turnos intermedios no relacionados antes de comprobar si se usa el dato anterior.
• Prueba las respuestas validadas, bifurcaciones y transferencias solo cuando formen parte del flujo publicado.

Incluye verificaciones operativas y requisitos responsables

La prueba de conversación no sustituye las comprobaciones operativas que acompañan una publicación. Como lista de trabajo para tu equipo, verifica por separado que el widget esté instalado y se muestre donde se espera; que una conversación de prueba llegue al espacio de trabajo previsto; y que la asignación o transferencia funcione de acuerdo con la configuración que hayas definido. webchat.vip ofrece un widget instalable y personalizable para cada canal de WebChat, además de una bandeja compartida que permite organizar operadores, departamentos, enrutamiento y horarios. Estos son elementos que puedes considerar al establecer tus propias verificaciones, no una garantía de que una configuración particular ya esté correcta.

Trata privacidad, consentimiento, accesibilidad y seguridad como requisitos operativos. Antes de publicar, determina qué avisos o consentimientos corresponden a tu caso y confirma que estén presentes cuando sean necesarios. Prueba con datos ficticios y limita el acceso a los registros de prueba a las personas autorizadas. Evita exponer credenciales o información sensible en mensajes, capturas y documentación.

Define también qué significa que la experiencia sea utilizable para las personas a quienes va dirigida. Por ejemplo, el equipo puede comprobar el uso con teclado, la claridad de las instrucciones y la legibilidad de los mensajes dentro de su proceso de accesibilidad. La guía no certifica conformidad ni atribuye esas propiedades al widget: son controles que deben validarse según los requisitos aplicables a tu organización.

Por último, decide cómo se solicita ayuda humana cuando el recorrido no resuelve la situación. Prueba la transferencia si está configurada y confirma que forma parte del resultado esperado. La disponibilidad de una opción de transferencia no sustituye la decisión del equipo sobre cuándo debe intervenir una persona.

• Comprueba la instalación y visualización del widget, así como la recepción y asignación de una conversación de prueba, usando criterios definidos por tu equipo.
• Revisa privacidad, consentimiento, accesibilidad y seguridad como requisitos independientes del éxito del flujo.
• Verifica la ruta de ayuda humana cuando forme parte de la experiencia prevista.

Establece criterios de publicación y conserva un registro

Un criterio de publicación útil debe permitir una decisión explícita, no una suposición. Antes de probar, especifica qué situaciones deben completarse, qué llamadas al backend deben confirmarse y qué verificaciones operativas son necesarias para tu organización. Asigna una persona responsable y establece cómo se registran los fallos. El contenido de las fuentes citadas no fija umbrales universales ni un criterio oficial de «apto para publicar» para WebChat; esos criterios corresponden a tu equipo.

Guarda un registro conciso con la situación, la fecha de la prueba, los pasos realizados, el resultado esperado, lo observado y el estado. Añade los problemas pendientes y quién debe revisarlos. Después de cambiar un flujo, repite las pruebas pertinentes y anota cuáles se ejecutaron de nuevo. Así puedes distinguir entre lo que se probó y lo que todavía no tiene evidencia.

Las fuentes respaldan prácticas generales, con límites concretos: Cekura recomienda probar recorridos principales de principio a fin y verificar cada llamada al backend; Testim describe identificar situaciones, mapear pasos y realizar pruebas manuales, además de mencionar automatización y CI; Autonoma presenta una comprobación del uso del contexto después de turnos no relacionados. No son una especificación completa de instalación, asignación, privacidad, accesibilidad o seguridad de webchat.vip.

• Cekura, «How to Test AI Chat Workflows Before Launching? 5 Methods»: https://www.cekura.ai/blogs/how-to-test-ai-chat-workflows-before-launching
• Testim, «End-To-End Testing: The One Guide To Rule Them All»: https://www.testim.io/blog/end-to-end-testing-guide/
• Autonoma, «The Chatbot Testing Checklist (Functional, LLM, and ...)»: https://getautonoma.com/blog/chatbot-testing-checklist
• Decide la publicación según los criterios de tu equipo y registra cualquier aspecto pendiente; una prueba de flujo, por sí sola, no certifica todo el lanzamiento.