Cómo leer las señales de un caso

Qué significa cada una de las cinco señales de un caso en una suite de Qably, cuándo aparece y una rutina breve para revisarlas.

Qably revisa cada caso de una suite con cinco reglas fijas y muestra una etiqueta cuando una se cumple. Una señal indica qué caso conviene abrir a continuación; no dice que el producto esté roto. Las reglas leen solo nombres, pasos, claves de automatización y resultados recientes, así que los mismos datos siempre producen las mismas señales.

Dónde aparecen las señales

Abra una suite de su proyecto. Sobre la lista de casos, una franja muestra cada señal con el número de casos que la activan, y cada tarjeta de caso repite sus propias etiquetas. Pase el cursor sobre una etiqueta, o enfóquela, para leer su explicación breve. Un caso automatizado sin pasos ni resultado esperado muestra Sin documentar en su tarjeta, en lugar de la etiqueta Sin pasos.

Las cinco señales

Señal	Cuándo aparece	Qué sugiere	Qué hacer
Sin pasos	Un caso automatizado no tiene pasos registrados. Los casos manuales nunca se marcan.	Los resultados llegan, pero nadie sabe qué comprueba la prueba.	Escriba los pasos y el resultado esperado. Vea la guía para escribir un caso de prueba.
Nombre técnico	El nombre no tiene espacios, parece un identificador de código y contiene un guion bajo o mezcla mayúsculas y minúsculas, como `test_login_1` o `testTokenNull`. También cuenta un nombre igual a la clave de automatización del caso.	Solo quien escribió la prueba puede leerla en un reporte.	Renómbrelo como una frase que diga qué hace la persona usuaria. Vea cómo nombrar las pruebas.
Inestable	Los últimos 6 resultados de un caso automatizado en ejecuciones terminadas, sin contar los omitidos ni los bloqueados, cambian entre éxito y falla al menos dos veces, como éxito, falla, éxito.	El resultado puede depender del tiempo, del orden de las pruebas, de datos compartidos o del entorno, y no del código probado.	Compare una ejecución exitosa con una fallida del caso, busque qué cambia y corrija la prueba antes de confiar en su estado.
Clave duplicada	Otro caso del mismo proyecto tiene la misma clave de automatización, la que Qably usa para vincular un resultado con un caso.	La misma prueba está registrada como dos casos, en suites distintas del proyecto, y uno de ellos probablemente quedó obsoleto.	Abra ambos, conserve el que sigue recibiendo resultados y elimine el otro. Para saber cómo una prueba se convierte en caso, vea la referencia de JUnit.
Título casi duplicado	Otro caso de la misma suite tiene el mismo título una vez que se ignoran mayúsculas, signos de puntuación y espacios sobrantes.	Dos casos se leen igual, así que una falla en un reporte resulta ambigua.	Renómbrelos para que cada uno diga qué comprueba, o elimine el repetido. La guía sobre qué tipos de errores buscar ayuda a decidir qué casos valen la pena.

Inestable es una pista, no un veredicto

Un caso inestable pasa y falla sin un cambio que se pueda señalar, así que una ejecución en rojo puede no ser una regresión. Tampoco llevan la señal un caso que cambia de resultado una sola vez, por ejemplo de éxito a falla (eso es una regresión, no inestabilidad), ni un caso que falla siempre.

Importante: Inestable solo marca el caso. Qably no lo aísla, no lo omite ni lo oculta: sus resultados siguen contando en cada ejecución tal como los reportó su CI.

Una rutina para revisar una suite

Abra la suite y lea la franja sobre los casos. Anote qué señal tiene el conteo más alto.
Corrija primero los duplicados: Clave duplicada y Título casi duplicado. Las demás señales se leen mejor cuando cada prueba es un solo caso.
Revise después los casos Inestable. Compare una ejecución exitosa con una fallida y corrija la prueba o los datos de los que depende.
Limpie luego Sin pasos y Nombre técnico en lotes pequeños, por ejemplo cada vez que toque el archivo de la prueba.
Si un caso que siempre pasaba ahora falla, es una regresión. Continúe con la guía para leer una regresión y sus commits candidatos.