DISEÑO DE CASO DE PRUEBA DE SOFTWARE

El diseño de casos de prueba de software es el proceso de crear una lista estructurada de pasos y condiciones para verificar la funcionalidad, la fiabilidad y la calidad de un sistema de software, identificando escenarios y combinaciones de entradas y salidas que simulen el comportamiento real y detecten defectos. Se basa en la identificación de requisitos y el uso de técnicas como la partición de equivalencia y el análisis de valores límite para maximizar la cobertura y asegurar que el software cumple con las expectativas, lo cual se documenta en una plantilla que incluye pasos, datos de prueba y resultados esperados. Es un plan paso a paso para validar una función específica del sistema.

Un caso de prueba sirve para comprobar:

• Que el software hace lo que debe hacer.

• Que responde correctamente a entradas válidas e inválidas.

• Que los errores o defectos se identifican oportunamente.

Ejemplo práctico de un caso de prueba: Login en una aplicación web.

Caso de Prueba ID: TC-001

Módulo: Autenticación de usuarios

Título: Verificar inicio de sesión con credenciales válidas

Objetivo: Validar que un usuario pueda iniciar sesión correctamente con usuario y contraseña válidos

• Condiciones Previas:

• • El usuario “admin” está registrado en el sistema.

  • El navegador tiene conexión a internet.

• Acciones de Prueba:

  1. Abrir la aplicación en el navegador.

  2. Ingresar en el campo "Usuario": admin.

  3. Ingresar en el campo "Contraseña": 12345.

  4. Hacer clic en el botón “Iniciar sesión”.

• Datos de Prueba:

  • Usuario: admin

  • Contraseña: 12345

• Resultado Esperado:
  El sistema redirige al usuario al panel principal mostrando el mensaje “Bienvenido, admin”.

Pruebas de Componentes (Unitarias o de Módulo)

Las pruebas de componentes verifican cada parte individual del software (clases, funciones, módulos) de forma aislada, antes de integrarlo con el resto del sistema.

Alcance y Estrategia de Prueba

• Qué se prueba: funciones individuales, clases, APIs, módulos independientes.

• Cómo se prueba: con herramientas de prueba unitaria (JUnit, NUnit, PyTest, etc.), validando entradas y salidas esperadas.

Entorno de Prueba

• Se configura un entorno controlado con librerías y dependencias simuladas (mocks o stubs).

Componentes de Software a Probar

• Funciones, métodos, algoritmos o clases específicas.

Acciones de Prueba

• Ejecutar cada función con diferentes entradas (válidas e inválidas).

• Comprobar salidas correctas, manejo de errores y excepciones.

Condiciones Previas

• Código compilado sin errores.

• Dependencias externas simuladas.

Datos de Prueba

• Entradas simples y controladas (ej: números positivos, negativos, nulos).

Resultados Esperados

• La función devuelve el valor correcto.

• Se manejan errores según lo esperado.

Recursos y Cronograma

• Recurso: desarrollador o tester con conocimiento del código.

• Cronograma: se ejecutan en paralelo al desarrollo, en cada commit o build (pruebas continuas).

   PRUEBAS DEL SISTEMA

Las pruebas del sistema validan el software completo e integrado, asegurando que todos los módulos trabajan de forma conjunta según los requisitos del cliente.

Alcance y Estrategia de Prueba

• Qué se prueba: la aplicación en su totalidad (front-end, back-end, base de datos, APIs).

• Cómo se prueba: con escenarios completos de negocio, pruebas funcionales y no funcionales.

Entorno de Prueba

• Similar al ambiente de producción (servidores, base de datos, red, dispositivos reales o virtuales).

Componentes de Software a Probar

• Interacciones entre módulos, integración con la base de datos, interfaz de usuario, seguridad, rendimiento.

Acciones de Prueba

• Ejecutar flujos completos de usuario (login, transacciones, reportes).

• Validar que se cumplen los requisitos funcionales y no funcionales.

Condiciones Previas

• Todos los módulos integrados y estables.

• Datos de prueba cargados en la base de datos.

Datos de Prueba

• Casos reales o simulados de negocio (ej: usuarios registrados, transacciones válidas e inválidas).

Resultados Esperados

• El sistema responde correctamente, sin errores.

• Cumple los tiempos de respuesta, reglas de negocio y seguridad establecidas.

Recursos y Cronograma

• Recursos: testers, analistas QA, herramientas de automatización (Selenium, JMeter).

• Cronograma: al finalizar la integración completa, antes de pruebas de aceptación del usuario.

Importancia del diseño de casos de prueba

1. Asegura la calidad del software: Permite verificar que cada módulo y el sistema completo cumplen con los requisitos funcionales y no funcionales.
2. Previene errores en etapas tempranas: Detecta fallos en componentes antes de que se integren, reduciendo costos de corrección.
3. Estandariza el proceso de prueba: Proporciona un método claro y repetible que facilita la comunicación entre testers, desarrolladores y clientes.
4. Facilita la trazabilidad: Cada caso de prueba se puede vincular a un requisito, asegurando que todo lo solicitado por el cliente sea probado.
5. Optimiza el uso de recursos: Al definir datos, condiciones y resultados esperados, se evita la improvisación y se aprovecha mejor el tiempo y el esfuerzo del equipo de pruebas.
6. Permite reproducir y documentar fallos: Ayuda a registrar errores con evidencias y repetir pruebas para verificar correcciones.

Conclusión

El diseño de casos de prueba es una actividad fundamental dentro del aseguramiento de la calidad del software, ya que garantiza que las funcionalidades se validen de manera sistemática, organizada y medible.

Las pruebas de componentes permiten aislar y validar cada parte del sistema en desarrollo, detectando errores de forma temprana, mientras que las pruebas de sistema aseguran que todos los módulos integrados funcionen correctamente en conjunto, replicando escenarios reales de uso.

En conjunto, ambos enfoques proporcionan una estrategia sólida de pruebas: primero se comprueba la correctitud interna de cada pieza y después la coherencia global del software. De esta manera, se minimizan riesgos, se mejora la confiabilidad del producto y se asegura la satisfacción del usuario final.

Video del diseño de casos de prueba y ejemplos:

https://youtu.be/rQf50sYvgJE 

Referencias

• Ammann, P., & Offutt, J. (2016). Introduction to software testing (2nd ed.). Cambridge University Press.
• Kaner, C., Bach, J., & Pettichord, B. (2002). Lessons learned in software testing: A context-driven approach. Wiley.
• Myers, G. J., Sandler, C., & Badgett, T. (2011). The art of software testing (3rd ed.). Wiley.
• Beizer, B. (1995). Software testing techniques (2nd ed.). Dreamtech Press.
• ISTQB. (2018). Standard glossary of terms used in software testing. International Software Testing Qualifications Board.
• Jorgensen, P. C. (2013). Software testing: A craftsman’s approach (4th ed.). CRC Press.