32. Caso práctico integrador: probar una funcionalidad simple

32.1 Introducción

En este tema aplicaremos varios conceptos vistos durante el curso a una funcionalidad simple. El objetivo no es usar una herramienta específica, sino practicar el razonamiento de testing: entender requisitos, identificar riesgos, diseñar casos, preparar datos, ejecutar pruebas y reportar defectos.

Trabajaremos con una funcionalidad de registro de usuario. Es un ejemplo común, fácil de entender y suficientemente rico para aplicar pruebas positivas, negativas, casos borde, criterios de aceptación, datos de prueba y reporte de defectos.

32.2 Funcionalidad a probar

La funcionalidad permite que una persona cree una cuenta en una aplicación web.

Campos del formulario:

  • Nombre.
  • Correo electrónico.
  • Contraseña.
  • Confirmación de contraseña.
  • Aceptación de términos y condiciones.

Al registrar correctamente, el sistema debe crear la cuenta y mostrar un mensaje de confirmación.

32.3 Requisitos iniciales

Supongamos que recibimos estos requisitos:

  • El nombre es obligatorio y debe tener entre 2 y 50 caracteres.
  • El correo electrónico es obligatorio y debe tener formato válido.
  • No se permiten dos cuentas con el mismo correo.
  • La contraseña es obligatoria y debe tener entre 8 y 20 caracteres.
  • La confirmación de contraseña debe coincidir con la contraseña.
  • El usuario debe aceptar términos y condiciones.
  • Si el registro es exitoso, el sistema debe mostrar el mensaje "Cuenta creada correctamente".
  • Si hay errores, el sistema debe informar el problema sin crear la cuenta.

Estos requisitos ya nos permiten diseñar varias pruebas, pero también podemos hacer preguntas para aclarar comportamientos.

32.4 Preguntas para aclarar requisitos

Antes de probar, conviene aclarar dudas:

  • ¿El nombre permite números o símbolos?
  • ¿El correo debe guardarse en minúsculas?
  • ¿El correo duplicado se compara ignorando mayúsculas y minúsculas?
  • ¿La contraseña requiere mayúsculas, números o símbolos?
  • ¿Qué mensaje exacto se muestra para cada error?
  • ¿Se envía correo de confirmación?
  • ¿El usuario queda activo inmediatamente o pendiente de verificación?
  • ¿Qué ocurre si el usuario presiona Registrar varias veces?

Estas preguntas son parte del trabajo de testing. Ayudan a transformar requisitos generales en comportamientos verificables.

32.5 Criterios de aceptación

Podemos expresar algunos criterios en formato Dado-Cuando-Entonces:

Dado un visitante con datos válidos,
cuando completa el formulario y acepta términos,
entonces el sistema debe crear la cuenta y mostrar "Cuenta creada correctamente".
Dado un visitante que ingresa un correo ya registrado,
cuando intenta crear una cuenta,
entonces el sistema debe rechazar el registro e informar que el correo ya está en uso.
Dado un visitante que no acepta términos y condiciones,
cuando intenta registrarse,
entonces el sistema debe rechazar el registro e indicar que debe aceptar los términos.

32.6 Riesgos principales

Para priorizar, identificamos riesgos:

  • Crear cuentas con datos inválidos.
  • Permitir correos duplicados.
  • Guardar contraseña y confirmación diferentes.
  • Crear cuenta sin aceptar términos.
  • Mostrar mensajes poco claros.
  • Crear varias cuentas si se presiona Registrar repetidamente.
  • No validar correctamente en backend.

Los riesgos relacionados con duplicados, contraseña y aceptación de términos tienen prioridad alta porque afectan reglas esenciales del registro.

32.7 Clases de equivalencia

Identificamos clases para algunos campos:

Campo Clase válida Clases inválidas
Nombre 2 a 50 caracteres. Vacío, 1 carácter, más de 50 caracteres.
Correo Formato válido y no registrado. Vacío, formato inválido, correo ya registrado.
Contraseña 8 a 20 caracteres. Vacía, menos de 8, más de 20.
Términos Aceptados. No aceptados.

32.8 Valores límite

Ahora seleccionamos bordes importantes:

  • Nombre de 1 carácter: inválido.
  • Nombre de 2 caracteres: válido.
  • Nombre de 50 caracteres: válido.
  • Nombre de 51 caracteres: inválido.
  • Contraseña de 7 caracteres: inválida.
  • Contraseña de 8 caracteres: válida.
  • Contraseña de 20 caracteres: válida.
  • Contraseña de 21 caracteres: inválida.

