Curiosidades QA — Día 6 de 7 Esta semana publico una curiosidad por día sobre el mundo del testing y la calidad de software. Ver la serie completa →
“Ship it with bugs” no es un meme
Minecraft vendió más de 300 millones de copias. Es el videojuego más vendido de la historia. También es uno de los productos con más bugs conocidos que nunca se han arreglado.
Y nadie lo usa menos por eso.
GTA V lleva más de una década en el mercado y cada actualización corrige cientos de bugs que estaban ahí desde el lanzamiento. Skyrim salió en 2011 con una lista pública de bugs tan larga que los fans la mantienen en una wiki.
Todos fueron éxitos masivos.
El dato que rompe todas las reglas de QA
En tu formación como QA te enseñan:
- Todo bug debe arreglarse antes de salir
- Un producto con bugs conocidos no está listo
- La calidad es no permitir defectos
Y después miras a la industria de los videojuegos — que mueve más dinero que Hollywood y la música juntos — y descubres que nadie sigue esas reglas.
¿Entonces están haciendo todo mal? No.
Están haciendo algo que la mayoría de la industria de software ignora: diferencian entre bugs que importan y bugs que no.
La matriz que nadie te enseña
Los equipos de QA en videojuegos tienen una matriz mental que funciona así:
¿El bug afecta la experiencia central del juego? Si Minecraft no te deja construir, es crítico. Si un pixel parpadea en el agua cuando miras desde cierto ángulo en un bioma específico, puede esperar.
¿El bug bloquea la progresión? Si no puedes avanzar de nivel, es crítico. Si un NPC dice la misma línea dos veces en una side quest opcional, puede esperar.
¿El bug corrompe los datos del usuario? Si pierde su progreso guardado, es crítico. Si un item aparece invertido en el inventario, puede esperar.
¿El bug es explotable para hacer trampa? Si rompe el balance competitivo online, es crítico. Si puedes glitchear a través de una pared en modo single player, puede esperar (y a veces se vuelve parte de la cultura del juego).
Esto es criterio. No es falta de calidad — es definir qué significa “calidad” para ese producto específico.
Dato real: el equipo de QA de Rockstar (GTA V) mantiene una base de datos con más de 100,000 bugs reportados a lo largo de los años. La mayoría nunca se arreglaron porque no afectaban la experiencia. Y el juego sigue siendo uno de los más exitosos de la historia.
Lo que puedes aprender de la industria de juegos
Si solo miras la industria de software “seria” (banca, salud, enterprise), vas a creer que todo bug es crítico y todo atraso es inaceptable. Es una visión limitada.
Los videojuegos te enseñan 3 cosas que deberías aplicar:
1. El costo de oportunidad existe
Cada semana que retrasas el lanzamiento por bugs menores es una semana sin ingresos, sin feedback de usuarios reales, sin aprendizaje. Minecraft no sería Minecraft si hubieran esperado a tener todos los bugs arreglados.
2. El usuario tolera bugs en funciones secundarias
Si el core funciona bien, el usuario perdona mucho. Lo que no perdona es que la función principal falle. Gmail ha tenido bugs en el selector de colores de etiquetas por años. Nadie se fue de Gmail por eso.
3. Algunos bugs se convierten en features
El “rocket jumping” de Quake empezó como un bug. La “wave dash” de Super Smash Bros también. Los jugadores amaron el “error” tanto que los desarrolladores decidieron mantenerlo. En software serio esto pasa menos, pero sucede.
La conversación incómoda
Ahora la parte difícil. Si los videojuegos pueden salir con 40 bugs, ¿por qué tu banca en línea no puede?
Porque el contexto es diferente:
- Reversibilidad: si un bug en un juego te hace perder 30 minutos, es molesto. Si un bug en tu banco te hace perder $500, es irreversible.
- Expectativa del usuario: el jugador sabe que los bugs son parte de la experiencia. El cliente bancario espera perfección.
- Costo de fallar: un bug crítico en un juego te puede costar un parche. Un bug crítico en salud puede costar vidas.
Pero incluso en software “serio” hay bugs que no importan. El botón del logo se corre 2 píxeles en un navegador específico en una resolución poco común. Un email llega 30 segundos más tarde de lo planeado. El ícono de carga hace un micro-salto al cargar.
Arreglar esos bugs tiene un costo. Dejarlos tiene un costo diferente. Tu trabajo como QA no es eliminarlos todos — es ayudar al equipo a decidir cuáles importan en tu contexto específico.
La reflexión
Si estás aprendiendo QA, probablemente te enseñaron que tu trabajo es decir “no” hasta que todo funcione. Es un buen punto de partida, pero es incompleto.
El trabajo real de un QA maduro es decidir qué bugs importan y cuáles no — y ser capaz de defender esa decisión con datos y contexto. No con miedo a equivocarte.
Los videojuegos más exitosos de la historia no salieron porque estuvieran perfectos. Salieron porque alguien, en algún momento, dijo: “esto está lo suficientemente bien para que valga más entregarlo que perfeccionarlo”.
Esa es la conversación más difícil que vas a tener en tu carrera. Y es la que más vas a tener.
Mañana: ¿Sabes cuál es el QA más caro del mundo? Testea aviones, no software. → Día 7