Construye un control de lanzamiento

1495. Identidad de la lección

Módulo

4.1 — Ingeniería de lanzamientos

Lección

Construye un control de lanzamiento

Tipo académico

Flujo de trabajo

Orden

2 del módulo

Tiempo estimado

40–55 minutos, incluida la práctica

Esta lección convierte los requisitos del producto en una lista de comprobación que otra persona pueda ejecutar y auditar. Cada control debe definir qué se prueba, qué cuenta como aprobado, qué evidencia debe conservarse, quién se responsabiliza de la comprobación y qué revisión candidata se probó.

La decisión final de lanzar o no lanzar corresponde a la siguiente lección. Aquí producirás registros que permitan tomar esa decisión sin ocultar fallos ni inventar seguridad.

1496. Objetivo de aprendizaje

Al terminar, podrás crear una lista de cinco a siete comprobaciones para la compilación de un juego pequeño. Cada fila incluirá un criterio de aceptación explícito, un estándar de evidencia, una persona responsable, una revisión candidata, un resultado de ejecución, un estado de suficiencia de la evidencia, una disposición del control y un estado de preparación para revisión.

1497. Por qué hace falta un criterio de aceptación

La evidencia registra lo ocurrido. El criterio de aceptación define qué debe ocurrir para que el requisito se considere cumplido. No son lo mismo.

• Evidencia sin criterio: «Se registró el tiempo de fotograma». No indica si el valor observado era aceptable.
• Criterio sin evidencia: «El tiempo de fotograma debe cumplir el objetivo». No demuestra si el candidato lo cumplió.
• Criterio y evidencia: «Criterio de aceptación: el percentil 95 del tiempo de fotograma no supera el objetivo proporcionado de 20 ms durante el encuentro definido. Evidencia: se registraron 18,6 ms en el candidato abc1234 bajo las condiciones especificadas».

Expresiones como «contraste suficiente», «buen rendimiento» o «la entrada funciona» no son repetibles si el requisito proporcionado no define el estándar, el objetivo, la tolerancia, el comportamiento admitido o el estado esperado.

1498. Modelo central

Utiliza este modelo en cada comprobación:

ALCANCE → CRITERIO DE ACEPTACIÓN → PROCEDIMIENTO → ESTÁNDAR DE EVIDENCIA → RESPONSABLE → REVISIÓN → ESTADOS

Usa este formato compacto:

ID | Área de riesgo | Alcance | Criterio de aceptación | Procedimiento | Estándar de evidencia | Responsable | Revisión/compilación | Severidad | Resultado de ejecución | Suficiencia de evidencia | Disposición | Preparación para revisión

Una fila está incompleta si no contiene un criterio de aceptación, aunque incluya capturas, registros u observaciones.

1499. Cuatro decisiones distintas

No combines la evidencia y el resultado en un único estado. Registra por separado estas dimensiones.

1. Resultado de ejecución

• Sin ejecutar: la ejecución no ha comenzado.
• Aprobado: el comportamiento observado cumplió el criterio de aceptación.
• Fallido: el comportamiento observado no cumplió el criterio de aceptación.
• Bloqueado: el procedimiento no pudo producir un resultado válido de aprobado o fallido porque faltaba un prerrequisito, un entorno, una compilación o una ruta de prueba necesaria.

2. Suficiencia de la evidencia

• Suficiente: la evidencia conservada cumple el estándar de la fila y puede relacionarse con el candidato y las condiciones probadas.
• Insuficiente: falta evidencia, está incompleta o es ambigua, o no puede asociarse con el candidato probado.

3. Disposición del control

• Satisfecho: el resultado es Aprobado y la evidencia es Suficiente.
• Criterio incumplido: el resultado es Fallido y la evidencia es Suficiente.
• No evaluable: el resultado es Sin ejecutar o Bloqueado, o la evidencia es Insuficiente.

Una comprobación fallida puede estar respaldada por una evidencia excelente. Por tanto, no debe describirse toda fila bien documentada como satisfecha. La suficiencia de la evidencia indica si el resultado puede defenderse; no convierte un fallo en un aprobado.

