Reproducir, acotar, validar

1410. Identidad de la lección

Módulo

3.16 — Depuración

Lección

Reproducir, acotar, validar

Tipo académico

Laboratorio de depuración

Tipo de esquema

práctica

Orden

2 del módulo

Tiempo estimado

60–90 minutos para investigar, implementar, validar y redactar el reporte

1411. Objetivo de aprendizaje

Al finalizar esta lección, podrás entregar un reporte de debugging que defina el alcance de un defecto, registre una reproducción confiable, use una prueba discriminatoria para respaldar un mecanismo, implemente una corrección enfocada y la valide frente al fallo original y a comportamientos cercanos.

1412. Punto de partida obligatorio

No dediques el laboratorio a buscar un defecto al azar. Debes llegar con uno de estos puntos de partida:

1. un defecto de tu proyecto que ya hayas reproducido al menos dos veces desde un punto de control registrado;
2. un defecto preparado y un punto de control inicial proporcionados para el laboratorio; o
3. un caso alternativo aprobado por la persona instructora, con comportamiento esperado y reproducción inicial ya confirmados.

Conserva el punto de control original antes de realizar cambios. Si no puedes reproducir el defecto elegido durante los primeros 10 minutos, registra los intentos y cambia al caso alternativo preparado. El registro de una reproducción bloqueada es un resultado de investigación honesto y útil, pero no completa el hito práctico de esta lección: para completarlo todavía debes acotar, probar un mecanismo, proponer una corrección y validarla después del cambio sobre un caso reproducible.

1413. Por qué importa

Un diagnóstico plausible todavía no es un resultado de debugging confiable. La reproducción permite que otra persona observe el fallo. Acotar evita que sistemas no relacionados entren en el argumento. Una prueba discriminatoria separa explicaciones rivales. La validación determina después si la corrección modificó el mecanismo relevante sin dañar un comportamiento que ya era correcto.

1414. Conocimientos previos

Completa primero 3.16 L1 — Síntoma, mecanismo y causa raíz. Debes poder separar observaciones de suposiciones y expresar un mecanismo propuesto como una cadena causal.

1415. Concepto central: tres límites de evidencia

Un resultado de debugging útil establece tres límites:

1. Límite de reproducción: la configuración mínima y confiable que todavía produce el fallo.
2. Límite de alcance: las condiciones donde ocurre el fallo y al menos una condición donde no ocurre.
3. Límite de validación: los casos que muestran que el cambio elimina el fallo y conserva el contrato previsto.

Usa el ciclo R-A-V: Reproducir, Acotar, Validar. Su equivalente en inglés es R-N-V: Reproduce, Narrow, Validate.

Que un síntoma desaparezca en una sola ejecución no constituye una validación suficiente.

1416. Ejemplo

Supón que un actor empieza con tres puntos de vida y un peligro debería quitar un punto por contacto. El síntoma observado es que un solo contacto sostenido puede reducir la vida de tres a cero.

Una reproducción útil especifica una escena limpia, la vida inicial, el movimiento exacto, la duración del contacto, la cantidad observada de eventos de daño, la vida mostrada y los resultados de varios intentos. Para acotar, se podría comparar un contacto breve con uno sostenido, uno con dos peligros o un actor nuevo con otro que ya recibió daño.

Un mecanismo posible es que el daño se procese repetidamente durante el solapamiento, en vez de una sola vez al comenzar el contacto. No debes aceptar ese mecanismo solo porque resulte plausible. Una prueba discriminatoria podría registrar los eventos de daño durante un contacto breve, uno sostenido y dos contactos separados. La cantidad de eventos respaldará o debilitará la cadena propuesta.

Después del cambio mínimo pertinente, la validación debe cubrir el contacto sostenido original, un contacto breve, dos contactos separados y una interacción ajena al peligro. La meta no es obtener solamente un valor visual distinto, sino conservar el contrato de daño previsto en toda la matriz.

1417. Flujo de trabajo nativo de IA

Usa la IA para proponer alternativas y revisar la cobertura, no para sustituir la evidencia observada.

1. Proporciona el estado inicial, las acciones ordenadas, el resultado esperado, el resultado real y el código o la configuración relevante.
2. Etiqueta cada afirmación como observación, contrato o hipótesis.
3. Solicita mecanismos rivales y una prueba discriminatoria para cada uno.
4. Ejecuta tú las pruebas y registra todos los resultados, incluidos los que contradigan la explicación preferida.
5. Antes de aplicar un cambio sugerido, indica qué mecanismo debería alterar y qué comportamientos cercanos deben conservarse.
6. Pide a la IA que revise la matriz de validación en busca de casos omitidos y decide después cuáles sugerencias son pertinentes.

