Introducción a las Pruebas No Funcionales

Mientras que las pruebas funcionales responden “¿Funciona?”, las pruebas no funcionales responden preguntas igualmente críticas: “¿Funciona bien? ¿Es usable? ¿Es accesible? ¿Funciona en todos lados?”

Las pruebas no funcionales validan atributos de calidad que determinan la satisfacción del usuario, el alcance de mercado y el éxito a largo plazo. Una aplicación perfectamente funcional que es lenta, difícil de usar, inaccesible para usuarios con discapacidades, o incompatible con ciertos navegadores puede fracasar en el mercado a pesar de tener cero bugs funcionales.

En esta guía completa, exploraremos los pilares clave de las pruebas no funcionales: usabilidad, compatibilidad, localización/internacionalización y accesibilidad. Aprenderás técnicas prácticas, herramientas y mejores prácticas para asegurar que tu software no solo funcione correctamente, sino que ofrezca una experiencia excepcional a todos los usuarios.

Entendiendo las Pruebas No Funcionales

¿Qué son las Pruebas No Funcionales?

Las pruebas no funcionales evalúan cómo funciona un sistema en lugar de qué hace (a diferencia de las pruebas funcionales que se enfocan en lo que el sistema hace). Se enfocan en atributos de calidad incluyendo:

  • Usabilidad: ¿Qué tan fácil y agradable es usar el sistema?
  • Rendimiento: ¿Qué tan rápido y responsivo es?
  • Confiabilidad: ¿Qué tan estable y confiable?
  • Compatibilidad: ¿Funciona en diferentes entornos?
  • Seguridad: ¿Qué tan bien está protegido?
  • Accesibilidad: ¿Pueden todos los usuarios, incluidos aquellos con discapacidades, usarlo?
  • Localización: ¿Se adapta a diferentes idiomas y culturas?

Por qué Importan las Pruebas No Funcionales

Impacto en el negocio:

  • Retención de usuarios: 88% de usuarios no regresarán después de una mala experiencia
  • Cumplimiento legal: Fallos de accesibilidad pueden resultar en demandas
  • Alcance de mercado: Mala localización limita expansión global
  • Reputación de marca: Problemas de compatibilidad dañan credibilidad
  • Ventaja competitiva: UX superior diferencia productos

Consecuencias del mundo real de descuidar pruebas no funcionales:

Ejemplo 1: Sitio e-commerce
- 1 segundo de retraso en carga = 7% reducción en conversiones
- Mala compatibilidad móvil = 50% de clientes potenciales perdidos
- Checkout inaccesible = Violación de regulaciones ADA

Ejemplo 2: Aplicación SaaS
- UI compleja = Mayores costos de soporte y abandono de usuarios
- Sin soporte RTL = Mercado de Medio Oriente inaccesible
- Incompatibilidad de navegadores = Contratos empresariales perdidos

Ejemplo 3: App móvil
- Alto uso de memoria = Reviews de 1 estrella y desinstalaciones
- Mala localización = Malas calificaciones en mercados internacionales
- Fallos de accesibilidad = Exclusión del 15% de usuarios potenciales

Usability Testing: Aseguramiento de Calidad Centrado en el Humano

Entendiendo Usabilidad

Definición: Usabilidad mide qué tan efectiva, eficiente y satisfactoriamente los usuarios pueden lograr sus objetivos usando un sistema.

Los cinco componentes de calidad de usabilidad (Jakob Nielsen):

  1. Aprendizaje: ¿Qué tan fácil es para nuevos usuarios lograr tareas?
  2. Eficiencia: ¿Qué tan rápido pueden usuarios experimentados realizar tareas?
  3. Memorabilidad: ¿Pueden los usuarios recordar cómo usarlo después de un descanso?
  4. Errores: ¿Cuántos errores cometen los usuarios y pueden recuperarse?
  5. Satisfacción: ¿Qué tan agradable es la experiencia?

Métodos de Usability Testing

1. Usability Testing Moderado

Qué: Un facilitador guía usuarios a través de tareas mientras observa y hace preguntas.

Cuándo usar:

  • Validación de diseño temprano
  • Flujos de trabajo complejos
  • Cuando necesitas insights profundos
  • Sistemas médicos, financieros o críticos

Proceso:

1. Preparación:
   - Definir objetivos
   - Crear escenarios de prueba
   - Reclutar participantes (5-8 usuarios por ronda)
   - Preparar entorno de prueba
   - Crear script del facilitador

2. Ejecución:
   - Bienvenida y consentimiento
   - Explicar protocolo de pensar en voz alta
   - Presentar escenarios
   - Observar y tomar notas
   - Hacer preguntas de seguimiento
   - Cuestionario post-prueba

3. Análisis:
   - Identificar patrones entre usuarios
   - Categorizar issues por severidad
   - Calcular tasas de éxito y tiempo en tarea
   - Documentar insights y recomendaciones

Mejores prácticas:

  • Usar escenarios realistas, no “Haz clic en el botón de login”
  • Evitar preguntas dirigidas
  • Permanecer neutral—no ayudar a menos que sea necesario
  • Grabar sesiones (con permiso)
  • Probar con usuarios representativos
  • Enfocarse en tareas, no características

Escenario de muestra (bueno):

"Acabas de terminar un entrenamiento y quieres registrarlo en la app.
Registra tu carrera de 30 minutos de esta mañana."

