Iniciar sesión
PapaHR · Mike Pritula Academy · Puestos

Ingeniero de QA (Tester de Software): perfil, KPI y preguntas de entrevista

El aseguramiento de la calidad (QA, del inglés Quality Assurance) ayuda a detectar fallos antes de que perjudiquen a los clientes. Aquí encontrará el perfil del puesto, indicadores clave de rendimiento (KPI), preguntas de selección y un plan para los primeros tres meses.

Crear un perfil para tu empresa Abrir en PapaHR gratis →

Perfiles de puesto, contratación, incorporación y evaluación en PapaHR. Gratis para hasta 25 empleados.

  1. Usa el perfil de abajo o crea el tuyo con el creador de perfiles.
  2. En PapaHR, el perfil se convierte en un anuncio de empleo, un plan de incorporación y objetivos para el periodo de prueba.
  3. A los 90 días, evalúa a la persona con los mismos KPI y competencias.

Perfil del puesto

Para qué existe el puesto

Detectar riesgos y defectos antes del lanzamiento, reduciendo pérdidas de clientes y costes de corrección.

Resultado al cabo de un año

Los recorridos críticos de los clientes cuentan con pruebas actualizadas, los defectos se reproducen siguiendo sus informes y cada lanzamiento tiene resultados y riesgos pendientes claros.

Lugar en la estructura

  1. Depende deAl responsable de desarrollo o de pruebas, si existe ese puesto.
  2. Personal a cargoNinguno.
  3. Trabaja conDesarrolladores: investigar defectos y verificar correcciones., Responsable de Producto: aclarar comportamientos esperados e impacto en clientes., Responsable de Proyectos: acordar plazos de pruebas y lanzamiento., Atención al Cliente: comprender fallos reportados y sus condiciones., Diseñador: revisar estados de interfaz y mensajes de error.
Áreas clave de resultados
  1. Recorridos críticos de clientes cubiertos por pruebas — Cumplimiento del plan de cobertura de escenarios críticos100% de los escenarios críticos acordados con pruebas actualizadas.
  2. Pruebas terminadas en el plazo acordado — Cumplimiento del plan de pruebas del lanzamiento100% de las pruebas previstas terminadas a tiempo.
  3. Defectos reproducibles a partir de sus informes — Informes de defectos reproducibles100% de los informes revisados permiten reproducir el defecto.
  4. Correcciones confirmadas mediante nuevas pruebas — Correcciones verificadas a tiempo100% de las correcciones disponibles verificadas en el plazo acordado.
  5. Riesgos del lanzamiento claros para el equipo — Cumplimiento del plan de informes de preparación del lanzamiento100% de las versiones con informe completo antes de decidir el lanzamiento.
  6. Versiones que mantienen operativas las funciones críticas — Versiones sin defectos críticos100% de las versiones observadas sin defectos críticos.
Requisitos

Experiencia: Experiencia en pruebas manuales web, desde requisitos hasta verificar correcciones.

Requisitos formales: Titulación específica opcional; presentar muestras claras de pruebas e informes.

Debe saber

  • Etapas del desarrollo y papel de las pruebas en los lanzamientos.
  • Valores límite y agrupación de entradas en clases de equivalencia.
  • Repetición de pruebas y pruebas de regresión de funciones existentes.
  • Interfaces de programación de aplicaciones (API) y verificación de respuestas.
  • Lenguaje de Consulta Estructurada (SQL) para leer datos.
  • Diferencia entre gravedad del defecto y prioridad de corrección.

Debe saber hacer

  • Convertir requisitos en escenarios comprobables.
  • Detectar ambigüedades antes de empezar las pruebas.
  • Registrar condiciones de los defectos y reunir evidencias.
  • Leer mensajes del navegador y respuestas de interfaces de aplicaciones.
  • Elegir pruebas según el riesgo y el tiempo disponible.
  • Explicar las consecuencias del defecto en términos de negocio.
Competencias en tres niveles

Análisis de requisitos y escenarios

Detecta lagunas en el comportamiento del producto antes de generar costes de corrección.

  1. Prueba el recorrido principal siguiendo la documentación y pregunta por condiciones poco claras.básico
  2. Identifica límites, datos inválidos, estados y dependencias entre funciones.intermedio
  3. Detecta requisitos contradictorios y ayuda al equipo a acordar resultados comprobables.avanzado

