Planes de pruebas

Un plan de pruebas es una selección con nombre de casos de prueba — una lista de reproducción, no una carpeta. Los casos son independientes y de primera clase; un plan los referencia. El mismo caso puede aparecer en un plan de smoke y en un plan de preparación para versión, y corregirlo en un sitio lo corrige en ambos.

Los planes están en Test Plans en el panel. Los casos están en Test Cases.

Por qué selecciones en lugar de contención

Si cada caso tuviera que pertenecer a exactamente un plan, cualquier caso que dos suites necesiten tendría que duplicarse — y los casos duplicados divergen. La referencia lo resuelve: una definición, muchas membresías, ninguna copia que mantener sincronizada.

Un caso no necesita un plan. Ejecutar un caso individual directamente, o configurar un objetivo por defecto de repositorio apuntando a un solo caso, sigue siendo un flujo de trabajo de primera clase.

Ejecutar un plan

Ejecutar un plan produce una ejecución por caso miembro, agrupadas bajo una ejecución de plan. La ejecución sigue siendo la unidad atómica de evidencia — cada caso miembro obtiene su propia cronología, artefactos y espacio de evidencia, exactamente como si lo hubieras ejecutado solo.

El estado de la ejecución del plan se deriva de sus miembros, nunca se almacena de forma independiente. Eso significa que el resumen no puede discrepar con las ejecuciones subyacentes: si un miembro sigue ejecutándose, la ejecución del plan sigue ejecutándose; si un miembro falló, la ejecución del plan falló.

Orden

La membresía tiene un orden, por lo que un plan ejecuta sus casos en la secuencia que hayas dispuesto. Úsalo cuando una suite se lee mejor en un orden particular. No lo uses para pasar estado entre casos — cada caso debe preparar y verificar su propio recorrido, o un solo fallo se propaga en cascada por todo lo que le sigue.

Dónde aparecen los planes

• En el panel, como una ejecución de plan cuya fila se expande mostrando las ejecuciones de los miembros.
• En un comando de GitHub, como nombre que puedes pasar: @autonomy run plans "Release readiness".
• Como objetivo por defecto de repositorio, para que un @autonomy test this sin más ejecute el plan completo. Un repositorio tiene como objetivo por defecto un caso o un plan, no ambos.

Qué agrupar

Mantén los planes pequeños y nombrados según una decisión que alguien toma:

• Smoke — el puñado de recorridos que deben funcionar antes de que merezca la pena comprobar cualquier otra cosa.
• Preparación para versión — lo que verificas antes de publicar.
• Por superficie — checkout, onboarding, facturación.

Evita un plan de "todo". Un plan que siempre tiene un fallo sin relación enseña a los revisores a ignorarlo.