17.1 Introducción
En el tema 15 generamos una lista de tareas y en el tema 16 revisamos su código sin modificarlo. Identificamos comportamientos implementados, límites del alcance y posibles defectos. Ahora ejecutaremos casos concretos para confirmar qué sucede realmente.
Una prueba manual no consiste en hacer clic al azar hasta sentir que la aplicación funciona. Cada caso parte de una condición, realiza acciones y compara el resultado con una expectativa definida previamente.
La exploración libre también aporta valor, pero conviene distinguirla de los casos repetibles. Si encontramos un problema, otra persona debe poder reproducirlo siguiendo nuestro registro.
17.2 Revisión estática y prueba dinámica
Ambas actividades buscan calidad, pero utilizan evidencias diferentes.
| Actividad | Observa | Ejemplo |
|---|---|---|
| Revisión estática | Archivos, estructura, lógica y relaciones. | Detectar que el contador usa siempre la palabra “tareas”. |
| Prueba dinámica | Comportamiento durante la ejecución. | Agregar una tarea y observar “1 tareas pendientes”. |
| Exploración | Situaciones no previstas en el plan. | Probar textos extensos o combinaciones rápidas. |
La lectura sugirió hipótesis. La ejecución confirmará cuáles afectan realmente al uso y aportará datos para describirlas.
17.3 Preparar el entorno de prueba
Utilizaremos la versión inicial de los tres archivos, sin aplicar todavía mejoras. Abrimos index.html en un navegador y conservamos acceso a las herramientas de desarrollo.
Antes de comenzar registramos:
- Versión o fecha de los archivos.
- Navegador y versión aproximada.
- Sistema operativo.
- Tamaño de ventana inicial.
- Forma de apertura: archivo local o servidor.
- Estado inicial esperado: ninguna tarea almacenada.
Recargamos la página antes de cada grupo cuando necesitemos volver al estado vacío. Como esta versión guarda datos solo en memoria, la recarga restablece la aplicación.
17.4 Estructura de un caso de prueba
Un caso manual puede registrarse con pocos campos, siempre que permita repetirlo.
| Campo | Contenido |
|---|---|
| Identificador | Nombre breve y único, por ejemplo CT-01. |
| Objetivo | Comportamiento que intentamos comprobar. |
| Precondición | Estado necesario antes de actuar. |
| Pasos | Acciones y datos exactos. |
| Resultado esperado | Respuesta definida por el requisito. |
| Resultado observado | Lo que ocurrió durante la ejecución. |
| Estado | Aprobado, fallido o bloqueado. |
“Funciona bien” no es un resultado observado preciso. “La tarea aparece al final, el campo queda vacío y el contador cambia a 1” sí puede compararse.
17.5 Comprobar el estado inicial
El primer caso confirma que la aplicación se presenta correctamente antes de recibir datos.
Precondición: página recién abierta.
Pasos: observar título, campo, botón, contador y lista.
Esperado: lista vacía, campo disponible y texto “0 tareas pendientes”.
Además observamos que no aparezcan mensajes extraños, elementos fuera de lugar ni errores en la consola. El resultado esperado se cumple en la versión propuesta.
Una lista vacía sin explicación puede considerarse una mejora de experiencia, pero no contradice el criterio inicial. Debemos registrarla separadamente y no marcar el caso como fallido.
17.6 Agregar mediante el botón
Probamos el camino más visible:
Precondición: lista vacía.
Pasos: escribir “Estudiar JavaScript” y presionar Agregar.
Esperado: aparece una tarea sin completar, el campo se limpia, recupera el foco y el contador indica una pendiente.
La tarea aparece y el foco vuelve al campo. El contador cambia, pero muestra “1 tareas pendientes”. La cantidad es correcta; la concordancia es incorrecta.
Registramos el hallazgo sin corregirlo:
- Título: contador con plural para una sola tarea.
- Pasos: abrir la página y agregar una tarea.
- Esperado: “1 tarea pendiente”.
- Observado: “1 tareas pendientes”.
17.7 Agregar mediante Enter
Botón y Enter deben activar el mismo envío de formulario.
Precondición: foco en el campo.
Pasos: escribir “Leer documentación” y presionar Enter.
Esperado: se agrega una única tarea y la página no se recarga.
Comprobamos que la tarea aparece una sola vez. La dirección del navegador y la lista anterior permanecen, por lo que preventDefault() evitó el envío tradicional.
También podemos mantener presionada la tecla brevemente para observar si se generan envíos repetidos. Si aparece un problema, debemos registrar la duración y el resultado sin generalizar a partir de una prueba imprecisa.
17.8 Entradas vacías y espacios
La revisión encontró un retorno anticipado para texto vacío. Diseñamos varios casos:
| Caso | Entrada | Resultado observado |
|---|---|---|
| CT-04 | Campo completamente vacío. | No agrega y mantiene el foco. |
| CT-05 | Varios espacios. | No agrega y mantiene el foco. |
| CT-06 | “ Comprar pan ”. | Agrega “Comprar pan” sin espacios exteriores. |
La validación funcional se cumple. Sin embargo, CT-04 y CT-05 confirman que no existe un mensaje visible o anunciado. Lo registramos como problema de experiencia y accesibilidad, no como aceptación de datos inválidos.
17.9 Completar y volver a dejar pendiente
Agregamos dos tareas para observar el cambio de estado y el contador.
- Agregar “Estudiar” y “Practicar”.
- Marcar la primera casilla.
- Comprobar el tachado y el nuevo contador.
- Desmarcar la misma casilla.
- Comprobar que recupera el aspecto pendiente.
La clase visual se aplica y elimina de acuerdo con la casilla. El contador pasa de dos a uno y luego vuelve a dos. El problema de singular aparece nuevamente cuando queda una sola pendiente.
También verificamos que completar una tarea no cambie el orden ni el texto de la otra. Esto comprueba que el evento modifica el objeto correcto.
17.10 Eliminar tareas, incluso si se repiten
La revisión indicó que la eliminación utiliza el identificador. Lo comprobamos con textos duplicados:
Precondición: dos tareas llamadas “Comprar pan”.
Pasos: presionar Eliminar en la primera.
Esperado: desaparece solo la primera y permanece una tarea con el mismo texto.
La versión inicial conserva una de las dos tareas. Luego eliminamos la restante y verificamos que el contador vuelve a cero.
El sistema permite duplicados. Eso no es un defecto confirmado porque la solicitud no los prohibía. El caso aporta información para decidir si la mejora debería advertir, impedir o aceptar esa situación.
17.11 Probar el contador sistemáticamente
El contador depende de varias acciones. Una tabla de transiciones evita comprobar solamente el valor inicial y final.
| Acción | Pendientes esperadas | Texto esperado |
|---|---|---|
| Abrir la página | 0 | 0 tareas pendientes |
| Agregar una | 1 | 1 tarea pendiente |
| Agregar otra | 2 | 2 tareas pendientes |
| Completar una | 1 | 1 tarea pendiente |
| Completar ambas | 0 | 0 tareas pendientes |
| Desmarcar una | 1 | 1 tarea pendiente |
Los números coinciden en todas las transiciones. Fallan las dos formas singulares. Un defecto puede afectar una parte de la salida sin invalidar todo el cálculo.
17.12 Navegación por teclado y foco
Sin utilizar el mouse, recargamos la página y presionamos Tab para recorrer los controles.
Comprobamos:
- Que el campo, el botón, las casillas y los botones Eliminar reciban foco.
- Que el indicador de foco sea visible.
- Que Enter envíe el formulario desde el campo.
- Que la barra espaciadora cambie la casilla.
- Que Enter o espacio activen el botón Eliminar.
- Que el foco no quede perdido después de agregar.
La versión inicial permite operar el flujo mediante teclado. Después de eliminar una tarea, el foco desaparece junto con el botón eliminado y el navegador decide el siguiente punto. Conviene registrar dónde queda y evaluar si la experiencia necesita una gestión explícita.
17.13 Pantallas pequeñas y contenido extremo
Reducimos gradualmente el ancho del navegador o utilizamos el modo adaptable de sus herramientas. Observamos la aplicación alrededor y por debajo de 520 píxeles, donde se activa la regla responsive.
Probamos además:
- Una tarea de una sola letra.
- Una frase de varias líneas.
- Una cadena extensa sin espacios.
- Caracteres acentuados y símbolos.
- Ampliación del navegador al 200 %.
- Varias tareas que obligan a desplazar la página.
overflow-wrap: anywhere evita que una cadena larga desborde horizontalmente. En una pantalla estrecha, la fila de cada tarea conserva casilla, texto y botón en una misma línea flexible; debemos observar si el botón deja espacio suficiente para leer.
Una captura puede acompañar el hallazgo, pero debe incluir ancho, nivel de ampliación y texto utilizado.
17.14 Recarga, consola y comportamiento inesperado
Agregamos varias tareas y recargamos la página. La lista vuelve a estar vacía. Este resultado coincide con la decisión de mantener los datos en memoria, por lo tanto no registramos un defecto.
Luego observamos la consola mientras repetimos el flujo. No deberían aparecer excepciones. También comprobamos que los archivos CSS y JavaScript se carguen correctamente en la sección de red o recursos.
Durante una exploración podemos combinar acciones:
- Marcar y eliminar rápidamente.
- Agregar muchas tareas seguidas.
- Alternar varias casillas.
- Volver atrás o recargar durante la interacción.
Si aparece un error, primero intentamos reducirlo a una secuencia mínima. Un informe reproducible es más útil que una descripción extensa sin condiciones precisas.
17.15 Informe de resultados y regresión
Al finalizar reunimos lo observado:
| Resultado | Clasificación | Próximo paso |
|---|---|---|
| Agregar, completar y eliminar funcionan. | Casos aprobados. | Conservarlos como regresión. |
| El contador calcula cantidades correctas. | Caso aprobado parcialmente. | Repetir después de corregir el texto. |
| “1 tareas pendientes”. | Defecto confirmado. | Corregir singular y plural. |
| Entrada inválida sin explicación. | Problema de experiencia confirmado. | Diseñar mensaje accesible. |
| Duplicados permitidos. | Decisión de producto. | Definir si deben aceptarse. |
| Datos desaparecen al recargar. | Limitación conocida. | Considerar persistencia como mejora. |
Después de cualquier corrección repetiremos el caso que fallaba y también los flujos relacionados. Eso es una prueba de regresión: comprobar que el nuevo cambio no rompió funciones que ya estaban aprobadas.
17.16 Actividad de comprensión
Ejecutá las pruebas sobre la versión que generaste en el tema 15. Como el código puede ser diferente, no supongas que producirá los mismos resultados de este ejemplo.
- Registrá navegador, versión del proyecto y estado inicial.
- Prepará al menos diez casos antes de ejecutarlos.
- Incluí caminos normales, entradas inválidas, límites, teclado y pantalla pequeña.
- Anotá el resultado observado y el estado de cada caso.
- Reproducí cada defecto mediante la menor cantidad de pasos posible.
- Diferenciá defectos, decisiones pendientes y funciones fuera de alcance.
- Elegí cinco casos que deberían repetirse después de las mejoras.
Guardá el informe y no modifiques todavía la aplicación. En el tema siguiente convertiremos los hallazgos confirmados y las mejoras elegidas en nuevas instrucciones para la IA.