Priorización de pruebas según riesgos

Concentra el tiempo disponible en fallos que amenazan pagos, datos y actividades de clientes.

  1. Empieza por escenarios críticos acordados y avisa si falta tiempo.básico
  2. Reordena las pruebas según el impacto del defecto y las funciones afectadas.intermedio
  3. Propone el alcance de pruebas del lanzamiento y explica los riesgos restantes.avanzado

Investigación e informes de defectos

Reduce el tiempo del desarrollador dedicado a aclaraciones y nuevas búsquedas del problema.

  1. Registra pasos, datos, versión del producto y fallo observado.básico
  2. Acota las condiciones de reproducción y adjunta mensajes útiles del sistema.intermedio
  3. Encuentra patrones en fallos intermitentes y distingue defectos del producto de problemas del entorno.avanzado

Organización de las pruebas

Permite conocer la preparación real del lanzamiento y repetir las pruebas importantes.

  1. Registra cada resultado y distingue pruebas no ejecutadas de pruebas superadas.básico
  2. Actualiza pruebas tras cambios y comprueba efectos de correcciones en funciones relacionadas.intermedio
  3. Elimina pruebas obsoletas, cierra lagunas y presenta resultados claros al equipo.avanzado

Comunicación sobre calidad

Apoya decisiones de lanzamiento con hechos y consecuencias para clientes.

  1. Describe problemas con calma y separa observaciones de suposiciones.básico
  2. Justifica la importancia del defecto por su impacto en clientes y debate posibles acciones.intermedio
  3. Resuelve desacuerdos sobre lanzamientos registrando decisiones, responsables y riesgos aceptados.avanzado

Mejora del proceso de pruebas

Previene defectos recurrentes y reduce tareas manuales poco útiles.

  1. Analiza un defecto no detectado y añade la prueba correspondiente.básico
  2. Detecta causas recurrentes de fallos no encontrados y propone cambios del proceso.intermedio
  3. Mide mejoras por tiempo y defectos no detectados, y comparte soluciones eficaces.avanzado
Creador de perfiles

Crea un perfil para tu empresa

Marca lo que hace esta persona en tu empresa. A la derecha verás el perfil listo: cópialo o ábrelo en PapaHR.

Ingeniero de QA (Tester de Software)

Detectar riesgos y defectos antes del lanzamiento, reduciendo pérdidas de clientes y costes de corrección.

Funciones
  1. Aclarar el comportamiento esperado de las funciones antes del desarrollo.
  2. Identificar fallos que interrumpan el trabajo del cliente o pagos.
  3. Crear listas de pruebas para funciones nuevas y cambios relacionados.
  4. Preparar datos de prueba y comprobar el entorno.
  5. Probar la interfaz y el intercambio de datos entre aplicaciones.
  6. Verificar valores límite, entradas inválidas y permisos de acceso.
  7. Documentar defectos con pasos, condiciones, resultados esperados y reales.
  8. Repetir pruebas de correcciones y comprobar funciones relacionadas tras cambios.
  9. Comunicar resultados de pruebas y riesgos antes del lanzamiento.
  10. Añadir pruebas basadas en fallos reportados por clientes.
  11. Automatizar pruebas repetitivas estables cuando se tengan las habilidades necesarias.
  12. Probar el rendimiento con la carga acordada.
  13. Comprobar el uso con teclado y lectores de pantalla.
  14. Probar otros dispositivos y versiones de navegadores.
  15. Contrastar datos tras migraciones entre versiones del sistema.
  16. Revisar traducciones de interfaz, formatos de fechas e importes.
  17. Ayudar a soporte a reproducir fallos intermitentes con datos anonimizados.
Abrir el perfil en PapaHR

