Ezequiel Canello

Ezequiel Canello 🎮 Game Tester y jugador apasionado
🔍 Analizo videojuegos desde adentro 💻Desarrollador y Programador.

09/04/2026

⚠️¿Los bugs más peligrosos son los que crashean el juego?

Por lo general si, pero también son muy peligrosos aquellos bugs que, parecen inofensivos, hasta que explotan💥

Después de testear decenas de proyectos, aprendí que hay 3 tipos de bugs que siempre causan más daño del que aparentan. Y la mayoría de los equipos los ignoran porque "no son prioridad ahora"🚧

1️⃣BUGS DE PROGRESIÓN SILENCIOSOS🔒
Son bugs que no rompen el juego la mayoría de las veces. Solo bajo condiciones específicas.
Ejemplo: Un checkpoint que guarda progresión el 95% de las veces. Pero si el jugador hace X acción antes de llegar, no guarda. Y el jugador pierde horas de progreso.

Son peligrosos porque son difíciles de reproducir en testing normal.
Los jugadores SÍ los encuentran (porque juegan de formas impredecibles).
Generan frustración masiva y refunds.
Las reviews negativas son devastadoras.📉

2️⃣ BUGS DE PERFORMANCE PROGRESIVOS🐌
El juego arranca bien. Después de 30 minutos, empieza a ir más lento. Después de 1 hora, es injugable⏰
Ejemplo: Memory leaks, objetos que no se destruyen, partículas que se acumulan🧩.

Son peligrosos porque no se detectan en sesiones cortas de testing.
Los jugadores solo los ven después de jugar varias horas.
Para cuando lo reportan, ya dejaron review negativa.
Son técnicamente complejos de arreglar tarde🔧

3️⃣ BUGS DE INTERACCIÓN ENTRE SISTEMAS🧬
Cada sistema funciona perfecto individualmente. Pero cuando interactúan, se rompe todo.
Ejemplo: El sistema de combate funciona. El sistema de inventario funciona. Pero usar un ítem durante combate crashea el juego.

No aparecen testeando sistemas aislados, aparecen en situaciones reales de juego.
Son difíciles de diagnosticar (¿es combate? ¿es inventario? ¿es la interacción?)
Requieren refactoring profundo para arreglar🛠️

Estos 3 bugs tienen en común lo siguiente:

Parecen menores cuando los encontrás.
Son fáciles de postergar ("lo vemos después").
Se vuelven críticos cuando llegan a usuarios.
Generan el peor tipo de feedback: frustración del jugador.

Por eso el QA preventivo es tan importante. ya que identificar este tipo de bugs es crucial para el desarrollo⚠️

Cuando trabajo con equipos, categorizo bugs no solo por gravedad actual, sino por riesgo de impacto futuro. Así priorizamos arreglar lo que realmente importa antes de que sea tarde📊.

07/04/2026

🐞Encontrar bugs es fácil, pero comunicarlos sin generar fricción es un arte.
Y es algo que nadie te enseña cuando empezás en QA.

Al principio, yo reportaba bugs de la forma más directa posible. "El sistema de combate está roto", "La UI no funciona bien", "Esto está mal implementado"❌

Técnicamente correcto. Pero terrible para la relación con el equipo, porque cuando un desarrollador lee "esto está roto", lo que muchas veces escucha es "tu trabajo está mal"🚧.
Y aunque no sea la intención, genera defensividad. El dev se pone en modo justificación en vez de modo solución.
Aprendí que la forma de comunicar un bug importa tanto como el bug en si.

En vez de ❌"El sistema de combate está roto" Ahora digo: ✅"Encontré un caso donde el sistema de combate no responde como esperábamos. Creo que puede estar relacionado con X cosa. ¿Tiene sentido revisar esa área?"
Hay una gran diferencia.
La información es la misma y el bug es el mismo, pero el tono cambia drásticamente.

Y no es por ser "suave" o "diplomático", sino que la gracia es entender que del otro lado hay una persona que trabajó horas en ese código, que se esforzó, y que quiere que funcione bien🧠.
Cuando reportás bugs con ese enfoque, pasa algo interesante, el dev no se pone a la defensiva.
Te ve como colaborador, no como "el que encuentra problemas"🤝.
Las correcciones se hacen más rápido (porque no hay fricción)⚡.
La relación con el equipo mejora exponencialmente🚀.