4. Preparación para revisión

• Lista para revisión: un resultado Aprobado o Fallido está respaldado por evidencia suficiente y puede revisarse en la siguiente lección.
• No lista para revisión: la fila no puede evaluarse porque la ejecución o la evidencia están incompletas.

Tanto un aprobado documentado como un fallo documentado pueden estar listos para revisión. Estar listo para revisión no significa estar aprobado, listo para lanzar ni publicado.

1500. Severidad y clasificación de hallazgos anteriores

La clasificación anterior de un hallazgo no determina automáticamente la severidad de un control. Aplica criterio profesional y consulta los requisitos proporcionados.

• Un bloqueador suele dar lugar a un criterio obligatorio, porque su incumplimiento impide satisfacer una condición requerida.
• Un riesgo puede dar lugar a un control informativo si debe trasladarse a la revisión del lanzamiento, pero no se ha definido como condición obligatoria.
• Un seguimiento no se convierte en aprobado. Sigue siendo trabajo pendiente salvo que un requisito lo incorpore a los criterios del candidato actual.
• Una afirmación sin respaldo necesita evidencia válida. Mientras no exista, el control correspondiente sigue sin poder evaluarse.

La conversión exige juicio. Por ejemplo, un riesgo de rendimiento pasa a ser obligatorio si el requisito del producto fija un límite de tiempo de fotograma que debe cumplirse.

1501. Ejemplo resuelto

Supón que los requisitos proporcionados para un candidato indican lo siguiente:

• Completar el primer encuentro debe conceder exactamente una recompensa antes de mostrar el siguiente punto de decisión.
• El teclado y el mando son métodos de entrada admitidos; perder el foco no debe dejar el movimiento atascado al recuperarlo.
• El texto de interfaz de tamaño normal debe cumplir la relación mínima de contraste proporcionada de 4,5:1.
• Durante el encuentro definido, el percentil 95 del tiempo de fotograma no debe superar el objetivo proporcionado de 20 ms bajo las condiciones registradas.
• Después de interrumpir una partida, la opción Continuar debe restaurar el último punto de control confirmado y conservar el estado registrado de la recompensa.

Estos valores pertenecen al ejemplo proporcionado. En un proyecto real, usa sus requisitos efectivos; no copies los objetivos sin revisarlos.

RG-01 | Funcionalidad | Final del primer encuentro y recompensa | Aparece exactamente una recompensa antes del siguiente punto de decisión | Iniciar una partida y completar el encuentro | ID de compilación, pasos, cantidad observada y captura o registro del evento | Responsable de pruebas | abc1234 / build-17 | Obligatoria | Aprobado | Suficiente | Satisfecho | Lista para revisión
RG-02 | Plataforma | Teclado y mando después de perder el foco | Tras recuperar el foco, ninguna entrada deja el movimiento atascado y ambas permiten reanudar la navegación admitida | Probar ambas entradas, retirar el foco durante el movimiento, recuperarlo y soltar la entrada | Plataforma, dispositivo, pasos y estado observado | Responsable de plataforma | abc1234 / build-17 | Obligatoria | Fallido | Suficiente | Criterio incumplido | Lista para revisión
RG-03 | Accesibilidad | Contraste del texto normal de interfaz | Cada par de colores incluido alcanza al menos 4,5:1 | Medir los estados indicados con el método aprobado | Lista de estados, relaciones medidas, método y capturas | Responsable de accesibilidad | abc1234 / build-17 | Obligatoria | Bloqueado | Insuficiente | No evaluable | No lista para revisión
RG-04 | Rendimiento | Encuentro definido con la carga objetivo | El percentil 95 no supera 20 ms bajo las condiciones especificadas | Realizar tres capturas con el dispositivo y los ajustes indicados | Capturas originales, condiciones, versión de la herramienta y cálculo | Responsable de rendimiento | abc1234 / build-17 | Obligatoria | Aprobado | Suficiente | Satisfecho | Lista para revisión
RG-05 | Integridad del contenido | Nivel, recompensa, textos y recursos requeridos | Todos los elementos del inventario aprobado están presentes y sus referencias se resuelven | Comparar la compilación con el inventario aprobado | Inventario completado con ausencias o diferencias identificadas | Responsable de contenido | abc1234 / build-17 | Obligatoria | Sin ejecutar | Insuficiente | No evaluable | No lista para revisión
RG-06 | Recuperación | Continuar después de interrumpir una partida | Se restaura el último punto de control confirmado y se conserva el estado de la recompensa | Interrumpir tras confirmar el punto de control, reiniciar y seleccionar Continuar | Punto de interrupción, pasos, punto restaurado y estado de recompensa | Responsable de pruebas | abc1234 / build-17 | Obligatoria | Aprobado | Suficiente | Satisfecho | Lista para revisión

