En este momento estás viendo Basura que entra es basura que sale

Basura que entra es basura que sale

La frase «garbage in, garbage out» se traduce literalmente al español como «basura entra, basura sale» y es una frase que se estudia en toda formación vinculada con inteligencia artificial ya que es muy importante tenerla siempre presente y ocuparse de la misma. El gran desafío que hoy tenemos como seres humanos es cómo implementamos un tratamiento que sea efectivo.

Si bien es un principio fundamental en el mundo de la informática y la tecnología, y que su lógica se aplica a muchos otros campos, actualmente es como si cobra mayor relevancia debido a que nos está atravesando la inteligencia artificial.

El concepto básico para entender el significado de la frase es que la calidad del resultado que se obtiene de un sistema o proceso depende directamente de la calidad de los datos, instrucciones o materiales que se introducen al principio.

En otras palabras:

  • Si alimentas un sistema (como un programa, un algoritmo de inteligencia artificial, o incluso un proceso manual) con datos incorrectos, de mala calidad o sin sentido (la «basura de entrada»), el resultado que producirá será igualmente incorrecto, de mala calidad o sin sentido (la «basura de salida»).

Ejemplos para entenderlo mejor:

  • En una hoja de cálculo: Si introduces cifras de ventas erróneas en un informe financiero, el total y todas las conclusiones que saques de él serán incorrectos.
  • En Inteligencia Artificial: Si entrenas un modelo de IA con datos sesgados o de mala calidad, sus predicciones y decisiones también serán sesgadas y poco fiables.
  • En la cocina (una analogía): Si usas ingredientes en mal estado («garbage in») para preparar una comida, el plato final tendrá un sabor horrible («garbage out»), por muy buena que sea la receta.

En resumen, la frase es una advertencia sobre la importancia crítica de la calidad de los datos de entrada para poder confiar en los resultados.


Llevemos a la práctica el tema

Aplicar un filtro de calidad (filter reality prompt) a los requerimientos es la forma más temprana y efectiva de aplicar el principio «garbage in, garbage out». Un requerimiento de alta calidad es la base para un desarrollo y un testing exitoso.

Te comparto una estructura de prompt framework genérico, con un ejemplo práctico, para verificar y validar la calidad de un requerimiento funcional. La técnica que aplico es el «Análisis crítico basado en atributos de calidad», donde el modelo de IA actúa como un «asistente analítico» experto que busca activamente ambigüedades, suposiciones y puntos ciegos.


Prompt Framework: Verificación y Validación de Requerimientos (V&V)

La situación que definí a modo de ejemplo es la siguiente:
Si tuviéramos que verificar y validar la calidad de los datos, definiciones e instrucciones de un requerimiento funcional vinculado con la mejora que se desea tener para la funcionalidad de selección de medios de pago en un sitio de venta de productos ya que actualmente cuenta con uno solo que es por transferencia bancaria y el interés es de incorporar (a) tarjetas de crédito, (b) billeteras virtuales, (c) criptomonedas.

# PROMPT FRAMEWORK: V&V DE REQUERIMIENTO FUNCIONAL

## 1. ROL Y OBJETIVO (Role & Goal)
- **Rol:** Actúa como un Analista de Calidad (QA) Experto en Requerimientos y Casos de Uso, con un enfoque crítico y orientado al detalle.
- **Objetivo:** Verificar y validar la calidad, completitud y testabilidad del siguiente requerimiento funcional. Tu misión es identificar ambigüedades, información faltante, suposiciones ocultas y posibles riesgos antes de que el requerimiento pase al equipo de desarrollo o testing.

## 2. TÉCNICA A APLICAR (Technique to Apply)
- **Nombre de la Técnica:** Análisis Crítico Basado en Atributos de Calidad.
- **Instrucción de la Técnica:** Evalúa el requerimiento de entrada a través del lente de los siguientes atributos clave. Para cada atributo, formula preguntas directas, señala las deficiencias o confirma su cumplimiento.
  - **Completitud:** ¿Falta información esencial para su desarrollo y prueba? (Ej: Criterios de aceptación, manejo de errores, casos límite).
  - **Ambigüedad:** ¿Existen términos subjetivos o frases que puedan interpretarse de múltiples maneras? (Ej: "rápido", "fácil de usar", "mejorar").
  - **Consistencia:** ¿El requerimiento contradice alguna funcionalidad existente o alguna otra parte del mismo requerimiento?
  - **Testabilidad:** ¿Se puede escribir un caso de prueba con un resultado claro de "pasa" o "falla" para cada punto del requerimiento? ¿Están definidos los resultados esperados?
  - **Identificación de Suposiciones:** ¿Qué se está asumiendo que no está explícitamente escrito? (Ej: El usuario tiene una cuenta, la moneda ya está definida, etc.).

