Hay una pregunta sencilla que en una entrevista en un estudio de slots delata de inmediato si alguien ha probado juegos: «Al jugador se le cae internet justo cuando giran los rodillos. ¿Qué debe pasar?»

La respuesta correcta: nada grave. La ronda ya está calculada en el servidor y, al volver, el jugador debe ver el mismo resultado y recibir el mismo dinero. Comprobar ese escenario es de lo primero que aprende un QA nuevo en slots, y de lo que no aparece en ningún curso de testing.

En qué se diferencia realmente del QA habitual

Formalmente las herramientas son las mismas: casos de prueba, Jira, Playwright, Postman, SQL. La diferencia está en el coste del error y en qué se considera un bug.

En un producto normal, un bug es que el usuario no pueda completar una acción. En un slot, un bug es que el dinero se calcule de forma distinta a lo prometido en las reglas del juego, o que el resultado de la ronda no se pueda reproducir. Lo primero cuesta pagos y reputación; lo segundo, un rechazo del laboratorio de certificación y semanas de retraso en el lanzamiento.

AspectoQA habitualQA de slots
Qué se compruebala función y la UIel dinero y el resultado de la ronda
Fuente de verdadlos requisitos de productomodelo matemático + reglas del juego
Aceptaciónrelease managerlaboratorio externo
Coste de un bug no detectadohotfixpagos y riesgo de licencia
Regresiónantes del lanzamientopor cada jurisdicción

De ahí el gran cambio de mentalidad. El QA de slots pulsa menos botones y concilia más números: el saldo antes y después del giro, el registro en el historial de rondas, la transacción del monedero y el log del servidor: todo debe cuadrar al céntimo.

Qué prueba en concreto un ingeniero de QA en un estudio

  • La ronda de juego y su recuperación. Corte de conexión, pestaña cerrada, móvil sin batería en mitad del juego bonus. La prueba clásica es matar la sesión en cada fase de la ronda y comprobar que el estado se recupera al volver.
  • Los cálculos y la tabla de pagos. Cada línea ganadora, cada multiplicador, todas las combinaciones extremas. Se contrasta con el documento del matemático, no con un «a ojo parece bien».
  • Las mecánicas de bonus. Giros gratis, compra de bonus, funciones acumulativas, botes. Aquí vive más de la mitad de los bugs: el estado se acumula entre giros y la lógica se rompe en transiciones atípicas.
  • El monedero y los límites. Apuesta superior al saldo, sesión paralela en dos pestañas, transacción cancelada del lado de la plataforma, divisas con decimales.
  • El juego responsable. Límites de depósito y apuesta, pausas, autoexclusión, avisos obligatorios de tiempo de juego. En algunas jurisdicciones son requisitos bloqueantes con su propia checklist: la misma lógica que en el departamento de cumplimiento del operador, pero a nivel del código del juego.
  • Las localizaciones y las divisas. Un mismo juego sale en 15–30 idiomas. Se revisa no solo la traducción, sino el texto cortado, los formatos numéricos y a veces palabras y símbolos prohibidos en un país concreto.
  • La compatibilidad. A los slots se juega sobre todo desde el móvil, a menudo uno flojo y con mala red: la matriz de dispositivos es aquí más larga que en productos corporativos.
La diferencia clave con el gamedev fuera del gambling: en un juego casual, un bug de saldo se arregla con un parche en el siguiente sprint. En un slot ya en producción, ese mismo bug significa recalcular pagos a jugadores concretos, un informe al regulador y una explicación con el operador que puso el juego en su sitio.

Certificación: lo que no existe en otro QA

Antes de llegar a las webs de los operadores, el juego lo revisa un laboratorio independiente: GLI, BMM, eCOGRA, iTech Labs. Verifican el generador de números aleatorios, que el RTP real coincida con el declarado, el comportamiento ante fallos y el cumplimiento de las reglas de cada jurisdicción.

El QA es quien prepara la build y el paquete documental para esa revisión: descripción de mecánicas, reglas del juego, informes de ejecución, pruebas de que la ronda se recupera. Un rechazo del laboratorio cuesta dinero al estudio y desbarata el calendario de lanzamientos, por eso «cuántas certificaciones pasaron a la primera» es un KPI real que te citarán en la entrevista.

Dificultad aparte: el mismo juego se compila distinto para cada mercado. En un sitio está prohibida la compra de bonus, en otro hay tope de apuesta máxima, en otro es obligatorio un temporizador de sesión. La regresión no se ejecuta una vez, sino tantas como jurisdicciones haya: por eso los estudios valoran tanto a los automatizadores.

Un día en la vida

09:30Ejecución nocturna de pruebas automáticas: revisar los fallos y separar defectos reales de tests flaky.
11:00Nueva función bonus en pruebas: ejecutar escenarios de desconexión en cada fase y conciliar pagos con el modelo matemático.
13:30Llamada con desarrollo y el matemático: desviación del 0,3 % entre el RTP calculado y el real en una ejecución larga.
15:00Revisión de localizaciones antes de lanzar en un mercado nuevo: texto cortado, formato de divisa, límites de la jurisdicción.
17:00Terminar las pruebas automáticas de las nuevas líneas de pago y montar el paquete para el laboratorio de certificación.