KPI del ingeniero de QA

  1. Cumplimiento del plan de cobertura de escenarios críticos — Escenarios críticos con pruebas actualizadas / escenarios previstos × 100%. Error: Considerar una lista de pruebas como evidencia de ejecución.peso 20% · mes
  2. Cumplimiento del plan de pruebas del lanzamiento — Pruebas terminadas a tiempo / pruebas previstas × 100%. Error: Contar pruebas bloqueadas como superadas.peso 20% · mes
  3. Informes de defectos reproducibles — Informes reproducibles / informes revisados × 100%. Error: Excluir defectos complejos de la evaluación para mejorar el indicador.peso 15% · mes
  4. Correcciones verificadas a tiempo — Correcciones verificadas puntualmente / correcciones previstas para verificación × 100%. Error: Contar correcciones como verificadas sin repetir las pruebas.peso 15% · mes
  5. Cumplimiento del plan de informes de preparación del lanzamiento — Informes completos antes de decidir / informes previstos × 100%. Error: Considerar completo un informe sin escenarios no probados ni riesgos pendientes.peso 10% · mes
  6. Versiones sin defectos críticos — Versiones sin defectos críticos / versiones en ventana de observación × 100%. Error: Evaluar solo al tester u ocultar defectos para proteger el indicador.peso 20% · trimestre
Calculadora

Calcula la bonificación por KPI

Introduce el porcentaje de cumplimiento de cada indicador y el importe de la bonificación al 100%. Puedes cambiar los pesos.

IndicadorPeso, %Cumplimiento, %Contribución
Cumplimiento del plan de cobertura de escenarios críticos
Cumplimiento del plan de pruebas del lanzamiento
Informes de defectos reproducibles
Correcciones verificadas a tiempo
Cumplimiento del plan de informes de preparación del lanzamiento
Versiones sin defectos críticos
Resultado de los KPI
Bonificación
Suma de pesos

Los pesos del ejemplo son una referencia. Deben sumar el 100%.

Preguntas para la entrevista

Ficha de evaluación

Haz la entrevista y obtén el resultado

Puntúa cada respuesta del 1 al 5: el resultado se calculará por competencias. Puedes mantener esta página abierta en el móvil durante la entrevista.

Análisis de requisitos y escenarios

Describa un requisito ambiguo: ¿qué aclaró, qué pruebas eligió y qué cambió?

✓ Qué buscar en la respuesta: Ambigüedad concreta, preguntas propias, comportamiento acordado y resultado de las pruebas.

⚑ Señal de alerta: Probó suposiciones sin acordar el comportamiento esperado.

Describa un defecto en valores límite: ¿cómo eligió los datos, encontró el problema y verificó la corrección?

✓ Qué buscar en la respuesta: Elección razonada de valores, diferencia observada y repetición de la prueba.

⚑ Señal de alerta: Cita términos, pero no puede explicar sus propias acciones.

Priorización de pruebas según riesgos

Recuerde un lanzamiento sin tiempo para todas las pruebas: ¿qué priorizó y cómo comunicó el riesgo restante?

✓ Qué buscar en la respuesta: Prioridad por daño al cliente, lagunas explícitas y decisión acordada.

⚑ Señal de alerta: Eligió solo pruebas rápidas y no informó sobre las demás.

¿Cuándo cambió el plan de pruebas por información nueva? ¿Qué revisó y cuál fue el resultado?

✓ Qué buscar en la respuesta: Datos nuevos, relación con riesgos, pruebas revisadas y resultado observado.

⚑ Señal de alerta: Mantuvo el plan pese a conocer una amenaza para una función crítica.

Investigación e informes de defectos

Describa un defecto que el desarrollador no pudo reproducir inicialmente: ¿qué investigó, añadió al informe y consiguió?

✓ Qué buscar en la respuesta: Comprobación de entorno, datos y versión, pasos claros y reproducción confirmada.

⚑ Señal de alerta: Insistió en que existía el defecto sin aportar condiciones ni evidencias adicionales.

Recuerde un fallo intermitente: ¿cómo reunió hechos, acotó condiciones y entregó los resultados al desarrollador?

✓ Qué buscar en la respuesta: Hipótesis sucesivas, condiciones comprobadas y evidencias útiles.

⚑ Señal de alerta: Presentó una causa supuesta como un hecho probado.

Organización de las pruebas

Describa una corrección que afectó a otra función: ¿qué pruebas añadió y cómo confirmó el resultado?

✓ Qué buscar en la respuesta: Dependencias entre funciones, escenarios adicionales y resultados registrados.

⚑ Señal de alerta: Solo comprobó el defecto original pese a conocer cambios relacionados.