Escenario de muestra (malo):

"Haz clic en el botón 'Agregar Entrenamiento' y llena el formulario."

2. Testing Remoto No Moderado

Qué: Usuarios completan tareas independientemente mientras sus interacciones son grabadas.

Cuándo usar:

  • Se necesitan muestras grandes
  • Base de usuarios distribuida
  • Restricciones presupuestarias
  • Feedback rápido necesario

Herramientas:

  • UserTesting
  • Lookback
  • Maze
  • UsabilityHub

Pros:

  • Costo-efectivo
  • Resultados más rápidos
  • Entorno natural
  • Tamaños de muestra más grandes

Contras:

  • Sin aclaraciones en tiempo real
  • No se pueden hacer preguntas de seguimiento
  • Puede perder contexto
  • Issues técnicos más difíciles de resolver

3. A/B Testing

Qué: Comparar dos versiones para determinar cuál funciona mejor.

Cuándo usar:

  • Optimizar elementos específicos
  • Decisiones de diseño basadas en datos
  • Aplicaciones de alto tráfico
  • Mejoras incrementales

Qué probar con A/B:

  • Botones de call-to-action (color, texto, ubicación)
  • Títulos y copy
  • Estructura de navegación
  • Layouts de formularios
  • Presentación de precios
  • Contenido de imagen vs video

Mejores prácticas:

✓ Probar una variable a la vez
✓ Asegurar significancia estadística
✓ Ejecutar pruebas suficientemente largas (típicamente 1-2 semanas mínimo)
✓ Segmentar resultados por tipo de usuario
✓ Considerar factores externos (estacionalidad, campañas)
✓ Documentar y compartir aprendizajes

Ejemplo de prueba A/B:

Hipótesis: Cambiar CTA de "Enviar" a "Obtener Mi Prueba Gratis"
aumentará conversiones

Métrica: Tasa de conversión (envíos de formulario / vistas de página)
Tamaño de muestra: Mínimo 1000 conversiones por variante
Duración: 2 semanas
Resultado: Versión B aumentó conversiones en 23%

4. Evaluación Heurística

Qué: Expertos evalúan la interfaz contra principios establecidos de usabilidad.

10 Heurísticas de Usabilidad de Nielsen:

  1. Visibilidad del estado del sistema: Mantener a usuarios informados sobre lo que está pasando

    • Ejemplo: Barras de progreso, indicadores de carga, mensajes de confirmación

  2. Coincidencia entre sistema y mundo real: Usar lenguaje y conceptos familiares

    • Ejemplo: Icono de basura para eliminar, icono de carrito para compras

  3. Control y libertad del usuario: Proporcionar deshacer/rehacer

    • Ejemplo: “Deshacer envío” en email, opciones de editar/eliminar

  4. Consistencia y estándares: Seguir convenciones de plataforma

    • Ejemplo: Logo arriba a la izquierda, búsqueda arriba a la derecha, estilos de botón consistentes

  5. Prevención de errores: Mejor que buenos mensajes de error

    • Ejemplo: Deshabilitar opciones inválidas, confirmación para acciones destructivas

  6. Reconocimiento en lugar de recordar: Minimizar carga de memoria

    • Ejemplo: Menús desplegables, elementos usados recientemente, autocompletar

  7. Flexibilidad y eficiencia: Atajos para usuarios expertos

    • Ejemplo: Atajos de teclado, plantillas, acciones en lote

  8. Diseño estético y minimalista: Sin información irrelevante

    • Ejemplo: Divulgación progresiva, layouts limpios, jerarquía clara

  9. Ayudar a usuarios a reconocer, diagnosticar y recuperarse de errores: Mensajes de error claros

    • Ejemplo: “La contraseña debe tener 8+ caracteres” en lugar de “Entrada inválida”

  10. Ayuda y documentación: Buscable, enfocada en tareas, concisa

    • Ejemplo: Ayuda contextual, tooltips, base de conocimiento buscable

Realizando evaluación heurística:

1. Preparación:
   - Seleccionar 3-5 evaluadores
   - Definir alcance (app completa o características específicas)
   - Proporcionar checklist de heurísticas

2. Evaluación:
   - Cada evaluador revisa independientemente la interfaz
   - Documentar violaciones con:
     * Qué heurística violada
     * Severidad (cosmética, menor, mayor, catastrófica)
     * Ubicación (screenshot, página, característica)
     * Descripción del problema
     * Corrección sugerida

3. Debriefing:
   - Consolidar hallazgos
   - Eliminar duplicados
   - Priorizar issues
   - Crear plan de acción

Métricas de Usabilidad

Métricas cuantitativas:

  1. Tasa de éxito de tarea: % de usuarios que completan tarea correctamente

    Fórmula: (Completaciones exitosas / Intentos totales) × 100
Bueno: >78%

  2. Tiempo en tarea: Cuánto tiempo toma completar

    Medida: Tiempo promedio, tiempo mediano
Comparar: Contra benchmarks o versiones previas

  3. Tasa de error: Errores cometidos durante tareas

    Fórmula: (Número de errores / Intentos totales de tarea) × 100
Rastrear: Tipo de errores y recuperación

  4. Clics/toques para completar: Medida de eficiencia

    Mejor práctica: Minimizar pasos al objetivo
Regla de 3 clics: Info crítica accesible en 3 clics

