11. Pruebas manuales y pruebas automatizadas

11.1 Introducción

Las pruebas de software pueden ejecutarse de forma manual o automatizada. En una prueba manual, una persona interactúa con el sistema, observa el comportamiento y compara el resultado obtenido con el resultado esperado. En una prueba automatizada, un programa ejecuta verificaciones de manera repetible.

Ambos enfoques son importantes. Las pruebas manuales aportan criterio humano, exploración y observación. Las automatizadas aportan velocidad, repetición y consistencia. El objetivo no es enfrentar una contra otra, sino entender cuándo conviene usar cada una.

En este tema veremos diferencias, ventajas, límites, ejemplos y criterios básicos para decidir qué pruebas ejecutar manualmente y cuáles automatizar.

11.2 ¿Qué es una prueba manual?

Una prueba manual es una prueba ejecutada por una persona. El tester sigue pasos definidos o explora el sistema con un objetivo, observa lo que ocurre y decide si el comportamiento es correcto.

Ejemplos de pruebas manuales:

  • Completar un formulario de registro y revisar los mensajes mostrados.
  • Explorar una nueva pantalla para buscar comportamientos inesperados.
  • Validar visualmente si una página se ve correctamente en un celular.
  • Revisar si un mensaje de error es claro para el usuario.
  • Comprobar un flujo nuevo que todavía cambia con frecuencia.
  • Ejecutar una prueba de aceptación junto con un usuario del negocio.

La prueba manual no significa prueba improvisada. Puede estar planificada, documentada y basada en criterios claros.

11.3 Ventajas de las pruebas manuales

Las pruebas manuales tienen ventajas importantes:

  • Flexibilidad: una persona puede adaptar la prueba si encuentra algo inesperado.
  • Observación humana: permite detectar problemas visuales, textos confusos o flujos poco naturales.
  • Exploración: sirve para investigar funcionalidades nuevas o poco conocidas.
  • Bajo costo inicial: no requiere crear scripts ni infraestructura de automatización.
  • Útil en cambios frecuentes: permite validar rápidamente cuando la funcionalidad todavía no está estable.
  • Buena para usabilidad: ayuda a evaluar experiencia, claridad y comprensión.

El criterio humano es especialmente valioso cuando no sabemos exactamente qué defectos buscar o cuando el producto todavía está evolucionando.

11.4 Límites de las pruebas manuales

Las pruebas manuales también tienen límites:

  • Pueden ser lentas si deben repetirse muchas veces.
  • Son propensas a errores humanos durante la ejecución.
  • Resultan costosas para regresiones frecuentes.
  • La misma prueba puede ejecutarse con pequeñas variaciones involuntarias.
  • No son ideales para validar muchas combinaciones de datos repetidamente.
  • Dependen de disponibilidad, concentración y contexto de quien prueba.

Por ejemplo, si cada nueva versión requiere revisar manualmente 200 casos de regresión, el equipo probablemente tardará demasiado y aumentará la posibilidad de omitir pasos.

11.5 ¿Qué es una prueba automatizada?

Una prueba automatizada es una prueba ejecutada por código o por una herramienta. La automatización realiza acciones, compara resultados y reporta si la prueba pasó o falló.

Ejemplos de pruebas automatizadas:

  • Una prueba unitaria que valida el cálculo de impuestos.
  • Una prueba de API que confirma que un endpoint devuelve estado 200 y datos correctos.
  • Una prueba de interfaz que inicia sesión y verifica que se muestre la pantalla principal.
  • Una prueba que se ejecuta automáticamente cada vez que se sube código al repositorio.
  • Una prueba de regresión que revisa un flujo crítico después de cada cambio.

Automatizar no significa que la herramienta piense por nosotros. Una persona debe decidir qué automatizar, diseñar la prueba, mantenerla y analizar sus resultados.

11.6 Ventajas de las pruebas automatizadas

Las pruebas automatizadas aportan valor cuando se usan correctamente:

  • Velocidad: pueden ejecutarse mucho más rápido que una persona.
  • Repetibilidad: ejecutan los mismos pasos de la misma manera.
  • Frecuencia: pueden correr en cada cambio, cada día o cada despliegue.
  • Regresión: ayudan a detectar si algo que funcionaba dejó de funcionar.
  • Consistencia: reducen variaciones involuntarias de ejecución.
  • Evidencia rápida: informan fallas temprano en el ciclo de desarrollo.

Su mayor fortaleza aparece en verificaciones repetibles, estables y con resultado esperado claro.

11.7 Límites de las pruebas automatizadas

La automatización no resuelve todos los problemas de calidad. Tiene límites importantes:

  • Requiere tiempo de creación y mantenimiento.
  • Puede fallar por cambios en la interfaz o en los datos.
  • No detecta problemas para los que no fue diseñada.
  • Puede dar falsa confianza si verifica cosas poco importantes.
  • No reemplaza la exploración humana ni la validación de usabilidad.
  • Puede ser costosa si se automatizan pruebas inestables o de bajo valor.
Automatizar una prueba mala solo permite ejecutar rápidamente una mala prueba.

Antes de automatizar, hay que entender qué riesgo se quiere cubrir y si la prueba será útil en el tiempo.

11.8 Comparación entre manual y automatizado

Aspecto Prueba manual Prueba automatizada
Ejecutor Una persona. Un script, herramienta o sistema automático.
Mejor uso Exploración, usabilidad, validación inicial, cambios frecuentes. Regresión, verificaciones repetibles, cálculos, APIs, flujos estables.
Costo inicial Menor. Mayor, porque hay que implementar y configurar.
Costo de repetición Alto si se repite muchas veces. Bajo una vez creada y mantenida.
Criterio humano Alto durante la ejecución. Necesario en diseño y análisis, no durante cada ejecución.
Mantenimiento Actualizar documentación y casos. Actualizar scripts, datos, selectores, ambientes y expectativas.

11.9 ¿Cuándo conviene probar manualmente?

Conviene usar pruebas manuales cuando:

  • La funcionalidad es nueva y todavía cambia mucho.
  • Se necesita explorar comportamientos no previstos.
  • Se evalúa usabilidad, claridad visual o experiencia de usuario.
  • El caso se ejecutará pocas veces.
  • El costo de automatizar supera el beneficio esperado.
  • Se necesita feedback de usuarios o representantes del negocio.
  • Hay dudas sobre el comportamiento esperado y se requiere análisis.

La prueba manual es útil cuando la observación, la adaptación y el juicio humano son parte central de la evaluación.

11.10 ¿Cuándo conviene automatizar?

Conviene automatizar cuando una prueba tiene estas características:

  • Se ejecutará muchas veces.
  • El comportamiento esperado es claro y estable.
  • La prueba cubre un flujo crítico para el negocio.
  • El resultado puede verificarse automáticamente.
  • La ejecución manual consume mucho tiempo.
  • Debe ejecutarse con frecuencia en integración continua.
  • Sirve para detectar regresiones importantes.

Ejemplo: si en cada versión debemos comprobar que un usuario puede iniciar sesión, agregar un producto al carrito y confirmar una compra, probablemente convenga automatizar ese flujo si es estable y crítico.

11.11 Qué no conviene automatizar al principio

No toda prueba es buena candidata para automatización. Al comenzar, conviene evitar automatizar:

  • Funcionalidades que cambian todos los días.
  • Pruebas con resultado esperado ambiguo.
  • Casos que requieren juicio visual complejo.
  • Validaciones de usabilidad que necesitan observar personas.
  • Pruebas que se ejecutarán una sola vez.
  • Flujos inestables por problemas de ambiente o datos.
  • Casos de bajo impacto que consumen mucho mantenimiento.

Automatizar demasiado pronto puede generar una suite frágil y costosa, especialmente si el producto aún no estabilizó su comportamiento.

11.12 Automatización y regresión

Una de las aplicaciones más importantes de la automatización es la prueba de regresión. Una regresión ocurre cuando algo que antes funcionaba deja de funcionar después de un cambio.

Las pruebas automatizadas ayudan porque pueden repetirse con frecuencia. Por ejemplo:

  • Después de cada cambio de código.
  • Antes de integrar una rama de desarrollo.
  • Antes de publicar una versión.
  • Durante la noche, como ejecución programada.

Esto permite detectar problemas antes de que avancen a etapas posteriores. Sin automatización, repetir siempre los mismos flujos críticos puede volverse lento y propenso a omisiones.

11.13 Tipos de pruebas que suelen automatizarse

Algunos tipos de prueba suelen ser buenos candidatos para automatización:

  • Pruebas unitarias: validan lógica pequeña y se ejecutan rápidamente.
  • Pruebas de API: verifican respuestas, códigos de estado, datos y reglas.
  • Pruebas de integración: comprueban comunicación entre componentes.
  • Pruebas de regresión: repiten verificaciones importantes en cada versión.
  • Pruebas de humo: confirman que las funciones básicas están disponibles.
  • Flujos críticos de interfaz: validan recorridos estables y de alto impacto.

La automatización puede aplicarse en varios niveles, no solo en la interfaz gráfica. De hecho, muchas veces es más estable automatizar pruebas unitarias o de API que depender únicamente de pruebas visuales completas.

11.14 El falso objetivo de automatizar todo

Un objetivo frecuente, pero poco realista, es querer automatizar el 100% de las pruebas. En la práctica, automatizar todo no siempre es útil ni rentable.