Recuerde un conjunto de pruebas desactualizado: ¿cómo lo revisó y qué mejoró para el equipo?

✓ Qué buscar en la respuesta: Eliminación de tareas innecesarias, cierre de lagunas y mantenimiento claro.

⚑ Señal de alerta: Añadió elementos sin resolver contradicciones ni duplicados.

Comunicación sobre calidad

Describa un desacuerdo sobre la gravedad de un defecto: ¿qué hechos aportó, qué decidieron y qué ocurrió tras el lanzamiento?

✓ Qué buscar en la respuesta: Impacto en clientes, argumentos de ambas partes, decisión registrada y resultado.

⚑ Señal de alerta: Recurrió al cargo o la autoridad en lugar de explicar consecuencias.

Recuerde un lanzamiento con un defecto conocido: ¿cómo explicó el riesgo, identificó al responsable de decidir y siguió las consecuencias?

✓ Qué buscar en la respuesta: Limitación clara, responsable de decidir, plan de corrección y seguimiento.

⚑ Señal de alerta: Ocultó el defecto o asumió toda la responsabilidad de decidir el lanzamiento.

Mejora del proceso de pruebas

Describa un defecto que llegó al cliente: ¿qué cambió en las pruebas y cómo evaluó el beneficio?

✓ Qué buscar en la respuesta: Causa de la omisión, cambio concreto y comprobación de su aplicación.

⚑ Señal de alerta: Buscó culpables y solo prometió prestar más atención.

Recuerde una prueba manual repetitiva que mejoró: ¿qué hizo personalmente y cómo cambiaron el tiempo o la fiabilidad?

✓ Qué buscar en la respuesta: Problema inicial, acciones propias y comparación del antes y después.

⚑ Señal de alerta: Automatizó un escenario inestable sin evaluar beneficios ni costes de mantenimiento.

Puntúa al menos una respuesta para ver aquí el resultado. ·
Gestionar candidatos en PapaHR

Prueba práctica

Probar la finalización de compra en un entorno de práctica · 2 horas

Facilite un entorno de práctica, una cuenta de prueba y una descripción breve de la finalización de compra. Reglas del ejercicio: la cantidad debe ser un entero positivo; el descuento solo se aplica al cumplirse la condición indicada; pulsar dos veces no debe crear un segundo pedido. La persona candidata enumera las pruebas, prioriza los mayores riesgos, ejecuta las pruebas disponibles y documenta los defectos encontrados. Al final entrega un informe breve sobre la preparación del lanzamiento con los escenarios no probados. Si no encuentra defectos, bastan los resultados de las pruebas; no debe inventarlos. Use únicamente datos de prueba y pagos simulados. Tras dos horas, entregue el trabajo completado e indique sus limitaciones.

Cómo evaluar

  • Cubre el recorrido principal, límites de cantidad y condiciones del descuento.
  • Las prioridades consideran pedidos duplicados e importes de pago incorrectos.
  • Los informes incluyen pasos, condiciones, resultados esperados y reales.
  • Las conclusiones tienen evidencias; las suposiciones aparecen por separado.
  • Se distinguen pruebas superadas, fallidas y no ejecutadas.
  • El informe explica riesgos del lanzamiento y limitaciones de las pruebas.

Anuncio de empleo listo para usar

Ingeniero de QA (Tester de Software) en [empresa]

Probar [producto], encontrar defectos y explicar riesgos antes del lanzamiento.

Tareas

  • Analizar requisitos y aclarar escenarios ambiguos con el equipo.
  • Probar funciones nuevas, correcciones y partes relacionadas del producto.
  • Documentar defectos para que los desarrolladores puedan reproducirlos.
  • Mantener pruebas de los recorridos principales de los clientes.
  • Probar API y datos dentro del alcance asignado.
  • Informar sobre preparación del lanzamiento y riesgos restantes.

Requisitos

  • Experiencia en pruebas manuales de productos web: [experiencia necesaria].
  • Capacidad para elegir pruebas y explicar sus prioridades.
  • Informes claros y atención a las condiciones de reproducción.
  • Práctica en pruebas de API y lectura de datos mediante SQL.
  • Capacidad para debatir defectos con desarrolladores sin buscar culpables.
  • Se valorará automatización si resulta necesaria en [equipo].