Métricas cualitativas:

  1. System Usability Scale (SUS): Encuesta estandarizada de 10 preguntas

    Rango de puntuación: 0-100
Por encima de 68: Por encima del promedio
Por encima de 80: Excelente

  2. Net Promoter Score (NPS): “¿Qué tan probable es recomendar?”

    Escala: 0-10
Promotores: 9-10
Pasivos: 7-8
Detractores: 0-6
NPS = % Promotores - % Detractores

  3. Satisfacción del Cliente (CSAT): “¿Qué tan satisfecho estuviste?”

    Escala: 1-5 o 1-7
Bueno: >80% satisfecho (4-5 en escala de 5 puntos)

Checklist de Usability Testing

Navegación y Arquitectura de Información:

  • Usuarios pueden encontrar lo que buscan rápidamente
  • Navegación es consistente entre páginas
  • Breadcrumbs ayudan a usuarios entender ubicación
  • Funcionalidad de búsqueda funciona bien
  • Etiquetas de menú son claras y descriptivas

Formularios e Entrada:

  • Formularios son lo más cortos posible
  • Etiquetas son claras y posicionadas apropiadamente
  • Campos requeridos están claramente marcados
  • Validación de entrada es útil, no frustrante
  • Mensajes de error son específicos y accionables
  • Formulario recuerda datos ingresados en error

Contenido y Legibilidad:

  • Texto es escaneable (encabezados, viñetas, párrafos cortos)
  • Tamaño de fuente es legible (mínimo 16px para texto de cuerpo)
  • Relación de contraste cumple estándares (mínimo 4.5:1)
  • Acciones importantes son visualmente prominentes
  • Contenido usa lenguaje simple

Usabilidad Móvil:

  • Objetivos táctiles son al menos 44×44px
  • Texto es legible sin zoom
  • Scroll horizontal no requerido
  • Formularios están optimizados para móvil
  • Navegación es amigable para pulgar

Rendimiento y Feedback:

  • Carga de página se siente rápida (<3 segundos)
  • Acciones proporcionan feedback inmediato
  • Estados de carga previenen confusión
  • Errores se previenen donde es posible
  • Confirmaciones de éxito son claras

Compatibility Testing: Asegurando Acceso Universal

Entendiendo Compatibility Testing

Definición: Compatibility testing verifica que el software funcione correctamente en diferentes entornos, incluyendo navegadores, dispositivos, sistemas operativos y redes.

Tipos de compatibilidad:

  • Compatibilidad de navegador: Chrome, Firefox, Safari, Edge, etc.
  • Compatibilidad de dispositivo: Desktop, tablet, móvil, diferentes tamaños de pantalla
  • Compatibilidad de sistema operativo: Windows, macOS, Linux, iOS, Android
  • Compatibilidad de red: Diferentes velocidades, escenarios offline
  • Compatibilidad de base de datos: Diferentes sistemas de bases de datos
  • Compatibilidad retroactiva: Funciona con versiones anteriores

Browser Compatibility Testing

La cuota de mercado impulsa prioridades (a partir de 2025):

Desktop:
- Chrome: ~65% (Prioridad 1)
- Safari: ~15% (Prioridad 1)
- Edge: ~10% (Prioridad 2)
- Firefox: ~7% (Prioridad 2)
- Otros: ~3% (Prioridad 3 o omitir)

Móvil:
- Chrome Mobile: ~65% (Prioridad 1)
- Safari iOS: ~25% (Prioridad 1)
- Samsung Internet: ~6% (Prioridad 2)
- Otros: ~4% (Prioridad 3 o omitir)

Enfoque de testing:

1. Identificar navegadores objetivo:

Analizar tus analytics:
- ¿Qué navegadores usan tus usuarios?
- ¿Qué versiones?
- ¿Qué porcentaje de tráfico?

Definir niveles de soporte:
Tier 1: Totalmente soportado, todas las características funcionan (90% de usuarios)
Tier 2: Soportado, características críticas funcionan (9% de usuarios)
Tier 3: Mejor esfuerzo, contenido accesible (1% de usuarios)

2. Crear matriz de prueba:

Navegador  | Versiones     | Sistemas Operativos | Prioridad
-----------|---------------|---------------------|----------
Chrome     | Latest, N-1   | Windows, Mac        | P0
Safari     | Latest, N-1   | Mac, iOS            | P0
Edge       | Latest        | Windows             | P1
Firefox    | Latest        | Windows, Mac        | P1
Samsung    | Latest        | Android             | P2

3. Issues comunes de compatibilidad:

Issues CSS:

/* Soporte Flexbox */
.container {
  display: -webkit-box;      /* Safari antiguo */
  display: -webkit-flex;     /* Safari 6.1+ */
  display: -ms-flexbox;      /* IE 10 */
  display: flex;             /* Navegadores modernos */
}

/* Soporte Grid - verificar caniuse.com */
@supports (display: grid) {
  .grid-container {
    display: grid;
  }
}

/* Prefijos de vendor */
.element {
  -webkit-transform: rotate(45deg);
  -ms-transform: rotate(45deg);
  transform: rotate(45deg);
}

Issues JavaScript:

// Características ES6 pueden necesitar polyfills para navegadores antiguos
// Verificar compatibilidad: caniuse.com

// Arrow functions
const multiply = (a, b) => a * b;  // Puede necesitar Babel

