QA Lab

Calidad, bugs y automatización

Calidad / QAQuality assurance

Testing de aplicaciones

Casos de prueba, bugs, automatización y calidad no funcional

QATestingCI/CDBugsNo funcional

Introducción

Recorrido completo de testing: diseño formal de casos de prueba; detección, reproducción y reporte de bugs con evidencia; automatización de una calculadora en Python integrada a un pensamiento de pipeline CI/CD; y evaluación de calidad no funcional (rendimiento, accesibilidad, usabilidad y seguridad).

En este proyecto

Diseño de casos de prueba y tablas de decisión
Bug reporting con evidencia y pasos
Automatización de tests y CI/CD
Calidad no funcional de punta a punta

Recorrido del proyecto

Abrí cada bloque: qué se hizo, cómo se hizo, qué se encontró y las evidencias visuales.

Se diseñó un caso de prueba completo a partir de un caso de uso de e-commerce: un usuario logueado con carrito intenta aplicar un cupón de descuento, solo válido si es mayor o igual a 21 años. El trabajo no se queda en “describir el flujo”: se traduce el caso de uso a variables de prueba, tabla de decisión, casos concretos (TC1–TC4) y un diagrama de flujo que muestra el camino feliz y los alternativos (alerta, reintentos y redirección).

Cómo se hizo

Primero se tabularizó el caso de uso (actores, precondiciones, flujo normal, alternativos y postcondiciones). Luego se identificaron las variables que cambian el comportamiento del sistema —edad, validez del cupón e intentos fallidos— y se eligieron valores representativos (edad menor a 21 / mayor o igual a 21; cupón válido/inválido; intentos 0–2 / 3 o más). Con una tabla de decisión se combinaron condiciones y acciones (aplicar descuento, mostrar alerta, redirigir). Finalmente se documentó en detalle el TC1 (flujo principal) y se dibujó la representación gráfica del flujo.

Qué se encontró

Resultados medibles y observaciones de la evaluación.

Variables críticas del escenario: edad del usuario, validez del cupón y contador de intentos fallidos.
TC1 (camino feliz): cupón correcto + edad mayor o igual a 21 → se aplica descuento y se actualiza el precio del carrito.
TC2: edad mayor o igual a 21 + cupón inválido + menos de 3 intentos → se muestra alerta y no se aplica descuento.
TC3: edad mayor o igual a 21 + cupón inválido + 3 o más intentos fallidos → alerta + redirección a otra página.
TC4: cupón válido pero edad menor a 21 → se muestra alerta (el descuento no se aplica por la regla de edad).
El diagrama de flujo deja explícito el orden de decisiones: primero ingreso de cupón, luego ramas de validez y de edad, con reintentos hasta el límite de tres fallos.

Detalle por pieza

Diagrama de flujo del caso de prueba — cupón válido, edad ≥21, alertas y redirección por intentos

Evidencia visual de este entregable de testing.

Diagrama de flujo del caso de prueba — cupón válido, edad ≥21, alertas y redirección por intentos

Testing exploratorio sobre el e-commerce de AcademyBugs (https://academybugs.com/find-bugs/). Se identificaron dos defectos reales, se documentaron pasos mínimos de reproducción y se armó un reporte formal por bug (título, descripción, esperado vs obtenido, severidad, prioridad y evidencia). El foco no fue solo “encontrar fallas”, sino reportarlas de forma que un desarrollador pueda reproducirlas y corregirlas.

Cómo se hizo

Exploración libre de la tienda de demo → localización de comportamientos anómalos → reducción a una secuencia corta de pasos → reporte estructurado. Para el bug de moneda se aplicó además un análisis de causa raíz con técnica de los 5 porqués, y se propusieron validaciones técnicas (logs, debugging de la función de cambio de moneda, existencia de casos de prueba y cobertura de requisitos).

Qué se encontró

Resultados medibles y observaciones de la evaluación.

Bug #19 — Hot Item (performance): al hacer clic en el producto de la sección “Hot item” (detalle de producto → panel derecho), la página queda en carga infinita. Esperado: ver el producto. Obtenido: spinner/carga que no termina. Severidad mayor; prioridad media (afecta UX pero no bloquea todo el sitio).
Bug #21 — Moneda (funcional/crash): en el detalle de producto, al abrir “Select a currency” y elegir otra moneda, la página se congela (no responde a clics ni scroll). Severidad crítica; prioridad alta (bloquea navegación y flujo de compra).
Ambos se clasificaron conceptualmente como fallas: el usuario las experimenta al interactuar con el sistema (síntoma visible del defecto).
Causa raíz planteada para el bug de moneda: falta de testing temprano y de colaboración entre desarrollo y QA sobre el cambio de moneda (no se validó bien esa función antes de publicarla).
Aprendizajes: un bug tiene que ser reproducible con la menor cantidad de pasos; un mal reporte genera ida y vuelta y bugs sin resolver; el análisis de causa raíz ataca el origen, no solo el síntoma.

Detalle por pieza

Evidencia Bug #19 — Hot Item en carga infinita

Evidencia visual de este entregable de testing.

Evidencia Bug #19 — Hot Item en carga infinita

Evidencia Bug #21 — congelamiento al cambiar moneda

Evidencia visual de este entregable de testing.

Evidencia Bug #21 — congelamiento al cambiar moneda

Se construyó una calculadora básica en Python (sumar, restar, multiplicar, dividir con manejo de división por cero) y se automatizaron 4 casos de prueba con pytest. Esos tests se integraron a un pipeline de GitHub Actions que corre en cada push: instala dependencias, ejecuta la suite, genera reporte HTML y lo publica como artefacto. El objetivo fue pasar de “probar a mano” a feedback automático y repetible.

Cómo se hizo

1) Definir el escenario y la tabla de casos (feliz, error, borde). 2) Implementar tests unitarios con pytest cubriendo suma exitosa, división por cero, resta con negativos y multiplicación por negativo. 3) Configurar workflow de GitHub Actions (install → pytest → HTML report → upload artifact). 4) Validar con un push real y analizar resultados + reflexión sobre calidad y dificultades de setup.

Qué se encontró

Resultados medibles y observaciones de la evaluación.

Módulo bajo prueba: sumar(a,b), restar(a,b), multiplicar(a,b), dividir(a,b) — esta última lanza ZeroDivisionError con mensaje “No se puede dividir por cero” si b = 0.
TC01 suma 5+3 → 8 (PASSED).
TC02 dividir(10,0) → excepción ZeroDivisionError esperada (PASSED).
TC03 restar(-5, 3) → -8, caso borde con negativos (PASSED).
TC04 multiplicar(4, -2) → -8 (PASSED).
Los 4 tests pasaron en el pipeline de GitHub Actions; cada push re-valida el comportamiento y reduce el riesgo de regresión.
Ventaja del CI: feedback rápido, ejecución consistente y menos errores humanos que en pruebas solo manuales.
Dificultad principal: configurar el YAML para que Python resuelva módulos por carpetas y generar el reporte HTML como artefacto.
Mejoras futuras planteadas: más tests (floats/decimales) y evitar push directo a main (branch + merge solo si el pipeline está verde).

Detalle por pieza

Código de la calculadora bajo prueba

Evidencia visual de este entregable de testing.

Código de la calculadora bajo prueba

Tests automatizados con pytest

Evidencia visual de este entregable de testing.

Tests automatizados con pytest

Ejecución exitosa de la suite / evidencia

Evidencia visual de este entregable de testing.

Ejecución exitosa de la suite / evidencia

Pipeline GitHub Actions — workflow

Evidencia visual de este entregable de testing.

Pipeline GitHub Actions — workflow

Pipeline — jobs y artefactos del reporte

Evidencia visual de este entregable de testing.

Pipeline — jobs y artefactos del reporte

Evaluación no funcional del portal de noticias Clarín (clarin.com): rendimiento (PageSpeed Insights), accesibilidad (WAVE), usabilidad exploratoria y seguridad (HTTPS, headers, consola, SSL). El sistema “funciona” para leer noticias, pero el análisis mostró deficiencias claras en performance, a11y y postura de seguridad, priorizadas en un informe de hallazgos y un informe ejecutivo.

Cómo se hizo

Se eligió Clarín por ser un sitio real de alto tráfico y muchas secciones. Se midió performance con PageSpeed Insights; accesibilidad con WAVE; usabilidad con inspección exploratoria (navegación, diseño, consistencia, publicidad); y seguridad con candado HTTPS, Security Headers, consola del navegador y SSL Server Test. Los resultados se consolidaron en una tabla de hallazgos (categoría, severidad, evidencia, recomendación) y un cierre ejecutivo con riesgos y prioridades.

Qué se encontró

Resultados medibles y observaciones de la evaluación.

Rendimiento (PageSpeed): score 51/100 — “necesita mejora”. Speed Index 6.6 s; LCP 2.1 s; FCP 1.1 s; CLS 0.02; INP 114 ms. El problema fuerte es el Total Blocking Time ~8740 ms: la página tarda en volverse interactiva.
Diagnósticos de performance: JS/CSS no usado (ahorro potencial de más de 2 MB de JS), imágenes no optimizadas (más de 2 MB), recursos que bloquean el render y prácticas recomendadas bajas (31/100), con mixed content detectado.
Accesibilidad (WAVE): 30 errores + 34 de contraste + 110 advertencias. Entre los errores: 8 missing form label, 2 empty form label, 1 multiple form labels, 18 botones vacíos y 1 link vacío. Advertencias frecuentes: alt redundantes o largos, posibles encabezados y textos muy chicos.
Impacto de accesibilidad: lectores de pantalla se ven afectados por botones/links vacíos y labels faltantes; el bajo contraste y los textos chicos perjudican a usuarios con baja visión.
Usabilidad: el menú es claro y la identidad visual es bastante consistente, pero el diseño está muy cargado, hay mucha publicidad (a veces similar a una noticia) y poco respiro visual; falta un buscador por palabras clave.
Seguridad: HTTPS con certificado válido y validaciones básicas en el login. A la vez: mixed content y errores de scripts de ads/Google en consola; faltan headers de seguridad importantes; el servidor expone información de stack (p. ej. versión de ASP.NET).

Conclusión

Cierre y prioridades

Clarín funciona a nivel funcional (navegar y leer noticias), pero las pruebas no funcionales muestran que la calidad percibida y la confianza del usuario se ven afectadas por lentitud, barreras de accesibilidad y una postura de seguridad débil. El cierre del trabajo prioriza qué atacar primero y por qué.

Severidad alta a priorizar: performance baja + TBT alto; 30 errores de accesibilidad críticos (botones vacíos / labels); headers de seguridad faltantes.
Severidad media: 34 errores de contraste; publicidad que se confunde con noticias y diseño sobrecargado.
Riesgos de negocio: abandono por lentitud (sobre todo en picos de tráfico), exclusión de usuarios con discapacidad, y daño reputacional si el sitio se percibe inseguro.
Recomendación final: corregir primero los hallazgos de severidad alta (seguridad + rendimiento + a11y crítica), después la UX de publicidad/diseño, y volver a medir con las mismas herramientas para validar la mejora.
Próximo paso posible: extender la evaluación no funcional a la tienda u otros sitios del ecosistema Clarín.