Módulo 5: Construir, probar y corregir

Construir algoritmos completos a partir de requisitos, comprobarlos con casos de prueba y corregir sus errores mediante un proceso ordenado y basado en evidencia.

Al terminar el módulo, podrá:

• convertir una situación cotidiana en requisitos claros;
• separar entradas, reglas, procesos, salidas y casos inválidos;
• reconocer requisitos incompletos o ambiguos;
• establecer resultados esperados antes de probar;
• diseñar casos normales, límite, inválidos y sin datos;
• comprobar todos los caminos importantes de una decisión;
• probar cero, una y varias iteraciones;
• realizar una prueba de escritorio;
• comparar resultado esperado y resultado obtenido;
• localizar el primer punto donde ambos se separan;
• diferenciar síntoma, causa y corrección;
• reconocer errores de cálculo, condición, límite, actualización y finalización;
• corregir una causa sin ocultar sus síntomas;
• repetir las pruebas después de una corrección;
• documentar qué falló, cómo se corrigió y qué evidencia demuestra el resultado;
• decidir cuándo un algoritmo está suficientemente comprobado para el alcance del problema.

Este módulo no enseña herramientas de depuración de Python, Java, JavaScript ni otro lenguaje. Enseña el razonamiento necesario para probar y corregir cualquier algoritmo.

PARTE 1 — ACTIVACIÓN

Si un algoritmo produce la respuesta correcta una vez, ¿eso demuestra que siempre funciona?

Considere esta regla:

Las personas de 65 años o más pagan 2 unidades. Las demás pagan 5.

Algoritmo:

SI edad > 65 ENTONCES
    precio ← 2
SINO
    precio ← 5
FIN SI

Con edad ← 70, el resultado es correcto.

Pero con edad ← 65, el algoritmo cobra 5.

Un caso exitoso demuestra únicamente que el algoritmo funcionó para ese caso. No demuestra que:

• los límites sean correctos;
• los datos inválidos estén contemplados;
• todos los caminos funcionen;
• una repetición termine;
• los totales se actualicen correctamente.

Una tienda aplica estas reglas:

• compras menores que 50 no reciben descuento;
• compras desde 50 hasta menos de 100 reciben 5 %;
• compras de 100 o más reciben 10 %;
• una compra negativa es inválida.

Responda:

1. ¿Qué valores utilizaría para probar el límite de 50?
2. ¿Qué valores utilizaría para probar el límite de 100?
3. ¿Qué valor comprobaría la entrada inválida?
4. ¿Bastaría con probar únicamente 75? ¿Por qué?
5. Para una compra de 100, ¿cuál es el resultado esperado?
6. Si el algoritmo devuelve 5 % para 100, ¿en qué regla comenzaría a investigar?

Propósito

Probar no consiste en ingresar números al azar. Consiste en elegir datos que permitan confirmar o refutar reglas concretas.

PARTE 2 — CONSTRUIR DESDE REQUISITOS

Un error frecuente es comenzar a escribir instrucciones antes de comprender el problema.

La construcción debe comenzar con preguntas:

¿Qué debe resolver?
¿Qué datos recibe?
¿Qué resultados debe producir?
¿Qué reglas transforman las entradas?
¿Qué datos no son válidos?
¿Qué ocurre en los límites?
¿Cuándo termina?

Analogía: una receta

Antes de cocinar es necesario conocer:

• qué plato se espera;
• para cuántas personas;
• qué ingredientes existen;
• qué restricciones deben respetarse;
• cómo reconocer que está terminado.

Un algoritmo puede seguir instrucciones perfectamente y aun así resolver el problema equivocado si la solicitud no se entendió.

Un requisito es una condición o comportamiento que la solución debe cumplir.

Ejemplo:

El sistema debe aceptar notas entre 0 y 100, incluidos ambos límites.

De este requisito se obtiene:

dato válido: nota ≥ 0 Y nota ≤ 100
dato inválido: nota < 0 O nota > 100

Y también aparecen pruebas:

-1, 0, 1, 99, 100, 101

Un requisito claro permite:

• construir;
• probar;
• explicar;
• decidir si el resultado es correcto.

Antes de escribir el algoritmo, organice el problema.

Ejemplo: registrar donaciones

Regla:

Registrar donaciones positivas hasta ingresar 0. Mostrar cantidad, total y promedio.

ENTRADAS
donación

REGLAS
aceptar valores mayores que 0
0 termina
negativos son inválidos

SALIDAS
cantidad
total
promedio o mensaje sin datos

CASOS INVÁLIDOS
valores negativos