Puedes usar este prompt:

Estas son las observaciones: [hechos]. Este es el contrato esperado: [contrato]. Esta es la reproducción: [pasos]. Propón tres mecanismos rivales, la prueba mínima que distinga cada uno y el resultado que debilitaría cada hipótesis. No presentes una causa raíz como un hecho sin evidencia correspondiente.

1418. Flujo de trabajo con Git y revisiones

Crea una rama o un punto de control enfocado antes de modificar el proyecto. Mantén la corrección separada de tareas de limpieza no relacionadas. Registra tanto la revisión de reproducción como la revisión de la corrección propuesta. Si la corrección falla durante la validación, conserva esa revisión y su resultado en vez de reescribir el reporte para aparentar éxito.

1419. Flujo práctico

Parte A — Confirmar la reproducción

Registra:

• estado inicial y ajustes relevantes;
• acciones exactas y ordenadas;
• resultados esperado y observado;
• frecuencia del fallo en al menos tres intentos;
• revisión o punto de control del proyecto.

Si la reproducción queda bloqueada, documenta los intentos y la incertidumbre y cambia al caso alternativo preparado. No uses la ausencia del fallo como prueba de que una corrección no verificada funcionó.

Parte B — Acotar el caso

Modifica una sola variable cada vez. Completa al menos tres comparaciones controladas, como duración breve frente a sostenida, una interacción frente a interacciones repetidas, configuración predeterminada frente a modificada o sistema aislado frente a sistemas cercanos activados.

En cada comparación, registra la variable modificada y el resultado. Identifica la configuración más pequeña que todavía falla y al menos un límite donde el fallo no ocurre.

Parte C — Probar el mecanismo

Escribe la cadena causal propuesta:

condición → evento o transición de estado → mecanismo → síntoma visible

Incluye al menos un mecanismo rival. Diseña y ejecuta una prueba cuyos posibles resultados permitan distinguirlos. Indica qué observaciones respaldan el mecanismo elegido y qué evidencia lo debilitaría.

Parte D — Implementar y validar

Realiza el cambio más pequeño que atienda el mecanismo respaldado. Completa esta matriz después del cambio:

No comuniques el estado solo mediante colores; incluye etiquetas explícitas. Clasifica cada fallo como defecto no resuelto, regresión introducida, expectativa incorrecta o evidencia bloqueada.

Parte E — Entregar el reporte

Incluye:

1. Alcance: sistema afectado, condiciones incluidas y condiciones excluidas.
2. Reproducción: configuración, pasos, frecuencia y resultados esperado y observado.
3. Evidencia: registros, valores, resultados de pruebas, capturas o grabaciones.
4. Mecanismo: cadena causal, explicación rival y prueba discriminatoria.
5. Corrección: qué cambió y por qué atiende el mecanismo respaldado.
6. Validación: matriz completa, cobertura de regresiones e incertidumbre pendiente.
7. Registro de revisiones: puntos de control original y de la corrección propuesta.

Acompaña cada captura, gráfico o grabación con una descripción textual breve o una transcripción de la evidencia relevante. El reporte debe poder entenderse sin depender de la percepción del color ni del acceso al audio.

1420. Estándar de finalización

Puedes entregar un registro de reproducción bloqueada como evidencia de un proceso honesto, pero no contará como hito práctico completado. Para completar el hito, el reporte evaluado debe permitir que una persona independiente pueda:

• reproducir el fallo original a partir de los pasos escritos;
• identificar el alcance y un límite sin fallo;
• distinguir observaciones de hipótesis;
• revisar una prueba discriminatoria que compare mecanismos plausibles;
• relacionar la corrección propuesta con el mecanismo respaldado;
• comparar el comportamiento antes y después del cambio;
• inspeccionar el caso original y casos de regresión pertinentes;
• identificar la incertidumbre y el registro de revisiones;
• comprender toda evidencia visual o grabada mediante equivalentes textuales.

1421. Puntos clave

• Comienza con un defecto confirmado o un caso alternativo preparado; no dediques el laboratorio a buscar uno.
• Acotar exige comparaciones controladas y límites tanto con fallo como sin fallo.
• Un mecanismo obtiene respaldo mediante una prueba discriminatoria, no por parecer plausible.
• La validación cubre el fallo original y los comportamientos cercanos que deben conservarse.
• Una reproducción bloqueada es un resultado válido para el registro, pero completar la capacidad exige un caso reproducible.

1422. Próxima lección

Continúa con 3.17 — Migraciones de guardado. La misma disciplina de evidencia te ayudará a distinguir un síntoma visible del esquema de guardado de la obligación de compatibilidad o migración que lo causó.

1423. Comprobación