Evidencia
Evidencia es la biblioteca de casos de prueba del espacio de trabajo. Un caso dice en palabras simples qué tiene que funcionar en tu app; un agente lo graba una vez con el navegador, y desde ahí Thulu lo repite solo en cada entorno, sin modelo de lenguaje, cada vez que tocás “Correr”, con un horario, después de un deploy o desde tu CI. Cada corrida deja un video, capturas anotadas y un pasó o falló por chequeo.
Los casos no necesitan una tarea. Está pensada para QA, producto y quien aprueba una release: gente que tiene que saber si la app funciona sin leer código ni logs.
La pantalla está en “Evidencia”, en la barra lateral (/evidence/). Antes se llamaba QA: /qa/ redirige a la pestaña “Desde tareas”, donde siguen los casos escritos dentro de las tareas (ver Casos de prueba y videos).
Conceptos
Sección titulada «Conceptos»| Concepto | Qué es |
|---|---|
| Caso | Qué tiene que funcionar: título, descripción, pasos, resultado esperado, prioridad, etiquetas y, si querés, un proyecto. Tiene una clave EV-1, EV-2… única en el espacio de trabajo. |
| Grabación | El guion de navegador que dejó el agente, con los pasos y los chequeos. Se descarga como JSON desde el caso. Las direcciones son relativas, así que la misma grabación corre en staging, en producción o en un Sandbox. |
| Entorno | Dónde corren los casos. Hay tres tipos, explicados abajo. |
| Tanda | Las corridas que arrancaron juntas: un “Correr todo”, un tic del horario o un deploy. Se ven en la pestaña “Corridas”. |
| Corrida | Un caso repetido en un entorno: estado, chequeos, video, capturas e informe. |
Los tres tipos de entorno:
| Tipo | Qué es | Qué casos corre |
|---|---|---|
| Entorno de un proyecto | Staging, producción o cualquier entorno del proyecto, con su dirección. Aparece también en la página del proyecto. | Los casos de ese proyecto y los que no tienen proyecto. |
| Sandbox | Una copia nueva del proyecto que Thulu levanta desde una rama con el script de inicio, sólo para esa tanda, y borra al terminar. Cada proyecto tiene uno. | Sólo los casos de ese proyecto. |
| Otro sitio | Cualquier dirección fuera de tus proyectos: una landing, el staging de un proveedor. | Todos los casos del espacio de trabajo. Su horario se puede acotar a un proyecto o una etiqueta. |
Los estados de un caso y de una corrida:
| Estado | Qué significa |
|---|---|
| “Falta grabar” | Ningún agente lo grabó, así que no puede correr. |
| “Sin correr” | Está grabado y espera su primera corrida. |
| “Pasó” | Pasaron todos los chequeos. |
| “Falló” | Falló un chequeo: la app no hizo lo esperado. |
| “Bloqueado” | Falló un paso antes de llegar a un chequeo (no encontró un botón, una página no cargó). |
| “En espera” | La corrida espera que se libere un runner. |
| “Corriendo” | Está corriendo ahora. |
| “No se pudo correr” | La corrida no llegó a probar nada: el entorno no respondió, el runner no arrancó o se cortó. Al abrirla dice la causa. No dice nada sobre la app. |
| “Cancelado” | Alguien canceló la tanda antes de que llegara a ese caso. |
Antes de empezar
Sección titulada «Antes de empezar»- Rol developer o más en el espacio de trabajo. Con rol viewer sólo podés mirar (ver Qué puede hacer cada rol).
- Un entorno con dirección. Sin entornos, “Grabar con agente” y “Correr en…” no tienen dónde ir. Para colgarlo de un proyecto, el proyecto tiene que existir antes (ver Proyectos); sin proyectos, el entorno nuevo sólo puede ser “Otro sitio”.
- Para grabar: un agente que tenga la etapa de chat con su prompt (ver Agentes) y una credencial de modelo para su motor (ver Credenciales y motores). El agente recibe el navegador para grabar aunque su etapa de chat no lo tenga configurado. En una instalación con Docker y el navegador en modo “uno por corrida”, los chats no reciben navegador y el agente no puede grabar.
- Para repetir: la instalación tiene que poder bajar la imagen del navegador (argus-browser). Cada tanda corre en un contenedor o pod propio con esa imagen.
- Para el Sandbox: el proyecto tiene que tener un script de inicio que diga en qué puerto escucha la app (ver Sandbox).
Flujo recomendado: del primer caso a las corridas automáticas
Sección titulada «Flujo recomendado: del primer caso a las corridas automáticas»-
Agregá el entorno donde vas a probar. Abrí “Evidencia” en la barra lateral, pestaña “Entornos”, y tocá “Nuevo entorno”. En “Dónde corre” dejá “Un entorno de un proyecto” (o elegí “Otro sitio” si la app no es un proyecto de Thulu; si no tenés proyectos, esa elección no aparece), elegí el proyecto y completá “Nombre” y “Dirección” con la dirección completa,
https://incluido. El “Nombre corto” se arma solo y no se puede cambiar después.
El formulario de un entorno nuevo. Proyecto, nombre y dirección alcanzan para guardarlo. -
Si la app pide iniciar sesión, cargá los logins de prueba en el mismo formulario. Tocá “Agregar login de prueba”, escribí un nombre en mayúsculas (
QA_USUARIO,QA_PASSWORD) y su valor. Una vez guardado nadie puede volver a leer el valor, ni el agente: el navegador lo escribe en el campo sin que pase por el modelo. Usá sólo cuentas de prueba. Si la app abre otros dominios (un proveedor de login, una CDN), sumalos en “Otros sitios que puede abrir”, uno por línea. -
Elegí cuándo corre solo. En “Horario”, “Repetir” ofrece “Apagado”, “Cada hora”, “Todos los días a las…”, “De lunes a viernes a las…” y “A medida (cron)”, con la zona horaria. Debajo, “Corre:” repite en palabras lo que elegiste. En un “Otro sitio”, “Casos de” y “Con la etiqueta” acotan qué casos corre el horario, y una línea dice cuántos son (“Corre los 3 casos grabados de tienda-web.”); si no corre ninguno, también lo dice. Si el proyecto está en GitHub, tildá “Correr todos los casos grabados después de un deploy exitoso en GitHub”: escucha los deploys del repositorio del proyecto al entorno de GitHub con el mismo nombre corto. Tocá “Guardar”.
Logins de prueba, horario y disparo por deploy. Antes de guardar, Desde tu CI muestra el comando con un lugar para el id del entorno. -
Escribí el caso. En “Casos”, tocá “Nuevo caso” (o la tecla N). Sólo “Título” es obligatorio, pero el agente graba mejor con “Qué tiene que funcionar”, los “Pasos” uno por línea y el “Resultado esperado” escritos como se lo contarías a alguien del equipo. Elegí la prioridad, el proyecto y las etiquetas. Al guardar se abre el caso en “Falta grabar”.
Un caso escrito sin código: qué hace la persona y qué tendría que ver. -
Pedile a un agente que lo grabe. En el caso abierto (o en su tarjeta) tocá “Grabar con agente”. En “Dónde grabar” elegí el entorno; en “Agente”, la lista muestra los agentes con etapa de chat y marca los que no tienen credencial de modelo o prompt de chat. Con “Elegí uno por mí”, el modal dice cuál va a grabar (“Va a grabar qa.”). Si a ese agente le falta algo, el modal lo dice con un link para arreglarlo y “Empezar a grabar” queda deshabilitado. Tocá “Empezar a grabar”. Se abre un chat con el agente en el panel de la derecha, que arranca con la tarjeta “Grabando EV-8 en Staging” (las instrucciones que recibe el agente quedan plegadas): lo podés mirar y guiar si se traba. El agente explora la app, filma el flujo, verifica cada resultado esperado y guarda la grabación.
El agente se trabó en el código postal, preguntó y siguió. Al guardar cuenta qué grabó, cuántas verificaciones tiene y que la primera corrida quedó encolada. -
Mirá la primera corrida. Cuando el agente guarda, el caso corre una vez en el mismo entorno, ya sin agente, para que veas si pasa. El resultado aparece en el caso y en “Corridas”. Desde ahí corre solo con el horario y los deploys que configuraste.
La primera corrida de EV-8, sin agente: "Primera corrida después de que qa lo grabó" y los 3 chequeos medidos en verde.
Revisar un caso y por qué falló
Sección titulada «Revisar un caso y por qué falló»Tocá una tarjeta para abrir el caso. Arriba están “Volver a grabar”, “Correr en…”, “Editar” y “Eliminar”. En “Última corrida” elegís el entorno con los chips de la derecha (“Todos”, “Producción”, “Staging”…): ves el video con capítulos por paso, cuándo corrió, cuánto duró y quién la arrancó.
Más abajo, “Chequeos” lista cada verificación con “Esperado”, “Qué pasó”, “Resultado” y “Cómo” (“Medido” cuando la corrida lo midió en la página). Un caso que falló agrega “Qué salió mal” con el paso que se cortó, las capturas anotadas y el “Informe completo”. “Historial” muestra las corridas anteriores del entorno elegido; “Ver” abre cualquiera.
Si cambia la app y la grabación queda vieja, tocá “Volver a grabar”: el agente graba de nuevo y reemplaza la anterior. “Descargar grabación (JSON)” baja el guion tal como corre.
Correr a mano
Sección titulada «Correr a mano»Hay tres botones y los tres abren el mismo modal “Correr en un entorno”:
| Botón | Dónde | Qué corre |
|---|---|---|
| “Correr en…” | En un caso o en su menú ⋯ | Ese caso. |
| “Correr todo en…” | En “Casos” y en “Corridas” | Los casos grabados que muestra la lista de “Casos”, con los filtros que tengas puestos. En “Corridas”, con un entorno elegido en el filtro, todos los casos grabados de ese entorno. |
| “Correr todo acá” | En la tarjeta de un entorno | Todos los casos grabados que corren en ese entorno. |
| “Correr en una rama” | En la tarjeta del Sandbox | Todos los casos grabados del proyecto, sobre la rama que elijas. |
El modal agrupa los entornos por proyecto y muestra sólo los que pueden correr esos casos. No preselecciona producción salvo que sea el único entorno posible. Arriba explica qué va a pasar: “Corre los 4 casos grabados de la lista. 2 casos grabados de la lista no corren en este entorno y quedan afuera. Faltan grabar 2 casos, que se saltean.”
Correr en una rama con el Sandbox
Sección titulada «Correr en una rama con el Sandbox»Elegí “Sandbox” debajo del proyecto: aparece el campo “Rama”, con la rama por defecto del proyecto. Thulu baja esa rama, la levanta con el script de inicio, corre los casos contra esa copia y la borra al terminar. Mientras levanta, la tanda muestra en qué está: “Consiguiendo una máquina”, “Bajando el código”, “Corriendo el script de inicio”, “Arrancando la app”.
Si el Sandbox no levanta, la tanda dice “No levantó” y ningún caso cuenta como fallado: los casos quedan “Sin correr” y la tarjeta explica la causa (“La rama main no existe en el repositorio”) con “Probar de nuevo”. Si el problema está en el script de inicio, ofrece “Ver lo que imprimió el script de inicio”.
La pestaña Corridas
Sección titulada «La pestaña Corridas»Cada fila es una tanda: el entorno, quién o qué la arrancó (“Por horario”, “Después del deploy acme/tienda-web@3f9c2a1 · staging”, “La corrió…”, “Desde el CI”, “Primera corrida después de que… lo grabó”), una barra con lo que pasó, falló o se bloqueó, cuándo y cuánto duró. Se actualiza en vivo y se filtra por “Entorno”. Una tanda que todavía corre se puede “Cancelar”: los casos que no arrancaron se cancelan y el que está corriendo termina.
Tocá una tanda para ver sus corridas, cada una con “Ver video” o “Abrir”, que lleva al caso en esa corrida.
Cuando el runner no arranca o se corta, la tanda dice la causa en palabras (“Thulu no pudo bajar la imagen del navegador; avisale a quien administra la instalación.”) y deja el error técnico bajo “Ver detalles”.
Entornos
Sección titulada «Entornos»La pestaña “Entornos” agrupa los entornos por proyecto, cada uno con su Sandbox, y al final “Otros sitios”. Cada tarjeta dice cuándo corre solo, cuántos logins de prueba tiene y cómo le fue la última vez.
- Un entorno de proyecto se borra desde la página del proyecto, no desde acá. La marca de producción también se cambia allá.
- En el Sandbox sólo se editan los otros sitios que puede abrir y los logins de prueba; el resto sale del script de inicio.
- Un “Otro sitio” se puede borrar (el tacho) o pasar a un entorno de proyecto (el ícono de enlace, “Pasar a un proyecto”): conserva sus corridas, logins y horario, pero el destino tiene que ser un entorno de proyecto que todavía no haya corrido nada.
Disparar desde tu CI
Sección titulada «Disparar desde tu CI»Si tu equipo despliega sin los deployments de GitHub, el pipeline puede arrancar las corridas. La sección “Desde tu CI” del formulario del entorno muestra un comando curl con su botón de copiar. Al crear el entorno, el comando tiene ID_DEL_ENTORNO en lugar del id; al editarlo ya guardado, el id real. Guardá una API key en la variable OCTOPUS_API_KEY de tu CI. “Crear una API key” abre “Configuración” → “API” en otra pestaña; el preset “CI” alcanza, con rol developer o más (ver Configuración). El comando arranca una tanda con todos los casos grabados que corren en ese entorno, y la pestaña “Corridas” la muestra como “Desde el CI”.
Qué puede hacer cada rol
Sección titulada «Qué puede hacer cada rol»| Acción | Viewer | Developer | Admin y owner |
|---|---|---|---|
| Ver casos, corridas, videos y entornos | Sí | Sí | Sí |
| Crear, editar y borrar casos; grabar; correr (Sandbox incluido) | No | Sí | Sí |
| Crear un entorno o editar su parte de pruebas, si no es producción | No | Sí | Sí |
| Crear o editar un entorno de producción y sus logins | No | No | Sí |
| Borrar un “Otro sitio” o pasarlo a un proyecto | No | No | Sí |
Los botones que tu rol no permite aparecen deshabilitados con el motivo al pasar el mouse (“Solo quienes administran el espacio de trabajo pueden cambiar producción.”). Un viewer ve además “Con tu rol podés mirar pero no cambiar nada acá.”
Filtros y proyectos
Sección titulada «Filtros y proyectos»Con dos proyectos o más aparece arriba el selector “Proyecto”. Al elegir uno, casos, corridas y entornos se acotan a ese proyecto, más los casos sin proyecto (“También muestra 1 caso sin proyecto.”). La elección queda guardada en tu navegador. En “Casos” filtrás además por estado (los chips con el conteo), “Entorno” (muestra el resultado de cada caso en ese entorno), “Prioridad”, “Etiqueta” (podés sumar varias: muestra los casos que tienen todas) y “Buscar” por clave, título o texto. “Orden” pone primero los más nuevos, por prioridad o por estado, y “Tarjetas” o “Lista” cambia la vista. “Correr todo en…” corre exactamente lo que dejan los filtros. El encabezado cuenta aparte los que “fallan” y los “bloqueados”.
Problemas comunes
Sección titulada «Problemas comunes»- Un caso no aparece en “Correr en…” para un entorno: el entorno es de otro proyecto. Los casos de un proyecto corren sólo en sus entornos, su Sandbox y los otros sitios.
- La grabación deja de pasar después de un cambio de diseño: el caso queda “Bloqueado” porque no encuentra un elemento. Tocá “Volver a grabar”.
- Un caso cuyo flujo cambia datos (crear un pedido, pagar) queda grabado con esos pasos marcados, y la repetición lo rechaza con “No se pudo correr” para no repetir el cambio en cada corrida.
- Correr después de un deploy no dispara nada: el entorno de GitHub tiene que llamarse como el nombre corto del entorno, y la GitHub App de la instalación tiene que estar suscripta al evento de deploys (ver Git y GitHub). También sirve que el entorno de GitHub se llame como el “Nombre” del entorno, sin importar mayúsculas. Un workflow de GitHub Actions sin deployment no dispara; para eso está el comando del CI.