// Promises
fetch('/api/data')  // Puede necesitar polyfill para IE11
  .then(response => response.json())
  .then(data => console.log(data));

// Usar detección de características
if ('IntersectionObserver' in window) {
  // Usar IntersectionObserver
} else {
  // Enfoque de fallback
}

4. Herramientas de testing:

Plataformas de testing cross-browser:

  • BrowserStack: Dispositivos y navegadores reales en la nube
  • Sauce Labs: Testing automatizado y manual
  • LambdaTest: Testing en vivo y automatizado
  • CrossBrowserTesting: Testing de navegadores reales

Testing local:

  • BrowserStack Local: Probar localhost en navegadores reales
  • Máquinas virtuales: Probar en diferentes OS
  • Device lab: Dispositivos físicos para testing

Testing automatizado:

// Selenium WebDriver - automatización cross-browser
const { Builder, By, Key, until } = require('selenium-webdriver');

async function testCrossBrowser(browserName) {
  let driver = await new Builder()
    .forBrowser(browserName)
    .build();

  try {
    await driver.get('http://yoursite.com');
    await driver.findElement(By.name('q')).sendKeys('webdriver', Key.RETURN);
    await driver.wait(until.titleIs('webdriver - Google Search'), 1000);
  } finally {
    await driver.quit();
  }
}

// Probar en navegadores
testCrossBrowser('chrome');
testCrossBrowser('firefox');
testCrossBrowser('safari');

Testing de Dispositivos y Responsive

Estrategia de testing:

1. Definir matriz de dispositivos:

Categoría       | Dispositivos                      | Prioridad
----------------|-----------------------------------|----------
Móvil - Pequeño | iPhone SE (375×667)               | P0
Móvil - Mediano | iPhone 14 (390×844)               | P0
Móvil - Grande  | iPhone 14 Pro Max (430×932)       | P1
Tablet          | iPad (810×1080)                   | P1
Desktop - Pequeño| 1366×768                         | P0
Desktop - Mediano| 1920×1080                        | P0
Desktop - Grande | 2560×1440                        | P2

2. Breakpoints responsive:

/* Enfoque mobile first */
/* Estilos base: Móvil (320px+) */
.container {
  padding: 1rem;
}

/* Tablet (768px+) */
@media (min-width: 768px) {
  .container {
    padding: 2rem;
    max-width: 720px;
  }
}

/* Desktop (1024px+) */
@media (min-width: 1024px) {
  .container {
    padding: 3rem;
    max-width: 960px;
  }
}

/* Desktop grande (1280px+) */
@media (min-width: 1280px) {
  .container {
    max-width: 1200px;
  }
}

3. Checklist de testing:

Layout:

  • Sin scroll horizontal en ningún viewport
  • Contenido es legible sin zoom
  • Imágenes escalan apropiadamente
  • Texto no desborda contenedores
  • Layouts grid/flex funcionan correctamente

Interacciones táctiles:

  • Objetivos táctiles son mínimo 44×44px
  • Botones tienen espaciado adecuado
  • Gestos de swipe funcionan (si implementado)
  • Menús desplegables son táctil-amigables
  • Estados hover tienen equivalentes táctiles

Rendimiento:

  • Imágenes están optimizadas para móvil
  • Lazy loading implementado
  • JavaScript mínimo en móvil
  • Carga inicial de página rápida

4. Herramientas de testing:

  • Chrome DevTools: Simulación de dispositivos
  • Firefox Responsive Design Mode: Múltiples viewports
  • Dispositivos reales: Testing de dispositivo físico
  • BrowserStack: Nube de dispositivos reales
  • Responsively App: Todos los viewports a la vez

Compatibilidad de Sistema Operativo

Consideraciones de testing:

Diferencias de Desktop OS:

Windows vs macOS:
- Renderizado de fuentes (Windows: ClearType, Mac: más suave)
- Atajos de teclado (Ctrl vs Cmd)
- Rutas de archivo (barra invertida vs barra inclinada)
- Disponibilidad de fuentes por defecto
- Estilización de controles de formulario

Linux:
- Varias distribuciones (Ubuntu, Fedora, etc.)
- Diferentes entornos de escritorio (GNOME, KDE)
- Disponibilidad de fuentes varía

Diferencias de Mobile OS:

iOS vs Android:
- Safari vs Chrome navegador por defecto
- Diferentes selectores de fecha/hora
- Diferentes comportamientos de entrada de formulario
- Manejo de eventos táctiles
- Diferencias de notificaciones push
- APIs de acceso a cámara/archivos

Mejores Prácticas de Compatibility Testing

1. Priorizar basado en datos:

✓ Usar analytics para identificar navegadores/dispositivos de usuarios
✓ Probar configuraciones más comunes primero
✓ Definir versiones mínimas soportadas
✓ Documentar política de soporte de navegadores

2. Automatizar donde sea posible:

✓ Tests cross-browser automatizados en CI/CD
✓ Testing de regresión visual
✓ Tests de diseño responsive
✓ Automatización de accesibilidad

3. Usar mejora progresiva:

✓ Funcionalidad core funciona en todos lados
✓ Características mejoradas para navegadores modernos
✓ Degradación elegante para navegadores antiguos
✓ Detección de características sobre detección de navegador

4. Documentar compatibilidad:

✓ Mantener matriz de soporte de navegadores
✓ Documentar issues conocidos
✓ Proporcionar workarounds si están disponibles
✓ Actualizar regularmente

Localización e Internacionalización Testing

Entendiendo L10n e I18n

Internacionalización (i18n): Diseñar software para que pueda adaptarse a varios idiomas y regiones sin cambios de código.

Localización (l10n): Adaptar software internacionalizado para una región o idioma específico.

Piénsalo como:

  • i18n = Hacerlo posible
  • l10n = Realmente hacerlo

Internacionalización: Construyendo para Alcance Global

Requisitos clave de i18n:

1. Manejo de texto:

// NO: Texto hardcodeado
<button>Submit</button>

// SÍ: Strings externalizadas
<button>{t('common.submit')}</button>

// Archivos de idioma
en.json: { "common": { "submit": "Submit" } }
es.json: { "common": { "submit": "Enviar" } }
fr.json: { "common": { "submit": "Soumettre" } }

2. Soporte Unicode:

✓ Usar codificación UTF-8 en todos lados
✓ Soportar caracteres de cualquier idioma
✓ Manejar emojis y caracteres especiales
✓ Cálculo adecuado de longitud de string (clusters de grafemas, no bytes)

Ejemplo de issues:
"Café" en UTF-8: é puede ser 1 o 2 caracteres dependiendo de normalización
"👨‍👩‍👧‍👦" (emoji familia): Parece 1 carácter, pero es en realidad varios

3. Fecha y hora:

// NO: Formato hardcodeado
const date = "12/01/2025";  // Ambiguo: ¿Dic 1 o Ene 12?

// SÍ: Usar formateo consciente de locale
const date = new Date('2025-01-12');
const formatted = new Intl.DateTimeFormat('en-US').format(date);
// Salida: 1/12/2025 (US)

const formattedUK = new Intl.DateTimeFormat('en-GB').format(date);
// Salida: 12/01/2025 (UK)

const formattedJP = new Intl.DateTimeFormat('ja-JP').format(date);
// Salida: 2025/1/12 (Japón)

// Zonas horarias
const options = {
  timeZone: 'America/New_York',
  hour: '2-digit',
  minute: '2-digit'
};

4. Números y moneda:

// Formateo de números
const number = 1234567.89;

new Intl.NumberFormat('en-US').format(number);
// Salida: 1,234,567.89

new Intl.NumberFormat('de-DE').format(number);
// Salida: 1.234.567,89

new Intl.NumberFormat('fr-FR').format(number);
// Salida: 1 234 567,89

// Moneda
const amount = 99.99;

new Intl.NumberFormat('en-US', {
  style: 'currency',
  currency: 'USD'
}).format(amount);
// Salida: $99.99

new Intl.NumberFormat('de-DE', {
  style: 'currency',
  currency: 'EUR'
}).format(amount);
// Salida: 99,99 €

new Intl.NumberFormat('ja-JP', {
  style: 'currency',
  currency: 'JPY'
}).format(amount);
// Salida: ¥100 (JPY no usa decimales)

5. Dirección de texto:

/* Soportar idiomas RTL (Right-to-Left) como árabe, hebreo */

/* NO: Dirección fija */
.container {
  text-align: left;
  padding-left: 20px;
}

/* SÍ: Propiedades lógicas */
.container {
  text-align: start;  /* Se adapta a dirección de texto */
  padding-inline-start: 20px;  /* Izquierda en LTR, derecha en RTL */
}

/* Atributo de dirección HTML */
<html dir="rtl" lang="ar">

/* Estilos específicos RTL */
[dir="rtl"] .icon {
  transform: scaleX(-1);  /* Reflejar iconos si es necesario */
}

6. Expansión de texto:

La longitud del texto de traducción varía:

Inglés "Account" (7 caracteres)
→ Alemán "Benutzerkonto" (14 caracteres) - 100% más largo
→ Francés "Compte d'utilisateur" (20 caracteres) - 185% más largo

Consideraciones de diseño:
✓ No establecer anchos fijos para texto
✓ Permitir que texto se ajuste
✓ Probar con idioma más largo
✓ Usar layouts flexibles (flexbox, grid)
✓ Agregar 30-40% de espacio extra en diseños

Factores de expansión comunes:
Inglés → Alemán: +30%
Inglés → Francés: +15-20%
Inglés → Español: +20-30%

Localización Testing

Qué probar:

1. Calidad de traducción:

Checklist:
- [ ] Todo el texto está traducido (sin inglés en versión española)
- [ ] Las traducciones son contextualmente correctas
- [ ] Sin texto truncado
- [ ] Sin desbordamiento de texto
- [ ] Consistencia de terminología
- [ ] Apropiación cultural
- [ ] Sin artefactos de traducción automática

2. Testing lingüístico:

Gramática y ortografía:
- [ ] Gramática correcta
- [ ] Puntuación apropiada
- [ ] Nivel de formalidad apropiado (formal vs informal)
- [ ] Concordancia de género (idiomas con sustantivos de género)
- [ ] Formas plurales (algunos idiomas tienen múltiples formas plurales)

Ejemplo: Plurales en ruso
1 файл (1 archivo)
2 файла (2 archivos)
5 файлов (5 archivos)
Diferentes terminaciones para 1, 2-4, y 5+ artículos

3. Formateo:

