2210. Identidad de la lección
Esta lección amplía la revisión de aceptación anterior. Un hallazgo no está completo cuando solo describe lo que parece incorrecto; se vuelve accionable cuando relaciona el síntoma observado con una causa probable, con la responsabilidad del contrato, con la superficie de regresión afectada y con un plan de validación.
2211. Objetivo de aprendizaje
Después de esta lección, podrás clasificar un hallazgo de revisión mediante el método de cinco casos y relacionarlo con una causa raíz probable, con la responsabilidad del contrato pertinente, con el riesgo de regresión y con una necesidad concreta de validación.
2212. Por qué importa
Una revisión que dice “esto podría romper algo” todavía no indica qué debe inspeccionarse ni quién debe resolverlo. Razonar sobre la causa raíz evita cambios aleatorios; razonar sobre la responsabilidad dirige el hallazgo a la persona o sistema adecuado; y analizar la regresión evita que una corrección local dañe silenciosamente un comportamiento existente. La IA puede ayudar a enumerar hipótesis, pero no puede establecer causalidad ni responsabilidad sin evidencia.
2213. Conocimientos previos
Ya deberías poder:
- comparar un encargo, un diff real y la evidencia de aceptación;
- distinguir un hallazgo bloqueante de una observación importante o no bloqueante;
- identificar límites explícitos del contrato y carencias de evidencia;
- redactar una revisión priorizada con una acción siguiente concreta.
La lección anterior, 5.8 L1 — Revisar el cambio contra el encargo, estableció la decisión de aceptación que ahora investigarás con más profundidad.
2214. Concepto central
Usa cinco casos para pasar de una observación a un hallazgo de revisión accionable:
- Caso observado: ¿Qué comportamiento o hecho del código puede verse directamente? Separa la evidencia de la interpretación.
- Caso de causa: ¿Qué cambio, suposición o protección ausente podría producir lo observado? Exprésalo como hipótesis hasta verificarlo.
- Caso de responsabilidad: ¿Qué contrato, estado o límite es responsable del comportamiento? Asigna la responsabilidad al sistema o rol que gobierna ese contrato, no solo al archivo donde está el código.
- Caso de regresión: ¿Qué comportamiento existente podría cambiar si se mantiene esta implementación o se aplica la corrección propuesta? Identifica la superficie y el modo de fallo.
- Caso de validación: ¿Qué inspección, prueba, traza o comparación confirmaría la causa y protegería el comportamiento afectado?
El método no exige certeza en la primera pasada. Su disciplina consiste en distinguir lo que se sabe, lo que se sospecha, quién controla el contrato pertinente, qué podría verse afectado y qué evidencia reduciría la incertidumbre.
2215. Modelo mental
Usa la cadena Evidencia → Hipótesis → Responsable del contrato → Superficie de regresión → Validación:
| Caso | Pregunta | Resultado válido |
|---|---|---|
| Observado | ¿Qué puedo señalar en el diff, el comportamiento o la evidencia? | Un hecho, una traza o una prueba ausente |
| Causa | ¿Qué podría explicar ese hecho? | Una o más hipótesis comprobables |
| Responsabilidad | ¿Qué contrato o límite de estado lo gobierna? | Un sistema, componente o rol responsable |
| Regresión | ¿Qué comportamiento existente podría verse afectado? | Un comportamiento y un modo de fallo plausible |
| Validación | ¿Qué confirmaría el diagnóstico y protegería la corrección? | Una comprobación concreta con resultado esperado |
Una entrada útil de revisión sigue este patrón:
Hallazgo: [hecho observado]. Causa probable: [hipótesis, marcada como no verificada si corresponde]. Responsable: [responsable del contrato o sistema]. Riesgo de regresión: [comportamiento existente y modo de fallo]. Validación: [comprobación y evidencia esperada].
No confundas estas tres relaciones:
- Responsabilidad del archivo: dónde está el código;
- Responsabilidad del contrato: qué sistema define el comportamiento;
- Responsabilidad de decisión: quién puede aprobar un cambio del contrato.
Pueden coincidir, pero no tienen por qué hacerlo.
2216. Ejemplo concreto
Considera este caso de revisión ficticio:
Un cambio añade una confirmación antes de una acción destructiva. El encargo exige que la acción siga indisponible hasta confirmar, conserve la ruta de cancelación existente y mantenga el cambio local a la pantalla de la acción.
El diff añade un estado local de confirmación, pero también modifica un ayudante compartido de acciones. En una ruta, la bandera de confirmación se activa antes de que termine la comprobación asíncrona. La evidencia entregada muestra la pantalla de confirmación, pero no muestra la cancelación, una comprobación rechazada ni un segundo intento después del fallo.
Aplica los cinco casos:
- Observado: La bandera se activa antes de que se resuelva la comprobación asíncrona y la evidencia solo cubre la pantalla de confirmación.
- Hipótesis de causa: La implementación trata “se inició la comprobación” como equivalente a “la comprobación fue aprobada”. Sigue siendo una hipótesis hasta rastrear la transición de estado y la ruta de fallo.
- Responsabilidad: La pantalla de la acción es responsable de la interacción de confirmación, pero el ayudante compartido es responsable del límite de ejecución de la acción. Por tanto, el cambio del ayudante debe revisarse contra su contrato existente; la persona responsable de la pantalla no puede aprobar por sí sola ese cambio de límite salvo que el proceso de decisión lo permita.
- Riesgo de regresión: Una comprobación rechazada podría dejar habilitada la acción, o un segundo intento podría reutilizar un estado de confirmación obsoleto. El ayudante compartido también podría alterar la cancelación de otros usuarios. Son riesgos, no regresiones confirmadas, hasta reproducirlos o descartarlos.
- Validación: Rastrea las transiciones de estado para éxito, rechazo, cancelación y un intento repetido. Inspecciona o prueba al menos otro usuario existente del ayudante compartido para verificar que su comportamiento de cancelación no cambió.
Un hallazgo sólido no afirmaría “el ayudante está roto” sin evidencia. Explicaría qué cambió, por qué el cambio es una causa plausible, qué contrato está implicado, qué podría regresar y qué validación permitiría tomar la siguiente decisión.
2217. Flujo de trabajo nativo de IA
Usa la IA para ampliar el conjunto de hipótesis y ordenar la evidencia, no para declarar la causa raíz:
- Proporciona el encargo, el hallazgo, el diff pertinente y la evidencia disponible.
- Pide al modelo que separe las observaciones directas de las hipótesis causales.
- Pídele que enumere los límites de estado o contrato implicados.
- Solicita posibles superficies de regresión y una matriz de validación, incluyendo la evidencia que refutaría cada hipótesis.
- Verifica cada causa propuesta contra el flujo de control real, las transiciones de estado y las personas usuarias del componente.
- Identifica tú la responsabilidad del contrato y redacta la entrada con etiquetas de confianza como observado, probable o no verificado.
No pidas al modelo que “encuentre el error” sin proporcionarle el contrato. Tampoco aceptes una explicación plausible como causa raíz solo porque suena técnicamente sofisticada. Una respuesta útil de IA acota la investigación; no la sustituye.
2218. Error común
El error común es asignar la responsabilidad al archivo modificado y llamar causa raíz a la primera explicación plausible. La ubicación del diff no necesariamente identifica al responsable del contrato, y la correlación no demuestra causalidad. Otro error es declarar una regresión solo porque existe código compartido. El código compartido amplía la superficie que debe inspeccionarse; no demuestra que haya cambiado el comportamiento de otra persona usuaria. Registra el riesgo, identifica el comportamiento afectado y solicita validación antes de convertir la sospecha en una afirmación confirmada.
2219. Práctica guiada
Usa el siguiente caso ficticio. No se afirma ni se implica ningún incidente del proyecto.
Encargo: Añadir una acción de reintento para una carga fallida. El reintento solo debe aplicarse a la carga fallida, debe conservar el comportamiento actual de cancelación y no debe cambiar el contrato compartido de navegación.
Evidencia de revisión:
- El diff añade una acción de reintento a la pantalla.
- Restablece el estado de la pantalla antes de que termine la solicitud de reintento.
- Modifica un ayudante compartido de navegación.
- La evidencia muestra un reintento exitoso, pero no muestra la cancelación, un segundo reintento fallido ni otra pantalla que utilice el ayudante.
Redacta una entrada de revisión usando los cinco casos:
- Observado: cita únicamente lo que establece la evidencia.
- Causa: proporciona una causa probable y márcala como hipótesis salvo que la evidencia la demuestre.
- Responsabilidad: nombra la pantalla o el contrato compartido implicado y explica la diferencia entre responsabilidad del archivo y del contrato.
- Regresión: identifica un comportamiento existente en riesgo y describe un modo de fallo plausible.
- Validación: especifica la traza, prueba o comparación de usuarios mínima y útil, junto con el resultado esperado.
Después toma una decisión: solicitar cambios, bloquear la aceptación o registrar el hallazgo para seguimiento. Basa la decisión en los criterios de aceptación de la lección anterior y en la solidez de la evidencia disponible. Si el restablecimiento crea un incumplimiento demostrado del contrato, puede justificarse bloquear. Si la evidencia solo muestra un riesgo plausible, declara la incertidumbre y solicita una validación específica en lugar de afirmar que existe una regresión confirmada.
2220. Validación / evidencia
Tu entrega está completa cuando contiene:
- una observación precisa respaldada por la evidencia ficticia;
- una explicación causal claramente marcada como confirmada o hipotética;
- una distinción entre responsabilidad del archivo y responsabilidad del contrato;
- una superficie de regresión identificada, con un modo de fallo plausible;
- una validación capaz de confirmar la causa y valorar el riesgo de regresión;
- una decisión cuya gravedad corresponda a la evidencia y no al número de preocupaciones.
Una entrega sólida no inventa incidentes, historial del repositorio ni detalles ocultos de implementación. Usa únicamente los hechos del caso, marca la incertidumbre y hace reproducible la siguiente investigación.
2221. Puntos clave
- Empieza por el hecho observado y separa la causa de la evidencia.
- Dirige los hallazgos según la responsabilidad del contrato, no automáticamente según el archivo modificado.
- Trata los cambios en código compartido como superficies de regresión que deben investigarse, no como pruebas de regresión.
- Define una validación que pueda confirmar la causa y proteger el comportamiento existente.
- Usa la IA para generar y organizar hipótesis, pero conserva la responsabilidad humana sobre la decisión de revisión.
2222. Próxima lección
Continúa con 5.9 — Tests generados por IA.
2223. Comprobación
Responde estas preguntas por tu cuenta antes de leer las respuestas.
¿Qué afirmación distingue mejor una observación de una hipótesis de causa raíz?
Mostrar respuesta y explicación
Respuesta: Una observación es un hecho directo del diff o de la evidencia; una causa es una explicación que debe verificarse.
Por qué: El hecho observado está respaldado directamente por la evidencia. Una explicación causal sigue siendo una hipótesis hasta que el flujo de control, el estado o el comportamiento pertinente la verifique.
¿Por qué no debe asignarse automáticamente la responsabilidad al archivo modificado?
Mostrar respuesta y explicación
Respuesta: El archivo modificado puede implementar un comportamiento gobernado por el contrato o el límite de decisión de otro sistema.
Por qué: La responsabilidad del archivo identifica una ubicación, mientras que la del contrato identifica el sistema que define el comportamiento. Esos límites pueden ser distintos.
¿Cuál es la respuesta más adecuada cuando un ayudante compartido crea un riesgo de regresión plausible pero no confirmado?
Mostrar respuesta y explicación
Respuesta: Registrar el comportamiento afectado, marcar el riesgo como no confirmado y solicitar una validación específica de otro usuario o recorrido.
Por qué: Un cambio compartido amplía la superficie de regresión, pero no demuestra una regresión. Una validación específica debe establecer si cambió el comportamiento existente.
¿Qué elemento completa el método de cinco casos después de identificar una causa probable, una responsabilidad y una superficie de regresión?
Mostrar respuesta y explicación
Respuesta: Un paso de validación específico con un resultado esperado.
Por qué: El caso de validación convierte la hipótesis de revisión en un siguiente paso reproducible y define qué evidencia confirmaría o descartaría la preocupación.