Pruebas y depuración mental: encontrar errores antes del código con pensamiento computacional

Pruebas y depuración mental: por qué “probar antes” ahorra errores

Antes de escribir código (o incluso antes de ejecutar una idea en la vida real), puedes validar tu solución con una simulación manual: ejecutar mentalmente los pasos como si fueras la máquina y comprobar si el resultado coincide con lo esperado. A esto se le suele llamar traza (trace): un registro paso a paso de lo que ocurre, qué cambia y qué falta.

La clave es tratar tu algoritmo en lenguaje natural como un “programa” y someterlo a pruebas con casos representativos. Si tu solución falla en papel, fallará en la realidad o en el código.

Dos herramientas: traza y casos de prueba

• Traza (simulación manual): ejecutas cada paso y anotas el estado (lo que queda por hacer, recursos disponibles, decisiones tomadas).
• Casos de prueba: eliges entradas y situaciones que ejerciten el algoritmo (normal, límite, excepcional) y defines qué debería pasar.

Tipos de casos: normal, límite y excepcional

Para probar una solución no basta con un ejemplo “bonito”. Necesitas variedad:

• Caso normal: lo típico, lo que esperas que ocurra la mayoría de veces.
• Caso límite: valores o situaciones en el borde (mínimos, máximos, “casi vacío”, “justo a tiempo”). Suelen revelar errores de condiciones.
• Caso excepcional: algo sale mal o no existe (faltan recursos, una opción no está disponible, una restricción impide continuar). Obliga a definir qué hacer cuando no se puede seguir como siempre.

Una buena práctica: por cada algoritmo, intenta diseñar al menos 1 caso normal, 2 casos límite y 2 casos excepcionales.

Cómo hacer una ejecución paso a paso (traza) anotando estado

Guía práctica en 6 pasos

1. Escribe el algoritmo en pasos numerados (en lenguaje natural, sin ambigüedad).
2. Define la entrada (qué datos o recursos tienes al inicio).
3. Define el resultado esperado (qué significa “funciona”).
4. Elige un caso de prueba (normal/límite/excepcional).
5. Ejecuta paso a paso y en cada paso anota el estado (pendientes, recursos, decisiones, salida parcial).
6. Marca el primer punto donde algo no cuadra: ahí suele estar el error (o una ambigüedad).

Formato de traza recomendado (tabla)

Usa una tabla para que sea fácil detectar dónde cambió algo:

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

El “estado” debe incluir, según el problema: qué queda por hacer, qué recursos faltan, qué condiciones se cumplieron y qué se eligió.

Ejemplo 1: Lista de compras (¿y si un producto no existe?)

Algoritmo en lenguaje natural

1. Tomar la lista de productos deseados.
2. Para cada producto, buscarlo en la tienda.
3. Si el producto está disponible, añadirlo al carrito.
4. Si no está disponible, elegir un sustituto aceptable o marcarlo como “pendiente”.
5. Al final, revisar pendientes y decidir: cambiar de tienda, eliminar o posponer.

Casos de prueba sugeridos

• Normal: todos los productos existen.
• Límite: lista vacía (no hay nada que comprar).
• Límite: solo 1 producto.
• Excepcional: un producto no existe y no hay sustituto.
• Excepcional: hay sustituto, pero supera el presupuesto.

Traza del caso excepcional: “producto no existe y no hay sustituto”

Hallazgo típico: si el algoritmo no define qué hacer cuando no hay sustituto, la ejecución se queda en una decisión implícita. Eso es un error de especificación: falta una condición y una acción.

Ejemplo 2: Ruta (¿y si hay un cierre?)

Algoritmo en lenguaje natural

1. Definir origen y destino.
2. Elegir una ruta principal.
3. Antes de salir, comprobar si hay cierres en la ruta principal.
4. Si hay cierre, elegir ruta alternativa; si no, seguir la principal.
5. Durante el trayecto, si aparece un cierre inesperado, recalcular desde la posición actual.