- [ ] Formatos de fecha correctos para locale
- [ ] Formatos de tiempo (12 vs 24 horas)
- [ ] Formatos de números (separador decimal)
- [ ] Símbolos de moneda y ubicación
- [ ] Formatos de número telefónico
- [ ] Formatos de dirección
- [ ] Orden de nombre (nombre dado primero vs apellido primero)

4. Adaptación cultural:

- [ ] Imágenes apropiadas para cultura
- [ ] Colores tienen significado cultural correcto
- [ ] Iconos entendidos en cultura objetivo
- [ ] Ejemplos relevantes a región
- [ ] Sin contenido ofensivo
- [ ] Festividades y celebraciones localizadas

Ejemplos:
- ❌ Emoji de pulgar arriba: Ofensivo en algunos países de Medio Oriente
- ❌ Rojo: Suerte en China, peligro en países occidentales
- ❌ Búho: Sabiduría en Occidente, mala suerte en algunas culturas asiáticas
- ❌ Direcciones de ejemplo: Usar formato local y nombres de ciudad reales

5. Funcionalidad específica de locale:

- [ ] Métodos de pago locales soportados
- [ ] Opciones de envío locales disponibles
- [ ] Cálculo de impuestos locales
- [ ] Cumplimiento legal local (GDPR, CCPA, etc.)
- [ ] Información de contacto local
- [ ] Horas de soporte al cliente local

6. Testing RTL (Right-to-Left):

Para árabe, hebreo, persa:
- [ ] Texto fluye de derecha a izquierda
- [ ] Layout se refleja correctamente
- [ ] Iconos se reflejan donde sea apropiado
- [ ] Formularios se alinean correctamente
- [ ] Tablas se leen de derecha a izquierda
- [ ] Barras de scroll en lado correcto
- [ ] Menú de navegación invertido

Herramientas de testing:

  • Pseudolocalización: Probar i18n sin traducciones reales

    Inglés: "Save Changes"
Pseudo: "[§Śàvè Çĥàñĝèś Ţèśţ Éẋţŕà Çĥàට]"

Beneficios:
- Muestra strings no traducidas
- Prueba expansión de texto
- Encuentra issues de codificación
- No necesidad de conocer idioma objetivo

  • Gestión de traducción: Crowdin, Lokalise, Phrase

  • Testing automatizado: Verificar traducciones faltantes, consistencia de claves

  • Hablantes nativos: Siempre involucrar para validación final

Mejores Prácticas de Localización

✓ Planificar para i18n desde el día uno
✓ Externalizar todos los strings
✓ Usar ICU MessageFormat para strings complejos
✓ Probar con hablantes nativos reales
✓ Evitar texto en imágenes
✓ Usar bibliotecas conscientes de locale
✓ Documentar contexto de traducción
✓ Implementar localización continua
✓ Probar temprano y frecuentemente
✓ Considerar diferencias culturales más allá del idioma

Accessibility Testing: Diseño Inclusivo

Entendiendo Accesibilidad

Definición: Accesibilidad asegura que personas con discapacidades puedan percibir, entender, navegar e interactuar con el software.

Quién se beneficia de la accesibilidad:

  • 15% de la población global tiene alguna forma de discapacidad
  • Discapacidades permanentes: Ceguera, sordera, impedimentos motores
  • Discapacidades temporales: Brazo roto, infección ocular
  • Limitaciones situacionales: Luz solar brillante, ambiente ruidoso, manos ocupadas

Caso legal y de negocio:

Requisitos legales:
- ADA (Americans with Disabilities Act)
- Sección 508 (gobierno US)
- EN 301 549 (UE)
- Posibles demandas por incumplimiento

Beneficios de negocio:
- Mayor alcance de mercado
- Mejor SEO (accesibilidad se superpone con SEO)
- Usabilidad mejorada para todos los usuarios
- Responsabilidad social corporativa
- Motor de innovación

Guías WCAG 2.1

Web Content Accessibility Guidelines (WCAG) 2.1 organizadas alrededor de cuatro principios:

1. Perceptible

La información debe ser presentable a usuarios de formas que puedan percibir.

1.1 Alternativas de texto:

<!-- Imágenes -->
<img src="chart.png" alt="Ventas aumentaron 25% en Q4">

<!-- Imágenes decorativas -->
<img src="decorative-line.png" alt="">

<!-- Imágenes complejas -->
<img src="complex-chart.png"
     alt="Gráfico de barras mostrando ventas trimestrales"
     longdesc="sales-data.html">

<!-- Iconos con texto -->
<button>
  <svg aria-hidden="true">...</svg>
  <span>Eliminar</span>
</button>

<!-- Iconos sin texto -->
<button aria-label="Eliminar artículo">
  <svg aria-hidden="true">...</svg>
</button>

1.2 Medios basados en tiempo:

Contenido de video:
- [ ] Subtítulos para usuarios sordos
- [ ] Descripciones de audio para usuarios ciegos
- [ ] Transcripción disponible

Contenido de audio:
- [ ] Transcripción disponible

1.3 Adaptable:

<!-- Estructura de encabezado apropiada -->
<h1>Título Principal</h1>
  <h2>Sección 1</h2>
    <h3>Subsección 1.1</h3>
  <h2>Sección 2</h2>

<!-- HTML semántico -->
<nav>...</nav>
<main>...</main>
<aside>...</aside>
<footer>...</footer>