Qué ofrecemos

  • Salario: [salario] dólares estadounidenses; condiciones de revisión: [condiciones].
  • Modalidad: [remoto/presencial/híbrido]; ciudad: [ciudad].
  • Horario: [horario]; zona horaria de trabajo: [zona horaria].
  • Equipo: [composición]; responsable: [puesto del responsable].
  • Equipamiento y acceso al entorno de pruebas: [condiciones].
  • Formación y desarrollo de habilidades de pruebas: [condiciones].

En PapaHR, este texto se convierte en una vacante con una página de empleo y un embudo de candidatos.

Plan de incorporación de 90 días

Antes del primer día

  1. Coordinar incorporación con recursos humanos y tecnología de la información.RRHH
  2. Preparar entorno de pruebas, cuentas y permisos mínimos necesarios.TI
  3. Elegir la primera función para probar y asignar un mentor.Responsable
  4. Preparar documentación, defectos conocidos y próximos cambios.Mentor

Primer día

  1. Mostrar recorridos críticos de clientes y consecuencias de los fallos.Responsable
  2. Explicar el recorrido desde el requisito hasta el lanzamiento.Mentor
  3. Comprobar accesos y ejecutar el recorrido principal en pruebas.Nuevo empleado
  4. Acordar criterios de defecto crítico y procedimiento de aviso.Responsable

Primera semana

  1. Crear pruebas de la primera función y registrar dudas sobre requisitos.Nuevo empleado
  2. Revisar cobertura y calidad del primer informe de defecto.Mentor
  3. Volver a probar una corrección con el mentor.Nuevo empleado
  4. Acordar objetivos del periodo de prueba y cálculo de indicadores.Responsable

30 días

  1. Probar un cambio del área asignada con autonomía.Nuevo empleado
  2. Resumir resultados, defectos pendientes y escenarios no probados.Nuevo empleado
  3. Reproducir defectos documentados sin indicaciones verbales.Mentor
  4. Revisar dificultades con el entorno, requisitos y colaboración con desarrolladores.Responsable

60 días

  1. Actualizar pruebas de escenarios críticos del área asignada.Nuevo empleado
  2. Ejecutar pruebas del lanzamiento y acordar los riesgos restantes.Nuevo empleado
  3. Analizar un defecto de cliente y añadir una prueba preventiva.Nuevo empleado
  4. Evaluar autonomía y prioridades en cambios reales.Responsable

90 días

  1. Completar el ciclo de pruebas de un cambio sin acompañamiento.Nuevo empleado
  2. Presentar resultados de objetivos y limitaciones pendientes del entorno.Nuevo empleado
  3. Comprobar el beneficio de una mejora del proceso de pruebas.Responsable
  4. Debatir resultados del periodo de prueba y próxima área de responsabilidad.Responsable

Objetivos para el periodo de prueba

  1. Dominar el ciclo completo de pruebas de un cambio.Antes del día 90, completar un ciclo con autonomía: requisitos, pruebas, defectos, correcciones e informe.
  2. Preparar pruebas de los recorridos críticos de clientes.Antes del día 60, documentar y ejecutar todos los escenarios críticos acordados del área asignada.
  3. Documentar defectos sin perder las condiciones de reproducción.Antes del día 60, el mentor reproduce tres defectos seleccionados siguiendo los informes, sin aclaraciones verbales.
  4. Eliminar una laguna recurrente en las pruebas.Antes del día 90, implantar una mejora acordada y demostrar su uso en el siguiente cambio.

Trayectoria profesional

Tester de Software Júnior

Prueba cambios limitados con un mentor y aprende a documentar defectos y aclarar dudas.

Para avanzar: Probar una función con autonomía y explicar los escenarios elegidos y sus riesgos.

Ingeniero de QA

Asume las pruebas de un área del producto, aclara requisitos e informa sobre su preparación.

Para avanzar: Planificar pruebas entre funciones, analizar omisiones y apoyar a compañeros con menos experiencia.

Ingeniero de QA Sénior

Dirige pruebas de cambios complejos, mejora métodos y selecciona oportunidades de automatización.

Para avanzar: Demostrar coordinación de pruebas, mentoría y acuerdo de prioridades entre equipos.

Responsable de QA

Reparte tareas, desarrolla al equipo y acuerda recursos para gestionar riesgos de calidad.