RG-02 está lista para revisión aunque haya fallado. Existe evidencia suficiente para que la siguiente lección considere el incumplimiento del criterio obligatorio. RG-03 no está lista porque la medición requerida no pudo completarse y no se cumplió su estándar de evidencia.

1502. Construcción de la lista

Limita la lista a cinco o siete comprobaciones que cubran:

• funcionalidad;
• comportamiento de plataforma;
• accesibilidad;
• rendimiento;
• integridad del contenido; y
• recuperación.

Una fila puede cubrir más de un área solo si sus criterios y evidencias siguen siendo inequívocos. No añadas filas vagas únicamente para aparentar mayor cobertura.

Para cada fila:

1. Relaciónala con un requisito proporcionado o un riesgo identificado de forma explícita.
2. Delimita el alcance.
3. Define el umbral, comportamiento admitido, tolerancia o estado esperado que permite aprobarla.
4. Escribe un procedimiento que otra persona pueda repetir.
5. Define la evidencia necesaria antes de ejecutar la prueba.
6. Asigna una persona responsable.
7. Registra el commit candidato y el identificador de compilación.
8. Clasifica el control como obligatorio o informativo y justifica la decisión.
9. Ejecuta el procedimiento sin cambiar el criterio después de conocer el resultado.
10. Registra por separado el resultado, la suficiencia de la evidencia, la disposición y la preparación para revisión.

Si un requisito es ambiguo, no inventes un umbral. Registra la pregunta pendiente y mantén el control como no evaluable hasta que la persona responsable del requisito lo aclare.

1503. Flujo de trabajo con IA

La IA puede ayudar a organizar los requisitos proporcionados y detectar áreas sin cubrir. No puede ejecutar la prueba, inventar un umbral, validar evidencia que no ha inspeccionado ni tomar la decisión final de lanzamiento.

Un prompt útil es:

Usando solo los requisitos proporcionados, la plataforma objetivo, las entradas admitidas, los requisitos de accesibilidad, los objetivos de rendimiento, el comportamiento de recuperación y la revisión candidata, propón entre cinco y siete comprobaciones de lanzamiento.
Para cada una, incluye alcance, criterio de aceptación explícito, procedimiento, estándar de evidencia, función responsable, severidad y los cuatro campos de estado.
Cita o referencia el requisito que fundamenta cada criterio. Marca como preguntas los umbrales ausentes o los requisitos ambiguos. No inventes objetivos, no conviertas comprobaciones sin ejecutar en aprobados y no tomes una decisión de lanzar o no lanzar.

Revisa la propuesta manualmente. Descarta filas duplicadas, sin criterio, redactadas de forma subjetiva o fuera de alcance. La IA solo debe resumir registros existentes después de comparar el resumen con la evidencia original.

1504. Git y las revisiones candidatas

La revisión candidata forma parte del registro de evidencia.

1. Inspecciona el árbol de trabajo e identifica el commit candidato antes de compilar.
2. Registra el commit y el identificador de compilación en cada fila aplicable.
3. Ejecuta las pruebas sobre esa compilación, no sobre cambios sin commit ni sobre un estado local desconocido.
4. Si una comprobación falla, conserva el candidato fallido, su evidencia y su disposición.
5. Registra por separado cualquier nuevo candidato creado después de una corrección.
6. Repite las comprobaciones afectadas y las regresiones justificadas sobre el nuevo candidato.
7. No copies un aprobado anterior a una revisión nueva sin ejecutar la prueba correspondiente.