Qué hay que saber hacer

  1. Diseño de pruebas. La habilidad básica, aquí más importante que las herramientas: un juego es una máquina de estados con dinero dentro, y hay que cubrirla de forma sistemática, no al azar.
  2. SQL. La mitad de las comprobaciones son una consulta a la base de datos: si cuadra la transacción, qué se registró en el historial de rondas, si coincide el saldo.
  3. Pruebas de API. El cliente del juego solo dibuja; toda la verdad está en las respuestas del servidor, así que Postman y REST son herramientas diarias.
  4. Automatización. Playwright, Cypress o Selenium en la UI más la capa de API. Son los automatizadores quienes cobran un grado más que los testers manuales.
  5. Nociones básicas de probabilidad. No hace falta ser matemático de juegos, pero sí distinguir una desviación estadística en una serie corta de un bug real de cálculo.
  6. Inglés B1+. La documentación de los laboratorios, la comunicación con el operador y las especificaciones internas están en inglés.

Cuánto se paga a un QA en iGaming

Las horquillas son sueldo fijo neto mensual, según la sección de profesiones y salarios de SpinHire. «Malta / Chipre» son equipos de oficina e híbridos de estudios y operadores; «UE», Polonia, Rumanía y el Báltico; «remoto», Tiflis, Ereván, Kiev y equipos totalmente distribuidos.

NivelMalta / ChipreUERemoto
Junior€1.9–2.6K€1.3–1.9K€1–1.6K
Middle€3–4.2K€2.3–3.3K€2–3K
Senior€4.5–6K€3.6–4.8K€3.2–4.5K
QA Lead€6.5–9K€5.2–7K€4.8–6.5K

El bono anual en QA es más modesto que en marketing: normalmente un 5–12 % de la base anual, a veces primas por lanzamiento en estudios. A cambio, la horquilla es estable y apenas depende de si el mes le fue bien al operador, a diferencia de un media buyer con porcentaje del beneficio.

Lo que de verdad sube la horquilla: la automatización (+20–35 % sobre el grado manual en igualdad de condiciones), la experiencia acompañando certificaciones y entender la parte de pagos. Para comparar, un desarrollador backend de plataforma del mismo grado cuesta alrededor de un tercio más: una referencia razonable si planeas pasarte a desarrollo.

Cómo entrar en la profesión

El QA manual es una de las puertas de entrada más accesibles al iGaming, al nivel del soporte. Estudios y plataformas contratan con frecuencia a testers sin experiencia en gambling, porque el conocimiento del dominio sí se aprende en un par de meses, pero la meticulosidad no.

  1. Desde el QA de cualquier otro sector. La ruta más habitual, normalmente sin perder grado. Fintech y e-commerce se valoran especialmente: ya existe el hábito de manejar dinero en el sistema y de la idempotencia.
  2. Desde el gamedev fuera del gambling. La comprensión de las mecánicas de juego y de la matriz de dispositivos ya está; queda aprender RTP, certificación y requisitos de las jurisdicciones.
  3. Desde cero al testing manual de juegos. Una vía real pero estrecha: la competencia por los puestos junior es alta y se pide inglés, cuidado y saber describir un bug con claridad. Otras vías de entrada están detalladas en el artículo sobre entrar en el iGaming sin experiencia.
  4. Desde el soporte, dentro de la propia empresa. El agente de soporte ve los bugs el primero y conoce el producto mejor que muchos. El salto interno a QA tras un año es una historia corriente en los operadores.

Qué poner en el CV: tipos de producto que has probado, herramientas de automatización con el stack concreto, nivel de SQL, experiencia con cálculos de pagos o financieros. Si no hay gambling en tu trayectoria, escribe sin rodeos qué escenarios con dinero probaste en el producto anterior. Eso convierte en entrevista mejor que un certificado ISTQB.

Hacia dónde crecer

La vertical es corta: QA → Senior QA → QA Lead → QA Manager / Head of Quality. Después, o diriges la calidad de todo el estudio o te pasas a roles adyacentes.

Las rutas horizontales desde QA funcionan mejor en iGaming que en la mayoría de sectores, porque el tester toca todo a la vez: producto, pagos, matemáticas y requisitos regulatorios. Los saltos más frecuentes son a desarrollo vía automatización, a product management, a analítica y a cumplimiento.

Lo último no es obvio, pero es lógico: quien ha pasado años probando límites de juego responsable ya conoce la mitad del trabajo del departamento de cumplimiento.

Las vacantes abiertas en estudios y plataformas están en la sección de desarrollo de juegos, y la ficha completa de la profesión con funciones, KPI y herramientas está en la página del ingeniero de QA. Todas las ofertas del sector con horquilla publicada están en el board de SpinHire.