# Cómo depurar errores de programación de forma efectiva

**Categoría:** Programación · **Nivel:** Intermedio · **Lectura:** 12 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/programacion/como-depurar-errores-de-programacion/

## Respuesta rápida

**Depurar** (o *debuggear*) es el proceso de encontrar y corregir errores en un programa. La diferencia entre hacerlo bien y mal es enorme: quien depura con método encuentra la causa en minutos, mientras que quien **adivina** cambios al azar puede pasar horas y, peor, «arreglar» el síntoma sin entender la causa —con lo que el error vuelve—. El método tiene cinco pasos. **Reproducir** el error de forma fiable: si no podés provocarlo a voluntad, no vas a saber cuándo lo arreglaste. **Leer el mensaje completo**, incluida la traza que indica archivo y línea; el mensaje casi siempre dice qué pasó. **Aislar la causa** con el método científico: formular una hipótesis, probarla, descartar. **Usar el depurador** para detener el programa y mirar los valores reales, en vez de suponerlos. Y **evitar que vuelva**: entender la causa, corregirla y escribir una [prueba](../../testing/introduccion-al-testing/index.md) que falle si el error reaparece. Depurar bien es una habilidad que se aprende, y es de las que más separa a quien programa con soltura de quien pelea con el código.

## Qué es depurar (y qué no)

**Depurar** es encontrar la causa de un comportamiento incorrecto y corregirla. La palabra viene del inglés *debugging*: quitar los *bugs*, los errores. Lo que **no** es depurar: cambiar cosas al azar hasta que «funcione». Ese método —tristemente común— tiene dos problemas graves.

> **Por qué adivinar es peor que lento**
>
> Cambiar al azar es lento, pero el problema mayor es otro: cuando algo «se arregla» sin entender por qué, no sabés si arreglaste la causa o tapaste el síntoma. Un error que desaparece por casualidad **vuelve** en cuanto cambian las condiciones, y encima ahora hay cambios al azar en el código que nadie entiende. Depurar con método no es solo más rápido: es la única forma de estar seguro de que el problema realmente se resolvió.

La buena noticia: depurar es una **habilidad**, no un talento. Sigue un método que se puede aprender y aplicar a cualquier lenguaje y cualquier error. Los cinco pasos que siguen son ese método.

## Reproducir y leer el mensaje

El primer paso es **reproducir** el error de forma fiable: conseguir provocarlo a voluntad. Suena obvio, pero es el paso que más se saltea, y sin él todo lo demás es imposible: si no podés provocar el error cuando querés, tampoco vas a saber cuándo lo arreglaste. Reproducir implica identificar *exactamente* con qué datos o en qué situación aparece.

El segundo es **leer el mensaje completo**. Los errores vienen con un mensaje y una **traza** (el *stack trace*) que indica el tipo de error, el archivo y la línea donde ocurrió, y la cadena de llamadas que llevó hasta ahí. Ese mensaje casi siempre dice qué pasó. Ignorarlo —o cerrarlo sin leerlo— es el error más común de quien empieza. Leer «no puede leer la propiedad X de indefinido» y la línea exacta ya resuelve media depuración.

## Aislar la causa

El tercer paso es el corazón del método: **aislar la causa** aplicando, sin nombrarlo, el **método científico**. En vez de mirar todo el código a la vez, se avanza por hipótesis:

1. **Formular una hipótesis concreta.** «Creo que la variable llega vacía a esta función», no «algo está mal».
2. **Diseñar una prueba que la confirme o la descarte.** Mirar el valor en ese punto, comentar una parte, probar con otro dato.
3. **Observar el resultado y ajustar.** Si la hipótesis era falsa, se descarta y se estrecha la búsqueda en otra dirección.

Una técnica poderosa dentro de este paso es **dividir a la mitad**: si el error está en algún punto de un proceso largo, comprobás el estado justo en la mitad. Eso te dice en cuál de las dos mitades está el problema, y repetís. En pocos pasos, un error escondido en cientos de líneas queda acorralado en unas pocas. Si usás [Git](../git-y-github-desde-cero/index.md), la misma idea sirve para encontrar *qué cambio* introdujo el error, revisando el historial.

## El depurador: mirar, no adivinar

El cuarto paso reemplaza la suposición por la observación. Un **depurador** (*debugger*) es una herramienta —integrada en los navegadores, los editores y los lenguajes— que permite **detener el programa** en un punto elegido (un *punto de interrupción* o *breakpoint*) y mirar los valores reales de cada variable en ese instante, además de avanzar **paso a paso**.