Casos de prueba sugeridos

• Normal: ruta principal sin cierres.
• Límite: destino a 1 calle (trayecto mínimo).
• Excepcional: cierre antes de salir (detectable).
• Excepcional: cierre inesperado en mitad del trayecto.
• Excepcional: no existe ruta alternativa (por ejemplo, zona aislada).

Traza del caso excepcional: “cierre inesperado en mitad del trayecto”

Hallazgo típico: si tu algoritmo solo contempla cierres “antes de salir” y no durante el trayecto, fallará en la realidad. La traza obliga a añadir la condición “si aparece un cierre inesperado, recalcular”.

Ejemplo 3: Receta (¿y si falta un utensilio?)

Algoritmo en lenguaje natural

1. Reunir ingredientes y utensilios necesarios.
2. Precalentar el horno.
3. Mezclar ingredientes en un bol.
4. Verter en un molde.
5. Hornear X minutos.

Casos de prueba sugeridos

• Normal: están todos los utensilios.
• Límite: cantidad mínima (porción pequeña) que cambia tiempos o tamaño de molde.
• Excepcional: falta un utensilio clave (molde, batidora, horno).
• Excepcional: el horno no calienta (recurso no funcional).

Traza del caso excepcional: “falta el molde”

Hallazgo típico: el algoritmo empieza por “precalentar” sin verificar recursos. En una ejecución real, puedes perder tiempo o arruinar el proceso. Solución: convertir el paso 1 en una verificación con salida clara: “si falta un utensilio, sustituir / conseguir / cambiar receta”.

Técnicas de depuración mental (debugging) aplicadas a algoritmos en lenguaje natural

1) Localizar el paso ambiguo

Un paso es ambiguo si permite varias interpretaciones. Señales:

• Usa palabras como “rápido”, “lo suficiente”, “un poco”, “cerca”.
• No define qué hacer si hay varias opciones (¿qué sustituto elegir?, ¿qué ruta alternativa?).

Técnica: reescribe el paso con criterios observables. Ejemplo:

Ambiguo: “elige un sustituto aceptable”
Más claro: “elige el sustituto más barato de la lista permitida; si no existe, marcar pendiente”

2) Revisar condiciones (especialmente límites)

Muchos fallos aparecen en “igual a” y en extremos. Preguntas útiles:

• ¿Qué pasa si la lista está vacía?
• ¿Qué pasa si el recurso existe pero está agotado?
• ¿Qué pasa si el tiempo es exactamente el límite?

Técnica: para cada condición, prueba mentalmente los valores: menor, igual, mayor.

3) Detectar bucles infinitos (repetición sin salida)

En la vida cotidiana también hay bucles: “seguir intentando hasta que funcione” sin criterio de parada.

Señales:

• Un paso que dice “repetir” pero no define cuándo parar.
• Una condición que nunca cambia (buscas el producto en el mismo lugar una y otra vez).

Técnica: añade un contador o un límite de intentos, o una condición de salida explícita:

Reintentar buscar sustituto hasta 3 opciones; si ninguna sirve, marcar pendiente y continuar.

4) Ordenar dependencias (lo que debe ocurrir antes)

Un error frecuente es ejecutar pasos en un orden que asume recursos o estados que aún no existen.

• Receta: mezclar antes de verificar utensilios.
• Ruta: salir sin comprobar cierres conocidos.
• Compras: ir a pagar sin revisar pendientes críticos.

Técnica: en la traza, marca cada paso que requiere algo (recurso/decisión) y asegúrate de que ese requisito se cumplió antes.

Plantilla simple de plan de pruebas (para algoritmos en lenguaje natural)

Usa esta plantilla para registrar pruebas de forma consistente. La columna “Resultado” se completa después de ejecutar la traza.

Consejo práctico: si en “Resultado” escribes “no se sabe” o “depende”, no es un fallo de ejecución; es una señal de que el algoritmo tiene una ambigüedad o una condición faltante que debes especificar.