Estos casos ayudan a detectar errores típicos en comparaciones de mínimo y máximo.

32.9 Casos positivos, negativos y borde

Tipo Caso Resultado esperado
Positivo Registrar con todos los datos válidos. Cuenta creada correctamente.
Negativo Registrar con correo inválido. Rechazar e informar formato inválido.
Negativo Registrar con correo ya existente. Rechazar e informar correo en uso.
Negativo Registrar sin aceptar términos. Rechazar e indicar aceptación obligatoria.
Borde Nombre de 2 caracteres. Aceptar si los demás datos son válidos.
Borde Contraseña de 21 caracteres. Rechazar por longitud máxima.

32.10 Datos de prueba

Preparamos datos controlados:

Dato Valor Uso
Nombre válido María Pérez Registro exitoso.
Correo nuevo maria.perez.prueba@correo.com Registro exitoso.
Correo duplicado usuario.existente@correo.com Validar rechazo por duplicado.
Correo inválido usuario-sin-arroba.com Validar formato.
Contraseña válida Clave1234 Registro exitoso.
Contraseña corta abc1234 Validar mínimo.

32.11 Ambiente y precondiciones

Antes de ejecutar, definimos:

  • Ambiente: QA.
  • Versión: candidata actual.
  • Base de datos con usuario.existente@correo.com ya registrado.
  • Servidor de correo de prueba disponible si el sistema envía confirmaciones.
  • Navegador soportado para la ejecución manual.
  • Datos de prueba listos y documentados.

Si estos elementos no están preparados, varios casos pueden quedar bloqueados o generar resultados engañosos.

32.12 Suite de prueba propuesta

Podemos agrupar los casos en una suite llamada S-REGISTRO.

ID Título Prioridad
CP-REG-001 Registro exitoso con datos válidos. Alta
CP-REG-002 Rechazo de registro con correo inválido. Alta
CP-REG-003 Rechazo de registro con correo duplicado. Alta
CP-REG-004 Rechazo de registro con contraseña corta. Media
CP-REG-005 Rechazo de registro con confirmación diferente. Alta
CP-REG-006 Rechazo de registro sin aceptar términos. Alta
CP-REG-007 Validación de nombre con longitud mínima. Media
CP-REG-008 Validación de contraseña con longitud máxima excedida. Media

32.13 Caso de prueba completo

Identificador CP-REG-001
Título Registro exitoso con datos válidos.
Objetivo Verificar que una persona pueda crear una cuenta con datos válidos y aceptación de términos.
Precondiciones El correo usado no existe previamente en el sistema.
Datos Nombre: María Pérez. Correo: maria.perez.prueba@correo.com. Contraseña: Clave1234.
Pasos Abrir registro, completar campos, confirmar contraseña, aceptar términos y presionar Registrar.
Resultado esperado El sistema crea la cuenta y muestra "Cuenta creada correctamente".
Prioridad Alta

32.14 Ejecución simulada

Supongamos que ejecutamos la suite y obtenemos estos resultados:

Caso Resultado Observación
CP-REG-001 Aprobado La cuenta se crea correctamente.
CP-REG-002 Aprobado El correo inválido es rechazado.
CP-REG-003 Fallido El sistema permite crear otra cuenta con correo ya registrado.
CP-REG-004 Aprobado La contraseña corta es rechazada.
CP-REG-005 Aprobado La confirmación diferente es rechazada.
CP-REG-006 Fallido El sistema crea la cuenta aunque no se acepten términos.

Estos resultados muestran dos defectos importantes que deben reportarse.

32.15 Reporte de defecto 1

Título El sistema permite registrar dos cuentas con el mismo correo.
Ambiente QA - versión candidata actual.
Precondición Existe una cuenta con usuario.existente@correo.com.
Pasos Abrir registro, completar datos válidos usando usuario.existente@correo.com, aceptar términos y presionar Registrar.
Resultado esperado El sistema debe rechazar el registro e informar que el correo ya está en uso.
Resultado obtenido El sistema crea una nueva cuenta con el correo duplicado.
Severidad sugerida Alta, porque permite duplicar identidad de usuario.

32.16 Reporte de defecto 2

Título El sistema crea la cuenta sin aceptar términos y condiciones.
Ambiente QA - versión candidata actual.
Precondición El correo usado no existe previamente.
Pasos Abrir registro, completar nombre, correo, contraseña y confirmación, dejar términos sin aceptar y presionar Registrar.
Resultado esperado El sistema debe rechazar el registro e indicar que es obligatorio aceptar términos.
Resultado obtenido El sistema crea la cuenta correctamente.
Severidad sugerida Alta, porque incumple una condición obligatoria del registro.