Hay pruebas donde la automatización aporta mucho, y otras donde el criterio humano es más importante. Además, toda prueba automatizada necesita mantenimiento. Si el equipo automatiza casos de bajo valor, puede terminar dedicando demasiado tiempo a corregir pruebas que casi no reducen riesgos.

El objetivo no es automatizar todo. El objetivo es automatizar lo que aporta valor repetido y reduce riesgos relevantes.

11.15 Ejemplo completo: inicio de sesión

Tomemos la funcionalidad de inicio de sesión. Algunas pruebas podrían organizarse así:

Prueba Manual o automatizada Motivo
Ingresar con usuario y contraseña correctos. Automatizada Es un flujo crítico, estable y repetible.
Rechazar contraseña incorrecta. Automatizada Resultado esperado claro y útil para regresión.
Evaluar si el mensaje de error es comprensible. Manual Requiere criterio humano y mirada de usuario.
Explorar combinaciones raras de navegación y recarga de página. Manual inicialmente Puede descubrir casos no previstos antes de decidir automatizar.
Comprobar que el botón se vea alineado en varios tamaños de pantalla. Manual o automatizada visual según contexto Depende del riesgo, herramientas y estabilidad visual.

Este ejemplo muestra que una misma funcionalidad puede requerir una combinación de enfoques.

11.16 Mantenimiento de pruebas automatizadas

Las pruebas automatizadas son código o configuración. Por lo tanto, también deben mantenerse. Si el sistema cambia y las pruebas no se actualizan, pueden fallar aunque el producto esté bien, o pasar aunque ya no verifiquen lo correcto.

El mantenimiento puede incluir:

  • Actualizar datos de prueba.
  • Modificar resultados esperados.
  • Ajustar selectores de interfaz.
  • Adaptar pruebas a nuevas reglas de negocio.
  • Eliminar pruebas duplicadas u obsoletas.
  • Mejorar pruebas inestables.
  • Revisar reportes de fallas frecuentes.

Una suite automatizada sin mantenimiento pierde confianza. El equipo debe tratarla como parte del producto.

11.17 Errores comunes

Al trabajar con pruebas manuales y automatizadas, algunos errores frecuentes son:

  • Creer que automatizar reemplaza completamente al tester.
  • Automatizar sin entender el objetivo de la prueba.
  • Automatizar funcionalidades inestables demasiado pronto.
  • Medir éxito solo por cantidad de pruebas automatizadas.
  • No revisar los resultados de las ejecuciones automáticas.
  • Ignorar el mantenimiento de la suite.
  • Ejecutar todo manualmente aunque haya regresiones repetitivas.
  • No combinar exploración humana con verificaciones repetibles.

Estos errores generan pérdida de tiempo, falsa confianza o suites difíciles de mantener.

11.18 Buenas prácticas

Para combinar bien pruebas manuales y automatizadas conviene:

  • Usar pruebas manuales para explorar, aprender y validar experiencia.
  • Automatizar pruebas repetibles, estables y de alto valor.
  • Definir claramente el resultado esperado antes de automatizar.
  • Priorizar flujos críticos y riesgos importantes.
  • Ejecutar pruebas automatizadas con frecuencia.
  • Mantener la suite limpia, confiable y actualizada.
  • Investigar las fallas automáticas en lugar de ignorarlas.
  • Revisar periódicamente si cada prueba sigue aportando valor.

La mejor estrategia suele ser híbrida: criterio humano donde aporta más valor y automatización donde la repetición reduce riesgo y esfuerzo.

11.19 Qué debes recordar de este tema

  • Las pruebas manuales son ejecutadas por personas y aportan observación, criterio y flexibilidad.
  • Las pruebas automatizadas son ejecutadas por herramientas o código y aportan velocidad, repetición y consistencia.
  • Automatizar no reemplaza el análisis humano.
  • No conviene automatizar todo; conviene automatizar lo que aporta valor repetido.
  • Las pruebas automatizadas son muy útiles para regresión.
  • Las pruebas manuales son muy útiles para exploración, usabilidad y validación inicial.
  • Una prueba automatizada necesita mantenimiento.
  • Manual y automatizado se complementan dentro de una estrategia de calidad.

11.20 Conclusión

Las pruebas manuales y automatizadas no compiten entre sí. Resuelven problemas distintos. Las manuales permiten observar, explorar y pensar con flexibilidad. Las automatizadas permiten repetir verificaciones importantes con rapidez y consistencia.

Un equipo maduro aprende a combinar ambos enfoques. Automatiza lo estable, repetible y crítico; mantiene espacio para la exploración humana; y revisa continuamente si sus pruebas siguen aportando valor.

En el próximo tema estudiaremos pruebas de caja negra, caja blanca y caja gris, tres enfoques que diferencian cuánto conocimiento interno del sistema usamos al diseñar las pruebas.