Cuando diseñamos casos de prueba, no debemos revisar solamente el camino ideal. También debemos comprobar cómo se comporta el sistema con errores, datos inválidos y condiciones extremas.
Para organizar esta mirada usamos tres conceptos muy prácticos: pruebas positivas, pruebas negativas y casos borde.
Las pruebas positivas confirman que el sistema funciona con datos y condiciones válidas. Las negativas verifican que el sistema rechace o maneje correctamente condiciones inválidas. Los casos borde revisan situaciones cercanas a los límites o condiciones extremas.
Una prueba positiva verifica que el sistema funcione correctamente cuando se usan datos válidos y se cumplen las condiciones esperadas.
Ejemplos:
Estas pruebas confirman que el camino esperado funciona. Suelen ser las primeras que se ejecutan para validar una funcionalidad nueva.
Las pruebas positivas ayudan a responder:
Son importantes porque si el camino positivo no funciona, muchas pruebas más específicas quedarán bloqueadas.
Una prueba negativa verifica que el sistema maneje correctamente datos inválidos, acciones no permitidas o condiciones de error.
Ejemplos:
Una buena prueba negativa no busca que el sistema "se rompa". Busca confirmar que el sistema rechace correctamente lo que debe rechazar y comunique el problema de forma adecuada.
Las pruebas negativas ayudan a responder:
Son fundamentales porque en el uso real los usuarios se equivocan, los datos llegan incompletos y los servicios pueden fallar.
| Aspecto | Prueba positiva | Prueba negativa |
|---|---|---|
| Datos | Válidos. | Inválidos, incompletos o no permitidos. |
| Objetivo | Confirmar que el sistema acepta y procesa correctamente. | Confirmar que el sistema rechaza o maneja correctamente. |
| Ejemplo | Compra con producto disponible. | Compra con producto sin stock. |
| Resultado esperado | Operación exitosa. | Error controlado, rechazo o mensaje adecuado. |
Un caso borde es una situación ubicada cerca de un límite, una condición extrema o una frontera entre comportamientos. Está muy relacionado con el análisis de valores límite.
Ejemplos:
Los casos borde son importantes porque muchos defectos aparecen en los límites.
Un caso borde puede ser válido o inválido. Depende de la regla.
Ejemplo:
Por eso los casos borde no reemplazan las pruebas positivas o negativas. Pueden pertenecer a cualquiera de esos grupos.
| Tipo | Caso | Resultado esperado |
|---|---|---|
| Positivo | Usuario activo con contraseña correcta. | Permitir acceso. |
| Negativo | Usuario activo con contraseña incorrecta. | Rechazar acceso. |
| Negativo | Usuario bloqueado con contraseña correcta. | Rechazar acceso e informar bloqueo. |
| Borde | Quinto intento fallido si el bloqueo ocurre al quinto intento. | Bloquear cuenta. |
| Borde | Cuarto intento fallido si el bloqueo ocurre al quinto intento. | Rechazar acceso, pero no bloquear todavía. |
El caso borde se enfoca en el límite de intentos fallidos, que es una regla crítica del flujo.
Para un registro de usuario con correo, contraseña y edad, podríamos diseñar:
Este conjunto cubre camino exitoso, errores esperados y zonas cercanas a límites.
Regla:
| Tipo | Caso | Resultado esperado |
|---|---|---|
| Positivo | Cargar PDF válido de 2 MB. | Aceptar archivo. |
| Negativo | Cargar archivo JPG. | Rechazar por formato no permitido. |
| Negativo | Cargar PDF corrupto. | Rechazar o informar archivo inválido. |
| Borde | Cargar PDF de exactamente 5 MB. | Aceptar si el límite es inclusive. |
| Borde | Cargar PDF apenas mayor a 5 MB. | Rechazar por tamaño máximo. |
Las fechas generan muchos casos borde porque dependen de días, horas, vencimientos y zonas horarias.
Ejemplos:
Los casos borde de fechas suelen ser críticos en reservas, pagos, vencimientos, promociones y reportes.
Los permisos también pueden tener casos borde. Por ejemplo:
Estos casos ayudan a descubrir problemas de seguridad o autorización que no aparecen con usuarios normales.
Cuando el sistema depende de otros servicios, los casos borde pueden estar en respuestas externas.
Ejemplos:
Estos casos son importantes porque muchas fallas reales ocurren en la frontera entre sistemas.
Un conjunto de pruebas equilibrado suele incluir:
Si solo probamos casos positivos, podemos pasar por alto errores importantes. Si solo probamos negativos y bordes, podemos olvidar comprobar que el flujo principal funciona. La combinación depende del riesgo y la importancia de la funcionalidad.
Estos conceptos se relacionan con técnicas ya vistas:
| Concepto | Relación |
|---|---|
| Clases de equivalencia | Ayudan a elegir datos positivos y negativos representativos. |
| Valores límite | Ayudan a elegir casos borde cerca de mínimos y máximos. |
| Tablas de decisión | Ayudan a cubrir combinaciones positivas y negativas de condiciones. |
| Transiciones de estado | Ayudan a probar cambios válidos e inválidos entre estados. |
Cuando el tiempo es limitado, conviene priorizar:
No todos los casos tienen el mismo valor. La prioridad debe estar basada en riesgo e impacto.
Al diseñar pruebas positivas, negativas y borde, algunos errores frecuentes son:
Una prueba negativa debe tener tanto criterio como una positiva.
Para diseñar mejor estos casos conviene:
Las pruebas positivas, negativas y casos borde permiten diseñar una suite más realista. Un sistema no solo debe funcionar cuando todo está bien; también debe protegerse ante errores, rechazar acciones incorrectas y comportarse adecuadamente en los límites.
Estos conceptos no reemplazan técnicas como clases de equivalencia, valores límite, tablas de decisión o transiciones de estado. Las complementan y ayudan a organizar la selección de casos.
En el próximo tema estudiaremos el plan de pruebas y la estrategia de testing, para ordenar objetivos, alcance, riesgos, recursos y criterios de ejecución.