He trabajado con equipos donde el QA anterior generaba tanto conflicto que dejaron de escuchar sus reportes. No porque estuvieran equivocados, sino porque la forma de comunicar los hacía imposibles de recibir🚫.
Un buen QA no solo encuentra bugs. También sabe cómo comunicarlos para que el equipo los reciba bien y los arregle rápido🛠️.

Por eso cuando trabajo con equipos, no solo reporto "hay un bug acá". Explico el contexto, propongo hipótesis, y lo presento como colaboración, no como crítica💬.
Porque al final, todos estamos del mismo lado, hacer que el juego funcione lo mejor posible🎮.

¿Alguna vez tuviste problemas de comunicación con equipos? ¿O al revés, trabajaste con alguien que sabía comunicar feedback difícil de forma constructiva?

02/04/2026

👤Una sombra flotante que casi llega a la demo pública.

Mientras trabajaba como QA para Kronos Interactive en Echoes From Ciudadela, me encontré con algo extraño entre ciertas cinemáticas🎮.

Todo parecía andar normal, hasta que miré al suelo y noté que, la sombra del personaje había desaparecido.
Solo se veía la sombra de la honda baleárica que se sostiene en la mano. Flotando, moviéndose sola, sin cuerpo.
A simple vista, parece un detalle menor, ya que no rompe el juego. No bloquea progresión y mucho menos crashea nada. Solo es... raro 🔍.

Pero ese "detalle menor" hace que el juego se vea poco profesional. Rompe la inmersión y le dice al jugador "algo acá no está del todo bien".

¿Por qué es relevante este tipo de bug?🎯
Porque bugs visuales como este no aparecen testeando mecánicas aisladas. Aparecen cuando testeas flujos completos, como de una cinemática hasta el gameplay, o de una transición hasta una cinemática.
Si solo testeás "el personaje camina bien" o "la honda funciona bien", nunca lo ves. Pero si jugás el flujo real que va a vivir el usuario, ahí aparece🧩.
Y lo importante, este tipo de bugs son los que los usuarios si notan y reportan 📢.
No porque rompan el juego, sino porque rompen la experiencia🎨.

En este caso, se detectó y se arregló antes de que la demo saliera públicamente. Los jugadores nunca lo vieron. Pero si no se hubiera testeado ese flujo específico, habría llegado a la demo del día 1.
Y cuando ocurre eso, se corre el riesgo de que aparezca en foros, reviews o clips de diversas índoles. No es crítico, pero sí es profesionalismo🛡️.

Por eso el QA no es solo "encontrar bugs graves". Es asegurar que nada raro llegue a tus usuarios, ni siquiera lo que parece menor🔧.

Si estás desarrollando un juego y querés detectar este tipo de bugs antes de que lleguen a tus jugadores, escribime "SOMBRA" por privado y vemos cómo lo manejamos.

31/03/2026

⚡Existen dos tipos de QA. Reactivo y preventivo.
Y la mayoría de los equipos hace reactivo sin darse cuenta.

QA reactivo es esto:
Desarrollás features durante semanas. Cuando está "listo", buscás bugs. Encontrás problemas graves. Frenas desarrollo para arreglarlos. Volvés a desarrollar. Repetís el ciclo.🔄
Funciona. Pero es agotador, y caro.

QA preventivo es esto:
Mientras desarrollás, alguien va testeando en paralelo. Detecta bugs cuando todavía son simples. Los arreglás en minutos, no en días. Nunca tenés que frenar desarrollo de forma crítica. Llegás al lanzamiento sin sorpresas🛡️

La diferencia no es cuántos bugs encontrás, es CUÁNDO los encontrás⏰.
Hay equipos que trabajan de manera reactiva durante meses, y todo parece ir bien, pero cuando llega el momento de "pulir para lanzar", se dan cuenta que tienen bugs de integración que vienen desde hace semanas🧩.
Problemas de performance que nadie vio💥.
Edge cases que rompen progresión🚧.
Features que no interactúan bien entre sí⚠️.
Y ahí empieza el pánico.

Arreglar bugs a último momento significa:
Tocar código que se modificó mil veces. Riesgo de romper otras cosas al arreglar. Presión extrema sobre el equipo. Decisiones difíciles "¿retrasamos o lanzamos con bugs?"
Todo eso se evita con QA preventivo🛠️.
Y la mejor manera de preveer eso es testear mientras se construye.
Es la diferencia entre revisar los cimientos mientras construís la casa y esperar a terminar la casa para ver si los cimientos aguantan.

QA reactivo apaga incendios. QA preventivo evita que haya incendios.
Por eso cuando trabajo con equipos, no espero a que "esté listo" para empezar a testear. Empiezo desde el inicio, en paralelo con desarrollo, para detectar problemas cuando todavía son baratos de arreglar⚡.

Si estás desarrollando en modo reactivo (esperando a "terminar" para testear), escribime "PREVENTIVO" por privado y coordinamos una llamada corta para ver cómo cambiar el enfoque.

¿Trabajás en modo reactivo o preventivo? ¿Alguna vez tuviste que apagar incendios de último momento?

26/03/2026

🔍 Hay una diferencia enorme entre reportar un bug y entender POR QUÉ ocurrió.

Y esa diferencia separa un QA básico de uno que realmente agrega valor al equipo.
Cualquiera puede decir "esto no funciona". Pero un buen QA dice "esto no funciona porque..."🛠️.
Hay reportes que dicen: "El personaje se traba cuando salta cerca de la pared".
Está bien. Es un bug, reportado. Pero le falta contexto.

Un reporte que agrega valor dice algo así:
"El personaje se traba cuando salta cerca de la pared solo si está en movimiento lateral antes del salto. Probé saltando desde quieto y no pasa. Probé con diferentes velocidades de movimiento, y el bug aparece solo cuando la velocidad supera cierto umbral. Creo que está relacionado con la detección de colisión lateral durante el estado de salto".
Hay una gran diferencia.

El primer reporte te dice QUÉ está roto. El segundo te dice QUÉ está roto y CUÁNDO pasa, BAJO QUÉ CONDICIONES, una hipótesis de POR QUÉ.

¿Y por qué importa esto?
Porque cuando un desarrollador recibe el primer reporte, tiene que:
Reproducir el bug (puede llevar tiempo si no sabe las condiciones).
Investigar qué lo causa (revisar múltiples sistemas).
Testear diferentes escenarios hasta encontrar el patrón.
Eso puede tomar horas🕒.

Cuando recibe el segundo reporte, ya tiene el 70% del trabajo hecho. Sabe exactamente dónde buscar, qué condiciones reproducir, y qué sistema revisar primero🎯.
Eso es lo que diferencia un QA que "encuentra bugs" de un QA que "facilita el desarrollo".
Es importante entender cómo interactúan los sistemas, qué puede estar causando el problema, y darle al desarrollador toda la información que necesita para arreglarlo rápido.

Por eso cuando trabajo con equipos, no solo les digo "hay un bug acá". Les explico el contexto, las condiciones, y mi hipótesis de causa. Así el equipo puede arreglar bugs en minutos en vez de horas⏰.

¿Alguna vez recibiste un reporte de bug tan completo que te facilitó el trabajo? ¿O al revés, tan vago que te costó horas entender qué pasaba?

24/03/2026

💸"Ahora no tenemos presupuesto para QA. Lo metemos cuando estemos cerca del lanzamiento."

Escucho esto todo el tiempo en equipos chicos e indies. Y lo entiendo. Hay presupuesto limitado, features por terminar. Entonces, "el QA puede esperar".
El problema es que QA al final no es QA, es bombero🔥.
Porque cuando esperás hasta estar cerca del lanzamiento para meter QA, pasa esto.

1. Los bugs ya se multiplicaron💥. Lo que era un error simple en la semana 5 ahora está en 10 lugares diferentes. Arreglarlo requiere tocar código que se modificó mil veces desde entonces.
2. No hay tiempo para iterar⏰. Si encontramos bugs graves dos semanas antes del lanzamiento, ¿qué hacés? ¿Retrasás el lanzamiento? ¿Lanzás con bugs? Ambas opciones salen carísimas.
3. El equipo está al límite 🚧. Cuando estás cerca del lanzamiento, todos están apurados. Features que faltaban, marketing, logística. Nadie tiene tiempo mental para arreglar bugs profundos. Y se hace mal, rápido, y genera más bugs.
4. No podés validar las correcciones⚠️. Arreglás un bug crítico, pero ¿cómo sabés que no rompiste otra cosa? No hay tiempo para testing regresivo. Lanzás esperando a que no se haya roto nada más.

He visto equios que deciden "ahorrar" en QA temprano y después gastan el triple apagando incendios antes del lanzamiento.
O peor, lanzan con bugs críticos, pierden users en los primeros días, y después tienen que hacer parches de emergencia mientras las reviews negativas ya están ahí para siempre📉.

QA temprano no es un gasto, es evitar un riesgo mucho mayor después.
Cuando trabajás con QA desde el inicio Detectás problemas cuando todavía son baratos de arreglar. Tenés tiempo para iterar sin presión. El equipo puede enfocarse en features, no en apagar incendios. Y claramente, llegás al lanzamiento tranquilo, no desesperado✨.

El problema no es "tener presupuesto", es entender que postergar QA no lo hace más barato, lo hace exponencialmente más caro.

Si estás desarrollando un juego y venís postergando QA porque "todavía no es el momento", escribime "TEMPRANO" por privado y coordinamos una llamada corta para ver cómo encajarlo sin romper tu presupuesto.
¿Alguna vez postergaste QA y después te arrepentiste?

19/03/2026

🎮Una de las cosas más raras de trabajar como QA. A veces tenés que testear juegos que personalmente no jugarías.

Y eso es algo que nadie te cuenta cuando empezás. Cualquiera podría pensar que trabajar en QA significaba jugar todo el día los juegos que te encantan. Y a veces sí, tengo la suerte de trabajar en proyectos que me apasionan.
Pero otras veces me toca testear géneros que no me interesan, o mecánicas que no disfruto, estilos visuales que no son lo mío, etc🎨.

Y ahí aprendí algo importante. Ser profesional es testear con la misma calidad sin importar si el juego te gusta o no🛠️.
Porque al final, el jugador que SÍ va a jugar ese juego merece que funcione bien, aunque a vos no te interese.
He visto QAs que testean con menos atención cuando el juego no les engancha. Y eso es un error, ya que bugs no discriminan géneros🐞.
Un bug crítico en un juego que no me apasiona es tan grave como un bug crítico en un juego que amo. El usuario final no sabe (ni le importa) si al QA le gustó testearlo.

Eso me hizo mejor QA.
Aprendí a desconectarme de mis preferencias personales y enfocarme en:
¿Funciona como debería?
¿La experiencia es coherente?
¿Hay algo que rompe la jugabilidad?
¿El usuario objetivo va a disfrutarlo sin fricciones?
Y lo curioso es que a veces, testeando juegos que inicialmente no me interesaban, terminé apreciándolos de otra forma. No como jugador, sino como creación✨.

Entendí el trabajo que hay detrás. La complejidad de balancear mecánicas. El esfuerzo por hacer que todo encaje🧩.
Ser profesional es eso. Es entregar calidad sin importar si es tu género favorito o no.

¿Les pasa algo similar en sus trabajos? ¿Alguna vez tuvieron que hacer algo con excelencia aunque personalmente no les apasionara?

17/03/2026

👥¿Los amigos son usuarios?

"Le pedí a mis amigos que probaran el juego y no encontraron nada grave". Escucho esto seguido. Y está bien, es mejor que nada.
Pero hay un problemita, tus amigos no son tus usuarios🎮.
Tus amigos saben que estás trabajando en esto. Saben que es un proyecto en desarrollo, y la mayoría de veces son comprensivos en respuesta. Te van a dar feedback constructivo, podrían ignorar bugs menores, van a decirte "está bueno" porque quieren apoyarte.
Y eso está perfecto, es feedback, pero no es testing real 🔍.

¿Por qué no? Porque cuando lancés, tus usuarios:
No conocen el contexto del proyecto.
No tienen paciencia con bugs técnicos.
No van a ser comprensivos si algo se rompe.
Van a comparar tu juego con TODO lo que jugaron antes.
Van a dejarte un review negativo si la experiencia falla📉.
He visto devs que lanzan demos después de testear solo con amigos, y se sorprenden cuando empiezan a llegar reportes de bugs que "nadie había visto"💥.

¿Por qué nadie los vio?
Porque probablemente quienes lo probaron siguieron el camino "obvio" (el que vos esperabas). No intentaron romper cosas a propósito, te consultaron cuando algo no funcionaba, en vez de abandonar. No jugaron con la mentalidad de "esto me costó dinero"⚡.
Un usuario externo no tiene esa relación con vos. Si algo falla, cierra el juego y te deja un review de 1 estrella🌟.
Por eso el testing con gente cercana sirve para feedback de diseño, pero no reemplaza el testing real con usuarios que no te conocen y que van a ser brutalmente honestos🛠️.

Trabajo con devs justamente en esa etapa. Antes de lanzar, revisar el juego con mentalidad de usuario externo que no tiene paciencia ni contexto. Así detectás lo que tus amigos nunca te van a reportar.

Si estás por lanzar una demo o early access y solo testeaste con gente cercana, escribime "EXTERNO" por privado y coordinamos una llamada corta para ver cómo cubrir esa brecha.

12/03/2026

🎮Hay una diferencia enorme entre un juego que "funciona" y un juego que "se siente bien"

Un juego puede tener cero bugs, todas las mecánicas implementadas, progresión balanceada, y seguir sintiéndose vacío.

¿Por qué? Porque la funcionalidad y la experiencia no son lo mismo✨.
Por ejemplo, he visto proyectos donde el personaje salta correctamente, la física funciona, las colisiones están bien y no hay bugs, pero se siente pesado. El jugador salta y siente que el personaje está bajo el agua🌊.
O juegos donde el combate técnicamente responde bien, pero le falta impacto. Golpeás a un enemigo y no hay feedback visual, no hay sonido satisfactorio, no hay screen shake, o directamente no se siente esa respuesta para con el jugador. Funciona, pero no se siente poderoso.
Eso claramente no es un bug, es diseño🎨.

Y la verdad es que muchos de esos problemas pueden detectarse en QA, no solo en diseño.
Cuando testeo un juego, no solo busco si algo se rompe, sino que también busco si algo se siente raro. Si el movimiento no fluye, o si el feedback es confuso. Incluso si la curva de dificultad frustra sin razón⚡.
A veces reporto cosas que técnicamente no son bugs, pero que arruinan la experiencia igual, y he visto equipos que ignoran eso porque "técnicamente funciona". Sin embargo, cuando lanzan, los jugadores se quejan, y expresan que el juego "se siente mal".

La diferencia entre un juego que funciona y uno que se siente bien es uno de esos elementos que separa a las buenas reviews de las malas⭐.
De ahi el por qué cuando trabajo con equipos no solo testeo funcionalidad, testeo experiencia pura. Porque al final, eso es lo que el jugador recuerda 🧠.

¿Alguna vez jugaste algo que técnicamente funcionaba bien pero se sentía mal? ¿O al revés, algo con bugs pero que igual se sentía increíble?

10/03/2026

🤔¿Este bug es prioridad ahora?

Hace un tiempo trabajé con un equipo que tenía un bug de colisión en una zona específica del mapa. No era critico ni rompía el juego, y solo ocurría si el jugador hacía una secuencia particular de movimientos.

Lo reporté, y me dijeron: "Lo sabemos, pero tenemos cosas más importantes ahora, lo arreglamos antes del lanzamiento".
Pasaron semanas, agregaron features nuevas, modificaron mecánicas y ajustaron valores🛠️.
Y el bug seguía ahí, esperando⏰.

Tres semanas antes del lanzamiento, hicieron un playtest público, y pasó lo inevitable. Un jugador encontró ese bug y lo compartió en redes.
Pero no era solo el bug de colisión, sino que ahora por la forma en que habían modificado otras mecánicas, ese bug permitía salir del mapa completamente y romper progresión💥.

Lo que hace un mes era "un detalle menor" ahora era un bug crítico que bloqueaba avance. Arreglarlo requería tocar código que se había modificado varias veces desde que lo reporté.
Lo que hubiera tomado 20 minutos arreglar en la semana 2, ahora tomó 3 días en la semana 10.
Por suerte estaban a tiempo. Pero si ese playtest público hubiera sido dos semanas después, habrían lanzado con ese problema🚨.
La lección no es "arreglá todo de inmediato", sino no dejes bugs conocidos sin evaluar cómo pueden evolucionar, ya que los bugs no se quedan quietos. Interactúan con el código nuevo, se multiplican y se vuelven más caros💸.

Esa es la razón por la cual, cuando trabajo con equipos, no solo reporto bugs. También marco cuáles tienen riesgo de volverse críticos si se ignoran, aunque hoy parezcan menores.
Si estás desarrollando un juego y querés evitar que bugs "menores" te exploten semanas antes del lanzamiento, escribime "RIESGO" por privado y lo vemos en detalle.

¿Te pasó alguna vez que un bug que parecía menor se volvió crítico después?

05/03/2026

❌¿El error más grande al priorizar bugs? arreglar los más fáciles primero.

Parece lógico, tenés 20 bugs en la lista. Algunos son complejos, otros son rápidos. Entonces arrancás por los rápidos "para avanzar".
El problema viene cuando los bugs fáciles de arreglar no son necesariamente los que más daño hacen.
He llegado a ver equipos que pasaron días arreglando bugs visuales menores (un texto mal alineado, un color incorrecto) mientras tenían bugs de gameplay críticos sin tocar🎮.

¿Por qué? Porque los bugs visuales tomaban 5 minutos cada uno, y daba la sensación de "progreso". Mientras que el bug de gameplay requería revisar lógica de combate, y nadie quería meterse en eso🔍.
Pero cuando llegó el lanzamiento, los bugs que explotaron fueron los de gameplay🔥.

Los jugadores no se quejaron del texto mal alineado, sino de que el sistema de combate no respondía bien. Eso generó refunds, reviews negativas, y pérdida de confianza📉.
La prioridad no debería ser "qué tan rápido lo arreglo", sino "qué tan grave es si no lo arreglo"⏰.

Por eso cuando trabajo con equipos, lo primero que hago es categorizar bugs según impacto real.
¿Rompe funcionalidad core, impide progreso o crashea/freezea? Crítico🔴
¿Es visible y no afecta al gameplay, o lo afecta en menor medida? Medio🟡
¿Es cosmético y pasa desapercibido o es muy rebuscado? Bajo🟢
Y claro que hay grises en el medio, eso siempre se evalúa.
Lo importante mas que arreglar todo, es arreglar lo fundamental antes de que sea tarde 🛠️.

No esperás a que se hunda el barco para arreglar el agujero más grande, solo porque el más chico era más fácil de tapar🚢.

¿Alguna vez priorizaste mal un bug y después te arrepentiste? Contame en comentarios.

03/03/2026

🧠Un desarrollador no puede testear su propio juego sin sesgos.

No es porque no sepa testear claro, sino que es porque conoce demasiado.
Cuando vos creaste el código, sabes cómo "debería" funcionar. Sabes que inputs espera el sistema, qué secuencia de acciones es la "correcta", que mecánicas están diseñadas para interactuar de cierta forma🕹️.
Entonces, cuando testeas, probás eso. Probás lo que sabes que funciona✅.
Pero el jugador no sabe nada de eso. El jugador hace cosas "raras". Clickea donde no debería, salta antes de lo esperado, ataca mientras carga otra acción, intenta usar un ítem en un contexto que nunca planeaste🎮.

Y ahí es donde aparecen los bugs🐞.
No porque el código esté mal, sino porque el código no esperaba ese comportamiento💥.
Trabajé con equipos donde el dev me decía "pero eso nunca debería pasar". Y tenía razón, no debería, pero pasa🔍.
Por eso mi trabajo como QA externo no es confirmar que lo que vos hiciste funciona, es buscar activamente las formas en que podría romperse🛠️.

Testeo como alguien que:
No conoce el código.
No sabe cómo "debería" jugarse.
Hace cosas impredecibles.
No tiene contexto de diseño.
Eso es lo que un developer no puede hacer solo, por más que lo intente🚧.
Cuando conocés el sistema por dentro, perdés la capacidad de verlo desde afuera. Es inevitable, completamente humano🧩.

Si estás desarrollando un juego y querés que alguien lo pruebe sin los sesgos de conocer el código, escribeme "EXTERNO" por privado y lo coordinamos bien.
¿Alguna vez encontraste un bug en tu juego que te sorprendió porque "nunca debería haber pasado"? Contame en comentarios!

Dirección

Buenos Aires

Página web

Notificaciones

Sé el primero en enterarse y déjanos enviarle un correo electrónico cuando Ezequiel Canello publique noticias y promociones. Su dirección de correo electrónico no se utilizará para ningún otro fin, y puede darse de baja en cualquier momento.

Atajos

Compartir

Categoría