> **Atención**
>
> Casi todos los errores nacen de una diferencia entre lo que el programa *hace* y lo que vos *creés* que hace. El depurador cierra esa brecha: en vez de suponer que una variable vale 5, la mirás y ves que vale `null`. Esa observación suele resolver el error al instante. Es infinitamente más eficaz que sembrar el código de mensajes impresos, aunque estos también sirven, sobre todo para [código asíncrono](../programacion-asincrona-en-javascript/index.md) o cosas difíciles de detener.

Cuando el error no se puede reproducir en vivo —porque pasa en producción, de forma intermitente— la herramienta es el **registro** (*logging*): dejar que el programa anote qué hace, para reconstruir después qué ocurrió. Es la misma pieza que vuelve confiable a un [guion automático](../automatizacion-de-tareas-con-python/index.md).

## Que el error no vuelva

El quinto paso es el que separa depurar de *parchear*. Una vez encontrada la causa:

- **Corregí la causa, no el síntoma.** Si una función recibe un valor vacío y falla, la solución no siempre es «que no falle con vacío»: a veces el problema real es *por qué* llega vacío. Preguntarse eso evita tapar el problema.
- **Escribí una prueba que falle con el error.** Una [prueba automática](../../testing/introduccion-al-testing/index.md) que reproduzca el caso corregido garantiza que, si el error reaparece en el futuro, se detecta solo. Es la mejor forma de que un error corregido no vuelva.
- **Aprovechá para mejorar el código.** Muchos errores se esconden en código confuso; dejarlo más [limpio](../clean-code-codigo-limpio-y-mantenible/index.md) tras arreglarlo previene los próximos.

## Errores frecuentes al depurar

- **Adivinar cambios al azar.** Lento, y no sabés si arreglaste la causa o tapaste el síntoma.
- **No leer el mensaje de error.** Casi siempre dice qué pasó y en qué línea; saltearlo alarga todo.
- **No reproducir primero.** Sin poder provocar el error, no sabés cuándo lo arreglaste.
- **No usar el depurador.** Suponer valores en vez de mirarlos es la causa de la mayoría de las horas perdidas.
- **Corregir el síntoma.** Si no entendés por qué pasó, el error vuelve con otra cara.
- **No escribir una prueba.** Un error sin prueba de regresión es un error que puede volver sin aviso.
- **Depurar cansado y solo por horas.** Explicarle el problema a otra persona (o en voz alta) revela la causa sorprendentemente seguido.

## Preguntas frecuentes

**¿Qué significa depurar o hacer debugging?**
Depurar, o hacer debugging, es el proceso de encontrar la causa de un comportamiento incorrecto en un programa y corregirla. El término viene del inglés y se refiere a quitar los bugs, que es como se llama a los errores de software. Es importante distinguirlo de lo que muchos hacen sin darse cuenta, que es cambiar cosas en el código más o menos al azar hasta que aparentemente funciona. Eso no es depurar, y es problemático por dos razones: es lento, pero sobre todo, cuando algo se arregla sin entender por qué, uno no sabe si corrigió la verdadera causa o simplemente tapó el síntoma, de modo que el error puede volver en cuanto cambien las condiciones. Depurar de verdad implica seguir un método ordenado para identificar la causa real, entenderla y corregirla con seguridad. La buena noticia es que ese método es una habilidad que se aprende, no un talento innato, y se aplica a cualquier lenguaje.

**¿Cuál es el método para depurar un error?**
El método tiene cinco pasos. El primero es reproducir el error de forma fiable, es decir conseguir provocarlo a voluntad, porque si no se puede provocar cuando uno quiere, tampoco se podrá comprobar si quedó arreglado. El segundo es leer el mensaje de error completo, incluida la traza que indica el tipo de error, el archivo y la línea donde ocurrió, ya que ese mensaje casi siempre dice qué pasó. El tercero es aislar la causa aplicando el método científico: formular una hipótesis concreta sobre qué falla, diseñar una prueba que la confirme o descarte, y repetir estrechando el área sospechosa. El cuarto es usar el depurador para detener el programa y observar los valores reales de las variables en lugar de suponerlos. Y el quinto es corregir la causa real, no el síntoma, y escribir una prueba automática que falle si el error reaparece, para que quede protegido. Aplicar estos pasos es lo que separa encontrar la causa en minutos de pelear con el código durante horas.