<!-- Listas -->
<ul><!-- Lista no ordenada --></ul>
<ol><!-- Lista ordenada --></ol>

<!-- Tablas -->
<table>
  <thead>
    <tr>
      <th scope="col">Nombre</th>
      <th scope="col">Edad</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Juan</td>
      <td>30</td>
    </tr>
  </tbody>
</table>

1.4 Distinguible:

Contraste de color:
- Texto normal: Relación mínima 4.5:1
- Texto grande (18pt+): Relación mínima 3:1
- Componentes UI: Relación mínima 3:1

Probar contraste:
- Chrome DevTools
- WebAIM Contrast Checker
- Plugin Stark para Figma

No usar solo color:
❌ "Campos requeridos están en rojo"
✓ "Campos requeridos están marcados con asterisco (*)"

Redimensionar texto:
- [ ] Texto puede redimensionarse al 200% sin pérdida de funcionalidad
- [ ] Usar unidades relativas (rem, em) no píxeles fijos

2. Operable

Los componentes de interfaz de usuario deben ser operables.

2.1 Accesible por teclado:

<!-- Todos los elementos interactivos deben ser accesibles por teclado -->

<!-- Elementos nativos son accesibles por teclado por defecto -->
<button>Haz clic</button>
<a href="/page">Enlace</a>
<input type="text">

<!-- Elementos personalizados necesitan tabindex -->
<div role="button" tabindex="0" onKeyPress={handleKey}>
  Botón personalizado
</div>

<!-- Enlace de saltar al contenido principal -->
<a href="#main-content" class="skip-link">
  Saltar al contenido principal
</a>

<main id="main-content">
  ...
</main>

<!-- Prevención de trampa de teclado -->
<!-- Usuarios deben poder navegar lejos de cualquier componente -->

Probar navegación por teclado:

- [ ] Tab a través de todos los elementos interactivos
- [ ] Shift+Tab navega hacia atrás
- [ ] Enter activa botones/enlaces
- [ ] Espacio activa botones/checkboxes
- [ ] Teclas de flecha funcionan en dropdowns/grupos de radio
- [ ] Escape cierra modales/dropdowns
- [ ] Foco visible en todos los elementos
- [ ] Orden de tabulación lógico
- [ ] Sin trampas de teclado

2.2 Tiempo suficiente:

Tiempo ajustable:
- [ ] Usuario puede extender límites de tiempo
- [ ] Usuario puede desactivar límites de tiempo (donde sea posible)
- [ ] Usuario advertido antes de timeout
- [ ] Al menos 20 segundos para extender

Contenido auto-reproducible:
- [ ] Usuario puede pausar/detener/ocultar contenido auto-actualizable
- [ ] Sin auto-reproducción a menos que usuario pueda controlar

2.3 Convulsiones:

- [ ] Nada parpadea más de 3 veces por segundo
- [ ] Sin áreas grandes de parpadeo
- [ ] Efectos parallax pueden deshabilitarse

2.4 Navegable:

<!-- Títulos de página -->
<title>Nombre de Página - Nombre de Sitio</title>

<!-- Landmarks -->
<header role="banner">...</header>
<nav role="navigation" aria-label="Principal">...</nav>
<main role="main">...</main>
<aside role="complementary">...</aside>
<footer role="contentinfo">...</footer>

<!-- Orden de foco -->
<!-- Orden visual debe coincidir con orden DOM -->

<!-- Propósito de enlace -->
❌ <a href="/products">Haz clic aquí</a>
✓ <a href="/products">Ver nuestros productos</a>

<!-- Múltiples formas de encontrar páginas -->
- Búsqueda
- Mapa del sitio
- Menú de navegación
- Breadcrumbs

3. Comprensible

La información y operación deben ser comprensibles.

3.1 Legible:

<!-- Idioma de página -->
<html lang="es">

<!-- Idioma de partes -->
<p>La palabra francesa <span lang="fr">bonjour</span> significa hola.</p>

<!-- Lenguaje claro -->
- Usar lenguaje simple
- Definir jerga
- Expandir abreviaciones
- Proporcionar contenido de nivel de lectura apropiado

3.2 Predecible:

Navegación consistente:
- [ ] Navegación en mismo lugar en cada página
- [ ] Mismos componentes tienen mismas etiquetas

Identificación consistente:
- [ ] Iconos tienen significados consistentes
- [ ] Misma funcionalidad = mismas etiquetas

Al enfocar:
- [ ] Foco no dispara cambios inesperados
- [ ] Modal no se abre al enfocar

Al introducir:
- [ ] Envío de formulario requiere acción explícita
- [ ] Sin navegación automática al seleccionar

3.3 Asistencia de entrada:

<!-- Identificación de error -->
<label for="email">Email *</label>
<input
  type="email"
  id="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<span id="email-error" role="alert">
  Por favor ingresa una dirección de email válida
</span>

<!-- Etiquetas e instrucciones -->
<label for="password">
  Contraseña (mínimo 8 caracteres)
</label>
<input type="password" id="password">

<!-- Prevención de errores -->
- Confirmación para acciones destructivas
- Capacidad de revisar antes de enviar
- Capacidad de deshacer envíos

4. Robusto

El contenido debe ser lo suficientemente robusto para funcionar con tecnologías asistivas.

4.1 Compatible:

<!-- HTML válido -->
- Sin IDs duplicados
- Anidamiento apropiado
- Etiquetas cerradas

<!-- ARIA (Accessible Rich Internet Applications) -->
<!-- Nombre, Rol, Valor deben determinarse programáticamente -->

<button
  role="button"
  aria-label="Cerrar diálogo"
  aria-pressed="false"
>
  ×
</button>

<div
  role="progressbar"
  aria-valuenow="25"
  aria-valuemin="0"
  aria-valuemax="100"
  aria-label="Progreso de carga"
>
  25% completo
</div>

Métodos de Accessibility Testing

1. Testing automatizado:

Herramientas:
- axe DevTools (extensión de navegador)
- Lighthouse (Chrome DevTools)
- WAVE (WebAIM)
- Pa11y (línea de comandos)

Captura ~30-40% de issues:
✓ Falta de texto alt
✓ Contraste de color
✓ Etiquetas faltantes
✓ ARIA inválido
✓ Estructura de encabezados

No captura:
✗ Calidad de orden de foco
✗ Calidad de texto alt
✗ Flujo de navegación por teclado
✗ Experiencia de lector de pantalla
✗ Contexto y significado

2. Testing manual:

Navegación por teclado:
1. Desconectar mouse
2. Navegar usando solo teclado
3. Verificar toda funcionalidad accesible
4. Verificar indicadores de foco
5. Probar orden lógico de tabulación

Testing de lector de pantalla:
- NVDA (Windows, gratis)
- JAWS (Windows, de pago)
- VoiceOver (Mac/iOS, integrado)
- TalkBack (Android, integrado)

Prueba básica de lector de pantalla:
1. Activar lector de pantalla
2. Navegar con atajos de lector de pantalla
3. Verificar todo el contenido anunciado
4. Probar formularios e interacciones
5. Verificar calidad de texto alternativo

3. User testing:

Probar con usuarios reales con discapacidades:
- Usuarios ciegos (lectores de pantalla)
- Usuarios con baja visión (magnificación)
- Usuarios con impedimento motor (solo teclado)
- Usuarios sordos (subtítulos)
- Discapacidades cognitivas (lenguaje claro)

Beneficios:
- Patrones de uso del mundo real
- Descubrir issues que herramientas pierden
- Construcción de empatía
- Insights de innovación

Checklist de Accesibilidad

Fundación:

  • HTML válido y semántico
  • Estructura de encabezado lógica
  • Regiones landmark definidas
  • Skip links proporcionados
  • Título de página describe contenido

Imágenes y Media:

  • Todas las imágenes tienen texto alt
  • Imágenes decorativas tienen alt vacío
  • Imágenes complejas tienen descripciones largas
  • Videos tienen subtítulos
  • Audio tiene transcripciones

Formularios:

  • Todos los inputs tienen etiquetas
  • Campos requeridos indicados
  • Mensajes de error claros y específicos
  • Errores asociados con inputs
  • Fieldsets agrupan inputs relacionados

Teclado:

  • Toda funcionalidad accesible por teclado
  • Indicadores de foco visibles
  • Orden de tabulación lógico
  • Sin trampas de teclado
  • Enlaces de saltar navegación

Color y Contraste:

  • Contraste 4.5:1 para texto normal
  • Contraste 3:1 para texto grande
  • Color no es único indicador
  • Funciona en modo de alto contraste

Tecnología Asistiva:

  • Funciona con lectores de pantalla
  • ARIA usado apropiadamente
  • Regiones live para contenido dinámico
  • Mensajes de estado anunciados

Contenido:

  • Lenguaje simple usado
  • Texto de enlace descriptivo
  • Idioma de página establecido
  • Instrucciones no dependen de forma/tamaño/ubicación

Conclusión

Las pruebas no funcionales no son opcionales—son esenciales para crear software que los usuarios amen y que alcance la audiencia más amplia posible. Cada dimensión que hemos cubierto contribuye a la calidad general del producto:

  • Usability testing asegura que tu software sea intuitivo y agradable de usar
  • Compatibility testing garantiza acceso a través de navegadores, dispositivos y plataformas
  • Localización testing abre mercados globales y muestra respeto cultural
  • Accessibility testing incluye a todos y frecuentemente mejora la experiencia para todos los usuarios

El mejor enfoque es integrar pruebas no funcionales a lo largo del desarrollo, no como una reflexión tardía. Construye accesibilidad en diseños, prueba usabilidad con prototipos, verifica compatibilidad temprano y planifica para localización desde el inicio.

Recuerda: La corrección funcional atrae usuarios, pero la excelencia no funcional los mantiene. En el panorama competitivo del software actual, la experiencia de usuario superior, la accesibilidad universal y el alcance global son los diferenciadores que impulsan el éxito.

Recursos

Usabilidad:

  • Nielsen Norman Group: https://www.nngroup.com/
  • Usability.gov
  • “Don’t Make Me Think” de Steve Krug
  • “The Design of Everyday Things” de Don Norman

Compatibilidad:

  • Can I Use: https://caniuse.com/
  • MDN Web Docs Browser Compatibility
  • BrowserStack, LambdaTest (plataformas de testing)

Localización:

  • Unicode CLDR (Common Locale Data Repository)
  • ICU (International Components for Unicode)
  • Crowdin, Lokalise (plataformas de traducción)

Accesibilidad: