QEvolution

El mayor problema de calidad en tu equipo no es técnico. Es cultural. Puedes tener Playwright, Cypress, k6 y una pipeline de CI/CD impecable. Y aun así tener bugs en producción cada semana. ¿Por qué? Porque si solo el equipo de QA se preocupa por la calidad, has perdido antes de empezar. Siempre de identifica el mismo patrón. Los equipos no fallan por falta de herramientas. Fallan porque la calidad es "cosa de QA". Esto se puede medir en 5 etapas: → Etapa 1 - Caótica: No hay proceso. Cada deploy es un acto de fe. La frase típica: "en mi máquina funciona". → Etapa 2 - Reactiva: QA aparece al final del sprint. Tests manuales, sin CI. Los bugs se trackean, pero siempre tarde. "Eso no era mi bug." → Etapa 3 - Estructurada: Hay tests escritos, CI básico y QA con rol definido. Mejora... pero las regresiones siguen apareciendo porque el problema se detecta tarde. → Etapa 4 - Preventiva: Shift-left real: los devs escriben tests, los criterios de aceptación incluyen calidad, QA y dev colaboran desde el inicio. Aquí la cosa cambia. → Etapa 5 - Cultura: Nadie pregunta "¿quién testea esto?". QA es un enabler, no un filtro. La calidad está integrada en cómo trabaja todo el equipo, sin silos. La mayoría de los equipos suelen estar entre la 2 y la 3. El salto a la 4 y 5 no requiere más herramientas. Requiere cambiar quién se hace responsable de la calidad. El diagnóstico rápido: → ¿Tu equipo debate criterios de aceptación antes de escribir código? → ¿Los devs revisan los tests como parte del code review? → ¿Tienes una métrica de calidad que el equipo mira cada semana? ¿En qué etapa está tu equipo ahora mismo? Os leemos 👇

¿Sabes realmente en qué nivel de madurez está vuestro equipo de QA? No el que creéis. El que sale cuando alguien pregunta cómo participáis en el ciclo de desarrollo, qué cubre vuestra estrategia de testing, o qué métricas usáis para medir calidad real. La mayoría de equipos lo intuyen. Pocos lo saben con criterio. Hemos lanzado QAssessment: una skill gratuita para hacer ese diagnóstico en 5 minutos, directamente desde vuestro asistente de IA (Claude Code, Cursor, Copilot, Windsurf...). Sin formularios. Sin reuniones. Solo 12 preguntas conversacionales que cubren lo que importa: → Cultura de calidad y ownership → Estrategia de testing y cobertura → Automatización y herramientas → CI/CD e integración en las pipelines → Monitorización y respuesta a incidentes → Quality Engineering vs. testing tradicional Al terminar obtenéis un nivel L1–L5, un radar visual con vuestras fortalezas y debilidades, además de 3 recomendaciones concretas para mejorar. Es freemium: (https://lnkd.in/egTtg92T). Para instalarlo ejecuta: npx skills add qevolution/qassessment ¿En qué dimensión creéis que vuestro equipo tiene más margen de mejora? #QualityEngineering #QA #SoftwareTesting #QAMaturity #Qevolution

Manual vs. automatización es la pregunta equivocada. La pregunta que importa es: ¿qué estamos intentando proteger?                                                                                                                         Hemos visto equipos con el 90% de cobertura automatizada que siguen sin detectar los bugs más críticos. Y equipos con testing mayoritariamente manual con productos impecables en producción.                                                                                                                                              La diferencia no está en la herramienta. Está en la decisión estratégica detrás de cada prueba.  Tiene sentido automatizar cuando:  → Son flujos que se ejecutan varias veces al día  → Las regresiones tienen patrones repetibles y estables  → El error humano tiene un coste alto y medible                                                                                                                       No tiene sentido cuando:                                                                                                → La funcionalidad cambia cada sprint                                                             → Necesitas criterio humano para evaluar la experiencia real del usuario  → El coste de mantenimiento supera el beneficio obtenido El mayor desperdicio que seguimos viendo: equipos que automatizan todo lo que pueden, en lugar de todo lo que deben. Automatizar mal es peor que no automatizar. Y no automatizar nada tampoco es la solución. La estrategia importa más que la herramienta.                                                                                                  ¿Cuál es el error de automatización más frecuente que habéis visto en un equipo?                                                                                   #QualityEngineering #TestAutomation #QA #SoftwareTesting #CalidadDeSoftware

Ojo al post de Brais Moure. Tras leerlo nos surge una pregunta: ¿estamos entrando en la era del "ya pillará otro el bug", o esta actitud siempre estuvo ahí y simplemente no quisimos verlo? Nuestra opinión: Siempre estuvo ahí, pero ahora se nota más. Y la vuestra, ¿cuál es? ¡Os leemos! 👇

Francisco Moreno Sanz publicó hace unos días en su Substack una conversación con Manfred sobre el futuro del QA que merece ser leida.                                                      La tesis central: el mercado se va a polarizar. Los roles de testing funcional y automatización básica van a desaparecer. Lo que queda son perfiles mucho más estratégicos: quienes construyen ecosistemas de calidad, quienes saben validar sistemas de IA, quienes transfieren criterio al equipo entero.                                                                                                    Es probable que menos QAs, pero con mucho más peso.                                     Una pregunta clave que nos hacemos es quién está ayudando hoy a los equipos a hacer esa transición. Porque el destino está claro. El camino, mucho menos.                                                            ¿Vuestro equipo tiene un plan para evolucionar hacia ahí, o se está esperando a que el mercado decida?                                                       🔗 Link en comentarios.                                            #QualityEngineering #QA #FuturoDelQA #QALeadership #SoftwareTesting

¿𝗤𝗔 𝗺𝗶𝗹𝗮𝗴𝗿𝗼𝘀𝗼 𝗼 𝗤𝗔 𝗘𝘃𝗼𝗹𝘂𝘁𝗶𝘃𝗼? Haz el test: 👇 · ¿Crees que tienes un sexto sentido para los bugs que el resto de los mortales no posee? · ¿Te has convertido en el "pope" que da la bendición final antes de subir a producción? · ¿Le pides a la IA que piense por ti porque "ella sabe más"? Si has respondido 𝗦𝗜 a al menos una de estas preguntas, déjanos decirte que... estás viviendo en el pasado. 🦖 Ese no es el camino. En la era de la entrega continua y la IA estratégica, el QA no es un mago místico al final del sprint; es una disciplina que debe impregnar cada línea de código desde el minuto uno. Si tu valor se limita a encontrar errores cuando ya es tarde (y caro) arreglarlos, no estás asegurando la calidad, solo estás retrasando el inevitable incendio. 𝗖𝘂𝗲𝗻𝘁𝗮𝗻𝗼𝘀 ¿Eres de los que previene el incendio o de los que espera a que todo arda para aparecer con el extintor?

La cobertura de código nunca fue una métrica perfecta. Con IA, se ha vuelto circular. Si la IA genera el código y el equipo le pide que genere los tests para ese código, ¿qué estás midiendo exactamente?. Seguramente que la propia IA sea consistente consigo misma. No que el producto funciona como debería. Las métricas que usamos en QA llevan décadas midiendo la misma cosa: ¿hemos comprobado lo que hemos construido? Con IA, la pregunta que nadie está haciendo todavía es otra: ¿deberíamos haber construido esto? Las métricas del futuro no van a medir cobertura de código. Deben medir criterio: cuántas decisiones de la IA fueron validadas por un humano antes de llegar a producción, qué porcentaje del output fue cuestionado, cuántos casos límite identificó el equipo que la IA no vio. Eso no tiene dashboard todavía. Pero los equipos que estén ya pensando qué medir y construyéndolo, van a tener una ventaja real a futuro.  ¿Vuestro equipo sigue midiendo cobertura, o ya estáis pensando en qué métricas tienen sentido en un flujo con IA?  #QualityEngineering #QEvolution #SoftwareTesting #QA #QAMetrics

Cinco recursos de IA para equipos técnicos que merecen tu tiempo. → Playwright Best Practices Skill — Una skill de Claude especializada en Playwright. Para equipos que ya automatizan con Playwright, es ahorro de tiempo desde el primer día. → AGENTS.md (Addy Osmani) — Cuándo tiene sentido crear un fichero de contexto para tus agentes de IA y cuándo no. Vale la pena leerlo antes de configurar el siguiente. → Skills de Claude — La plataforma skills.sh permite instalar y crear skills especializadas para Claude. Si vuestro equipo trabaja en QA, podéis tener un asistente que ya conoce vuestro contexto desde el primer prompt. → Presidio (Microsoft) — Si trabajáis con IA y datos reales de usuarios, Presidio anonimiza la información sensible antes de que llegue al modelo. No es opcional si hay PII en juego. → Anthropic Skilljar — La formación oficial de Anthropic. Sin hype, bien estructurada. Buen punto de entrada para entender qué puede hacer Claude y qué no. Links en el primer comentario 👇 ¿Cuál de estos cinco conecta más con el problema que tenéis ahora mismo en vuestro equipo? #QualityEngineering #QEvolution #ClaudeAI #SoftwareTesting #QA

Tras revisar el State of Code 2026 de Sonar — 1.149 desarrolladores encuestados — tres datos que si trabajas en QA, no puedes ignorar. 1. La IA crea un nuevo cuello de botella de verificación. El 96% no confía plenamente en el código que genera la IA. Solo el 48% lo revisa siempre antes de hacer commit. La velocidad subió. El proceso de verificación no se movió. 2. La deuda técnica no desaparece. Muta. El tiempo improductivo sigue siendo el 24% de la semana laboral, uses IA constantemente o no. El 88% ya ha notado al menos un impacto negativo. El trabajo pesado cambió de cara: antes era código legacy sin documentar, ahora es código generado por IA que parecía correcto. 3. La habilidad más valorada no es hacer prompts. Es saber si lo que generó la IA vale algo. El 47% señala "revisar y validar código generado por IA" como la competencia más crítica. Por encima de dominar herramientas. Por encima de escribir buenos prompts. Los tres puntos dicen lo mismo con datos distintos: la IA amplifica lo que ya tienes. Si tienes cultura de calidad, la multiplica. Si no la tienes, multiplica los problemas. ¿Cuál de estos tres puntos describe mejor la situación de vuestro equipo ahora mismo? #QualityEngineering #QEvolution #SoftwareTesting #StateOfCode #QA

El vibe coding va a crear la primera generación de software que nadie entiende del todo. Y con ella, el primer tipo de bug que nadie sabe si es un bug. Cuando el código se genera describiendo lo que quieres y dejando que la IA lo construya, pasan tres cosas que el testing tradicional no está diseñado para manejar: 1️⃣ El developer aprueba código que funciona pero no puede explicar. 2️⃣ El tester valida comportamiento visible, no intención original. 3️⃣ El bug reportado responde a "¿qué hace?" pero no a "¿qué debería hacer?" El testing siempre asumió que alguien en el equipo sabía lo que se quería construir. El vibe coding puede romper esa premisa. El mayor riesgo de calidad en 2026 no va a ser el código que falla. Va a ser el código que funciona perfectamente, hace exactamente lo que se le pidió, y nadie recuerda por qué se pidió así. En ese escenario, el rol más valioso no es el que ejecuta tests. Es el que hace la pregunta que detiene la demo: "¿Esto es lo que necesitábamos realmente?" QA no desaparece con el vibe coding. Se convierte en la persona del equipo que cuestiona si lo que se construyó tiene sentido. ¿Vuestro equipo tiene a alguien con ese "superpoder"? #QualityEngineering #VibeCoding #AIinQA #SoftwareTesting #QA