**¿Qué es un depurador y cómo se usa?**
Un depurador es una herramienta que permite detener la ejecución de un programa en un punto elegido, llamado punto de interrupción, para inspeccionar el valor real de cada variable en ese instante y avanzar luego paso a paso, línea por línea, observando cómo cambia el estado. Viene integrado en los navegadores, en los editores de código y en los propios lenguajes, así que casi siempre está disponible sin instalar nada especial. Su utilidad es enorme porque la mayoría de los errores nacen de una diferencia entre lo que el programa hace realmente y lo que uno cree que hace; el depurador cierra esa brecha al mostrar los datos reales en lugar de dejar que uno los suponga. En la práctica se coloca un punto de interrupción cerca de donde se sospecha el problema, se ejecuta el programa hasta que se detiene ahí, y se examinan las variables para ver si sus valores coinciden con lo esperado. Suele resolver el error al instante y es mucho más eficaz que llenar el código de mensajes impresos, aunque estos también sirven en ciertos casos.

**¿Por qué es mala idea cambiar cosas al azar hasta que funcione?**
Porque tiene dos problemas, y el segundo es más grave que el primero. El primero es que es lento e ineficiente: sin una hipótesis que oriente la búsqueda, uno prueba modificaciones sin rumbo y puede pasar horas dando vueltas. El segundo y más serio es que cuando algo parece arreglarse de esa manera, uno no tiene forma de saber si corrigió la verdadera causa del problema o si simplemente lo tapó por casualidad. Un error que desaparece sin que se entienda por qué es un error que probablemente vuelva en cuanto cambien las condiciones, por ejemplo con otros datos o en otro entorno, y para entonces el código además tendrá una serie de cambios hechos al tanteo que nadie comprende del todo y que pueden haber introducido nuevos problemas. Depurar con método no es solo más rápido: es la única forma de tener la certeza de que el problema quedó realmente resuelto y no meramente oculto.

**¿Cómo evito que un error corregido vuelva a aparecer?**
La forma más efectiva es escribir una prueba automática que reproduzca el caso del error y que falle si el problema reaparece. Una vez que encontraste y corregiste la causa, esa prueba queda formando parte del proyecto y se ejecuta junto con las demás, de modo que si en el futuro algún cambio vuelve a introducir el mismo error, se detecta automáticamente y de inmediato, en lugar de que lo descubra un usuario. Esto se conoce como prueba de regresión y es una de las grandes razones por las que el testing y la depuración van de la mano. Además de la prueba, conviene asegurarse de haber corregido la causa real y no solo el síntoma visible, preguntándose por qué se produjo el problema de fondo, y aprovechar el momento para dejar más claro y ordenado el código donde estaba escondido el error, porque el código confuso es donde más errores se ocultan y mejorarlo previene los siguientes.

**¿Depurar se puede aprender o es cuestión de talento?**
Se puede aprender, y de hecho es una de las habilidades que más claramente distingue a quien programa con soltura de quien vive peleando con el código, precisamente porque es un método y no un don. No depende de una intuición mágica sino de aplicar de forma disciplinada una serie de pasos: reproducir el error, leer con atención el mensaje, formular y probar hipótesis para aislar la causa, observar los valores reales con el depurador en vez de suponerlos, y corregir la causa protegiéndose con una prueba. Cualquiera que practique este método mejora notablemente su capacidad de resolver problemas, sin importar cuánta experiencia tenga al empezar. Con el tiempo, muchos de estos pasos se vuelven automáticos y uno reconoce patrones de errores frecuentes más rápido, pero esa velocidad es fruto de la práctica del método, no de un talento innato. Por eso vale la pena tratarlo como una habilidad que se entrena de forma consciente desde el principio.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección Programación](https://underc0de.org/foro/programacion/). Consultas sobre errores, depuración y resolución de problemas.
2. **Underc0de, foro.** [Dudas y pedidos generales](https://underc0de.org/foro/dudas-y-pedidos-generales/). Ayuda con errores concretos de código.

### Documentación oficial

1. **Mozilla.** [Qué salió mal: solucionar problemas de JavaScript](https://developer.mozilla.org/es/docs/Learn_web_development/Core/Scripting/What_went_wrong). Guía de depuración de MDN.
2. **Mozilla.** [El depurador de las herramientas de desarrollo](https://developer.mozilla.org/es/docs/Tools/Debugger). Puntos de interrupción y ejecución paso a paso.
3. **Python Software Foundation.** [pdb, el depurador de Python](https://docs.python.org/es/3/library/pdb.html). Depuración interactiva en Python.
4. **Python Software Foundation.** [logging](https://docs.python.org/es/3/library/logging.html). Registrar para diagnosticar lo que no se puede reproducir en vivo.

## Guías relacionadas

- [Clean Code: código mantenible](../clean-code-codigo-limpio-y-mantenible/index.md)
- [Introducción al testing](../../testing/introduccion-al-testing/index.md)
- [Git y GitHub desde cero](../git-y-github-desde-cero/index.md)
- [Programación asíncrona en JS](../programacion-asincrona-en-javascript/index.md)
- [Índice de Programación](../index.md)