Para empezar a aprender testing manual, no necesitas inventar una aplicación enorme ni comprar primero una certificación. Puedes comenzar con una tarea pequeña: interpretar una regla, diseñar comprobaciones y explicar un fallo de forma que otra persona pueda reproducirlo. Ese trabajo es más concreto que limitarte a decir que sabes encontrar errores.
Esta propuesta de aprendizaje se dirige a lectores de España y utiliza recursos oficiales consultados el 28 de octubre de 2026. El ejercicio es ficticio y no se ha ejecutado sobre un producto real. No ofrece vacantes, salarios ni una garantía de acceso a una profesión.
Por qué merece atención la calidad del software
ITI anunció el 21 de octubre la edición de VLCTESTING de los días 27 y 28 de octubre de 2026, con temas como automatización, IA, accesibilidad y trazabilidad. Es una señal verificable de actividad profesional en España, no una medición de búsquedas ni una prueba de que cualquier curso tenga salida laboral.
Para iniciarte, el interés práctico está en una pregunta: ¿cómo explicarías que una función cumple lo acordado? Antes de elegir una herramienta, necesitas saber qué se espera del producto y qué evidencias permitirían revisar tu conclusión.
Utiliza un temario oficial como mapa, no como una promesa
El programa Foundation Level de ISTQB reúne fundamentos, análisis y diseño de pruebas, gestión de defectos y beneficios y riesgos de la automatización. Su página permite descargar materiales y contempla el autoestudio como opción de preparación.
Leer el temario no equivale a obtener la certificación. Tampoco demuestra experiencia laboral. Si más adelante te interesa un examen, comprueba proveedor, idioma, condiciones y coste antes de inscribirte. Para realizar la propuesta de este artículo no necesitas pagar un examen ni contratar una plataforma.
Ejercicio propuesto: un formulario de reserva ficticio
Imagina una aplicación de práctica que reserva plazas para un taller inventado. No es una web pública donde debas introducir reservas reales. Puedes utilizar una maqueta propia o un entorno que autorice expresamente las pruebas. Si solo tienes el documento, diseña los casos y déjalos como pendientes de ejecución.
Escribe estas reglas del ejercicio antes de probar: la cantidad debe ser un número entero entre 1 y 6; el correo es obligatorio; no se debe confirmar una reserva con cantidad inválida; una reserva válida debe mostrar un resumen antes de su confirmación final. Son requisitos inventados para aprender, no el comportamiento de un servicio existente.
Si una regla no aclara algo, conviértelo en pregunta. Por ejemplo: ¿qué ocurre si el usuario deja espacios en la cantidad?, ¿puede editar el resumen?, ¿se conserva el correo al volver atrás? No inventes la respuesta y después declares defectuoso el programa por no coincidir con ella.
Diseña pocos casos que permitan razonar
El temario CTFL v4.0.1 describe técnicas como las particiones de equivalencia y el análisis de valores límite. Para este ejercicio podemos aplicarlas distinguiendo cantidades válidas e inválidas y revisando los bordes del intervalo. La siguiente selección es una propuesta propia.
| Caso | Datos propuestos | Resultado esperado según nuestras reglas |
|---|---|---|
| C01 | Cantidad 1 y correo de prueba válido | Mostrar resumen, sin confirmar aún |
| C02 | Cantidad 6 y correo de prueba válido | Mostrar resumen, sin confirmar aún |
| C03 | Cantidad 0 | Rechazar la cantidad y no confirmar |
| C04 | Cantidad 7 | Rechazar la cantidad y no confirmar |
| C05 | Cantidad 1,5 | Rechazarla porque no es entera |
| C06 | Cantidad 2 y correo vacío | No permitir continuar a la reserva |
Estos casos no constituyen una prueba completa de calidad. No cubren seguridad, rendimiento, todos los navegadores ni accesibilidad. Su valor inicial es que cada uno tiene una razón y un resultado esperado definido antes de observar el comportamiento.
Añade a tu documento una columna de resultado real y otra de estado. Déjalas vacías o marca «No ejecutado» mientras no hayas realizado la comprobación. Una tabla bien presentada no permite afirmar que todos los casos han pasado.
Registra el entorno y ejecuta sin mezclar cambios
Si dispones de una aplicación propia o autorizada, anota su versión, navegador, sistema y datos iniciales. Ejecuta cada caso desde el punto de partida definido. Si cambias varias condiciones a la vez, después será más difícil explicar cuál produjo la diferencia.
No utilices datos de clientes ni correos de personas ajenas. Prepara información ficticia dentro del entorno de pruebas. No intentes comprobar límites de una web real generando solicitudes masivas, pagos o reservas que puedan afectar a otros usuarios.
Cómo redactar un informe de error reproducible
ISTQB incluye en el informe el contexto, los pasos, los resultados esperado y real, las evidencias y datos de seguimiento. Para practicar, supón que observases que la aplicación acepta 7 plazas. Solo si lo has observado puedes presentarlo como incidencia real.
Un ejemplo hipotético de título sería: «El formulario permite continuar con 7 plazas cuando el máximo es 6». Describe después el entorno, el estado inicial y tres acciones: abrir el formulario, introducir los datos de prueba y pulsar Continuar. Explica por separado qué debía suceder y qué apareció realmente.
En una muestra no ejecutada, escribe «Resultado real: pendiente de comprobar». No fabriques capturas ni registros para completar el informe. Si sí realizas la prueba, adjunta evidencia mínima y revisa que no revele información privada.
Distingue impacto de prioridad. La importancia del fallo para el usuario y el orden en que se arreglará no son necesariamente lo mismo. Como principiante, puedes describir el impacto observado y dejar la prioridad para su revisión, en lugar de asignar siempre la etiqueta más urgente.
Convierte el ejercicio en una muestra honesta
Reúne alcance, reglas, casos, resultados reales cuando existan y dudas pendientes. Nuestra guía de portafolio en GitHub explica cómo presentar proyectos con contexto y límites. No necesitas publicar código confidencial ni una colección de insignias.
Antes de invertir en formación larga, comprueba si disfrutas interpretando requisitos, documentando y comunicando con precisión. Compara programas por ejercicios corregidos, acompañamiento y condiciones, no por promesas de contratación. Una primera muestra pequeña sirve para detectar qué necesitas aprender después, no para atribuirte una trayectoria que aún no tienes.
Portada ilustrativa, no participante identificada del congreso ni prueba de software ejecutada: Mizuno K en Pexels, licencia Pexels.