FINALIZACIÓN
cuando la entrada sea 0

Un criterio de éxito describe algo observable que debe cumplirse.

Para las donaciones:

1. Una donación positiva aumenta la cantidad en 1.
2. Una donación positiva se suma al total.
3. Una donación negativa no se suma ni se cuenta.
4. El valor 0 termina y no se procesa.
5. Si no hay donaciones válidas, no se divide entre cero.
6. El promedio utiliza únicamente donaciones válidas.

Estos criterios se convierten después en casos de prueba.

Una regla es ambigua cuando permite más de una interpretación razonable.

Ejemplo:

Las personas menores pagan descuento.

Faltan respuestas:

• ¿menores de qué edad?
• ¿el límite está incluido?
• ¿cuánto descuento?
• ¿qué edades son válidas?
• ¿qué ocurre si la edad es negativa?

No conviene inventar silenciosamente una regla.

Si no puede preguntar

Cuando un ejercicio no permite consultar a la persona responsable:

1. escriba la ambigüedad;
2. declare una suposición;
3. aplíquela de forma consistente;
4. incluya una prueba que muestre su efecto.

Ejemplo:

SUPOSICIÓN
"Menor" significa edad < 18.

1. COMPRENDER
2. ORGANIZAR
3. PROPONER EJEMPLOS
4. DISEÑAR
5. ESCRIBIR
6. REVISAR

Comprender

Explique el problema con sus propias palabras.

Organizar

Separe entradas, reglas, salidas, inválidos y final.

Proponer ejemplos

Calcule manualmente al menos un resultado normal y un límite.

Diseñar

Decida qué partes son:

• secuenciales;
• decisiones;
• repeticiones.

Escribir

Construya el algoritmo y el pseudocódigo.

Revisar

Compruebe que cada requisito aparece y que no agregó reglas inexistentes.

PARTE 3 — DISEÑAR PRUEBAS ÚTILES

Un caso de prueba contiene:

• una entrada específica;
• un resultado esperado;
• la regla que se desea comprobar;
• el resultado obtenido;
• la conclusión.

Plantilla

El resultado esperado debe escribirse antes de recorrer el algoritmo. De lo contrario, existe el riesgo de aceptar como correcto cualquier resultado que aparezca.

RESULTADO ESPERADO
lo que las reglas indican que debe ocurrir

RESULTADO OBTENIDO
lo que el algoritmo realmente produce

Si coinciden, el caso pasa.

Si no coinciden, el caso falla y proporciona evidencia de un defecto.

esperado = 10 % de descuento
obtenido = 5 % de descuento
estado = FALLA

Una falla no dice todavía cuál línea está mal. Dice que existe una diferencia que debe investigarse.

Un caso normal utiliza un valor claramente dentro de una regla.

Para el rango de notas 0 a 100:

nota = 75

Para precio de persona adulta:

edad = 30

Los casos normales son necesarios, pero suelen ser los más fáciles. No deben ser los únicos.

Un límite es un punto donde cambia la regla.

Si:

edad < 12 → precio infantil
edad ≥ 12 → precio general

pruebe:

11 → justo antes
12 → exactamente en el límite
13 → justo después

Regla de tres valores

Para cada límite numérico:

límite - 1
límite
límite + 1

Cuando se usan decimales, elija valores inmediatamente cercanos según la precisión permitida.

Un caso inválido comprueba que el algoritmo rechace información imposible o prohibida.

Ejemplos:

edad = -3
nota = 120
cantidad = -8
hora = 25
opción = 9 cuando solo existen 1, 2 y 3

No basta con que el algoritmo calcule correctamente para datos válidos. También debe proteger las reglas ante datos que no corresponden.

Algunos algoritmos permiten terminar antes de procesar información.

Ejemplo:

0 es centinela
primera entrada = 0

Debe comprobarse:

• que el ciclo no procese el centinela;
• que los contadores sigan en cero;
• que no exista división entre cero;
• que aparezca un mensaje apropiado.

Para una repetición controlada por condición, pruebe:

Para un ciclo con máximo tres intentos:

acierto en el primero
acierto en el tercero
tres fallos

No es necesario probar todos los números posibles. Se agrupan valores que deberían seguir la misma regla.

Ejemplo de edades:

Se selecciona al menos:

• un valor normal de cada familia;
• los valores alrededor de sus límites.

Este método reduce pruebas repetidas que no aportan nueva información.

Para este curso, una prueba suficiente debe recorrer:

• cada salida principal;
• cada categoría;
• cada mensaje de error;
• cada límite;
• cero, una y varias iteraciones cuando existan ciclos;
• el final normal.

No se utilizarán porcentajes ni herramientas profesionales de cobertura.

La pregunta será:

¿Existe algún camino importante que ninguna prueba haya recorrido?

Duración: 6 minutos y 16 segundos Tema exacto: Seguimiento de variables y detección de resultados inesperados Antes de continuar: Observe cómo se registra cada cambio. La tabla puede hacerse en papel.

PARTE 4 — PRUEBA DE ESCRITORIO

Es la ejecución manual de un algoritmo.

La persona actúa como si fuera la computadora:

1. lee una instrucción;
2. evalúa las expresiones;
3. actualiza las variables;
4. elige el camino correspondiente;
5. registra las salidas;
6. repite hasta finalizar.

No se corrige mientras se rastrea. Primero se registra honestamente lo que el algoritmo hace.

Algoritmo:

LEER cantidad
precio ← 4
subtotal ← cantidad * precio

SI cantidad ≥ 5 ENTONCES
    descuento ← subtotal * 0.10
SINO
    descuento ← 0
FIN SI

total ← subtotal - descuento
MOSTRAR total

Caso:

cantidad = 5

Resultado esperado:

18

Resultado obtenido:

18

Estado:

PASA

En cada condición registre:

• la expresión completa;
• el resultado verdadero o falso;
• el camino elegido.

Ejemplo:

edad ≥ 12 Y edad ≤ 17

Para edad ← 18:

18 ≥ 12 → VERDADERO
18 ≤ 17 → FALSO
VERDADERO Y FALSO → FALSO
camino elegido → SINO

Esto ayuda a detectar si el error está:

• en los datos;
• en una comparación;
• en un operador;
• en el orden de los caminos.

Registre una fila por iteración.

total ← 0

PARA numero DESDE 1 HASTA 3 HACER
    total ← total + numero
FIN PARA

Si el ciclo es MIENTRAS, agregue:

• resultado de la condición;
• valor que provoca la salida.

La pista más valiosa es el primer momento donde:

valor esperado ≠ valor obtenido

Ejemplo:

total esperado después del segundo dato = 15
total obtenido = 10

Si antes de esa instrucción ambos eran 5, la investigación debe comenzar en la actualización del segundo dato.

No conviene comenzar por la última salida si el estado ya era incorrecto desde varias instrucciones antes.

Una tabla puede incluir:

• variables que cambian;
• condiciones importantes;
• salida producida.

No necesita repetir información que nunca cambia, salvo que ayude a comprender una fórmula.

El objetivo no es llenar una tabla enorme. Es poder responder:

¿qué valor tenía?
¿qué instrucción lo cambió?
¿qué valor obtuvo?
¿era el esperado?

PARTE 5 — DIAGNOSTICAR Y CORREGIR

Síntoma

Lo que se observa.

El total final es demasiado bajo.

Causa

La instrucción o decisión que origina el problema.

El total se reemplaza en vez de acumularse.

Corrección

El cambio que elimina la causa.

total ← total + valor

Cambiar solamente el mensaje final no arreglaría el acumulador.

El algoritmo resuelve una regla distinta de la solicitada.

Requisito:

65 años o más

Algoritmo:

edad > 65

La lógica ejecuta exactamente lo escrito, pero lo escrito no representa el requisito.

Corrección:

edad ≥ 65

Se utiliza una comparación u operador incorrecto.

Requisito:

Tener inscripción y cupo.

Incorrecto:

inscripcion_confirmada O cupos > 0

Corrección:

inscripcion_confirmada Y cupos > 0

La fórmula no representa la operación correcta.

Incorrecto:

descuento ← subtotal * 10

Corrección para 10 %:

descuento ← subtotal * 0.10

Una prueba con números fáciles, como 100, ayuda a reconocer el error.

El algoritmo incluye o excluye accidentalmente un valor extremo.

hora ≥ 8 Y hora ≤ 17

es incorrecto si el servicio cierra exactamente a las 17.

Corrección:

hora ≥ 8 Y hora < 17

La variable no conserva el valor correcto.

Incorrecto:

total ← valor

si se desea acumular.

Correcto:

total ← total + valor

Otro ejemplo:

contador ← 0

dentro de un ciclo puede borrar todo lo contado.

El ciclo:

• no actualiza la variable de control;
• cambia en dirección contraria;
• nunca vuelve a leer;
• utiliza una condición imposible de finalizar;
• procesa el centinela como dato.

Estos errores pueden provocar:

• ciclo infinito;
• una iteración adicional;
• salida demasiado temprana;
• datos repetidos.

1. REPRODUCIR
2. DEFINIR LO ESPERADO
3. REDUCIR
4. RASTREAR
5. FORMULAR UNA CAUSA
6. CORREGIR UNA COSA
7. VOLVER A PROBAR

Reproducir

Conserve una entrada que demuestre la falla.

Definir lo esperado

Calcule manualmente la respuesta correcta.

Reducir

Utilice el caso más pequeño que todavía muestre el problema.

Rastrear

Busque la primera diferencia.

Formular una causa

Explique por qué esa instrucción genera el resultado.

Corregir una cosa

Realice un cambio controlado. Varios cambios simultáneos dificultan saber cuál resolvió o creó un problema.

Volver a probar

Ejecute:

• el caso que falló;
• los casos que ya pasaban;
• los límites relacionados.

Después de una corrección, un caso antiguo podría fallar.

Ejemplo:

• corregir el precio para edad 65;
• volver a probar 11, 12, 64, 65 y 66.

La prueba que se repite después de un cambio se utiliza para comprobar que la corrección no dañó comportamientos anteriores.

En este curso llamaremos conjunto de regresión a la lista breve de casos que se vuelve a ejecutar después de cada arreglo.

Documentar evita:

• repetir la misma investigación;
• olvidar qué se cambió;
• afirmar que algo está arreglado sin evidencia.

Duración: 9 minutos y 46 segundos Tema exacto: Proceso ordenado para encontrar y corregir errores Antes de continuar: Relacione sus pasos con reproducir, rastrear, formular una causa y volver a probar.

PARTE 6 — EJEMPLOS RESUELTOS

Requisito

• subtotal menor que 50: sin descuento;
• subtotal de 50 o más: 10 %;
• subtotal negativo: inválido.

Algoritmo defectuoso

LEER subtotal

SI subtotal > 50 ENTONCES
    descuento ← subtotal * 0.10
SINO
    descuento ← 0
FIN SI

total ← subtotal - descuento
MOSTRAR total

Casos

Diagnóstico

• -1: falta validación.
• 50: subtotal > 50 es falso; el límite debe incluirse.

Corrección

LEER subtotal

SI subtotal < 0 ENTONCES
    MOSTRAR "Subtotal inválido"
SINO
    SI subtotal ≥ 50 ENTONCES
        descuento ← subtotal * 0.10
    SINO
        descuento ← 0
    FIN SI

    total ← subtotal - descuento
    MOSTRAR total
FIN SI

Después se repiten los cuatro casos.

Requisito

Sumar tres valores.

Algoritmo defectuoso

total ← 0

PARA posicion DESDE 1 HASTA 3 HACER
    LEER valor
    total ← valor
FIN PARA

MOSTRAR total

Caso:

4, 6, 5

Esperado:

15

Rastreo:

La primera diferencia aparece en la segunda iteración.

Corrección:

total ← total + valor

Algoritmo defectuoso

LEER numero

MIENTRAS numero ≠ 0 HACER
    MOSTRAR numero
FIN MIENTRAS

Con numero ← 5, muestra 5 indefinidamente.

La condición depende de numero, pero el cuerpo nunca lo modifica.

Corrección:

LEER numero

MIENTRAS numero ≠ 0 HACER
    MOSTRAR numero
    LEER numero
FIN MIENTRAS

Pruebas:

0
5, 0
5, 8, 0

Requisito

Leer una nota y mostrar:

• inválida si está fuera de 0 a 100;
• excelente desde 90;
• aprobada desde 70;
• necesita mejorar en cualquier otro caso válido.

Casos antes del algoritmo

Diseño

validar
clasificar de la categoría más alta a la más baja
definir caso restante

Pseudocódigo

LEER nota

SI nota < 0 O nota > 100 ENTONCES
    MOSTRAR "Nota inválida"
SINO SI nota ≥ 90 ENTONCES
    MOSTRAR "Excelente"
SINO SI nota ≥ 70 ENTONCES
    MOSTRAR "Aprobada"
SINO
    MOSTRAR "Necesita mejorar"
FIN SI

Los ocho casos recorren todos los caminos y sus límites.

PARTE 7 — ACTIVIDAD SIN COMPUTADORA

Roles

• Persona solicitante: lee los requisitos.
• Algoritmo: sigue exactamente las instrucciones.
• Persona probadora: entrega casos y resultados esperados.
• Observadora: registra el primer punto de diferencia.

Requisitos

