El testing manual es probar el software a mano, sin herramientas de automatización, pero con método. No es hacer clic al azar: se apoya en técnicas para encontrar los errores que importan. Las más útiles al empezar son las clases de equivalencia (agrupar entradas que el sistema trata igual y probar una de cada grupo), los valores límite (probar los bordes, donde más fallan las cosas) y el testing exploratorio (investigar el sistema con un objetivo, aprendiendo y probando a la vez). Cuando aparece un error, el trabajo no termina: hay que reproducirlo, aislar los pasos mínimos y escribir un reporte de defecto claro —qué hiciste, qué esperabas y qué pasó— para que alguien pueda arreglarlo. El testing manual no compite con el automático: cada uno encuentra cosas distintas, y el exploratorio manual halla lo que ninguna automatización busca.
Ver índice de contenidos
Qué es el testing manual y qué no
El testing manual es evaluar un software operándolo a mano —como lo haría una persona usuaria— para comprobar si se comporta como debe y encontrar dónde no lo hace. La palabra «manual» lo distingue del testing automatizado, donde un programa ejecuta las pruebas; pero el método es igual de riguroso.
Esta guía es la parte práctica: cómo se prueba a mano. El panorama general del testing —qué es, qué tipos y niveles hay, cómo es la profesión de QA— está en testing de software: empezar en QA. Y el diseño formal de casos a partir de una especificación está en diseñar casos de prueba a partir de requisitos. Acá el foco es la ejecución y el hallazgo.
Conviene fijar tres términos que se confunden y que el glosario del ISTQB separa: un error es la equivocación de una persona; un defecto es la falla que ese error dejó en el código; y un fallo es lo que ves cuando el defecto se manifiesta al ejecutar. El testing manual busca fallos para descubrir defectos.
La mentalidad de tester
Antes que cualquier técnica está una forma de pensar, y es lo que más diferencia a un buen tester. Quien programa quiere que el software funcione; quien prueba quiere descubrir dónde no funciona. No es pesimismo: es que un defecto que encontrás vos hoy es un problema que no llega a quien usa el sistema mañana.
Las preguntas que hace un tester
Frente a cualquier funcionalidad: ¿Qué pasa si dejo esto vacío? ¿Y si pongo un valor enorme, o negativo, o con símbolos raros? ¿Y si hago los pasos en otro orden? ¿Y si pierdo la conexión a la mitad? ¿Y si aprieto dos veces rápido? Los defectos casi nunca están en el camino feliz que el desarrollador ya probó: están en los bordes, en lo inesperado y en lo que nadie pensó.
Esa curiosidad sistemática es entrenable. No se trata de romper por romper, sino de imaginar cómo se usará el sistema en el mundo real —con datos sucios, personas apuradas y situaciones que el diseño no contempló— y comprobar qué pasa entonces.
Técnicas para encontrar errores
Como probar todas las entradas posibles es imposible, hay técnicas para elegir las que más rinden. Las tres imprescindibles:
- Clases de equivalencia. Agrupá las entradas que el sistema debería tratar igual y probá una de cada grupo. Si un campo acepta edades de 18 a 65, hay un grupo válido (18–65), uno inválido por debajo, uno por encima, y uno de entradas no numéricas. Probar un representante de cada grupo cubre mucho con pocas pruebas.
- Valores límite. Los errores se concentran en los bordes. En el rango 18–65, probá 17, 18, 19 y 64, 65, 66: ahí es donde se confunde un «menor que» con un «menor o igual».
- Tablas de decisión. Cuando el resultado depende de varias condiciones combinadas (por ejemplo, un descuento que aplica según tipo de cliente y monto y día), armá una tabla con todas las combinaciones y su resultado esperado, para no olvidar ninguna.
Estas técnicas se estudian en detalle, aplicadas al diseño de casos, en estrategias para escribir casos de prueba. Acá alcanza con saber que existen y que guían dónde mirar.
El testing exploratorio
El testing exploratorio es donde el testing manual brilla y ninguna automatización llega. Consiste en investigar el sistema aprendiendo y probando a la vez: no seguís un guion escrito de antemano, sino que cada resultado te sugiere la siguiente prueba. Pero no es improvisación: se hace con un objetivo y en sesiones acotadas.
- Definir una misiónAntes de empezar: «voy a explorar el proceso de pago buscando problemas con montos y cantidades». Un foco, no «probar todo».
- Explorar en una sesión con tiempoUn bloque acotado —45 o 60 minutos— dedicado a esa misión, tomando notas de lo que encontrás y de lo que se te ocurre probar después.
- Seguir las pistasCada comportamiento raro abre una puerta: si un monto negativo hace algo extraño, explorá alrededor de eso.
- Registrar hallazgos y preguntasNo solo los defectos: también las dudas y las zonas que quedaron sin cubrir, para la próxima sesión.
El exploratorio encuentra lo que los casos escritos no anticipan, porque el propio proceso de explorar genera hipótesis nuevas. Es complementario a las pruebas guionadas: unas verifican lo esperado, el otro descubre lo inesperado.
Reportar un defecto
Encontrar un defecto es la mitad del trabajo; la otra mitad es reportarlo de forma que se pueda arreglar. Un reporte malo —«no anda el pago»— hace perder horas; uno bueno permite reproducir y corregir en minutos. Lo que no puede faltar:
| Elemento | Qué incluir |
|---|---|
| Título claro | Qué falla y dónde, en una línea. «El total no incluye el envío al pagar con cupón» |
| Pasos para reproducir | La secuencia mínima y numerada para provocar el fallo |
| Resultado esperado | Qué debería pasar |
| Resultado obtenido | Qué pasó en realidad |
| Entorno y evidencia | Navegador, versión, datos usados, captura o video |
Antes de reportar, reproducí el defecto y quitá todo paso que no sea necesario para que ocurra. Un reporte con quince pasos donde solo tres importan hace que quien lo lea pierda tiempo descartando ruido. «Pasos mínimos para reproducir» significa exactamente eso: la secuencia más corta que dispara el fallo, sin nada de más.
Testing manual y automático no compiten
Una confusión común es creer que el testing automático «reemplaza» al manual. Encuentran cosas distintas:
- El automático es imbatible para repetir lo mismo muchas veces sin cansarse: pruebas de regresión, verificar que lo que funcionaba sigue funcionando tras cada cambio. Ejecuta rápido y sin errores humanos, pero solo comprueba lo que alguien le programó que comprobara.
- El manual, y sobre todo el exploratorio, encuentra lo que a nadie se le ocurrió automatizar: problemas de experiencia, comportamientos raros, cosas que «se ven mal». Aporta criterio y curiosidad, que ningún script tiene.
La estrategia sensata combina los dos: automatizar lo repetitivo y estable, y reservar el tiempo de las personas para explorar. Cuándo conviene automatizar y cuándo no es el tema de estrategias de prueba, y las herramientas concretas están en Selenium, Cypress o Playwright.
Errores frecuentes
- Probar solo el camino feliz. Los defectos viven en los bordes y en lo inesperado, no donde todo sale bien.
- Confundir exploratorio con improvisar. El exploratorio tiene misión, tiempo acotado y notas; sin eso es solo hacer clic.
- Reportar sin pasos mínimos. Un defecto que no se puede reproducir no se puede arreglar.
- No anotar mientras se prueba. Lo que no registrás en el momento se pierde, incluidas las dudas y zonas sin cubrir.
- Ignorar los valores límite. Es donde más fallan las cosas y lo primero que hay que probar.
- Creer que la automatización vuelve inútil el manual. Encuentran cosas distintas; se complementan.
- Reportar juicios en vez de hechos. «Está mal hecho» no ayuda; «esperaba X y pasó Y» sí.
Preguntas frecuentes
¿El testing manual sigue teniendo sentido si existe la automatización?
Sí, porque encuentran cosas distintas y se complementan. La automatización es insuperable para repetir las mismas comprobaciones muchas veces sin cansarse ni equivocarse, lo que la hace ideal para pruebas de regresión que verifican que lo que funcionaba sigue funcionando tras cada cambio. Pero solo comprueba lo que alguien le programó de antemano. El testing manual, y en especial el exploratorio, encuentra lo que nadie pensó en automatizar: problemas de experiencia de uso, comportamientos extraños, cosas que simplemente se ven o se sienten mal. Aporta criterio, curiosidad y juicio, que ningún script tiene. Por eso la estrategia sensata no elige uno sobre el otro, sino que automatiza lo repetitivo y estable y reserva el tiempo de las personas para explorar.
¿Qué diferencia hay entre error, defecto y fallo?
Son tres cosas distintas que el glosario del ISTQB separa con precisión. Un error es la equivocación que comete una persona, por ejemplo un programador que entiende mal un requisito o se confunde al escribir una condición. Ese error deja un defecto en el producto: la parte del código que está mal. Y el fallo es lo que se observa cuando ese defecto se manifiesta al ejecutar el software, es decir, el comportamiento incorrecto que ve quien prueba o usa el sistema. La cadena es error, defecto, fallo. El testing manual busca fallos —comportamientos incorrectos— para descubrir los defectos que los causan, de modo que puedan corregirse antes de que lleguen a quien usa el sistema.
¿Qué es el testing exploratorio?
Es una forma de probar en la que se investiga el sistema aprendiendo y probando al mismo tiempo, sin seguir un guion escrito de antemano: cada resultado sugiere la siguiente prueba. La clave es que no es improvisación desordenada, sino que se hace con un objetivo concreto y en sesiones acotadas en el tiempo. Se define una misión —por ejemplo, explorar el proceso de pago buscando problemas con montos—, se dedica un bloque de tiempo a esa misión tomando notas de lo que se encuentra y de lo que se ocurre probar después, y se siguen las pistas que abren los comportamientos raros. Su valor es que encuentra defectos que los casos escritos no anticipan, porque el propio acto de explorar genera hipótesis nuevas sobre dónde puede estar fallando el sistema.
¿Cómo se escribe un buen reporte de defecto?
Con la información justa para que otra persona pueda reproducir y arreglar el problema sin adivinar. No puede faltar un título claro que diga en una línea qué falla y dónde, los pasos mínimos y numerados para provocar el fallo, el resultado esperado, el resultado que realmente se obtuvo, y el entorno con evidencia: navegador, versión, datos usados y una captura o video. Lo que más se descuida son los pasos mínimos: antes de reportar conviene reproducir el defecto y quitar todo paso que no sea imprescindible, porque un reporte con muchos pasos irrelevantes hace perder tiempo. Y conviene reportar hechos, no juicios: «esperaba esto y pasó esto otro» ayuda mucho más que «está mal hecho».
¿Por dónde empiezo a probar una funcionalidad nueva?
Por las técnicas que más rinden con menos esfuerzo, porque probarlo todo es imposible. Primero identificá las clases de equivalencia: agrupá las entradas que el sistema debería tratar igual y probá un representante de cada grupo, incluyendo los grupos inválidos. Después atacá los valores límite, que es donde más se concentran los errores: los bordes de cada rango y los valores justo alrededor. Con eso cubrís lo sistemático. Luego dedicá una sesión de testing exploratorio con una misión concreta para descubrir lo que las técnicas no anticipan. Y en todo momento mantené la mentalidad de tester, preguntándote qué pasa con lo vacío, lo enorme, lo negativo, lo fuera de orden y lo inesperado, que es donde viven los defectos.
¿Necesito saber programar para hacer testing manual?
No para el testing manual en sí: probar a mano, aplicar técnicas, explorar y reportar defectos no requiere escribir código, y muchas personas construyen una carrera sólida en QA por esta vía. Lo que sí hace falta es método, atención al detalle, capacidad de comunicar con claridad y una mentalidad curiosa y sistemática. Dicho esto, con el tiempo aprender algo de programación amplía mucho lo que podés hacer, porque abre la puerta a la automatización de pruebas, a entender mejor dónde pueden estar los defectos y a colaborar más de cerca con quien desarrolla. Una ruta habitual es empezar por el testing manual, dominar las técnicas y el criterio, y sumar programación gradualmente cuando ya se entiende bien qué se está probando y por qué.
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
- Underc0de, foro. Sección QA (Quality Assurance). Consultas de la comunidad sobre pruebas manuales, exploratorio y reporte de defectos.
- Underc0de, foro. Sección Informática. Aportes sobre calidad de software y metodología.
Documentación oficial
- ISTQB. Foundation Level Syllabus. El temario de referencia del testing, con las técnicas y los conceptos citados.
- ISTQB. Glosario. Las definiciones estándar de defecto, error, fallo y técnica de prueba.
- Ministry of Testing. Ministry of Testing. Comunidad de referencia sobre testing exploratorio y práctica profesional.
- Cem Kaner y otros. Context-Driven Testing. Principios sobre pruebas guiadas por el contexto.