Un nuevo candidato no borra el fallo anterior. El historial debe mostrar qué estado produjo cada resultado.

1505. Errores frecuentes

Confundir la evidencia con el criterio

«Guardar una captura» indica qué evidencia conservar, pero no define qué debe demostrar esa captura.

Interpretar la evidencia suficiente como un aprobado

Un fallo bien documentado tiene evidencia suficiente, pero su disposición es Criterio incumplido.

Usar Bloqueado para cualquier fallo

Usa Fallido cuando la ejecución terminó y el comportamiento incumplió el criterio. Usa Bloqueado cuando no fue posible producir un resultado válido de aprobado o fallido.

Cambiar el umbral después de ejecutar

Los criterios deben proceder de requisitos proporcionados o de una aclaración aprobada. No debilites un criterio porque el candidato no lo haya cumplido.

Convertir un seguimiento en aprobación

El trabajo futuro no demuestra que el candidato actual haya aprobado. Conserva el resultado y la evidencia actuales.

1506. Práctica guiada

Usa este alcance: la persona jugadora debe iniciar el juego, comenzar una partida, completar un encuentro, recibir una recompensa y llegar al siguiente punto de decisión. Añade únicamente requisitos de plataforma, accesibilidad, rendimiento, contenido y recuperación proporcionados por tu proyecto o por quien imparte la actividad.

1. Registra una revisión candidata de Git y un identificador de compilación. En un escenario descrito, usa un identificador claramente provisional, como candidate-01.
2. Escribe entre cinco y siete filas que cubran las seis áreas de riesgo.
3. Añade un criterio de aceptación explícito a cada fila. Si falta un umbral o un estado esperado, registra la pregunta pendiente en lugar de inventarlo.
4. Define el procedimiento y el estándar de evidencia antes de ejecutar.
5. Asigna una persona responsable y clasifica cada fila como obligatoria o informativa. Justifica la clasificación en una frase.
6. Inicializa los estados como Sin ejecutar, evidencia Insuficiente, No evaluable y No lista para revisión.
7. Ejecuta las comprobaciones disponibles y conserva la evidencia exigida.
8. Determina de forma independiente los cuatro campos de estado.
9. Repara una fila deliberadamente débil añadiendo el criterio, el estándar de evidencia, la persona responsable, la revisión, la severidad y los estados justificables que falten.
10. Si se crea un nuevo candidato, conserva el registro anterior e identifica las comprobaciones afectadas y las regresiones necesarias.

No tomes la decisión general de lanzar o no lanzar.

1507. Validación y evidencia

1508. Puntos clave

• La evidencia registra lo ocurrido; el criterio de aceptación define qué cuenta como aprobado.
• El resultado, la suficiencia de la evidencia, la disposición y la preparación para revisión son dimensiones distintas.
• Un fallo con evidencia suficiente puede estar listo para revisión sin estar satisfecho.
• Los requisitos ausentes o ambiguos permanecen sin evaluar; no son aprobados provisionales.
• Git relaciona la evidencia con un estado candidato concreto.
• La IA puede proponer estructuras y detectar preguntas, pero las personas controlan los criterios, la ejecución, la evidencia y la decisión de lanzamiento.

1509. Siguiente lección

4.1 L3 — Escribe el memorando de lanzamiento o no lanzamiento utilizará los criterios, resultados, estados de evidencia, disposiciones, posibles riesgos aceptados y carencias de evidencia producidos aquí.

1510. Ensayo local de lanzamiento (fix-release-candidate)

Abre academy-fixtures/labs/release-candidate. Ejecuta node run.mjs. Recoge ejecución limpia, artefacto versionado, humo, sonda de localización, persistencia, empaquetado, rollback, notas, issues conocidos, go/no-go. Es un candidato de lanzamiento local, no una publicación en Steam.

1511. Comprobación