Edad válida: 1 a 120.
Menor de 12: precio 3.
De 12 a 64: precio 5.
Desde 65: precio 2.

Algoritmo con error

SI edad < 12 ENTONCES
    precio ← 3
SINO SI edad > 65 ENTONCES
    precio ← 2
SINO
    precio ← 5
FIN SI

Tarjetas de prueba

-1, 1, 11, 12, 64, 65, 66, 120, 121

Instrucciones

1. La persona probadora escribe el resultado esperado.
2. El algoritmo recorre las instrucciones sin interpretarlas.
3. La observadora registra condición, camino y precio.
4. Se marcan los casos que fallan.
5. El grupo propone una causa.
6. Se realiza un solo cambio.
7. Se repiten todas las tarjetas.

Aprendizaje esperado

El algoritmo no puede “entender la intención”. Ejecuta las reglas expresadas. Las pruebas conectan la intención con el comportamiento real.

PARTE 8 — EJERCICIOS

Los ejercicios son práctica guiada. No se envían uno por uno. Intente resolverlos antes de abrir sus soluciones.

PARTE 9 — RETOS

PARTE 10 — MINI PROYECTO

PARTE 12 — EVALUACIÓN

PARTE 13 — RECURSOS

Duración: 4 minutos y 32 segundos Tema exacto: Uso de la función de prueba de escritorio de PSeInt Uso recomendado: Después de dominar el rastreo manual

La herramienta no sustituye la capacidad de predecir y explicar el resultado.

Lectura esencial sobre algoritmos

📖Algoritmos y pseudocódigo — INTEF

Utilidad:

• repasar que un algoritmo debe ser correcto, finito, claro y portable;
• recordar la importancia de pensar antes de programar;
• revisar representaciones independientes del lenguaje.

Referencia de pseudocódigo

📖Documentación oficial de PSeInt

Utilidad:

• consultar estructuras de control;
• comparar su pseudocódigo con una notación formal;
• ejecutar opcionalmente los casos del módulo.

Ampliación opcional sobre errores

📖¿Qué ha salido mal? Corrigiendo JavaScript — MDN Web Docs

La lectura utiliza JavaScript. No aprenda su sintaxis en este curso. Concéntrese en:

• diferencia entre un error que impide ejecutar y un error lógico;
• uso de evidencia;
• investigación ordenada;
• importancia de explicar el problema.

PARTE 14 — GLOSARIO

PARTE 15 — CIERRE

COMPRENDER
   ↓
ESCRIBIR REQUISITOS MEDIBLES
   ↓
CALCULAR RESULTADOS ESPERADOS
   ↓
CONSTRUIR EL ALGORITMO
   ↓
PROBAR:
NORMAL + LÍMITE + INVÁLIDO + SIN DATOS
   ↓
RASTREAR CADA CAMBIO
   ↓
LOCALIZAR LA PRIMERA DIFERENCIA
   ↓
CORREGIR LA CAUSA
   ↓
REPETIR TODAS LAS PRUEBAS
   ↓
DOCUMENTAR LA EVIDENCIA

Ocho ideas fundamentales

1. No se puede probar correctamente un requisito ambiguo.
2. El resultado esperado se define antes de ejecutar.
3. Un caso exitoso no demuestra que todos los caminos funcionen.
4. Los límites revelan muchos errores.
5. La prueba de escritorio muestra cómo cambia el estado.
6. La primera diferencia orienta hacia la causa.
7. Se corrige la causa, no se oculta el síntoma.
8. Toda corrección debe volver a probarse.

Al completar el módulo, habrá desarrollado:

• análisis de requisitos;
• detección de ambigüedades;
• diseño de resultados verificables;
• selección estratégica de casos;
• pruebas normales, límite, inválidas y sin datos;
• rastreo de secuencias, decisiones y ciclos;
• diagnóstico basado en la primera diferencia;
• distinción entre síntoma y causa;
• corrección controlada;
• comprobación de regresión;
• documentación de evidencia;
• revisión integral de algoritmos.

Ahora usted sabe:

• comprender un problema;
• organizar entradas, procesos y salidas;
• utilizar variables;
• tomar decisiones;
• construir repeticiones;
• diseñar pruebas;
• encontrar y corregir errores.

El Módulo 6 será el proyecto final. No introducirá una gran cantidad de teoría nueva. Su objetivo será integrar todo el curso en una solución completa, explicada, representada, probada y corregida.

FIN DEL MÓDULO 5

No avanzar al Módulo 6 hasta que el Módulo 5 sea revisado y aprobado.