## 3. DATOS DE ENTRADA (Input Data)
- **Requerimiento Funcional (Texto Original):**
  """
  **Título:** Incorporación de Nuevos Medios de Pago.
  **Descripción:** Se necesita mejorar la funcionalidad de medios de pago del e-commerce. Actualmente solo se acepta transferencia bancaria. Se deben incorporar las siguientes opciones para que el proceso sea más moderno y rápido:
  a) Tarjetas de crédito.
  b) Billeteras virtuales más comunes.
  c) Criptomonedas.
  La confirmación de la compra debe ser inmediata después del pago.
  """

## 4. INSTRUCCIONES Y FORMATO DE SALIDA (Instructions & Output Format)
- **Acción:** No generes casos de prueba ni soluciones. Tu única tarea es analizar el texto de entrada y producir un informe de validación.
- **Formato de Salida:** Presenta tu análisis en un informe estructurado utilizando el siguiente formato Markdown.

---
### INFORME DE VERIFICACIÓN Y VALIDACIÓN DEL REQUERIMIENTO
---

#### **Resumen General de Calidad:**
[Evalúa en 1-2 frases la calidad general del requerimiento y su preparación para el desarrollo.]

---

#### **Análisis Detallado por Atributo:**

**1. Análisis de Completitud (Información Faltante):**
* **Tarjetas de Crédito:**
    * ¿Qué marcas de tarjetas se aceptarán (Visa, MasterCard, Amex, etc.)?
    * ¿Se aceptarán tarjetas de débito además de crédito?
    * ¿Se almacenarán los datos de la tarjeta para futuras compras? Si es así, ¿qué consideraciones de seguridad (PCI DSS) se deben tener en cuenta?
    * ¿Cuál es el flujo exacto para el manejo de una transacción rechazada? ¿Qué mensaje se le muestra al usuario?
* **Billeteras Virtuales:**
    * ¿Qué es lo que define a las "más comunes"? Se necesita una lista explícita (ej: Mercado Pago, PayPal, etc.).
    * ¿Cómo se gestiona la devolución de un pago a través de una billetera virtual?
* **Criptomonedas:**
    * ¿Qué criptomonedas específicas se aceptarán (BTC, ETH, USDT, etc.)?
    * ¿Qué proveedor o pasarela de pago se utilizará para procesar las transacciones cripto?
    * Dada la volatilidad, ¿cómo se manejará el tipo de cambio? ¿Se fija en el momento de la compra? ¿Por cuánto tiempo?
* **General:**
    * ¿Existe algún costo o comisión adicional para el usuario según el medio de pago elegido? ¿Debe mostrarse?

**2. Análisis de Ambigüedad (Términos Subjetivos):**
* **"más moderno y rápido":** Estos términos son subjetivos. Se necesita definir métricas objetivas. ¿"Rápido" significa que la transacción se completa en menos de 3 segundos? ¿Qué aspecto técnico define a "moderno"?
* **"confirmación ... inmediata":** "Inmediato" debe ser cuantificado. ¿Significa en tiempo real (<1 segundo)? ¿O puede haber una demora aceptable de hasta 1 minuto, como ocurre con algunas confirmaciones de blockchain?

**3. Análisis de Consistencia:**
* El concepto de confirmación "inmediata" puede entrar en conflicto con la naturaleza de las transacciones de algunas criptomonedas (ej: Bitcoin), que requieren múltiples confirmaciones en la red y pueden tardar varios minutos. Esto es una inconsistencia potencial que debe ser aclarada.

**4. Análisis de Testabilidad:**
* El requerimiento en su estado actual es difícil de probar debido a las ambigüedades. No se pueden escribir casos de prueba para "rápido" o "más comunes" sin una definición clara.
* Faltan los resultados esperados para los flujos de error (ej: tarjeta rechazada, saldo insuficiente en billetera, red cripto congestionada).

**5. Identificación de Suposiciones:**
* Se asume que la plataforma ya cuenta con un sistema para manejar diferentes monedas o tipos de cambio (crítico para criptomonedas).
* Se asume que la infraestructura actual puede integrarse de forma segura con pasarelas de pago externas.
* Se asume que el usuario ya ha pasado por las etapas previas del checkout (carrito, dirección de envío, etc.) y ha llegado al paso final de pago.

Gus Terrera

Apasionado por el agile testing y la ia.