32.17 Regresión después de corregir

Después de corregir los defectos, no alcanza con probar solo los casos fallidos. Conviene ejecutar una pequeña regresión del registro:

  • Registro exitoso con correo nuevo.
  • Registro con correo duplicado.
  • Registro sin aceptar términos.
  • Registro con contraseña válida.
  • Registro con confirmación diferente.
  • Registro con campos obligatorios vacíos.

Esto ayuda a confirmar que la corrección no rompió otros comportamientos del formulario.

32.18 Trazabilidad resumida

Requisito Caso Resultado Defecto
Correo no duplicado CP-REG-003 Fallido DEF-REG-001
Aceptar términos CP-REG-006 Fallido DEF-REG-002
Contraseña entre 8 y 20 caracteres CP-REG-004, CP-REG-008 Parcial -
Registro exitoso CP-REG-001 Aprobado -

La trazabilidad permite ver rápidamente qué requisitos tienen problemas y qué pruebas los evidencian.

32.19 Métricas simples de ejecución

Con la ejecución simulada podemos informar:

  • Casos planificados: 8.
  • Casos ejecutados: 6.
  • Casos aprobados: 4.
  • Casos fallidos: 2.
  • Casos no ejecutados: 2.
  • Defectos abiertos: 2.
  • Defectos de severidad alta: 2.

Pero el dato más importante no es solo el número: los defectos afectan reglas centrales del registro, por lo tanto el riesgo es alto.

32.20 Qué se puede automatizar

Algunas pruebas de esta funcionalidad podrían automatizarse en el futuro:

  • Registro exitoso con datos válidos.
  • Rechazo de correo inválido.
  • Rechazo de correo duplicado.
  • Rechazo de contraseña corta.
  • Rechazo de confirmación diferente.
  • Rechazo sin aceptar términos.

Primero conviene estabilizar la funcionalidad y confirmar reglas. Luego, si estos casos se repetirán en regresión, la automatización puede aportar valor.

32.21 Qué se puede explorar

Además de los casos documentados, una sesión exploratoria podría investigar:

  • Presionar Registrar varias veces rápidamente.
  • Usar espacios antes o después del correo.
  • Usar correo con mayúsculas y luego repetirlo en minúsculas.
  • Probar nombres con acentos, guiones o apóstrofes.
  • Actualizar la página durante el registro.
  • Volver atrás después de crear la cuenta.
  • Comportamiento visual en dispositivos móviles.
  • Mensajes de error simultáneos en varios campos.

La exploración puede descubrir riesgos que los casos iniciales no contemplaron.

32.22 Informe breve de estado

Un informe claro podría decir:

Se ejecutaron 6 de 8 casos planificados para registro de usuario en ambiente QA. Se aprobaron 4 casos y fallaron 2. Los defectos encontrados permiten crear cuentas con correo duplicado y crear cuentas sin aceptar términos. Ambos afectan reglas obligatorias del registro, por lo que no se recomienda publicar esta funcionalidad sin corrección y retest.

Este informe combina métricas, hallazgos y recomendación basada en riesgo.

32.23 Qué debes recordar de este caso

  • Primero se entienden requisitos y criterios de aceptación.
  • Luego se identifican riesgos.
  • Las clases de equivalencia y valores límite ayudan a elegir datos.
  • La suite debe combinar casos positivos, negativos y borde.
  • Los datos y ambiente deben prepararse antes de ejecutar.
  • Los resultados se registran con estado y observación.
  • Los defectos deben reportarse con pasos, esperado, obtenido y evidencia.
  • Después de corregir, se ejecuta retest y regresión relacionada.
  • El informe final debe comunicar riesgo, no solo cantidad de casos.

32.24 Conclusión del curso

Este caso práctico muestra cómo los conceptos del curso se conectan entre sí. El testing comienza entendiendo qué se espera del sistema, continúa con diseño de casos y datos, sigue con ejecución y registro, y termina con comunicación clara de defectos y riesgos.

Un tester efectivo no se limita a seguir pasos. Analiza requisitos, piensa en riesgos, diseña datos, observa resultados, reporta con claridad y ayuda al equipo a decidir con evidencia.

Con esta base, ya estamos preparados para profundizar en cursos específicos como pruebas unitarias, integración, end-to-end, automatización, testing por lenguaje, TDD, APIs, aplicaciones web, CI/CD, rendimiento y buenas prácticas de calidad de software.

Volver al índice