Para avanzar: Ampliar la responsabilidad de calidad a varios productos cuando lo necesite la empresa.

Preguntas para la reunión 1:1

  1. ¿Qué recorridos críticos de clientes necesitan más pruebas?
  2. ¿Qué requisitos le obligan a adivinar el comportamiento esperado?
  3. ¿Qué defectos les cuesta reproducir a los desarrolladores siguiendo sus informes?
  4. ¿Qué impide recibir a tiempo una versión con las correcciones?
  5. ¿Qué riesgo del último lanzamiento deberíamos haber debatido antes?
  6. ¿Qué pruebas repetitivas consumen tiempo sin un beneficio claro?
  7. ¿Qué laguna de las pruebas podemos eliminar en el siguiente cambio?
  8. ¿Qué apoyo necesita para probar una función más compleja con autonomía?

Errores de contratación y gestión

  1. Evaluar al tester por el número de defectos encontrados.
    Cómo hacerlo mejor: Evaluar cobertura de riesgos, calidad de informes e información útil antes del lanzamiento.
  2. Buscar automatización cuando nadie analiza requisitos ni ejecuta pruebas básicas.
    Cómo hacerlo mejor: Definir primero el volumen de pruebas manuales y las tareas concretas de automatización.
  3. Entregar cambios para pruebas justo antes del plazo prometido al cliente.
    Cómo hacerlo mejor: Involucrar al tester en los requisitos y reservar tiempo para correcciones.
  4. Culpar personalmente al tester por cada defecto posterior al lanzamiento.
    Cómo hacerlo mejor: Analizar causas en equipo, considerando cambios y limitaciones de pruebas acordadas.
  5. Asignar una prueba de selección en un producto con pagos reales.
    Cómo hacerlo mejor: Usar un entorno de práctica, datos de prueba y límite de dos horas.
RRHH en dinero

Cuánto cuesta una mala contratación del ingeniero de QA

El mismo cálculo que en la sección «RRHH en dinero» de PapaHR: el costo de selección más el salario de los meses en que el nuevo empleado trabajó a la mitad de su capacidad.

Una salida
Por año

En los primeros meses, un nuevo empleado aporta aproximadamente la mitad del resultado: la otra mitad del salario es lo que la empresa paga por su aprendizaje. En PapaHR, el cálculo se basa en las salidas reales de tu empresa.

Preguntas y respuestas

¿En qué se diferencian un ingeniero de QA y un tester?

Las ofertas suelen usar ambos títulos para el mismo puesto; revise las tareas. Las pruebas comprueban el comportamiento del producto, mientras el aseguramiento de la calidad también abarca requisitos y mejoras del desarrollo. En un equipo pequeño, una persona puede combinar estas actividades.

¿Un ingeniero de QA necesita saber programar?

En pruebas manuales pesan más el análisis de escenarios, la investigación de defectos y los informes claros. Programar es necesario cuando el puesto incluye crear o mantener pruebas automatizadas. Conviene evaluar las pruebas de interfaces y la lectura de datos por separado de la programación.

¿Cómo evaluar a un tester que encuentra pocos defectos?

Revise los riesgos cubiertos y la claridad de los resultados. Pocos defectos pueden indicar un producto estable o pruebas superficiales. Compare los resultados con el plan, la complejidad de los cambios y los reportes de clientes.

¿Quién decide el lanzamiento del producto?

El tester comunica resultados, defectos pendientes y limitaciones. El responsable designado decide considerando el riesgo para clientes y negocio. Defina previamente los criterios que bloquean el lanzamiento y quién toma la decisión.

¿Cómo fijar objetivos de QA en un equipo pequeño?

Empiece por escenarios críticos, plazos de verificación de correcciones y calidad de informes. Acuerde el plan, las reglas de muestreo y la ventana de observación tras el lanzamiento antes del periodo. Evalúe la calidad de las versiones con el equipo; no calcule el indicador si faltan datos.

Contrata, incorpora y evalúa en un solo sistema

PapaHR es gratis para hasta 25 empleados: perfiles de puesto, vacantes, incorporación, objetivos, reuniones 1:1 y evaluaciones.

Abrir el perfil en PapaHR Ya tengo una cuenta

Puestos similares