Las pruebas de software son actividades orientadas a obtener información sobre el comportamiento y la calidad de un sistema. Ayudan a detectar defectos, validar requisitos, reducir riesgos y aumentar la confianza antes de entregar o modificar una versión.
Probar no significa demostrar que el sistema es perfecto. Significa evaluar, bajo ciertas condiciones, si el software se comporta como se espera y qué riesgos siguen presentes.
En Ingeniería de Software, las pruebas forman parte del proceso completo: se relacionan con requisitos, diseño, construcción, integración, entrega, mantenimiento y calidad del producto.
El software es construido por personas y puede contener errores de comprensión, diseño, programación, configuración o integración. Además, los sistemas reales tienen muchas combinaciones de datos, usuarios, permisos, dispositivos y condiciones de uso.
Las pruebas ayudan a:
Las pruebas están muy relacionadas con la calidad, pero no son lo mismo. La calidad del software depende de requisitos claros, buen diseño, código mantenible, arquitectura adecuada, revisión, pruebas, documentación y operación responsable.
Las pruebas permiten evaluar aspectos de calidad como:
Una prueba puede revelar un problema, pero la mejora de calidad ocurre cuando el equipo analiza y corrige las causas.
Dos conceptos importantes son verificación y validación.
| Concepto | Pregunta que responde | Ejemplo |
|---|---|---|
| Verificación | ¿Construimos correctamente lo especificado? | Comprobar que una regla fue implementada según el requisito. |
| Validación | ¿Construimos lo que el usuario realmente necesita? | Confirmar con usuarios que el flujo de reserva resuelve su tarea. |
Un sistema puede estar verificado contra una especificación y aun así no estar validado si la especificación no representaba bien la necesidad real.
Conviene distinguir tres conceptos básicos:
| Concepto | Significado | Ejemplo |
|---|---|---|
| Error | Equivocación humana al comprender, diseñar, programar o configurar. | Un analista interpreta mal una regla de descuento. |
| Defecto | Problema introducido en código, diseño, datos, configuración o documentación. | La fórmula implementada calcula mal el total. |
| Falla | Comportamiento incorrecto observable durante la ejecución. | El usuario ve un importe incorrecto al finalizar la compra. |
Las pruebas pueden organizarse por nivel, según el alcance de lo que se evalúa.
| Nivel | Qué evalúa | Ejemplo |
|---|---|---|
| Unitarias | Partes pequeñas de código, como funciones o clases. | Probar el cálculo de descuento. |
| Integración | Colaboración entre módulos o servicios. | Probar pedido junto con pago e inventario. |
| Sistema | El sistema completo funcionando como una unidad. | Probar el flujo completo de compra. |
| Aceptación | Cumplimiento de necesidades y criterios del usuario o negocio. | Validar que la reserva de turnos cumple los criterios acordados. |
También pueden clasificarse según el objetivo que persiguen.
Un proyecto puede combinar varios tipos de pruebas según riesgos, alcance y criticidad.
Un caso de prueba describe una situación específica que se desea verificar. Incluye condiciones iniciales, datos, pasos y resultado esperado.
Una estructura simple puede incluir:
| Objetivo | Qué se quiere verificar. |
|---|---|
| Precondiciones | Qué debe cumplirse antes de ejecutar la prueba. |
| Datos de entrada | Valores o información necesaria. |
| Pasos | Acciones a realizar. |
| Resultado esperado | Comportamiento que debe observarse. |
| Resultado obtenido | Lo que ocurrió durante la ejecución. |
Para la funcionalidad de cancelar una reserva:
| Objetivo | Verificar que una reserva puede cancelarse con más de dos horas de anticipación. |
|---|---|
| Precondiciones | Existe un usuario autenticado y una reserva activa para dentro de tres horas. |
| Pasos | Ingresar a mis reservas, seleccionar la reserva, presionar cancelar y confirmar. |
| Resultado esperado | La reserva queda cancelada, el cupo vuelve a estar disponible y se muestra confirmación. |
Este caso debería complementarse con otros: reserva fuera de plazo, reserva inexistente, usuario sin permiso y reserva ya cancelada.
Las pruebas pueden ejecutarse manualmente o automatizarse mediante programas.
| Tipo | Ventajas | Limitaciones |
|---|---|---|
| Manual | Flexible, útil para exploración, usabilidad y validación inicial. | Puede ser lenta, repetitiva y depender mucho de la persona. |
| Automatizada | Repetible, rápida para regresión y útil en integración continua. | Requiere mantenimiento y no reemplaza el criterio humano. |
Automatizar todo no siempre conviene. Se deben priorizar pruebas repetitivas, críticas y estables.
Como no es posible probar todas las combinaciones, conviene priorizar según riesgo. El riesgo combina probabilidad de falla e impacto si ocurre.
Se deberían probar con especial atención:
Las pruebas deben relacionarse con los requisitos. Los criterios de aceptación son una fuente directa para diseñar pruebas.
Ejemplo:
| Requisito | Pruebas derivadas |
|---|---|
| El usuario puede cancelar una reserva hasta dos horas antes. | Cancelar con tres horas de anticipación, cancelar con una hora, cancelar reserva ya cancelada. |
| Solo administradores pueden modificar precios. | Modificar con administrador, intentar modificar con usuario común, intentar sin autenticación. |
| La búsqueda debe responder en menos de dos segundos. | Medir búsqueda con volumen de datos definido y condiciones acordadas. |
Las pruebas no deberían comenzar cuando el sistema ya está terminado. Pueden aparecer en distintas actividades del ciclo de vida:
Probar temprano suele reducir costo de corrección y mejora la comprensión del producto.
Cuando se encuentra un defecto, debe comunicarse de forma clara para que pueda reproducirse, analizarse y corregirse.
Un reporte básico debería incluir:
Un buen reporte ahorra tiempo y reduce discusiones innecesarias.
Aunque algunos equipos tengan testers o responsables de calidad, la calidad no pertenece a una sola persona. Todo el equipo influye en ella.
Las pruebas son una parte de una cultura de calidad más amplia.
Al probar software suelen aparecer errores como:
Algunas buenas prácticas iniciales son:
Las pruebas de software son una práctica esencial para construir sistemas confiables. Permiten detectar defectos, validar requisitos, reducir riesgos y aportar evidencia para tomar decisiones durante el desarrollo y la entrega.
Para quien comienza, la idea principal es esta: probar software significa observar su comportamiento de forma planificada para compararlo con lo que debería hacer y descubrir riesgos relevantes.
En el próximo tema veremos verificación, validación y gestión de defectos, profundizando en cómo se detectan, comunican y administran los problemas encontrados.